Archive for the ‘iOS’ Category

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

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

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.

OperationQueue, Operation and ownership

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

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 worldAlthough 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는 사람들마다 쓰는 용어가 다 다르냐.. )

%d bloggers like this: