Volume Number: 23 (2007)
Issue Number: 08
Column Tag: iPhone

Developing for the iPhone

OR: how I learned to stop worrying and love Web 2.0

by Marc S. Ressl

The iPhone has finally come to us. After several months of speculation, jokes, disappointments and surprises, the incredible device hit the streets. In this article we will talk a little bit about the recent developments in the iPhone scene, about the kind of applications you can write for the iPhone, and about the ways you can implement them. We'll also discuss some human interface aspects, so you can start writing intuitive applications that "just work".

Let's talk a little bit about history. It was January 9th, 2007, a beautiful Tuesday morning at the MacWorld conference in San Francisco when Steve Jobs introduced the "next big thing", the iPhone.

During the following months the hype and spin grew to epic proportions. Rumor had it that the iPhone would be capable of some sort of third-party application development.

But in June, at Apple's developer conference WWDC 2007, the unexpected happened. Based on the fact that the full Safari engine is inside the phone, Steve Jobs introduced a "very sweet solution" for developing apps. Web 2.0 applications can look and behave exactly like iPhone applications, he claimed.

Most people weren't expecting a full-blown SDK in a version 1.0 device. However, his announcement let down some developers, as Jobs was hardly telling anything new. This feeling was only exacerbated by Jobs' claims from a week before, when he said that "...you can't do that stuff in a browser", while discussing the iPhone's internal Google Maps client.

In spite of Apple's real reasons for not opening up the iPhone (yet), there are many advantages with web applications:

· Security. Keeping third-party web applications sand-boxed in Safari protects the device and networks from software pathogens. The https protocol provides secure communications over the Internet. A stolen iPhone is no security concern, as no sensitive application data is stored locally. There is also no need for an application certificate, as with Symbian.

· Installations. No installation is needed, as an application just exists as a URL, a username and a password. As a side-effect, applications get copy protection. Your code stays on the server.

· Updates. Web-apps only need to be updated on the server. Update once, update everywhere.

· Access. Being platform-agnostic, a web-app for the iPhone works on a regular web browser and on other mobile browsers as well, wherever you are.

· Usability. HTML controls, enhanced with JavaScript, provide all the flexibility you could expect from a traditional application. Besides, the pinch gesture always works as expected.

· New ways for earning revenue. You can charge for usage of your app. Another possibility is to add advertisements to it.

· Efficient data transmission. There has been some criticism that web-apps would have a large overhead. But Safari has a cache, and Web 2.0 apps can be highly optimized.

Of course, the list of disadvantages is also quite long:

· Web applications can't be stored on the local file system, they are not available offline. Forget widgets à la Mac OS X.

· No access to the iPhone's resources. No direct sound playback or recording, no direct access to the camera, no interfacing with Bluetooth, no direct access to the Internet, no direct access to the cellular network, no direct access to iPhone's sensors.

· Computationally intensive tasks are not possible. No sound, image or video processing.

· Limited access to the multi-touch interface.

· Containment. Since web-apps are contained in Safari, they cannot call your attention while Safari is out of focus.

· No direct links to the applications from the iPhone home screen. If you want to open an application you have to open a Safari bookmark, and this is odd.

· Bills. Data service bills might get pretty hefty when roaming.

· This is not confirmed at the time of this writing, but there appears to be no access to the data on the local file system.

Want to write an app for the iPhone? You should ask yourself first if it is feasible.

It should be feasible if your requirements are not on the list of disadvantages we just mentioned. Particularly well suited are applications that demand permanent connection, like instant messengers, remote control or directory look-up services. Group collaboration tools, regular office applications, calculators, converters, RSS readers, news tickers, and mobile mini-games are also good candidates.

But sadly there are many things that can't be implemented: Skype-like VoIP (obviously not in the interest of cellular operators), a voice recorder (for voice blogging purposes, perhaps?), games (I certainly would love MAME or ScummVM for iPhone), third-party media players (like VLC or MPlayer) and VNC (this might be possible with Web 2.0, albeit slowly). And many futuristic applications using the camera, microphone, Bluetooth or motion sensors are just not possible at the time being.

To see an example of what is feasible consider Google Docs & Spreadsheets. It is a powerful online office application that runs on the iPhone. And "iGoogle" is a personalized homepage with many customizable "Google Gadgets". It even accepts user-submitted gadgets.

It is clearly visible that Apple is heading in an open-standards, web-based direction. I myself can see many benefits in this move, as more and more online web applications might end up replacing traditional VPN systems with online, secure document viewing/editing and group collaboration tools. Might there be a big market about to be exploited?

How does one start writing a web application? Well, if you have something that serves web pages you are done, it'll work on the iPhone. I have always had a very good experience with AMP (Apache, mySQL and PHP), and do recommend it. You can easily find AMP (LAMP or MAMP) tutorials on the web. Other interesting frameworks are Ruby on Rails and Java+any application server.

As a first step, you should think about the web-app client-server communication. It will have a huge impact on people's patience (and maybe on their phone bills, too) if you transmit too much data. Remember the iPhone is GSM/EDGE.

The most straightforward approach is a classic HTTP request>response scheme. You display an HTML form, receive the variables from the form, and respond with the requested information. This simple approach works well for directory look-ups.

The problem with this scheme is complex interfaces that require minor screen updates (as a Web 2.0 office application certainly would). The overhead of HTML pages and forms will quickly render such a web-app unusable. Fortunately, one can use Ajax (Asynchronous JavaScript and XML) to solve this issue. JavaScript provides the XMLHttpRequest class that lets a web browser send asynchronous messages to a web server and receive a response. The JavaScript client on the browser can then update the page accordingly, with no reloading at all.

Let's see an example of a web page that automatically fills in a city name from a ZIP code. The HTML code for this example is:

<input type="text" id="zip" name="zip" onblur="getCityFromZip();"> <input type="text" id="city" name="city">

The onblur event starts the getCityFromZip() function when the user leaves focus of the zip field. Shown below is the JavaScript code that performs the look-up:

<script type="text/javascript" language="JavaScript">
// Create the HTTP object
function getHTTPObject() {
   var xmlhttp;
   if (typeof XMLHttpRequest != 'undefined') {
      try {
         xmlhttp = new XMLHttpRequest();
    } catch (e) {
         xmlhttp = false;
    }
   }
   return xmlhttp;
}
var http = new getHTTPObject();
// Look-up function
var url = "http://www.example.com/getCity.php?zip=";
function getCityFromZipcode() {
  var zip = document.getElementById("zip").value;
  http.open("GET", url+escape(zip), true);
  http.onreadystatechange = handleHttpResponse;
  http.send(null);
}
// HTTP response handler
function handleHttpResponse() {
  if (http.readyState == 4) {
    // Split the comma delimited response into an array
    document.getElementById('city').value = http.responseText;
  }
}
</script>

getHTTPObject() initializes the 'http' variable with an XMLHttpRequest object. A call to getCityFromZip() sets the request's http handler to handleHttpResponse(). It also starts a GET web request to:

   http://www.example.com/getCity.php?zip=[zipcode]

When the server answers, handleHttpResponse() takes over and updates the HTML element 'city' with the response from the GET request. In this example, the http response from the server is read directly. When you deal with complex data types an XML container might not be a bad idea.

How can you optimize your web-app? You can start by separating static and dynamic content. If static content is in a separate file it will be loaded only once, reducing data flow. You can get dynamic content with the XMLHttpRequest class described before. The same optimization can also be applied to JavaScript code. Consider creating a .js file for JavaScript code common to many URLs. Yet another optimization is to minimize the data flow of the dynamic requests: keep variable names short, keep URLs short. Try to bundle multiple dynamic requests to avoid HTTP overhead. Also, try to use HTTP GET requests, they have a smaller overhead than a POST (unless you have a lot of data). You can improve responsiveness by putting all user interface screens in a single .html file and using <DIV> styles to show only the one you currently need. It will take longer to load on the first time, but Safari caches content, so it will pay off soon. Final advise: enable gzip compression on the server, it helps when and if the browser allows it (Safari does). By following these guidelines, you will make many users happy.

Now you know a little bit about the internals of good web-apps, but there is still something missing: the user interface.

It is unfortunate that so many developers disregard user interface design. Horrible, unintuitive apps are out there, and this is particularly true of mobile phone applications. I am sure you can make a difference. UIs are not just decor, they are what your users work with.

The iPhone screen

The iPhone screen is 320x480 pixels. At 160 pixels per inch, this is two by three inches. But HTML page width is not important, as iPhone's Safari is resolution independent (it adjusts page width automatically). It is nevertheless a good idea to limit HTML page width to 480 pixels, as this is the iPhone's largest native resolution.

You should also consider that your application can be viewed in either portrait or landscape mode. When viewed in portrait mode, an application gets approximately 320x355 visible pixels. In landscape mode, about 195x480 pixels are visible. When scrolling down, additional 60 or so pixels get available from the top of the title/address bar.

You should always choose font sizes that are easy to read in both portrait and landscape modes.

Controls

A great user interface is grandmother-proof. iPhone has one, so make no exception! A typical finger is 1/2 inch thick, so you should never pack more than 4 or 5 buttons in a row. The buttons should also be approximately the size of a finger.

When selected, text-entry fields open up the virtual keyboard. Consider resizing all HTML input elements so that they are easily accessible on the iPhone's screen.

In order to send an email from a form, link to a mailto: [email address] URI. At the time of this writing, this is unconfirmed, but most likely you can start a phone call by linking to a tel: [phone number here] URI (RFC 2806 standard).

Interaction

This is probably the most important, but also the hardest aspect to achieve, as it depends on the application. General guidelines are: keep everything as clean as possible. Never have more than eight user interface elements visible at the same time. The human brain is not good at dealing with more than eight things at once. You can use an <iframe> to emulate the iPhone's scrolling center part of the screen. Attempt to use the same symbols and logic as in the rest of the phone. Consider the flow of the different screens of your user interface. Is everything as simple as possible? Is it possible to accommodate your user interface so that users don't have to re-learn things they know from somewhere else?

Always keep asking yourself how your UI can be improved. And read Apple's Human Interface Guidelines, they are an excellent reference.

Eye candy

If you want to create a nice user experience, attempt to integrate your style with the iPhone's UI style. Split content and presentation with HTML/CSS (this will also reduce data flow). You can do pretty amazing animations in JavaScript. Check out this site for some examples: http://script.aculo.us/

This article came to be because I was looking for an iPhone ssh client and simply couldn't find one. So, I started developing a Web 2.0 ssh client, as this was the one thing from keeping me buying an iPhone.

Luckily, I found the open-source Ajaxterm project. They were doing something similar to what I had in mind. Only the user interface had to be adapted.

So how does Ajaxterm work? It consists of a web client written in JavaScript, and a web server running in python. The web client periodically polls the server for screen updates. The web client also sends any key presses to the server.

What was needed to adapt Ajaxterm to the iPhone?

Ajaxterm gets key events through the JavaScript "onkeypressed" event. Unfortunately, this is not supported on the iPhone. Therefore, I added a text input control below the console screen, and several buttons for cursors, control and other special keys. The UI elements were arranged so the most common keys are close to where you actually work. The least used key combinations are hidden behind an alternative button control.

You can test the ssh client as well as download the source code at this URL:

http://www-personal.umich.edu/~mressl/webshell

In my opinion Web 2.0 (JavaScript + Ajax + XML + XHTML + RSS) is much more powerful than many believe. There are lots of limitations: no local storage, no access to iPhone's resources, limited computing resources, limited access to the multi-touch interface. But except for the applications discussed previously, I can't find a serious software limitation for iPhone.

Nevertheless, I hope that we will soon see a native iPhone software development kit. It will trigger a whole new generation of applications that we are not even capable of dreaming right now. Just imagine what a multi-touch controller with accelerometers and Bluetooth could do to a mobile game...

Marc S. Ressl is a senior developer in the cell phone business. He presently designs web applications using open-source technologies. He is also experienced in computer security and user interface design. You can reach him at mressl@umich.edu.