Zend certified PHP/Magento developer

BuildMobile: Mobile Web Apps: Quick Wins

As we move though the book, we’re going to meet some relatively complex code for recreating native effects and behaviors. Thanks to some (fairly) standard hooks and APIs, however, there are a few tricks we can employ to add a bit of pizzazz to our apps without having to do much work at all.

For security reasons, mobile web applications are sandboxed away from many built-in features of the mobile device; for example, unlike native apps, they’re not able to retrieve a list of a user’s contacts, or take a photo with the device’s camera (yet). However, they do have the ability to open a few core applications and fill them with data just by using some carefully constructed hyperlinks.

3.1.1. Email

The simplest of these is the well-known mailto: URI scheme. On the desktop, these will launch your default mail application – and a smartphone does the same:

a href="mailto:feedback@startrackr.com?subject=Complaint"
  Send complaint
/a

This will bring up the device’s email app, with the subject line filled out with the variable we passed in, as Figure 4.3, “mailto: links will bring up the phone’s email app” shows.

Mobile Web Apps Quick WIns Figure 1

3.1.2. Phone Numbers

We can also assist in dialing a phone number using the tel: URI scheme. This will bring up (but not dial, of course) a phone number:

a href="tel:1-408-555-5555"
  Call in a sighting!
/a

In fact, for the iPhone, there’s no need to even wrap the number in a hyperlink. Mobile Safari includes a feature that automatically detects phone numbers in a page and turns them into links for you. “Excellent,” you may think – until the first time it tries to turn your product IDs into “dialable” phone numbers! Similarly, there’s a feature that turns address-like text into map links. But like any automagic feature, it’s not always what you want. If that’s the case, you can include tags in the head of your page to disable these features:

Again supported by the iPhone but not Android is the sms: URI scheme, which also takes a phone number, but opens up the text message application. At this point you might be worried about the limited support – fortunately, it’s not a big problem if a device fails to recognize a URI scheme, as nothing will break; the link will simply do nothing.

3.1.3. Maps

Turning now to maps, the situation is a little less ideal. If you want to open a map and zoom to a given location, there’s no widely implemented, standards-defined way to do it. A common method is to simply construct a URL that points to http://maps.google.com/ with a properly formatted latitude and longitude. Both iOS and Android will open this using the built-in mapping application rather than following the link in the browser:

a href="http://maps.google.com.au/maps?q=sitepoint"Visit us!/a

A more standards-friendly version is the geo: URI, which accepts a variety of values that will be interpreted as map data by the device’s mapping application. You can pass a latitude and longitude:

a href="geo:-33.87034,151.2037"Visit us!/a

Or a street address or business name and location:

a href="geo:0,0?q=123+Fake+St"Visit me!/a

This is certainly nifty, but it’s currently only supported on Android.

3.2. Form Field Attributes

With our links all polished up, let’s turn to forms. HTML5 drags the basic form into the future with a quiver of shiny new input types and form attributes, which are well-supported on the current crop of mobile devices.

The HTML5 placeholder attribute of an input field will populate the field with a user prompt, which disappears when the user focuses on it. This is commonly used to avoid the need for a field label, or to offer additional help text to the user:

fieldset
  label for="name"
    spanWho/span
    input type="text" name="name" placeholder="Star's name"/
  /label
  label for="tags"
    spanTags/span
    input type="text" name="tags" placeholder="Tag your sighting"/
  /label
/fieldset

The iPhone’s keyboard tries to help out users by capitalizing the first letter in a form field. Most of the time, this is what you want – but not always; for example, in the tags field in our sample form. The iPhone will also attempt to correct words it fails to recognize, which can become a problem for our celebrity name field. These features can be disabled via the autocorrect and autocapitalize attributes:

fieldset
  label for="name"
    spanStar/span
    input type="text" autocorrect="off" placeholder="Star's name"/
  /label
  label
    spanTags/span
    input type="text" autocapitalize="off" placeholder="Tag your sighting"/
  /label
/fieldset

Note that these attributes are nonstandard, in that they’re not in the HTML specification – at least for now.

Turn off the Automagic

If the majority of your form’s fields require these attributes, you can also add them to the form tag itself, to apply them by default to all fields in that form. You can then override this setting on any given field as required.

Another HTML5 feature that’s useful for mobile sites is the addition of a number of new input types. Beyond the traditional type=“text”, HTML5 provides email, number, url, date, and even color inputs. These will all display as simple text fields on most browsers, but the iPhone cleverly provides appropriate keyboards for the data in question – for example, including shortcut keys for @ and . (period) when you use type=“email”. For type=“number”, it will provide a number pad instead of a traditional keyboard, as shown in Figure 4.4, “A numeric keypad appears when focusing a number input on the iPhone”. The BlackBerry browser even provides date and color pickers for date and color input types.

Mobile Web Apps Quick WIns Figure 2

Here’s an example of these input types in action:

label
  spanTags/span
  input type="text" autocapitalize="off" placeholder="Relevant tags"
/label
label
  spanNumber of celebs/span
  input type="number" placeholder="Number of celebs"
/label
label
  spanTags/span
  input type="email" placeholder="Your email address"
/label

Support for all these features is inconsistent, so you’ll need to test your target devices. The good news is that even when support is lacking, the app won’t appear broken. Unsupported input types will simply behave as regular text fields, and users will be none the wiser.

Because the iPhone was the first to market, many of the iOS proprietary tricks have wide support on other devices; yet, not everyone wants to implement a competitor’s features! Thankfully, support for the HTML5 standard is growing, and that should trickle down to all the big mobile players soon.