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

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. Javascript handlers to respond to mousedown events or to clickable elements instead. On the positive side, the form and document elements produce the usual onblur, onchange, and onfocus events. Finally, Apple’s human interface guidelines dictate that iPhone web pages should be small, and focussed on doing one thing very well. There are valid reasons for this: • The iPhone has a small screen. Cluttering it up with multiple windows or controls makes the web page’s functions difficult to intuit or access. Nor does Mobile Safari support multiple windows, other than the temporary display of alert or dialog boxes over the main page. • The network interface can vary in throughput. As the iPhone user interacts with your web page, the connection speed to the host can vary as the device moves between WiFi, 3G, and 2.5G wireless networks. Therefore, you must assume the worst-case scenario and design the page for the slowest network. Smaller pages load faster on slow networks, but this also limits the pages as to what they can do. • The iPhone has constrained RAM and processing throughput. Therefore, Mobile Safari can’t execute web pages with complex scripts. To appreciate this problem, point Mobile Safari to a heavily scripted web-based e-mail service and watch it take the page several minutes to render and respond. There’s a reason the iPhone comes with its own native e-mail application. In short, the iPhone’s small screen, varying network speeds, and limited processing throughput dictates that you keep your web pages small and simple. You can link to other, separate pages, but they should also follow these guidelines. Lengthy page loads and with sluggish responses are only going to frustrate users so that they don’t use your web application. Mobile Safari Overview and Behavior First, let’s get the nomenclature straight. While Apple calls an appropriately designed web page for an iPhone an “iPhone application,” I’m going to stick with the term “web page” because in the end, no matter how well the web page integrates into the iPhone’s look-and-feel, that’s what it is. Mobile Safari brings lots of features to the table for developers. It uses the same WebKit rendering engine that the desktop version of Safari uses. It’s also compliant with a number of the latest web standards: HTML 4.01, XHTML 1.0, CSS 2.1 and partial CSS 3, Document Object Model (DOM) 2, and ECMAScript 3, a Javascript standard. Mobile Safari also supports the AJAX XMLHTTPRequest remote scripting object. These features let the browser render most web pages accurately and manage interactive script sessions. You probably noticed the word “most” in that last sentence. It’s there for a reason. Mobile Safari doesn’t support Java applets, nor (at this time) does it handle Flash content. The browser is unaware of the phone’s filesystem, so there’s no downloading of plugins or other files. However, it does support cookies. Another difference is that in Mobile Safari, certain browser events have changed or have disappeared in order to support Apple’s gestures interface. For example, scrolling through a web page’s content by use of a finger flick requires that the iPhone’s gesture interface capture and consume events that might normally be construed as mouse events. Most mouseover events, if they appear in the browser at all, are now mapped to mousedown events. For the same reasons, the hover style is gone. If your web page uses mouseover events to implement menu choices, you need to rework the property to reveal or hide form elements, depending upon the choices the field engineer makes. The page gathers the information entered (such as the MCU type and the team assigned to the problem) and massages the data into a text-formatted e-mail that the company’s CRM system can read. All the engineer does to complete the report is inspect the e-mail for errors, then send it to our CRM system, where the SR is logged into a database and the selected team notified. My plan was to overhaul the SR’s UI because the layout of the web page’s elements were made for a large laptop screen, and not for a mobile phone. The iPhone has a 320×480-pixel screen, which is large by mobile phone standards, but still much smaller than a laptop screen. Rather than try to pack everything onto the small screen, I would instead display the array of choices as a list, where each list element serves as a link to a separate page. I wanted the web page’s iPhone-based front end to gather the SR information into the same Javascript variables used by the original SR form’s backend scripts. I could then re-use the fieldtested back-end functions to reformat the data for the CRM system. Along the way, I expected to contend with the changes in the browser’s event behavior, plus any quirks Mobile Safari threw at me. Some initial tests with simple HTML forms showed that Mobile Safari could present the Design Considerations The original SR web page was an HTML form that presents an array of drop-down menu elements, along with several text fields where you can enter information, as in Figure 1. Other fields display explanations that help guide users. The form relies on CSS to provide some styling, and it uses the display Figure 1: A portion of the original Service Request form as it appears on a laptop browser. November 2008 l www.ddj.com l Dr. Dobb’s Journal 23 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.