Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Porting Javascript Applications to the iPhone

Tom Thompson is the head of Proactive Support for embedded products at Freescale Semiconductor. He can be reached at [email protected].

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.