Dr. Dobb's Journal - November 2008 - (Page 27)

Steps to Writing an iPhone Web Page 1. Prototype and write the page’s code on a standards-compliant desktop browser, such as FireFox 3 or Opera 9.x I prefer FireFox because then I can apply Aptana’s Firebug to debug the Javascript. Note that for these two browsers that iUI’s buttons don’t render well, but it’s good enough for code testing. 2. If you haven’t already, modify the application’s interfaces so that they don’t use mouseover events. 3. Test and fix the page with the desktop version of Safari 3.x. The iUI buttons render fine on this browser. Clean up any quirks with events or side-effects to CSS selectors. 4. Do final test and revisions on the iPhone. Be prepared for another round of fixes for quirks and CSS side-effects. Also, you may have to tweak the interface for the small screen. Don’t forget to re-orient the phone and verify that you haven’t hardcoded the screen positions of any of the application’s elements or controls! Acid Test with Mobile Safari Once I got the web page working reliably on both the FireFox and Safari desktop browsers, it was time to try the web page where it really counted: Mobile Safari on the iPhone. I placed the program on a web site, downloaded it to the iPhone, and tapped away at the screen. When I tapped Submit, the verify function insisted I hadn’t made any choices. Because the code’s logic checked out on the desktop browsers, I knew the problem was rooted in changes to browser events for drop-down menus, since I relied on onchange events to transfer the choices into variables. However, after some tests, I discovered that the drop-down menus weren’t generating any events at all. I went to iPhoneDevWeb, a Google group where developers discuss issues with iPhone web page development. I spotted a report that explains where a bug in Safari prevents drop-down menus from producing events if they have a size attribute. It took only seconds to delete this attribute with the editor, and the dropdown menu choices began working. The next issue I had was with the radio buttons. Rather than small circles, they were stretched across the screen. By adding table cells, I could get the buttons to appear less elongated, which hinted that something in iUI was the culprit. A query on iPhoneDevWeb got me a response in about a day. This was a known problem with the input selector in iUI’s CSS file. A suggested work-around was to modify the CSS to position the button with margins. I decided to go in search of custom radio buttons instead, as the typical browser radio button doesn’t hew closely to the iPhone interface. Soon I found Checkbox and Radio Input Replacement (CRIR) written by Chris Erwin. This is more CSS and Javascript code that generates custom buttons and checkboxes. I dropped the radio button code into the program and got it working in short order. The only changes I made were to replace the small, light-green button image with the blue button image that appears in the Apple Mail application. I haven’t had any problems with iUI and CRIR’s styles and code creating conflicts. You can download CRIR from Dr. Dobb’s (see “Resource Center, page 5), with the modified button images, or at www.chriserwin.com/scripts/crir. Finally, when I attempted to enter text into a description field, the virtual keyboard kept disappearing after I typed a character. This I traced to the character count routine, which removed the focus from an input text field, updated the character count field, and reestablished the focus on the text field. This sequence of events interfered with the virtual keyboard’s operation. The solution was to modify the counting function so that it didn’t alter the focus. After these hurdles were cleared, I was able to tap in various choices, hit submit, and the iPhone’s Mail application appeared, with the message ready to go. The SR form’s code could stand some improvements, but it demonstrates that the iPhone would be a suitable platform for making field reports. All that remains to do is add the back-end formatting code, but that will wait until the IT department approves the iPhone as secure enough for corporate work. For more tips on writing iPhone web pages, see the sidebar, “Steps to Writing an iPhone Web Page.” Figure 3: The code in Listing Two rendered on the iPhone. While I made it resemble the original SR page (Figure 1), this isn’t a requirement. Better Browsing on Mobile The partial port of the SR web page shows that it’s not difficult to move a subset of a company’s web-based applications onto the iPhone. I was able to locate and use an offthe-shelf framework and custom Javascript software to impart an iPhone look and feel to the SR web page. Would using an iPhone for SR reporting risk vendor lock-in? Not really, which brings us back to the point I made at the start of this article. Apple’s iPhone has raised the bar on what’s acceptable for a smartphone browser. Mobile users will demand that their browsers be fully capable of viewing the web—albeit painfully slow at times—and executing light-weight web applications. Over time, the performance of both the platform and Javascript will improve; thereby expanding what a mobile phone is capable of doing for us. It should come as no surprise that Apple’s added SquirrelFish, a high-speed Javascript interpreter, to the WebKit rendering engine. You can expect other smartphone vendors to improve the capabilities of their browsers as fast as they can. When that happens, then we’ll run web apps on any phone that we choose. That’s an outcome that will be good for all of us. DDJ 27 November 2008 l www.ddj.com l Dr. Dobb’s Journal http://www.chriserwin.com/scripts/crir http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2008

Dr. Dobb's Journal - November 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer's Notebook Saving Open Source Conversations iPhone Building Your Own Web Server Green Telnet What's New In Boost Threads? Testing Service Oriented Architectures Test Case Generation, UML, and Eclipse Unit Testing Web Services C3 Programming The Agile Edge Swaine's Flames Effective Concurrency

Dr. Dobb's Journal - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.