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.

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!

Before Facebook Installation

This shows the menu in this application before installing the Facebook application.  After installation, you can see that the Facebook application has added a new menu item to this application.

After Facebook Installation

This is a pretty nice feature of the API.  Although I don’t have actual code to show for this, my assumption is that this is provided by using:

• ApplicationMenuItem
• ApplicationMenuItemRepository
  • MENUITEM_MESSAGE_LIST

API’s like this allow for incredible integration with the rest of the applications on the device, opening up many very interesting opportunities.

The Pulsar project also saw an initial early release with Galileo.  I will provide some background on this project in an upcoming post.

ZBerry Library Selection

I need to add some suspend/resume support before this thing becomes really very usable on a phone, but some progress anyway…

protected void paint(Graphics graphics) {
// Stash the current colors and invert them for the
// background fill
int currentBgColor = graphics.getBackgroundColor();
int currentFgColor = graphics.getColor();
int w = getWidth();
int h = getHeight();

graphics.setColor(currentFgColor);
graphics.fillRect(0, 0, w, h);

graphics.setColor(currentBgColor);
graphics.setBackgroundColor(currentFgColor);

// Draw the pieces of text
int midHeight = h / 2;
int midWidth = w / 2;
buffer = new StringBuffer();
buffer.setLength(0);
buffer.append(“Moves: “).append(moves);
graphics.drawText(
buffer, 0, buffer.length(), w, midHeight, Graphics.VCENTER | Graphics.RIGHT, w);

buffer.setLength(0);
buffer.append(“Score: “).append(score);
graphics.drawText(
buffer, 0, buffer.length(), midWidth, midHeight, Graphics.VCENTER | Graphics.HCENTER, w);

graphics.drawText(statusText, 0, midHeight, Graphics.VCENTER | Graphics.LEFT);
}

I had expected three pieces of text, aligned right, left and center.  Instead, I ended up with:

Broken Text Alignment

The Graphics#drawText methods look similar to:

public int drawText(StringBuffer text,
int offset,
int len,
int x,
int y,
int flags,
int width)

The trick with this API has to do with that last parameter.  The width parameter is used to define a bounding box.  The x and y parameters define the top-left corner of that bounding box.  Horizontal alignment flags (HCENTER and RIGHT) do the alignment relative to the bounding box defined by (x, y, x + width, y + height).  To get the same behavior I had expected, I needed to set the bounding box to include the complete width and then specify those alignment flags.  The correct code now looks more like the following:


protected void paint(Graphics graphics) {
// Stash the current colors and invert them for the
// background fill
int currentBgColor = graphics.getBackgroundColor();
int currentFgColor = graphics.getColor();
int w = getWidth();
int h = getHeight();

graphics.drawText(
statusText,
padding,
midHeight,
Graphics.VCENTER | Graphics.LEFT);
}

graphics.setColor(currentFgColor);
graphics.fillRect(0, 0, w, h);

graphics.setColor(currentBgColor);
graphics.setBackgroundColor(currentFgColor);

// Draw the pieces of text
int midHeight = h / 2;
int paddedWidth = w – (2 * padding);

buffer = new StringBuffer();
buffer.setLength(0);
buffer.append(“Moves: “).append(moves);
graphics.drawText(
buffer,
0,
buffer.length(),
padding,
midHeight,
Graphics.VCENTER | Graphics.RIGHT,
paddedWidth);

buffer.setLength(0);
buffer.append(“Score: “).append(score);
graphics.drawText(
buffer,
0,
buffer.length(),
padding,
midHeight,
Graphics.VCENTER | Graphics.HCENTER,
paddedWidth);

}

This results in expected text layout:

Correct Text Alignment