iPhone and iPad applications containing long running tasks - such as HTTP requests or data processing - that block the main thread are annoying and often appear sluggish.
The following snippet fixes this issue:
I spent some time earlier today playing with the UIMenuController offered in the iPhone SDK and realized two thing: sometimes Apple’s examples suck and having an environment that often gives no feedback is terrible.
In this case, I implemented a copy of an example that was supposed to present a semi-modal cut / copy / paste menu. It didn’t. After spending nearly an hour trying to realize why nothing was happening, I found I had missed copying a line. Anyways, for the record, here is the concise example of how to present a UIMenuController:
Cocoa extensions provide a great way to modify existing classes with additional functionality. Here is a good example of extensions in action:
Accessing extensions is simple: just import the header file. In the case above, easily readable dates are now at the finger tips!
Over the past half-year I have been developing software for the iPhone (and recently iPad). Although I feel that Cocoa is excellent overall, a few rough edges prevent it from being a truly great experience:
The Language
Objective-C is the language of choice for most Cocoa developers (Cocoa can be accessed through bridges by Ruby, Python and a handful of other tools). It provides a thin layer on-top of the C program language, adding support for dynamic typing and messaging.
Objective-C’s very fast execution speeds do not compensate for the amount of code required to perform trivial tasks (especially compared with Ruby or Python). Issues such as memory management and duplicate feature sets (NSString and string, NSArray and [], etc.) can leave developers wanting something better.
The Controls
Interface builder is one of the best GUI designers available. That said, the iPhone and iPad controls are not nearly as verbose as the Mac desktop application controls. The lack of support for grids, checkboxes, colour pickers, and even good looking buttons does not make any sense. It is obvious that Apple had to exclude tools that will not work on the mobile platform, but their over-zelous axing of features ultimately ended up increasing the workload for developers.
Although Cocoa offers great customization of controls, developers must revert to code to get certain core features working. A great example is creating form elements within a table (something done in thousands of applications, including the ‘Settings’ app). Developers will need to setup delegates, protocols, and data-structures for something that should be drag-and-drop. For static forms, this is wasteful and time consuming.
The Ecosystem
Having recently spent some time developing in Ruby on Rails, I feel confident stating that the Cocoa ecosystem is terrible. Although a few great libraries and extensions exist (Three20, BWToolkit and Pinch Media), the non-existence of a package manager (such as RubyGems) means that third-party software is few and far between.
Installation of almost anything introduces dependency headaches and is completely non-strandard. A look through the 10-20 step guides required for any framework will make some cringe and others cry.
Conclusion
Given Apple’s reputation, it is a wonder better options are not available for Mac and iPhone development. The benefits of releasing a 25 year old language on brand new mobile devices or not upgrading existing SDK’s with new languages (Microsoft has gone through at least four) are very limited. Further support for projects like MacRuby are required, and hopefully existing open community frameworks can be better integrated with Cocoa in the future.
A Ruby and Cocoa developer and designer living in Santa Monica, California.
