February 2009

Well, “Be Mine” is wrapped up from the development stand point. A few marketing tid-bits and a hopeful plug from the local news (more on that..stay tuned) should provide the traction to get this app selling through Valentine’s Day. Damn that ad in the Denver Post – oh well.

So now what? The creative minds are busy with all sorts of ideas. We will be holding our next “jam session” this week with the goal of answering, “So now what?”

Enough babel, I want to keep this post focused on a technical debrief on what we learned working on Be Mine. So here it goes…

The simplicity of the design did not present too many obstacles as I have spent a good deal of time studying the SDK especially in the area of UIView and how UIView interacts with other views through UIController design patterns. One interesting memory problem surfaced and made itself apparent while using the UIImageView class. I used this class to “contain” the heart images, sized to native resolution (320×480), initially using imagedNamed method on the UIImage class and assigning the UIImageView image property. The imageNamed method loads the image from the app bundle but adds a performance gain in caching and retaining the image in memory. Enough unique heart images loaded from a “shake” very quickly built up memory resource and soon the OS sent the kill signal to term the app. I resolved the problem by assigning the UIImageView image property using the imageWithContentsOfFile method. This method loads the image from the bundle (file system i/o) similar to imageNamed BUT does not perform caching. So short story long, imageNamed is good if the app references the images over and over with the added performace gain of in memory cache. But if you have several images, at runtime, need to swap into a view and the app does not need the past image, use the imageWithContentsOfFile (or similar) method.

The last topic to cover is the accelerometer. I’m sure that few application developers have had the experience programming to such a device but Apple has made it easy to tap into this feature. Basically you need to implement the UIAccelerometerDelegate in your applications main controller, setup the accelerometer during an initialization routine (I did ours in initWithNibName) with the following calls

[[UIAccelerometer sharedAccelerometer] setUpdateInterval:(1.0 / kUpdateFrequency)];
[[UIAccelerometer sharedAccelerometer] setDelegate:self];

and implement the delegate method

- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration*)acceleration

Bingo! Now you have the UIAcceleration data to perform processing. Note above the setUpdateInterval method, it pokes the OS to tell it the frequency your delegate sould receive accelometer events. In our case kUpdateFrequency was defined as 20, so 1/20 = 20Hz (or 20 times a second.) An active game that heavily depends on accelerometer events driving the UI should set the interval to 60Hz or possible greater but 60 should do the job in most cases. I believe the device accelerometer is capable of 100Hz max.

Finally, I end this long-winded post by referencing must reads for some of our developers.

Login to the iPhone Dev Center and read the guide on Objective-C programming. This is a must even for experienced OOP developers (C++, C#, Java.)

Introduction to The Objective-C 2.0 Programming Language:

http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/chapter_1_section_1.html

And for the best reference book on the C programming language go get your hands on:

The C Programming Language

The C Programming Language.

by Kernigan and Ritchie

Posted by b malcolm at 2/08/2009

{ Comments on this entry are closed }