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 drop-down 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.
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."