Archive for the ‘Objective-C’ Category

Some new additions in Objective-C : Nullability

After starting to work at Telestream, I don’t have time to write posts usually here. Actually more correct reason is that I don’t run into some subjects which interest me : Win32/MFC programming? Not doing much here. Here in-house framework is used although it’s written on top of Win32 and Cocoa/Carbon and sometimes I do touch those but not as much as I did before. Also, it’s not interesting to share such information here, because those frameworks/libraries are not used outside of this company.

.NET is not technically interesting or is almost same to Cocoa in its philosophy-wise. So, if I touch one subject in Cocoa, it’s also applicable to .NET or vice versa.

So, I feel like I’m behind of time, because I can’t catch up with their latest and greatest additions and changes.
Sometimes it suddenly makes me feel stupid and retarded. Here is one such thing : Nullability

Apple people nowadays don’t speak out things on fundamental stuffs. They like to speak out new functionality which attracts media journalists’ eyes rather than developers. ( Why are there so many non-developers who anticipates new products at WWDC? ) However to us, developers, this kind of fundamental changes are more interesting.
Here are some good blog posts. Please have your hands wet in them.

객체 소유를 strong으로 할 것이냐 weak으로 할 것이냐? 그 새로운 시작

이미 이 주제에 대해선 몇번 언급을 했다. 그리고 항상 헷갈리고.

더군다나 OS X에선 특정 인터페이스는 strong이나 assign으로만 해야 하는 것도 있고. (ARC가 활성화 되었어도, assign으로!)

OS X에서 iOS 프로그래밍까지 더 하기 시작했을 때, 둘 사이에 이게 달라 무지하게 헷갈렸다. 더군다나 Xcode의 Interface Builder 모듈도 종종 버그도 있고 해서, 그 놈이 기본으로 설정해 주는 것을 믿기도 힘들고.

그래도 다행스러웠던 점은, 애플이 iOS와 Mac OS X간의 차이를 해소하려 했다는 것이다.
이제 스토리보드가 Mac에도 사용되기 시작함으로써, 그 내재된 구조적 차이는 해소되어 가는 것 같다.

자. 이 문제를 갱신해 보자. 요번엔 애플의 문서에 무엇이 top object인지 좀 더 명확한 정의가 내려져 있다. (정말 이전엔 헷갈렸다. 알고 있다가도 또 보면 모르겠고.)

When your program loads a nib file, Cocoa recreates the entire graph of objects you created in Xcode. This object graph includes all of the windows, views, controls, cells, menus, and custom objects found in the nib file. The top-level objects are the subset of these objects that do not have a parent object. The top-level objects typically include only the windows, menubars, and custom controller objects that you add to the nib file. (Objects such as File’s Owner, First Responder, and Application are placeholder objects and not considered top-level objects.)

Resource Programming  Guide : Nib Files
From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should therefore typically be weak, because:

Scroll views inside scroll view

Scroll views inside scroll view

Without creating help files using Doxygen/HeaderDoc, Xcode 5에선 자동으로 Quick Help에 코멘트를 보여줍니다.

“structured comments in your own source code are displayed in the quick help panel and in code completion popover views. Doxygen and HeaderDoc structured comments are supported formats.”

converting frame image data in CVImageBufferRef to PNG

This StackOverflow explains how to convert a video frame image in CVImageBufferRef to PNG through CIImage of Core Image and CGImageRef of Core Graphics.
Of course, it can be also changed to NSImage and do whatever you want there too.
(toll-free bridging between Core* and NS*.. :). But in this case, there are some more chores to do manually. )

Saving NSImage as JPEG ( or anything else)

// Output as JPEG
NSImage *image4 = [[NSImage alloc] initWithSize:NSMakeSize(320.0f, 240.0f)];
[image4 lockFocus];

[[NSColor redColor] setFill];
[[NSColor blueColor] setStroke];

[rectPath setLineWidth:10.0f];
[rectPath stroke];
[rectPath fill];

//        NSArray *representations = [image4 representations];
//        NSData *jpegData = [NSBitmapImageRep representationOfImageRepsInArray:representations
//                                                                    usingType:NSJPEGFileType
//                                                                   properties:[NSDictionary dictionaryWithObjectsAndKeys:@0.8f, NSImageCompressionFactor, nil]];

// Code above doesn't work.
//        (lldb) po representations
//        <__NSArrayI 0x104801d10>(
//                                 <NSCGImageSnapshotRep:0x104802fe0 cgImage=<CGImage 0x104802f00>>
//                                 )
// the presentation doesn't return an appropriate instance of NSImageRep concrete interface.

NSBitmapImageRep *jpegImageRep = [[NSBitmapImageRep alloc] initWithFocusedViewRect:NSMakeRect(0.0f, 0.0f, 320.0f, 240.0f)];
NSData *jpegData = [jpegImageRep representationUsingType:NSJPEGFileType
                                              properties:[NSDictionary dictionaryWithObject:@0.8f forKey:NSImageCompressionFactor]];

[image4 unlockFocus];

[jpegData writeToFile:[NSString stringWithFormat:@"%@/redRectangle-comparison.jpg", desktop]

allocWithZone: Why doesn’t it matter much nowadays.

From StackOverflow : What is difference between alloc and allocWithZone?

Correct. The reality, though, is that pretty much nothing uses zones. It was originally intended to give the ability to, say, co-locate all of the objects related to a document in a zone and then bulk destroy them by simply deallocating the zone. In practice, this proved unworkable and zones haven’t been used in more than a decade in the OpenStep APIs.

In my case, why I didn’t use allocWithZone: much is because I believe my code should be fast and efficient enough even without memory zone. For special case where we want to make memory allocation/deallocation fast, we can use memory zone, but nowadays ARC takes care of memory allocation. If people are OK with ARC largely, there will be less and less people who care about allocWithZone.

For Windows, my team had used our own special allocation ( malloc/free/new/delete ) functions in C++ to allocate a big chunk of memory and give back memory aligned portions of the allocate space to callers of those new memory allocation/deallocation functions/methods.
For environment which requires really fast operation, it was beneficial.
So, for that.. probably still allocWithZone is useful.. but as said above.. who cares?

%d bloggers like this: