 |
|||||||||
|
|||||||||
|
|
This is the first blog post in a series that I plan on writing about iPhone application development. The first thing you should know is that these blog posts will not cover anything related to taking existing content sites and making them more "iPhone-friendly". While I think that is a valuable topic, it has little interest to me as a programmer. If I was a website manager, then it might have more interest to me. There are plenty of online resources for making your web content more iPhone-friendly and the fact that the iPhone runs a full version of Safari makes this a somewhat minor task.
Secondly, while I may refer to the "iPhone" as the target device for this series of articles, keep in mind that there are now 2 devices that can be considered targets for "iPhone Applications": the iPhone and the iPod Touch. The iPhone can access potential iPhone apps using WiFi or EDGE and the iPod touch can use WiFi. Do not underestimate the potential consumer base of the iPod Touch - think of the number of public WiFi locations as well as the number of people who have WiFi in their homes... the iPod Touch users will be quite well connected, even without the backing of a cellular network.
Thirdly, while I am aware of the possibility of jailbreaking my phone and using things like iPHUC (gotta love the choice of acronym there) to push stuff to the phone that will eventually allow me to SSH which can then eventually allow me to compile native Objective-C apps for the phone - I'm not covering that in this article. Not only is it an unsupported activity, it is certainly not something that the average iPhone user can do, which rules out the ability of distributing your application to a mass audience. Not to mention the fact that I think every time you jailbreak an iPhone, kittens die. Hey, that's the rumor.
So what is an iPhone application? To be short, an iPhone application is a unit of discrete functionality delivered via the Web to a mobile form factor device running Safari 3 over a potentially narrow-band network. There is a lot more to it, and I address the anatomy of an iPhone application in the rest of this blog post. While I provide an overview of some topics here, I will be covering a lot of these topics in much greater, perhaps painful, detail in subsequent posts.
When building your iPhone application you need to keep in mind that you need to provide a discrete unit of functionality. The iPhone is not the platform on which to be deploying monolithic applications. If the consumer of your application needs to pick from a lengthy menu of features to utilize on the phone, then your application is not finite enough. Keep the scope small and provide a very clear, distinct purpose for your app. Before writing your application code, jot down a single sentence that describes the problem your application solves, and write down another sentence that describes the functionality contained in your application. If you have a tough time narrowing the functionality of your application down to a single sentence, perhaps it is not meant to be an iPhone application, or perhaps you need to break it down so that some of your app functionality is delivered via iPhone and the rest via traditional application means.
Think about the usage pattern of the iPhone. iPhone users are carrying the device with them, but it's not a laptop. It doesn't tether, and in general (unless showing it off to crowds of jealous fans) the iPhone is not out and active for long periods of time. Here's a really good template to look at:
Consumer: Hey... I really need to (discrete application functionality)!
*consumer whips out the iPhone*
*consumer does 30 seconds or less worth of poking around*
Consumer: Damn. I am so glad I had the iPhone and access to (your application).
Obviously there are exceptions to this rule, but the bottom line is that when you are designing your iPhone application and determining what functionality you are going to expose to iPhone users, make sure you keep this one rule in mind:
Your application should integrate with the standard workflow of an iPhone user. In short, it should be dead simple to use, it should be quick, responsive, and provide a very clear, obvious set of functionality. It should not take excessive tapping. It should be an in and out process that is over and done with quickly providing a maximum amount of value with a minimum amount of suffering to the user.
If you build your application design in terms of thinking about rapid, quick, purposeful sessions then you're on the right track.
The iPhone is quite a capable multimedia device, capable of playing Quicktime videos. While you cannot use flash, the iPhone is really, really good at playing videos and listening to music. It is an iPod, after all (especially the iPod touch which is..well...an iPod!). Keep this in mind when building your application. Using Quicktime Pro you can encode directly for the iPhone and you can use reference videos that will automatically provide the right video based on the requester - so you can potentially share the same .mov file that points to an iPhone movie when an iPhone wants it and points to a high-res movie when a desktop browser wants it.
Keep in mind the connectivity requirements of the device when building an iPhone application. An iPhone application is not an application that is bursting with rotating, flipping, animating, flashing crap. If you look at the suite of applications on the iPhone, you can use the phrase "elegantly spartan" to describe them. They are quick, short, to the point, but they look good doing it. Your application should do the same. Do not attempt to cram a pile of stuff into your application that will cause the user to download 2MB over an EDGE network. Even on WiFi, things can be slow depending on what you're downloading.
Keep your content lightweight. Avoid the lazy trick of using the HTML tag to resize images. When rendering small content for the iPhone, make sure the source content is also small. Use stylesheets instead of littering your page with inline styles dropped onto table tags... These are all standard rules for keeping your content lightweight and maximizing the use of cached content.
I've been aluding to this in earlier paragraphs. iPhone users expect the applications on their iPhone to look and operate a certain way. It isn't rocket science, and it's actually quite easy to imitate the look and feel of native iPhone applications from inside a browser, and I'll be doing some posting on this as well. The bottom line is that if you want your application to feel as though it belongs on an iPhone (which you do... yes, you do...) then it needs to conform to the standards and guidelines that are already there implicitly by the applications that came with the phone. If you need guidelines on how your app should operate, use an iPhone. 20 minutes of use and you'll know exactly how your application should look and behave.
You need to always be aware that the iPhone is a device with a relatively small screen. In addition to it being a device with a small screen, it is not a device that allows the user to easily make precision clicks. In short, you should assume that the user will be tapping on your interface with the delicacy of a sledge-hammer. Make the interactive pieces of your application big and easy to 'hit' with a finger. I'll be going into the concept of reacting to finger-touches within a browser in an upcoming blog post. There are very specific dimensions you need to keep in mind when building your app, including the idea that you want to avoid losing all pertinent information when the virtual keyboard pops up.
While it might be tempting to try and so some really fancy Ajax stuff with the iPhone there are some limitations. For example, there is a "dead man switch" on the JavaScript running inside the mobile version of Safari. If you try and do something in script that takes too long, Safari is going to (rightly so) assume you're dead, and quit the script. This is an essential feature that keeps the phone highly reactive so that even if some idiot decided to do a long-running synchronous process in JavaScript on the iPhone, the user can still answer an incoming call. Without this, phone functionality (or other functionality as well) could be impeded or outright prevented by bad web coding practices. This means that you also need to keep an eye on long-running background stuff too - you won't be able to do background polling for incoming data to simulate "push" to an iPhone application. Also, JavaScript timers shut off when the device goes into lock mode or when the user hits "home" to take focus away from Safari. This goes back to keeping in mind the workflow of an iPhone user - they do not want to be sitting looking at a screen for 15 minutes watching data refresh.
Anyway, I hope you found this introduction to developing iPhone apps useful. It is intended to hopefully inspire you and get you thinking about the kinds of iPhone apps that you might want to be developing. Then, when I get off my ass and start writing more blog posts about other iPhone dev topics, you'll be ready with your idea in one hand and your web browser in the other.
Great start to the iPhone Developer Series!
Very objective and well-written. I am now a fan.
Thanks!!!
