Posts Tagged ‘iPhone App Development’

Apple at it again!!

August 19th, 2009

Apple’s release of iPhone OS 3.0 was eagerly awaited by the iPhone developer as well as the user community alike. But since it has been released I haven’t been able to get a good night’s sleep, not because of the cool new features it had using which I could create new exiting applications, but because of the bugs it has in it’s new iPhone OS 3.0.

Ever since Apple has released the new iPhone OS, I have been looking around for a fix to the problem I have seen with UIImageViews. Frantically “Google”ing for a fix, searching Apple iPhone Documentation again and again just to see if I have missed anything in the Release Notes and Change Logs of the iPhone SDK for UIImageView have not yielded any result. My self imposed deadlines to update all my apps for iPhone OS 3.0 have been breached and a resolution was not in sight.

The bug in UIImageView was its memory usage. As long as an image on screen is left alone after being created, nothing happens. But if you have any sinister designs on your mind, of moving/resizing the image on screen memory usage starts increasing. And there is no way you could do anything to bring the memory usage down, even releasing the image view object does not work.

And the most important finding in this issue is that “there are no memory leaks”. All the memory allocated is always being used!! That is what I had to believe, but performance of my applications on iPhone was rapidly falling down with the amount of time spent on it. Clearly indicating to me that there was something odd with the new iPhone OS.

A detailed bug report that I sent to Apple received a reply stating

This is due to a bug in the graphics system that mis-reports how it is allocating memory to ObjectAlloc, which causes it to display memory usage as continuously increasing.
If you attach the Memory Monitor instrument to your sample application, you will find that the Real Memory usage stays constant through out the application’s execution, indicating that while ObjectAlloc believes memory usage is increasing, it really is not.

For a couple of days, I was devastated at receiving that reply. So, no way out for me from this situation? Are all my app users going to give me bad ratings for no fault of mine?

Fortunately, I received another e-mail from Apple Support acknowledging that

this is a known issue, which is currently being investigated by engineering

Obviously someone else has already reported the issue, but the above response is only a “consolation prize” for me and nothing in the equation between me and my application purchasers changed. They are still going to complain that my apps are resource hogging and give them bad ratings.

This issue seems to be fixed in iPhone OS 3.1 and beyond, but the damage is already done!! Will all iPhone/iPodTouch users update their devices promptly?

Hope your applications are not plagued with these problems, and/or you have found an alternative to overcome this problem.

Happy programming!!

Tags: iPhone App Development, iPhone OS, iPhone OS 3.0 issues, iPhone OS Bugs

Effective ways of handling Interruptions in iPhone App Development

August 18th, 2009

It is a known and acknowledged fact that user’s experience with your iPhone app is of paramount importance in keeping them glued to it. Towards that, handling interruptions gracefully in an iPhone app plays a key role.

iPhone being a “one app at a time” device, apps get interrupted by incoming Phone Calls, SMSs, Calendar Events, Alarms or Push Notifications from other apps on the device.
The iPhone SDK provides a few methods in UIApplicationDelegate which can be implemented to handle the interruptions and keep user’s experience as flawless/seamless as possible.

The Interruption
- (void)applictaionWillResignActive:(UIApplication*)application

This method lets your application know that it is about to be interrupted by the iPhone OS. The name of the method suggests that your app will no longer be active, and will not respond to any user actions until the interruption is taken care of. An interruption like an incoming phone call or an SMS can either be accepted or dismissed by the user, and this is where you have to perform all tasks necessary to resume if the user chooses to leave the application. If the app was a game, it could save any game state needed for a resumption later.

The Resumption / Interruption Dismissed
- (void)applicationDidBecomeActive:(UIApplication*)application

When your application is about to become active again, this method is called by the iPhone OS. If the user decides not to leave the application and dismisses the interruption this is a good place to allow the user resume using the application. Since the application has not yet been closed, all the required state to resume is still in memory and continuing using the app is really as simple as a Pause/Resume feature.

The Interruption Accepted
- (void)applicationWillTerminate:(UIApplication*)application

If the user decides to leave the application or accepts an interruption, this method call from the iPhone OS notifies us of that intention. This is the place where you save all necessary state of the app/game to resume later.

The best place to save all game/app state to resume later is “applicationWillResignActive”. The simple reason being, all iPhone interruptions need user’s input to either accept or dismiss the interruption. This action from the user might needs a few seconds of his/her time to understand what the interruption is and what to do with it. This duration should be just enough for a well written application to save all state. Whereas, in the case of the application being closed by the user, iPhone OS wouldn’t wait for the app to complete saving state. The time available is really short and many applications might fail to save state.

Since there are multiple reasons and ways for an app being closed, state saving method calls need to be placed both in “applictaionWillResignActive” and “applictaionWillTerminate”. But ensure you don’t waste precious time in saving app state at both places. If the user closes the application by pressing the “Home” button, use “applictaionWillTerminate” to save state and necessary cleanups. If the application is being closed due to an interruption, save state in “applictaionWillResignActive” and perform any necessary cleanup in “applictaionWillTerminate”.

So, make it a point to use various UIApplicationDelegate methods to maintain user experience and reusability of the app. Keep your users glued to your application or game and return to it after an interruption.

For more tips and strategies on iPhone App Development, click here. For iPhone app marketing tips, try this link.

Tags: iPhone App Development, iPhone Development help, iPhone Development tips, iPod Touch Development tips