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?

Objective-C for Android

Well, we have heard about many SDKs like C# for iOS, C# for Android, Java for iOS, etc.
However, comparably Objective-C/Cocoa for Android was less visible. Probably it’s because there are more Java programmers than Obj-C programmers.

However, it looks attractive, especially if you know how dirty, unelegant  different Android SDK is.along with Java.
Don’t get me wrong. I was huge fan of Java in early 1990s.

So, anyway, if any of you visiting my blog has interest in using your knowledge about Obj-C for Android, try taking a look at this.

Geocoding “Service” for Mac

Oh.. If you need to use “geocode” often, this tip will be quite useful.


iOS의 피해자, Core Data 그리고 개발 용이성대 유지 및 관리 용이성 등에 대한 단상

아무래도 영어가 내 모국어가 아니어서 그런가… 필요해서 읽는게 아닌 경우엔, 좀 모호하다가, 필요해서 읽으면 그제서야 의미가 몸에 와 닿는다.
이 회사에 오기 전엔 쓰지 않았고, 쓸 필요도 없었고, 가능하면 쓰려고 하지 않았다. 왜냐하면 Cocoa Binding에 기반한 이런 기술은 일단 문제가 생기면 어디서 버그가 생겼는지 (만든 사람 빼곤) 알기가 힘들고, 데이터 로딩 타임이 원할 때 되지 않을경우 제어가 좀 힘들어질 수도 있는 등 여러가지 문제가 있기 때문이다.

아무튼 Object Graph가 뭔진 알아도 감각적으로 몸에 딱 스며들진 않았는데, 이제 필요에 의해서 코딩을 하게 되니 그냥 막 몸에 스며든다.
Object Graph가 뭔지에 대한 설명이, 애플도 그렇고 다른 데도 그렇고 뭐 그리 감각적으로 알 수 있게 되어 있지 않은지.
그리고선 CoreData는 DBMS가 아니라는 소리들만 잔뜩하고…

근데 iOS가 인기가 생김에 따라 Core Data도 타격이 컸구나. 분명 몇년전에 NeXIO 관련 프로그램들을 만들땐, MySQL용 Core Data connector library가 분명 있었고, PostgreSQL도 한 두어가지 있었는데, 이젠 다 없어졌다. 그냥 C/C++ library를 이용해서 수동으로 연결하라 이거지.
뭐 그것도 좋다. 솔직히 내가 더 선호하는 방식.
앞서 이야기했듯이 Core Data로 만들 경우, 이런 저런 문제가 있기에…

작성시에 쉬운 것 (Cocoa Binding/Core Data) vs. 유지/관리가 쉬운 것을 택하라면 난 후자를 택한다.

근데 iOS 때문에, 흥미로운 기술들이 많이 죽거나, 어중간한 선에서 그냥 구현되어 나오는 것을 많이 보네…
Resolution Independence
AV Foundation
그 밖의 이런 저런 것들

%d bloggers like this: