Fred Grott, a programmer who specializes in smart phone 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 smart phone, 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 smart phone market in a 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 smart phone platforms." ]
After experimenting with writing native code for the different smart phone platforms, I took a step backward and played with recoding my Web application. Instead of writing Java, C# or C++, I fiddled with CSS files to format the information for the screen and then wrote JavaScript to handle the events.
The results are quite good. While I can't recommend the solution for sophisticated games that rely heavily on an accelerometer for the user interface, I can say that just about everything else can be handled quite well in JavaScript. There's a reason why Steve Jobs toyed with limiting iPhone developers to this tight sandbox (i.e., Safari applications) at the beginning. It's pretty good.
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 smart phones, 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 semistandard 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 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.
The additions aren't limited to wormholes in the OS because all of the browsers support a variety of new hooks in the CSS specifications and in JavaScript. The BlackBerry browsers, for instance, will share your GPS location with the JavaScript interpreter, but only after notifying you that a nosy Web site wants to know your location. If you approve, the JavaScript code gets the longitude and latitude of your handset to do with as it will. The options might include reporting this data to some distant Web site.
The big smart phone companies are also embracing the Web as a major conduit for software and information by making it easier to integrate Web pages into the entire environment. Apple, for instance, offers a surprisingly broad set of meta tags that seem to turn any Web page into an Apple iPhone application. The tags simply enable the user to place a bookmark from a Web page on their start page, but the bookmark appears just like any iPhone application downloaded from the iTunes store. The URL form can be hidden, allowing the Web page to fill the screen whenever the user clicks on the icon. It's still a Web application that's written in JavaScript and CSS, but it appears to be written in Objective C.
The features aren't limited to visual gimmicks or DOM-level toys. Mike Kirkup, a manager of developer relations at RIM, says that the JavaScript interpreters in the mobile browsers are also going to be able to store information on the handset in a SQLite database.
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.
Go JavaScript, go
RIM's decision to embrace Google Gears reflects a bit of standardization that's slowly emerging. Google, of course, began the process by adding Google Gears to the current version of Android. Web developers can count on the JavaScript extensions being ready and waiting.
Dan Morrill, an Android developer advocate at Google, says that the Gears tool kit is just a start. The code is just a steppingstone to the features that are emerging in the HTML 5 standard.
"At the end of the day, we could start adding one-off or custom APIs to JavaScript, but that boils down to adding proprietary extensions to Android and that's not really what we want," Morrill explains. "We want to see them added to every browser as a standard."
The standardization is being helped a bit by the interest in WebKit. Although Google Android's browser is based on the same open-source WebKit engine embraced by Apple, it doesn't include all of the hooks. Apple's browser includes several features that allow the CSS for the page to be redefined whenever someone tilts the phone and changes it from landscape to portrait or vice versa. It also includes some JavaScript hooks for changing the extra CSS features.
Some of the differences change the core of the Web programming model. I've relied heavily on detecting the mouse-over and the mouse-move events on some Web sites I've designed because they make the site seem very interactive. These break badly on touch screens because the smart phone 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 mouse-move events.
Another solution is to use new events like the ones that Apple created to package the multiple touches that are detected by its phone. The gesture-start event begins when two or more fingers hit the screen, and the gesture-change fires whenever the fingers move a bit. If only one finger is left touching the screen, then the gesture-end comes along.
One of the more fascinating ideas in the iPhone version of Safari is the ability to set up transformation matrices in the CSS style layer. If these are manipulated in JavaScript, they can animate many simulated 3-D effects to create sprites. It's not OpenGL, but it's much simpler to use.
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.
Many of these templates rely upon the iUI framework from Joe Hewett. The framework is a savvy piece of JavaScript that converts standard HTML into the iPhone's characteristic menus. If the data is marked up with some standard HTML, the JavaScript will pick it apart and format it for the screen. The menus can be specified with UL tags, instead of lower-level Cocoa. If you're building your own mechanism, you might include this framework.
A touch of native Creating Web pages that display correctly on the phone isn't the only way to use HTML, JavaScript and CSS to build an application. There are also hybrid applications that are little more than thin wrappers of native code around HTML, CSS, and JavaScript. These let you do most of your work in Web languages but ship something that has all of the power and status of a native application. In Google's case, you build your application around a WebView object that acts like a browser window.
"There's a particular method that lets the developer inject an arbitrary object into the JavaScript environment," explains Google's Morrill. "You can make a little object in Android-coded Java and expose that into JavaScript, so JavaScript code can access it. This might be useful to make a local gadget container or a widget like the ones on Apple's Dashboard."
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 smart phones, and in theory it's possible to write one application that works on all of them.
The tools, distributed under an MIT license, include all of the native code to link the JavaScript interpreter with the parts of the phone that normally require native code. The GPS data from the iPhone, Android phone, and BlackBerry can be loaded with the same JavaScript calls to getCurrentPosition. The accelerometer data is also available for Android and the iPhone. The group hopes to extend the code base to support Symbian and Windows Mobile platforms and to cover more parts of the phone, including the camera and the graphics display layer.
"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, 3-D 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.
Although projects like PhoneGap can do a very good job of exposing much of the application layer to the user, they can't make JavaScript run with the speed and efficiency of tightly crafted C.
"There are limits to how far you can go with this model," explains Ed Burnette, author of 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 smart phone 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."
Peter Wayner is contributing editor of the InfoWorld Test Center.
This story, "The cross-platform option: Developing Web applications for smart phones" was originally published by InfoWorld.