For the last article, we’re going to discuss a lesser-known feature of iOS 4: Local Notifications. Previously, we had Push Notifications, introduced with iPhone 3.0, which offer a way around multitasking by leaving a server at the other end performing tasks for you and notifying you via a pushed message that you should relaunch your app to see a change. This could be an IM via the AIM service, or a message from Mint.com that you’re overbudget, to name just two of the many possibilities.

But what about an app that’s primarily useful locally on your device and has no real need to maintain any sort of connection to the internet? A clock, or a to-do application, or a calendar, for example. Using Push Notifications is costly for the developer, as they must maintain a server that allows for always-on connectivity from their users, and if they experience a surge in popularity, those costs could skyrocket. Thankfully, Local Notifications are here to save the day.

The basic principle is to write some code to display these notifications, some code that hooks into the Local Notifications service to release these notifications based on the device’s internal time, and then some code to decide what to do about the notification after it fires. That last piece will likely be dependent on whether or not the app is running.

So that takes you through the whole thought process, but what about examples? Head on over to the Local Notifications article at iCodeBlog for a walkthrough, but make sure you’ve already nailed down some basics.

Let’s talk about something that has now become commonplace on mobile devices capable of having apps: touch screens.

While that simulator that came with the device’s SDK can be useful, remember that it’s not a true substitute; it’s meant to test things when they’re in-progress. Once you have a working build, you need to install it on your device and live with your (maybe not so) shiny new app. Use it with two hands, one hand, one hand while walking, in bright light, dim light, in both orientations (if your app will support that), and in any other situation you can think of.

Especially taking into account the one-handed thing, deciding button placement becomes a huge issue. Just a few pixels too close together can change a button from being just right to always being mistakenly triggered.

In addition, with a touch interface, we’ve lost a particular paradigm of mouse and cursor interfaces: hovering. There are no longer any hover states, as there is no pointer to hover. While this has a greater effect on websites and web apps, it can still create trouble if you’re trying to demonstrate to your users which elements are actually UI elements, and which elements are just content.

This sort of thing, of course, is where having a small army of beta testers is most useful. So crack that whip and see what they have to report!

Let’s take a look at one of the lesser-discussed development issues surrounding mobile devices: memory. Why is this such a problem? Well, to keep it simple we’ll focus on the iPhone, as there are only 4 versions to take into account. Let’s look at each of the four:

• iPhone (aka iPhone 1, iPhone 2G) & iPhone 3G both have a grand total of 128 MB.
• iPhone 3GS has 256 MB
• iPhone 4 has 512 MB

So you can see, we’ve returned to the days before a gigabyte of RAM was commonplace. However, this is total physical memory; once you actually turn the device on and get going, that number plummets. In the case of all of them, the system RAM usage (including the MobilePhone application, which also must always be running) is roughly 64MB. In the case of iPhone and iPhone 3G, that cuts your memory in half. Pretty brutal. Thankfully, the later two devices up the ante considerably, but they are still somewhat constraining.

So what does this mean programmatically? It means you’re going to implement things on an as-needed basis, and kill them off as swiftly as possible. Otherwise, SpringBoard (in the case of iOS) will quite ruthlessly kill your application with an out-of-memory error, and we all know how jarring that can be.

Keeping these sorts of physical / systematic limitations in mind is one of the most important concepts in mobile development. It’s akin to developing for some of the previous generation console gaming systems; you have to get it as solid as possible, using as little memory, with as few bugs as you can, at version 1.0.

Good luck!

Let’s talk about the stage of development after you’ve actually written your app: the testing stage. Conjures up all sorts of evil images from school, doesn’t it? Well relax, you get to be the test giver, and the idea now is to make the testing as painless as possible for your users, so they’ll want to help you out and make their own experience better.

So how do we test our apps before we release them? In the case of Android apps, this is quite simple, as installation of non-Market apps is possible by checking the “Unknown sources” checkbox in the “Applications” area of “Settings.” For security reasons, be sure to disable this once you’ve installed the app you’re looking for.

In the case of iOS apps, however, the only distribution method is the App Store. So how do we get our app into testers’ hands? We need to create what’s called Ad Hoc distribution. This is a capability that came along with iPhone 2.0. You’ll need to collect the UUID for each tester’s device(s) and use the Program Portal for your app to create provisioning profiles for all of your testers. You then bundle the profiles into the test version of your app, and then build and distribute to them. You’ll need to supply each tester with a ZIP of the .app bundle and a copy of the Ad Hoc .mobileprovision file that you generated.

More explicit, step-by-step instructions for this can be found in Apple’s Developer documentation, but the easiest to read resource is definitely Craig Hockenberry’s Beta testing on iPhone 2.0 article, which outlines the whole procedure. Things have moved around a bit in Xcode 3, and Xcode 4 promises even greater changes, but the procedure is similar enough.

So go forth, and test your new app with your loyal minions!