Put Your Content in my Pocket, Part II – A List Apart

Hopefully, you’ve now read the first part of this series and have started to think about the iPhone and how it relates to your own web development efforts. In this second article of the series, I’ll focus on some of the things that made me scratch my head and dig around for answers or otherwise impeded my work.

Article Continues Below

If you had any doubts about the relevancy of this series to your own web properties, last week’s announcement of Mobile Safari being available on the iPod sweetens the deal: there have been over 100 million iPods sold to date. The mobile web is no longer just about phones.

Let’s begin with the size of the screen. There are two sets of dimensions to consider, depending on how the user has oriented the device: 320×480 pixels (portrait) or 480×320 pixels (landscape). But you don’t get to use all of those pixels: the top status bar, where the signal strength, time, and battery indicators are located, uses 20 pixels of screen real estate. Then there’s the Mobile Safari address bar (60 pixels at the top) and toolbar (44 pixels at the bottom in portrait, 32 pixels in landscape).

Additionally, Mobile Safari—unlike other browsers—does not maintain a constant size for content viewing. Because of the small screen, the content area is constantly adjusted to maximize the space available for the task at hand. For one thing, Mobile Safari’s address bar moves out of the way as you scroll down the page. If the user is in portrait mode, the height of the viewport is 356px at the top and 416px further down the page (with a constant width of 320 pixels). In landscape mode, the dimensions are 208px or 268px by 480px.

Available screen real state with iPhone in portrait orientation

Available screen real state with iPhone in landscape orientation

The onscreen keyboard will also hide some of your content while the user is typing. In portrait mode, the keyboard uses 260px at the bottom of the screen (covering the toolbar). The portrait keyboard uses 224px.

Remember also that viewport scaling means that your content may not be displayed pixel-for-pixel within these dimensions. If you’d like to prevent that, you can use the tag to disable scaling—a very useful trick when you are trying to emulate the iPhone UI. You can disable scaling using this meta tag:

Smart phone, tiny brain#section3

The physical size of the display is not your only limitation. Unlike your desktop, with its gigabytes of memory, the iPhone has a much smaller area to store data. The four or eight GB of storage on the iPhone is for files, not for caching data like web pages.

Only Apple knows how much RAM is actually in the iPhone. What we do know are the limits imposed by the Mobile Safari browser when loading a page:

• Each text resource must be less than 10 MB (.html, .css, and .js files as well as any other text-based resources).
• Images must be less than eight MB uncompressed, calculated as width x height x four bytes. In other words, less than two megapixels. (The exception: JPEG images up to 32 MB will be loaded, but automatically resampled down to the eight MB size.)
• Animated GIF graphics must be less than two MB.
• Total page content size should be less than 30 MB.

Not only are there limits on how much data can be stored, but there are limits on how fast it can be processed. Again, Apple is keeping quiet about the CPU that’s in the phone, but it’s rumored to be about 400-600 mhz. Compare this with your desktop that’s running three or four times as fast.

To get an idea of the performance differences between the two platforms, I ran some simple benchmarks. The test results show that the iPhone executes JavaScript about 80 times more slowly than an average desktop computer. If your application takes 1/10 of a second to execute on your desktop, it could take up to eight seconds on the iPhone.

Because of the memory and speed limitations, the JavaScript interpreter also places limits on your code: a maximum of 10 MB of data (objects) can be created, and any JavaScript that runs for more than five seconds in a function call will be terminated with an exception.

Note also that scripts will pause frequently to minimize CPU usage. Scripts will not run during a phone call, if a window is inactive, or if another iPhone application is running. Scripts will continue to run during QuickTime playback—though there is no way to control the playback with a script.

Eight windows OK. Nine? Nein.#section4

Finally, there are limits in the Mobile Safari browser itself. The user is only allowed to open a total of eight windows. You can create a new window using either window.open() or “_new” as a link target attribute. If you try to open a pop-up when there are no windows left, the user will see an error (“Could not open a pop-up because there are too many pages open”) and the page load will fail. This also triggers a bug in the current version of Mobile Safari: the browser history in the original window becomes unusable. My advice is to open links in the same window and let the user control the creation of new pages.

As you explore the iPhone, you’ll be happy to learn that the browser works surprisingly well. Still, there are cases where functionality is either missing or behaves differently than it does on the desktop.

Much of what’s missing in Mobile Safari is missing because the user is working with a finger, not a mouse. There are no gestural equivalents to many familiar desktop actions, so corresponding events cannot be generated. When developing on the phone, you’ll find that events for cut/copy/paste, drag and drop, or selection changes (select/unselect) do not fire. Other events behave differently on the phone—most notably mouseDown, which fires after the completion of a tap instead of at the beginning.

In a similar vein, you’ll find that there is no multiple-selection mechanism, since there is no Command or Control key to use while tapping. This may be a good thing: how many sites have you seen with a note to “hold down the key” next to the element? Multiple selection is not an intuitive action for many users.

It’s not surprising that the showModalDialog() method doesn’t work either, since there are no such windows on the iPhone. The same is true about the print() method—there is no way to get printed output from the phone.

There are also issues that arise because of the simplified user interface. After using the phone for awhile, you’ll notice that there are no open or save dialogs. Indeed, there is no file system that’s visible to the user, so it’s not surprising that the

does not work—there’s no way for a user to pick the file to upload.

if ("showModalDialog" in window)
  {
    // show a modal dialog
  }
  else
  {
    // the iPhone cannot show
    // a modal dialog, so do
    // something else
  }

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) »
AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 »
Mobile/1C25 Safari/419.3