Fred Grott, a programmer who specializes in smartphone applications, has two models for his business: He can write specialized applications in native code that take advantage of all of the features of a specific smartphone, or he can write a Web application that works in the Web browsers of all of the top devices.
"Guess which one of those business models [needs] $15K in seed capital and [which] one is in the $250,000 range?" he asks. Given the economics, Grott's choice is simple. Take a standard Web application, add a bit of logic that tests the type of Web browser, and then send back slightly customized versions formatted to the screens of smaller handsets.
Developers are attacking the smartphone market in any number of ways, but one of the most overlooked is the customized Web application. The high sales figures from Apple's App Store seem tantalizing, but native code is not always the best solution.
[ Go native with Apple iPhone, Google Android, RIM BlackBerry, Palm, Nokia Symbian, and Windows Mobile. See "A developer's-eye view of smartphone platforms." ]
There are a number of reasons why HTML works well in this environment. It was designed from the very beginning to mark up documents without regard for the size of the display. Although Web designers have always chafed at the lack of control for errant DIVs, the results will often look quite good on the smaller display. Picky designers will still want to come up with custom CSS files and even some custom markups for the smaller screens of the smartphones, but the default is often serviceable.
A second major advantage is the popularity of WebKit, an open source library that renders HTML on the page. The iPhone and Google Android both use WebKit directly, and now Torch Mobile is making a WebKit-based browser for Windows Mobile. Eliminating the incompatibilities among mobile browsers makes it a bit easier to develop cross-platform tools. Android may run Java and the iPhone may be built on Objective C, but the same application can reach both via WebKit.
Some developers lament that semi-standard platforms such as Adobe Flash aren’t well-represented across all of the phones. That may not be as unfortunate as it seems. Many designers love Flash because it lets them lock down text and pictures to hard-coded coordinates, something that may look good on a normal screen but will fail badly on the smaller mobile screen. It's hard to write up Flash that runs well on both large and small screens, so the empty hole may be a blessing.
Swift browser tricks
The major device platform vendors have added a variety of different enhancements to their browsers that let you tap into some but not all of the features of the handset. Many of these additions are a bit ad hoc, but they're still quite powerful. Apple's iPhone, for instance, watches for calls to the domain maps.google.com, then redirects you to the native Maps application outside of the browser. You can integrate your application with the native Maps application just by limiting your URL to the right standard format.
This direction will make the handset more a stand-alone machine and less of a dumb client, something that is mainly practical.
"It's the unfortunate reality of mobile coverage today. You have to provide good service out of coverage," explains Kirkup. "We're going to be supporting Gears and SQLite, and the ability for Web applications to persist information offline."
This twist could make it easier to build lighter applications that put less stress on the wireless networks. The handset can store much of the working data locally and send copies to the server farm only occasionally. It's not exactly a typical client-server model but a hybrid that crosses the freedom of the stand-alone desktop with some of the deployment simplicity of the client-server model.
Dan Morrill, an Android developer advocate at Google, says that the Gears toolkit is just a start. The code is just a stepping stone to the features that are emerging in the HTML5 standard.
Some of the differences change the core of the Web programming model. I've relied heavily on detecting the mouseover and the mousemove events on some Web sites I've designed because they make the site seem very interactive. These break badly on touchscreens because the smartphone can't distinguish between a touch that is intended to move a mouse and a touch that is intended to manipulate the size and position of the Web page. I would touch the screen to move the mouse to interact with a control and the iPhone would think I wanted to shove the page around to look at a different part.
The solution is to abandon these events and switch over to buttons to manipulate the screen. I added new buttons that move a cursor left and right instead of letting the cursor track the mousemove events.
Another solution is to use new events like the ones that Apple created to package the multiple touches that are detected by their phone. The gesturestart event begins when two or more fingers hit the screen, and the gesturechange fires whenever the fingers move a bit. If only one finger is left touching the screen, then the gestureend comes along.
These sorts of innovations are slowly being absorbed by the major programming frameworks. WordPress, for instance, comes with a theme that will reformat the data especially for the handheld screen. The theme automatically tracks the user-agent of the browser and applies the customized CSS and HTML changes to iPhone users only. Similar efforts are making it relatively easy for programmers to upgrade sites that rest upon Drupal, Ruby on Rails, Joomla, and many other content management systems.
A touch of native
This flexibility is spawning some hybrid frameworks. One of the most fascinating is PhoneGap, a cross-platform collection of tools that wraps around a Web application and turns it into a stand-alone application. The project has constructed native wrappers for the major smartphones, and in theory it's possible to write one application that works on all of them.
"There are not necessarily apps that should be written using PhoneGap instead of being written natively," explains Dave Johnson, the PhoneGap developer responsible for the BlackBerry part of the code base. "But certainly PhoneGap makes it easier to do things like converting an existing Web app to run on the iPhone or Web mashups that might mean a lot more work if written for the iPhone natively."
Johnson explains that some areas of the underlying API like the OpenGL display layer are out of reach of the PhoneGap model because of performance. If you want to build a fast, three-dimensional game, native code is the only solution.
There are also trickier challenges to working with PhoneGap. A clever feature can turn into a dangerous bug if it opens up some of the underlying iPhone API to any random Web site.
Johnson rejects the idea of building a PhoneGap browser for general use because it could expose these features to dangerous manipulation. It would be possible to generalize the project, so any Web site could activate the features just by including the project's gap.js file in the HTML.
"We would be hesitant to suggest such a thing because of security concerns," Johnson says. "Opening up the iPhone APIs to any Web site could clearly pose a security threat."
Stars of the small screen
Johnson notes that the group is actively searching for volunteers to port the code to other phones. "We are looking for people to take up the cause of Windows Mobile and Symbian," he says. "On Symbian we are hoping to use S60WebKit, which is their version of the same WebKit browser as on Android and iPhone." It may be a bit trickier to work with Windows Mobile phones, he says, but he thinks there might be some possibility to link in libraries from Firefox.
"There are limits to how far you can go with this model," explains Ed Burnette, author of the book "Hello, Android." "If you need a high level of interactivity, immersive media, or access to local resources like disk space, then you'll need to use the native development environment for the device."
He adds, "I think it's telling that many popular Web applications such as Amazon, eBay, Facebook, and Twitter have been re-implemented as native smartphone applications. The Web versions work OK, but the user experience is better with an application that is customized for the device in a way that Web apps simply can't be today."