With their announcement of the Pre last week, Palm has placed their bet that great mobile applications can be built using the same open web technologies that drive the desktop environment today. Web applications that run on modern desktop browsers are constantly pushing the envelope of the types of applications that no longer require a proprietary platform-specific SDK.
When Apple first launched the iPhone in 2007 their first answer to developers was similar to Palm’s new OS. Apple gave a long talks at its 2007 Worldwide Developers Conference about how you can build great applications using standard web technologies. Unlike Palm’s webOS the iPhone web SDK was severely lacking in many areas. Apple has corrected some of these shortcomings in the subsequent releases of their mobile browser. Mobile Safari now supports multi-touch gestures, basic rotation tracking, and hardware accelerated CSS animations. Unfortunately, Apple’s open web SDK still lacks many of the most critical features that would allow developers to build applications that take full advantage of the mobile environment.
Everyone who owns an iPhone (or who has been holding out for an iPhone 3G) is bound to be excited about a lot of the new things the device can finally do, particularly the introduction of third-party applications. But those of us in the web development community have been itching for something further still: good web applications on the iPhone. This means we need a suitable replacement for mouse events. And boy did we get them! Though at first the APIs seem a little sketchy, once you’ve learned them you should be able to do amazing things in your application.
SMS is a great way to push small amounts of text to mobile users. But what happens when your application needs to send more than 140 characters of information? Most modern phones, including Apple’s iPhone, support the ability to launch the mobile web browser using the URL embedded in the SMS message. Your application can create a short URL that points to the content you need to send and send the URL in the body of the SMS instead of the content itself. The user experience varies from phone to phone. On the iPhone, the user simply touches the link; on other phones, there is usually a menu option that will activate the url.
The URL is subject to the same size limits as any other SMS message. Keeping the URL as short as possible is key, allowing you to send descriptive text along with the message to give the user an idea as to what they will be viewing when they click the link. URL shortening services like tinyurl will keep your URL to around 25 characters. Twitter users are no doubt familiar with this idea, whether they send Tweets from their phone or not.
Navigating a mobile app can be slow, especially on long pages and slow scrolling phones. Fortunately the xhtml mobile profile markup language supported by mobile phones provides a solution to finding links and starting phone calls inside the mobile browser.
Adding the accesskey attribute to link a lets users “click” on that link by simply pressing a number on their phone’s keypad. Valid values for accesskey can be 0-9,#, and * (all of the keys on a standard phone keypad). Displaying which key will activate a link is up to the application as most phones won’t tell the user that a link has an access key. Web site designers currently need to decide on a consistent way to inform users that an access key is associated with a given link. Most apps will use ordered lists where the order of the links corresponds with the access keys. Putting the number in brackets inside or next to the link is another way to denote the accesskey.
Today, I was eating lunch alone at a restaurant and reading some news via my iPhone’s EDGE connection. Suddenly, Surfin’ Safari – Blog Archive » Optimizing Page Loading in the Web Browser made even more sense.
Apple has been putting actual dollars into making Safari and the underlying open source WebKit really, really fast. Safari 3 is significantly faster than Safari 2. There was another big speed boost after Safari 3.0.
Mobile application development has many challenges. The announcement of Google Gears on Mobile Devices will help solve the problems of network connectivity, network latency, and limited bandwidth. On the desktop, a lot of the focus on Gears was its ability to allow applications to function when your computer was not connected to the network. In addition to building mobile web apps here at SitePen, we released Dojo Offline, which integrates the Dojo Toolkit with Gears to make building disconnected web applications even easier. As we all know, mobile devices lose connectivity with the network on a regular basis. Gears’ ability to keep the data that users need stored on the phone will be key to keeping mobile applications running even when networks fail to keep phones connected.
Google released the first preview of Android today. It is chock full of features and a great emulator, but there was one interesting omission.
Beyond what has been covered elsewhere, there are many attention grabbing features for mobile app developers:
- XMPP in the application stack, giving applications access to low-latency event driven messaging
- Location data (via GPS or cell-tower triangulation) accessible by applications
- SQLite for local data storage
- Applications can provide services to other applications… no need for 10 different photo taking apps
I recently had the opportunity to speak about Dojo on the iPhone at AjaxWorld West. The session was a straightforward, if not colorful, review of the current state of app development for the iPhone.
In preparing for the presentation, I needed to install several native applications in order to create high quality screenshots for my slides. As a result, I presented the audience with an overview of this information because there are a variety of useful development tools that require installation.
Because Christopher Allen gave a talk just prior to mine with an iPhone and iPod Touch Ajax overview, I dove right into specifics about the current issues and problems with iPhone development for Dojo developers. I wrapped things up by walking through a few working examples of Dojo-based applications, some optimized for the iPhone and others not. At the end of the talk, I promised a forthcoming, iPhone-optimized Dojo build that removes features and code for items not supported on the iPhone. We hope to have that ready in time for the 1.0 release of Dojo on October 31.
The press seems to have enjoyed the session, with Network World running a fairly lengthy article titled Unauthorized iPhone Apps Market Flourishes. I should make it clear that my talk focused mainly on pitfalls and frustrations that developers face, but the iPhone is by far the best mobile, open web, development solution on the market today.
I speak at a number of conferences and am giving a couple of talks later this year about Dojo on the iPhone. Of course, giving a talk without being able to show demos is frustrating, but giving a talk without having high-quality screenshots is silly. There wasn’t a solution known outside of Apple until recently, and it is still a bit of a process, or I daresay a bit of a quest. These instructions are for Mac users… I’m sure the steps are pretty similar for Windows users as well.