Run Loop Required for Networking

One of the earliest things I needed to do was build out the networking code for my Daap player.  Initially, I was building this code as a standard Macintosh command-line application.  I happily wrote code to set up a synchronous networking call using NSURL and NSURLConnection and then… nothing.  Unlike Java, it was necessary to have a “run loop” executing.  Had I done this test initially on the iPhone emulator, I would have never run across this since the iPhone has a run loop executing the application.

Subclassing and Class Clusters

In Java, it is not possible to add functionality to another class.  The only real available option is to subclass the class of interest.  In general, that works ok until you get a class like java.lang.String that isn’t mean to be subclassed, in which case you need to provide some kind of wrapper or utility class.  My first attempt at adding some new functionality to NSMutableDictionary from the Foundation library was using a subclass.  I was greeted at runtime by an error similar to:

2010-08-14 09:55:48.965 TestProject[1136:207] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘*** -[NSDictionary objectForKey:]: method only defined for abstract class.  Define -[MyDictionarySubclass objectForKey:]!’

What the heck?  It turns out that most of the collection classes in iPhone are implemented as class clusters.  According to the Cocoa Fundamentals Guide class clusters

… group a number of private, concrete subclasses under a public, abstract superclass. The grouping of classes in this way simplifies the publicly visible architecture of an object-oriented framework without reducing its functional richness.

Had I really needed to subclass NSMutableDictionary, Matt Gallagher talks about how to create such a subclass.  In my case, it turns out what I really needed was just an Objective-C category to add methods to NSMutableDictionary directly rather than subclassing the class.  Categories remind me of similar functionality available in Smalltalk, allowing additional methods to be attached to classes.  The class “shape” (instance variables) cannot be changed using categories, but new methods can be added which is very helpful for creating utility methods on a specific class rather than having to do it on a separate class.  Looking around the documentation for the various frameworks in the system, it is amazing to see how many classes are extended using categories.

Summary

Although my Daap player is nowhere near complete, the project did offer me plenty of visibility into Objective-C and iPhone development.  Objective-C and, in particular, the various libraries for iPhone development are incredibly powerful.  While there were a few growing pains along the way, the transition to doing iPhone development was relatively straightforward and enjoyable.

Tab Based Main View

In addition, there is now a (very) rudimentary Now Playing screen to control playback.

Now Playing View

iPhone Versus Exceptions

In my last entry, I mentioned that I’ve struggled through some interesting differences when dealing with iPhone development when compared to my years of experience in Java.  As a long time Java developer, I’m very accustomed to the use of checked exceptions.   Most, if not all, error handling in Java is handled through the creation, throwing and catching of exceptions.  I’m accustomed to catching/handling exceptions from the underlying libraries as well as creating and throwing my own exceptions.  It was with that background that I approached iPhone development and quickly found out that is not the recommended way of handling error conditions.  While, the standard try/catch functionality is supported in Objective-C, the documentation for Cocoa development makes it clear that using exceptions should be avoided:

Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.

Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications.

This is an important difference to understand when transitioning to Cocoa development from Java development.  While this is important to understand when making calls to library methods and functions, it must also be considered when defining your own calling conventions and libraries.  In order to remain consistent, it is important to use the pattern of NSError usage.

The Project

In order to learn a new platform, I always like to have a project to build.  Looking around, I didn’t find any iPhone DAAP clients for servers like the Firefly Media Server.  I’ve been trying to build a DAAP client as my learning experience.  I have a good chunk of the navigation working at this point.

DAAP Player

The iPhone Core Data support is amazingly powerful, providing a good chunk of the underlying data source support for table views like those in the client.

DAAP Albums

There is still much to be done, but the iPhone SDK has provided a large amount of functionality for a very small price.  As always, I continue to be impressed with the power packed into modern handsets.

Circus VIC-20

Looking back at this article publication, there are a couple of things that make it particularly interesting to me 20+ years later.

• My original program was written on the Commodore VIC-20 (5K of user memory!) and was rewritten for all of the other computers for the publication.  This happened behind the scenes and I was unaware until publication.  Not surprising, they also rewrote all of my descriptive text.
• This game was a clone of a game that was available in arcades and pizza places around that same time.  Had I done this in present day, this game would very likely not have been published due to copyright or other legal issues.

20+ years later, I’m still a computer programmer (software engineer?).  While I program less than I used to, it is cool that my hobby so many years ago has been able to be both a hobby and a source of income for so many years.

• Motorola
• Nokia
• SonyEricsson
• Research in Motion
• Several individual contributors

This new MTJ release has been included in the first service release of the Eclipse Pulsar project.  In addition, the Pulsar QuickInstall now includes an SDK from SonyEricsson.

As Christian pointed out via his email, now would be an excellent time to consider getting involved in the Eclipse MTJ project.  Even something as simple as being involved on the mailing list can help us out.  If you are a mobile developer using Eclipse Mobile Tools for Java, consider contributing a patch to provide a cool new feature or to fix the bug that annoys you the most.  Not a developer, but still want to contribute?  We can always use help with documentation and project marketing.  Pitch in and lend a hand!

ZBerry Game Play

Please take this for what it is worth… a silly little hobby project of mine that may or may not continue.  If you really like this, feel free to comment.  If you find bugs, source code patches are welcome, but complaints are not.  My hope is that is that it is worth more than its price (FREE) but given that I’m making nothing from this I hope that everyone can understand there is absolutely no support implied or available.

If you have Snow Leopard on your system, please do not install the patched version of PPPD.

I will keep the replacement package available for those like myself that are still running Leopard on their systems.  In addition, there is a version built for Tiger.

• The TmL project contains components that are useful on many mobile platforms, not just Linux. As the primary contributor to TmL up to this point, Motorola desires to expand the scope of the project to support other mobile platforms.
• The MTJ project contains some components that could be valuable to all mobile developers, not just those who use Java ME.
• Code for Eclipse Pulsar was placed in the MTJ repository due to timing issues. Since the Pulsar developers also work on MTJ, it seemed a reasonable location. There is a need for a more suitable and permanent location for this work.
• A new project, focused on the needs of all mobile developers has momentum, as previously seen from the excitement around Pulsar. By removing the artificial barriers of “Linux” and “Java”, we hope to provide a home for all Eclipse mobile developers.

It is easy to understand Motorola’s motivations in making this move, given their transition to the Linux-based Android operating system for many of their upcoming devices.  With that said, I do believe that this move is truly beneficial to the mobile development community.  While developers have to deal with the plethora of mobile device platforms and the associated fragmentation, consumers really only care about the results of development.  The more that the tools can help developers bridge the gaps between the various platforms, the easier it will be to get applications into consumer’s hand no matter what their device.

In many ways, this is a natural extension to my original goals of making EclipseME support all JavaME devices no matter which vendor provided those devices.  Of course, JavaME’s role in mobile devices has diminished significantly in recent years, so it makes a lot of sense to broaden the scope to other platforms.  For more information, take a look at the presentation or drop by one of the project mailing lists.