Whether to call [super mouseDown:] etc or not

From View Programming Guide : Handling Mouse Click and Dragging Events

Notice that the mouseDown: implementation in Listing 4-7 does not call the super implementation. The NSView class’s default implementation for the mouse handling events are inherited from NSResponder and pass the event up the responder chain for handling, bypassing the view in question entirely. Typically a custom NSView subclass should not call the super implementation of any of the mouse-event methods.

Once [super mouseDown:…] is called, mouseDragged: is not called. mouseMoved: can be still received by calling [[self window] setAcceptsMouseMovedEvents:YES]; though.

So, for custom views which needs to handle all details of mouse event, it’s better not to call super’s messages of NSResponder, in other words, mouseDown, mouseUp, mouseDragged, mouseMoved, etc.

There is different results obtained by different combination of acceptsFirstResponder, acceptsFirstMouse etc. So, when implementing mouse event handler, please consider situation thoroughly and test as many as cases you can imagine. ( Hmmmm… S/W engineers who are not considerate tend to think that they know everything and ignore general situation.. So, I wonder if this recommendation would be effective to them. )

Xcode 6.1이 가져온 큰 변화 (Integration of iOS & Mac OS X for programmers )

놀랍게도 내가 보기엔 Swift가 아니다.

Xcode 6.1이 가져온 큰 변화는 드디어 Mac에서도 iOS의 View Controller를 쓸 수 있다는 것.
이렇게 함으로써 주가 되는 뷰들을 각각의 xib에 넣고 관리하게끔 유도한다. (물론 그 xib들을 storyboard로 관계 맺어주는 것이지. 사실 storyboard의 등장은 xib를 없앤게 아니다. 스토리보드 파일을 열어보면 그 답이 나온다.)
당연히 덩치가 큰 프로그램은 메모리 사용량 관리에서 더 좋아질테고. 이렇게 함으로써 사실상 Mac과 iOS의 가장 큰 차이점이 없어지게 되었다. 물론 프레임워크의 차이야 조금은 있지만, 그건 마치 다른 버젼의 프레임웍 같은 느낌이고.. 사용 패턴등에 대해선 차이가 없다.

자. 이제 맥에서도 NSView가 NSWindow의 상위에 놓일지는 의문이다. 그렇게 되면 프로그래밍적으로 iOS와 OS X의 통합이 될거다.
NS*대신 UI*를 사용할텐데, 어느 쪽으로 통합될까? 혹 UI*는 아닐까? NS는 NextStep의 흔적이니까.

그래도 난 NS가 좋다. 왠지 UI*는 뭐랄까.. 히피같은 느낌?

그리고 iOS에선 Core Foundation 혹은 그 레벨에 준하는 것들을 Foundation보다 더 많이 사용하는데 (UIColor vs. CGColor) 앞으로 iOS 이전의 프레임워크처럼 CF*에 해당하는 해당하는 것에 대응하는 UI*를 빨리 빨리 만들어 주었으면 하는 바램이다.

Scroll views inside scroll view

Scroll views inside scroll view

Concurrent programming in OpenCL vs Grand Central Dispatch

http://stackoverflow.com/questions/21504053/concurrent-programming-in-opencl-vs-grand-central-dispatch

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. )

http://stackoverflow.com/questions/4014396/converting-cvimagebufferref-to-png

Be careful about object ownership around NSOperation and NSOperationQueue

For recent years, Apple people concentrated more on iOS than Mac OS X.
So, during that period of time, I’ve noticed that the quality of SDK for OS X and its documentation got worse.

In the case of NSOperation and NSOperationQueue, actually it was announced before the iOS was announced as far as I remember.
However, at that time, they were implemented around pthread or NSThread to provide eaiser pattern for multithreaded programming under specific scenario. ( Although those serial and pipe-like working model is quite convenient in many circumstances, but not always still. If you need more sophisticated interaction among threads, etc, you still need implementation with pthread/NSThread. )

Here is one example.
Were they clear about object ownership for NSOperation ( and its child classes ) when it’s added into a queue?
For tasks like it’s just queued and quickly consumed and gone, it will not easy to catch a case where an instance of a concrete children classes of NSOperation is deallocated while it’s in a queue and being processed.

However, today I did noticed such a case. So, be careful about this thing.
Making a pattern around something looks cool. It may show yourself a very skillful developer. By glancing at that kind of code, people can think of you as such.
However, it’s only skin-deep.

ADDED : According to the document of NSOperationQueue, it says for addOperation:

Parameters

operation

The operation object to be added to the queue. In memory-managed applications, this object is retained by the operation queue. In garbage-collected applications, the queue strongly references the operation object.

So, at least it’s said to retain the operation. But be careful about it.

Switching to Android from iPhone

( should not be too much shocked. I, anyway, have another iOS device, iPod Touch with 4 inch screen. )

약 25불에 스맛폰 껍데기를 사는 건, 1 센트짜리 Moto X에겐 배보다 배꼽이 더 큰 억울한 경우지만.. 그래도 이번에 Android로 바꾼다.

{ Well.. the power button of my iPhone 4 is not clickable any more. I can still use it, and iOS wakes the device up even after discharged and turned off for itself.  However, it’s time to upgrade the old 3G iPhone 4, and Moto X costs just 1 cent. — I’m so glad! A few weeks ago, I tried to switch to Moto X, but it costed ~$45. If hidden cost is added up, then it became $100 easily. But 1 cent for Moto X is good deal. Well.. Motorola Mobility is gone and absorbed by Lenovo. Probably why they are liquidating the fairly new Moto X this quickly is that probably the new leaders at Lenovo may have different plan and don’t want to support old Moto-Google device. They may introduce devices of their own design. How different can they be is different issue. However, if the doomed H/W manufacturer made the device on some standard like how the PCs are, I think there is no problem in installing any new Android OS on it. Anyway, migration to new OS on Android world is not as quick as how it is on iOS world.  Although this guy says it’s pretty quick to adopt new Androids…
Well, the adoption rate for the latest and the 2nd from the latest in Android market is pretty good. Being faster to newer whatever is not necessarily good always. As far as I  remember ( yes! I have monitored Android market and its SDKs since its introduction ), the Jelly Bean adoption ratio was not this much several months ago.
Anyway, I have strong feeling that the reason people adopt even faster on iOS devices are.. they are usually enthusiastic on their Apple technology and I noticed that many old things were broken and deprecated quickly especially in iOS 7. So, as a developer, I would adopt iOS 7 very quickly also if I work on iOS project at work or home. I left Panascout behind though.

So.. what all of that says is that Moto X will have good life span, not just as a functioning device but also in terms of S/W support. I know that smartphone engineering is different from PCs. So, the H/W manufacturer would end up provide some glue layer between Android and its underlying H/W, because the H/W components can be different from vendors. But they are mostly now commodity. They may end up using different address space, though… So.. anyway..
}

어차피 iOS 장비는 iPod Touch가 있으니.. (이것도 회사일 하기 위해서, 회사에 요청하다가 안들어주고 fix만 요구하기에 내 돈주고 산거).. 더군다나 이제 새 iOS 프로젝트는( 맡게 될지 자체를 모르겠지만) 4인치 이상에서 시작할거고, 3.5인치도 제대로 view controller를 이용해서 할거기 때문에 그다지 필요치 않다.

애플이 미국 시장에서 거의 45% 시장을 장악하는 기염을 토했지만, 안드로이드가 점점 좋아지는 이 시점에 (여전히 framework는 iOS에 비해 나쁘지만) 돈주고 멤버쉽에 가입해야만 장비에 내 테스트 프로그램을 올리는 (때때로 iOS 프로그램 만들고 싶은 아이디어가 떠올라 개념을 테스트하고 싶을때) 것 조차 못하게 하는.. 이런 황당한 상황에서 web app이 경우에 따라선 훌륭한 대안이 되겠지만 역시 번들로 만들 경우엔..
그래서 안드로이드가 훌륭한 대안이 될 수있다는 생각.

이제부터 주말엔 공부 모드. 웹 앱쪽도 Cappucino와 Ember인지 Amber인지도 공부해볼 생각. Cappucino는 금방 익힐거 같고.. Amber도 그다지 어려울거로 보이지 않음. 어차피 DOM editing의 성질을 갖는 비효율적 JavaScript 기반 프로그래밍에 framework로 감싸서 마치 네이티브 개발의 스타일을 적용하는거라… 그래도 JavaScript 지식 다시 refresh하고, AJAX 쪽을 봐야겠지. 정확히 내 Web programming은 AJAX이전에서 끝나니.
(근데 HTML 3.x까진 그래도 좀 웹 프로그래밍에 관심이 있었는데, 그 후엔 영 없어졌으니. 마치 Java처럼. 처음엔 Java 굉장히 좋아했는데, 점점 이럴 거 왜 Java 쓰나 하는 생각. )

Agile 문서도 더 읽어볼 작정.
원래 S/W Engineering이란게 흔히 말하길 코에 걸면 코걸이 귀에 걸면 귀걸이라지만, 미국 사람들은 여기에 꽤나 목 메는거 같다.
그리고 자기네가 아는 용어가 마치 다인양 생각하기 때문에, 그걸 synch하기 위해서라도 읽어 두는게 좋겠다 생각.
( 왜.. 다른 것도 그렇지만 특히 이 AJAX는 사람들마다 쓰는 용어가 다 다르냐.. )

Difference between Objective-C compilation for Mac and iOS for 32 bit

For past several years, Apple people tried to make kernel for Mac and iOS identical.In Snow Leopard, they got rid of PowerPC code and started to introduce 64 bit kernel.

On Lion, as far as I know, kernel version of iOS caught up that of Mac OS X. So, after that it’s widely said that kernels for iOS and Mac are the same.
However, Apple recently introduced 64bit iOS for iOS 7. So, although the kernel for Mac was built as 64bit, iOS was built 32bit so far.
Anyway, the trend is that Cocoa becomes similar and Objective-C compiler becomes similar in feature list they support.

However, I noticed that 32bit compilation for Mac is not up-to-date compared to that for iOS.

Here is the difference between the two.

32bit compilation for Mac OS X (on the left) and iOS (on the right)

Although the overall direction is to make them identical on Mac OS X and iOS identical, it turns out that Apple didn’t update 32bit compilation for Mac to match that for iOS. The 64 bit runtime on Mac OS X is so called ‘modern run-time’. But should the run-time different for Mac and iOS?
I’m not sure because I don’t know the detailed story about what happened at Apple.

Because I have worked for iOS recently, i thought that 32 bit build environment for OS X would be the same to 32 bit environment for iOS. But it was not.
Apple’s official feature matrix can be found here.
What doesn’t catch is that modern runtime is only for 64 bit on Mac.

 

Spark Inspector : Its flexibity

Ok.. Using Spark Inspector was very easy.

At first there was one odd thing : Where is the SparkInspector.framework?
It’s located in Spark Inspector app. However, if using its “Framework Setup assistant”, the app ingest frameworks to be linked for a chosen project for you.

One thing I didn’t like was that.. as most Cocoa programmers tend to set up a Xcode project, it puts framework setting in “target” Build Settings rather than “Project” Build Settings.

If you want to set those links as default for all targets you end up adding, the easier way is to put that setting in “project” Build Settings. I know that many Mac/iOS app developers who usually jumped into Mac/iOS app dev. after iOS became popular don’t understand the different necessity between the “Target” and “Project” Build Settings.
Anyway, this is not a big deal.

Now, let’s talk about cool things.

As you can see from the above picture, your app runs on a simulator or an actual device while debugging, but the Spark Inspector app intercept that also and displays view hierarchy in list form on its left pane, visual representation of it in the middle pane, and finally, properties of chosen view/layers on the right-most pane. So, while you are debugging and interacting with a real device or a simulator, you can change colors, tints etc by choosing a layer/view on the Spark Inspector and changes some properties of them.
You don’t need to paint your layer/view in your code for debugging purpose anymore!
Isn’t that cool?

Also, the most important and useful feature of this app is the 3D display of those views and layers. When one view occludes an underlying view completely, and if there is some transition is applied to the underlying view ( unexpectedly ), you can still check what’s happening visually.

You can say that recursiveDescription is good enough. (It’s undocumented message of UIView )
However, when there are lots of view/layers, it can be very hard to identify which one is which when you use the message. However, this great helper tool for UI debugging eases debugging very easy.

After the PaintCode, I think this is a must-have tool for iOS developers!
I’ll buy it soon.

BTW, there is one little glitch there. As you can see, the right side of the right-most pane invades the right border of its super view. So, the content on the right-most pane goes beyond the right border.

Maybe Apple people consider Mac OS X/iOS hybrid apps?

The last time I looked up documentation on “How to build iPhone/iPad hybrid app” was 2 years ago roughly. (When did the 1st gen. of iPad come out?)

At that time, I think there was no “platform key” in this identifier format in info.plist.

key_root-<platform>~<device>

According to a section “updating your info.plist settings” in “Creating a Universal App”, it says :

For apps that run only on iOS, you can omit the platform string. (The iphoneos platform string is used to distinguish apps written for iOS from those written for Mac OS X.)

Hmm… what does that mean? Are they preparing a unified executable file format like they did for 32/64 and Intel/PowerPC for iOS and Mac OS X?
So, you can choose whether a project is built for Mac OS X or iOS, or the both?
Surely, iOS uses ARM instruction set in Mach-O format ( I believe ) while Mac OS X uses x86/x64 instruction set in Mach-O format. then…. yeah.. it can be possible to have one bundle.

Hmm.. if they announce a Mac-iPad hybrid device, it can be interesting. I like Lenovo’s effort on this with Windows 8.