What a difference a few years can make. Case in point: The way you implement mobile solutions for enterprise applications has changed dramatically. What caused this shift? The iPhone did, but probably not for the reasons you expect.
In my article "The Android Mobile Platform" (www .ddj.com/mobile/210300551), I mentioned that the iPhone liberated the mobile phone UI, expanding its capabilities beyond that of a keypad and function buttons. However, the iPhone changed the rules for writing mobile solutions in another way—the iPhone's Mobile Safari browser is a fully featured web browser. Its ability to view many Internet web pages and execute their scripts opens the possibility that the iPhone can handle certain corporate web-based applications. In this article, I examine the iPhone's web capabilities by porting a web-based problem-reporting form to it.
I admit when the iPhone was first pitched as a web-application platform, I was among many who clamored for the ability to write native iPhone applications. The phone runs a stripped-down version of Mac OS X, after all. Fortunately, after a year Apple has allowed us to do just that. In the interim, however, I've had an attitude adjustment in that I believe the iPhone can also serve—within limits—as a decent web-application platform. To understand my change of heart, some background information is in order.
Reports From the Field
The company I work for produces microcontroller units (MCUs). Ideally, these MCUs—and the development tools that write the embedded programs that execute on them—work perfectly. Realistically, problems happen. Much effort is put into collecting problem reports on the silicon and software, then routing this information to the appropriate engineering team. The team is responsible for correcting the problem, or devising a work-around. Often our field engineers transmit problem reports straight from the customer's site while the details are still fresh, and to get a team working immediately on a solution.
Currently, these problem reports, known as "Service Requests" (SRs), are filed electronically using a HTML/Javascript web page that executes in a laptop's web browser. This scheme avoids application and vendor lock-in, and the code is relatively easy to maintain. This solution works well—as long as you can access the customer's intranet or WiFi network. However, customers might deny our field engineer access to their network for reasons of security. Using an IT-department-certified smartphone to by-pass this connectivity problem by sending the SR through a carrier's cell towers is the obvious next step.
Several years ago, I was asked if the company's SR web page could be migrated to smartphones. A key concern was to avoid vendor lock-in. At the time, the choice was simple: Use Java Mobile to write the application. It would run on any smartphone or Blackberry with Mobile Java support. Due to other higher priority projects, the project was shelved.
Time passed and I got my hands on an iPhone. I was impressed at how many web pages it could display and interact with. The capabilities of its browser got me to wondering: How difficult would it be to port that SR web page to the iPhone? I decided to do a proof-of-concept rewrite of its code and find out.
