While working on version 2 of BikeNav, I attempted to make some improvements not only to the app itself, but also to my development and build environment. Streamlining the process of minification was one of the goals I had in mind. The following step-by-step guide illustrates how I integrated YUI Compressor into the BikeNav Xcode project, which in itself is a PhoneGap project. Nevertheless, this can be applied to any mobile web application that stores assets (HTML, CSS and JavaScript) on the device itself.

Step 1: Download YUI Compressor

Obviously we need to download YUI Compressor first. After downloading and extracting the ZIP file, we end up with a folder yuicompressor-[version-number]. I decided to copy that folder into my iOS project folder into a directory tools, that I had created earlier. The final path to the YUI Compressor folder would be:

/Users/komenda/Documents/PhoneGapApps/BikeNav2/tools/yuicompressor-2.4.2

Step 2: Create a Shell Script File

Since YUI Compressor only handles minification for us, we need to make sure that our JavaScript and CSS files are concatenated into one file each before fed to the Compressor. Also, in order to include this step into the iOS build process, we need to point the build settings to some file it can execute. I decided to create another folder in my iOS project directory called scripts in which I created a shell script called bikenav_build.sh which will hold the shell commands to concat the files first and then call YUI Compressor to minify them.

$ pwd
/Users/komenda/Documents/PhoneGapApps/BikeNav2/scripts
$ ls -l
total 8
-rwxrwxrwx@ 1 komenda  _lpoperator  1098 Nov  8 15:51 bikenav_build.sh

Step 3: The Build Script

rsync

In order to be able to do development in the browser before pushing anything on to the iOS Simulator or the device, I had set up my dev environment in such a way that I am serving all the BikeNav code from within my local Apache DocumentRoot (since there is no server-side processing involved, Apache is not even necessary, but because I store all my other projects in there as well, it keeps things nice and tidy). The path and folder structure looks like this:

$ pwd
/Users/komenda/Webroot/BikeNav
$ ls -l
total 264
drwxr-xr-x  18 komenda  _lpoperator     612 Nov  8 16:35 audio
drwxr-xr-x   5 komenda  _lpoperator     170 Oct 24 17:11 css
drwxr-xr-x  27 komenda  _lpoperator     918 Oct 29 16:46 img
-rw-r--r--   1 komenda  _lpoperator   12497 Nov  8 17:48 index.html
drwxr-xr-x  13 komenda  _lpoperator     442 Nov  8 15:49 js
-rw-r--r--   1 komenda  _lpoperator  116575 Aug 17 17:33 phonegap-1.0.0.js

Once I reach a certain point during development where I feel it is time to try things out on simulator or device, I sync this directory with the www directory inside the iOS/PhoneGap project. A great tool to do this is rsync, which already comes with Mac OSX. The following command is how I run rsync when working on BikeNav (from inside the scripts directory in the iOS project). For details on rsync command line options please refer to the documentation.

rsync -avz --exclude 'index.html' --delete ~/Webroot/BikeNav/ ../www/

This is also the first thing I put into the bikenav_build.sh script:

#!/bin/bash

echo "Custom BikeNav build script"
echo "==========================="

echo "Step 1: rsync files from web directory"

rsync -avz --exclude 'index.html' --delete ~/Webroot/BikeNav/ ../www/

Concatenation

As mentioned above, we need to concatenate our JavaScript and CSS files into one single file each before passing it on to the YUI Compressor for minification. For this, we simply use the Unix cat command like so:

cat ../www/js/one.js ../www/js/two.js ../www/js/three.js > ../www/js/combined.js
cat ../www/css/one.css ../www/css/two.css > ../www/css/combined.css

These two commands create two new files, combined.js and combined.css, each holding the contents of the JavaScript and CSS files, respectively. With that, we are now ready to give the YUI Compressor something to…well…compress.

Minification

Now we can send YUI Compressor to work to give us a nicely minified JavaScript and CSS files:

java -jar ../tools/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -o ../www/js/bikenav.min.js ../www/js/combined.js
java -jar ../tools/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -o ../www/css/bikenav.min.css ../www/css/combined.css

This will create bikenav.min.js and bikenav.min.css in their respective directories, based on the concatenated files created in the previous step. With some additional output and commenting as well as deleting the concatenated files after minification (since we don’t need them any more after that) the final bikenav_build.sh script looks like this:

#!/bin/bash

echo "Custom BikeNav build script"
echo "==========================="

echo "Step 1: rsync files from web directory"

rsync -avz --exclude 'index.html' --delete ~/Webroot/BikeNav/ ../www/

echo "Step 2: minify JavaScript and CSS files"

echo "=== JavaScript ==="
echo "concatinating files"

cat ../www/js/one.js ../www/js/two.js ../www/js/three.js > ../www/js/combined.js

echo "minifying files"

java -jar ../tools/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -o ../www/js/bikenav.min.js ../www/js/combined.js

echo "removing combined.js"

rm ../www/js/combined.js

echo "=== CSS ==="
echo "concatinating files"
cat ../www/css/one.css ../www/css/two.css > ../www/css/combined.css

echo "minifying files"

java -jar ../tools/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -o ../www/css/bikenav.min.css ../www/css/combined.css

echo "removing combined.css"

rm ../www/css/combined.css

Step 4: Integration into iOS Build Settings

Now that we got our build script ready, we need to integrate it into the build process of our project in Xcode. The following instructions are based on the Xcode 4 user interface.

1. After opening the project, make sure that the “Project Navigator” view is selected
2. Select the top level project, in my case it would be BikeNav
3. In the project editor window, select the target, BikeNav in my case
4. Select “Build Phases”
5. In the lower right corner, select the + sign labeled “Add Build Phase” and select “Add Run Script”

After going through these steps, a new bar in the sequence of Build Phases will show up labeled “Run Script”. Because we want to run our build script before any data is copied onto the simulator or device, we need to move it up in the sequence (I put it right after “Target Dependencies”). Now we only need to specify the path to the build script and how to run it. Therefor, in the text area inside that “Run Script” phase, I put the following:

cd /Users/komenda/Documents/PhoneGapApps/BikeNav2/scripts
./bikenav_build.sh

For better illustration, have a look at this screenshot, showing how that “Build Phase” section should look like after you added our build script.

Step 5: Testing

To test whether everything works correctly, build and run your project either on the iOS Simulator or an actual device. To verify that the script is being run, select the “Log Navigator” in the Xcode UI and then “Build [Projectname]” in the left sidebar. In the “Build target [projectname]” section in the log output you should see an entry “Run custom shell script ‘Run Script’”, which should show the familiar commenting messages we put in the shell script.

As a sidenote, of course in order to use the minified files, these need to be properly referenced in the index.html of your project.

The iSpeech demo page gives you an idea of the power of the API by providing a regular text input and being able to turn any text into spoken words. Let’s have a closer look now as to what is required to make this work in a web application.

Step 1: Sign up for a Developer Account and set up an API key

Signing up for a developer account is a requirement in order to use the API. After creating your account and logging in, you can create a new API key. Fill in the form and select “Desktop, Web, Other” as the application type in order to be able to use iSpeech’s REST API.

Step 2: Trying out the API

After creating an API key, you should find it in your list of available API keys. Clicking on “Settings” leads you to a form where you can set certain parameters for the text-to-speech functionality, like file formats, bit rates and frequency as well as add some more information about the app that uses the key. For this step, we just want to try out the API and get some text converted into speech, so the first thing we need to do is familiarize ourselves with how the API request is constructed. iSpeech provides good documentation on that and gives us the general layout of the request:

http://api.ispeech.org/api/rest?apikey=YOURAPIKEYHERE&action=convert&text=This+is+the+text+I+want+to+convert

Now we only need to replace YOURAPIKEYHERE with the API key we created in Step 1 and copy that request URL to the address bar of our browser or create an HTML5 audio element like the one below to embed in our HTML document.

Step 3: Tweaking the Request Parameters

The attentive reader might have noticed, from looking at the source code of the audio element in step 2, that we need to provide several fallback versions in addition to the MP3 format that the iSpeech API generates by default. This is necessary to satisfy the different codec requirements by modern browsers. To achieve this, the iSpeech API has a format parameter, that lets us specify the format in which we would like the audio piece to be returned to us. A complete list of supported formats can be found in the iSpeech API documentation.

If we want to use the Ogg Vorbis format, we can specify this like this:

http://api.ispeech.org/api/rest?apikey=YOURAPIKEYHERE&action=convert&text=This+is+the+text+I+want+to+convert&format=ogg

We can also specify a different voice using the “voice” parameter:

http://api.ispeech.org/api/rest?apikey=YOURAPIKEYHERE&action=convert&text=This+is+the+text+I+want+to+convert&format=ogg&voice=auenglishfemale

It is also possible to slow down the voice by providing a “speed” parameter with values between -10 (very slow) and 10 (very fast). However I noticed that not all voices provided by iSpeech support this parameter.

http://api.ispeech.org/api/rest?apikey=YOURAPIKEYHERE&action=convert&text=This+is+the+text+I+want+to+convert&format=ogg&speed=-5

Sounds great (literally), but…

By this point it is probably obvious that being able to use this text-to-speech API from within HTML documents using regular web technologies is pretty powerful. However, there is a catch to it in the name of costs. The web API key that we created is free for the first 500 words being transformed to audio by the API (you can check your key’s total word balance on the settings page of the key). If you exceed that limit, you have to pay, $50 for 1000 word credits to be exact, which essentially means that you can only feasibly use this API in some sort of premium app setting where your revenue generated can cover for these costs. While I would love this technology to be free, I can understand that it is not, considering the amount of work that goes into developing such piece of software.

The upside is, however, that iSpeech in addition to the REST API also offers SDKs for pretty much all popular mobile platforms, such as the iPhone, and API keys generated for these do not have any word quota imposed on them. Maybe another good reason to start learning Objective-C.

Step 1: Sign up for a Developer Account and get an API key

CloudMade lets you sign up for a developer account for free. After completing that initial step, access your account and click on the “Get API Key” button. Fill the details into the form presented to you, selecting “Web” as the platform and the “Free” pricing plan. Since we will not use any of the other features the API provides, the free version has more than we need.

Step 2: Create a token from your API key

In order to be able to communicate with CloudMade’s servers, you need to create an access token from your API key. This is done by sending an HTTP POST request to a particular authentication server as noted in their documentation. If you are using PHP, the following code can help you out (using Wez Furlong’s do_post_request function).

$apiKey = 'my-api-key';
$userId = 'your-generated-user-id';

// http://wezfurlong.org/blog/2006/nov/http-post-from-php-without-curl/
function do_post_request($url, $data, $optional_headers = null)
{
  $params = array('http' => array(
              'method' => 'POST',
              'content' => $data
            ));
  if ($optional_headers !== null) {
    $params['http']['header'] = $optional_headers;
  }
  $ctx = stream_context_create($params);
  $fp = @fopen($url, 'rb', false, $ctx);
  if (!$fp) {
    throw new Exception("Problem with $url, $php_errormsg");
  }
  $response = @stream_get_contents($fp);
  if ($response === false) {
    throw new Exception("Problem reading data from $url, $php_errormsg");
  }
  return $response;
}
$token =  do_post_request('http://auth.cloudmade.com/token/' . $apiKey . '?userid=' . $userId, '');

echo "generated token: " . $token;

Step 3: Requesting POI data along a given route

Equipped with the token from Step 2, we can now try to retrieve POIs along the route. The following example would do a search along the route for a maximum of 20 points of interest of type “cafe” from my place to Cupertino, within a radius of 1 kilometer and returning the data in JSONP format.

http://geocoding.cloudmade.com/[APIKEY]/geocoding/v2/find.js?token=[TOKEN]&object_type=cafe&along=37.36721,-122.03533,37.36756,-122.0354,37.36752,-122.03662,37.36672,-122.03607,37.36642,-122.03648,37.36429,-122.03288,37.33911,-122.03241,37.33763,-122.03239,37.32283,-122.03241&distance=1000&results=20&callback=mySuperCallback

The find method of the Local Search API lets you pass in various parameters, which are well documented. For the purpose of this article, the following are the most important ones:

• object_type: the API lets you choose from an extensive list of point-of-interest types
• along: vector of the route your are traveling along, i.e. a comma separated list of lat/long pairs
• distance: radius of the search are in meters
• results: number of results to return
• callback: signaling the server to return the response in JSONP format and specifying a publicly accessible JavaScript function to execute, passing in the response data

The result from the above request will come back as JSONP and look similar to the following:

mySuperCallback({
    "found": "3",
    "bounds": [{
        "json": ["37.33155", "-122.03642"]
    }, {
        "json": ["37.36805", "-122.03266"]
    }],
    "features": [{
        "id": "7367785",
        "centroid": {
            "type": "POINT",
            "coordinates": ["37.36768", "-122.03642"]
        },
        "bounds": [{
            "json": ["37.36768", "-122.03642"]
        }, {
            "json": ["37.36768", "-122.03642"]
        }],
        "properties": {
            "operator": "Starbucks",
            "osm_element": "node",
            "amenity": "cafe",
            "synthesized_name": "Cafe",
            "osm_id": "266625630"
        },
        "type": "Feature"
    }, {
        "id": "26073213",
        "centroid": {
            "type": "POINT",
            "coordinates": ["37.33155", "-122.03266"]
        },
        "bounds": [{
            "json": ["37.33155", "-122.03266"]
        }, {
            "json": ["37.33155", "-122.03266"]
        }],
        "properties": {
            "osm_element": "node",
            "amenity": "cafe",
            "name": "Bagel Street Cafe",
            "osm_id": "957085286"
        },
        "type": "Feature"
    }, {
        "id": "14342531",
        "centroid": {
            "type": "POINT",
            "coordinates": ["37.36805", "-122.03338"]
        },
        "bounds": [{
            "json": ["37.36805", "-122.03338"]
        }, {
            "json": ["37.36805", "-122.03338"]
        }],
        "properties": {
            "osm_element": "node",
            "amenity": "cafe",
            "name": "Peet's Coffee",
            "osm_id": "441987522"
        },
        "type": "Feature"
    }],
    "type": "FeatureCollection",
    "crs": {
        "type": "EPSG",
        "properties": {
            "code": "4326",
            "coordinate_order": ["0", "1"]
        }
    }
});

In our mySuperCallback function we can then use this data to e.g. plot each of the returned points of interest on a map, in addition to the given route.

Be aware of long routes

Attentive readers will notice that there is a slight flaw in the way the request is constructed. If you have a long route with a lot of waypoints that you are passing along in the request to the search API, at some point you will reach the limit of the maximum amount of characters you can pass along in a URL. One way to mitigate this is to drop every other entry from the array of waypoints if the number exceeds a certain limit. That way, the search will still be somewhat accurate (since you are only taking out points in between instead of cutting them off at the beginning or the end). A JavaScript example code could look like this:

maxWaypoints = 160; // a good threshold that I noticed works well for BikeNav
waypoints = [ ... ]; // array where each entry represents a waypoint along the route
no_of_waypoints = waypoints.length;

if (no_of_waypoints > maxWaypoints) {
    while (waypoints.length > maxWaypoints) {
        for (var i = 0, len = waypoints.length; i < len; i++) {
            waypoints.splice(i + 2, 1);
        }
    }
}

A couple of weeks ago I got contacted by someone from Bicycling Magazine, which has been providing the bike community with bike gear and equipment reviews, training plans, maintenance how-to’s and more for 47 years, that they would like to feature my application in their December issue. This was great news and really the best thing that could have happened, considering the state the development process was in. I had hit some technical difficulties when working on an update version of the application back in May and combined with higher load at work and less free time, I had lost interest a bit in improving the application. The interest from the magazine, combined with the news that the piece will be contributed by Ray Maker (whose blog should be your #1 destination if you are interested in any kinds of gear reviews when it comes to outdoor and endurance sports), gave me the spark that I needed to continue working and improving the app.

Motivated by this attention that I had received, I spent huge chunks of my spare time since to improve the app, which led to the release of version 2 of BikeNav on pretty much the same date—incidentally—as the publish date of the December issue of Bicycling Magazine. And just today I was able to pick up a copy and found, with great joy, a little paragraph about my app in the upper right hand corner on page 20. Nothing big. Nothing fancy. But still something.

BikeNav 2.0: The tech details

What was holding me back a little bit since the release of version 1 was that I was an earlier adopter of jQuery Mobile, having used their first alpha release for my initial version. The upgrade to a more stable version always seemed too painful and time consuming and so I kept adding hack after hack on top of an understandably buggy (in parts) version of the framework. In addition, I was also using a 0.9.x release of phoneGap to power BikeNav.

With version 2, both of the frameworks were upgraded to their most recent version. In addition, I also gave the application a bit of a UI overhaul, abandoning the black & white look from the initial version and introducing a new splash screen, updating the logo to feature a blue color tone instead of black and cleaning up the interface in general. I also introduced new features, like the ability to search for points of interests along a route using the CloudMade’s Local Search API and being able to add custom location pins to the map.

The attention that I got from the magazine and from the occasional user who emails with his feedback certainly motivates me to keep working on BikeNav. In addition to being a very useful app for bicyclists, it is also a great playground for me to see how far I can get with the hybrid mobile application approach, where the majority of the heavy lifting is done using web technologies.

So if you are a cyclist and haven’t checked out my app, please do so. And after you are done, feel free to send me feedback.

What is it?

I really like to use my bike as a clean way of transportation but when going from A to B by bike, it is especially vital in car-dominated USA to pick a route that preferably has some sort of bike lane in order for the cars to give you some space or where the speed limit is at a reasonable level (i.e. residential streets). The native map application on the iPhone already has routing functionality built in for public transport, walking and when driving with your car, but not for biking. Interestingly though, the desktop version of Google Maps has this functionality (launched in March 2010 for several cities in the US and Canada). So in order to fill this gap, I had the idea for BikeNav, which uses this Google Maps functionality to give the user the most bicycle friendly route from A to B.

Further details about the features of the application as well as screenshots can be found on the App Store as well as on my support page. Below I will focus more on an overview of the technical implementation of the application.

The Tech

After looking into Objective-C and native iPhone development, it became clear to me rather quickly that I should stay with what I am good at, meaning web development technologies. Objective-C as well as how all the different pieces fit together in XCode was just hugely confusing, which made me decide that if I can somehow use web technologies to achieve what I want then I am certainly going to go for that .

jQuery Mobile

I had to do some research at work on Mobile JavaScript Frameworks and looked into two of them that got mentioned quite a lot: jQuery Mobile and Sencha Touch. I had never really worked with jQuery and Sencha was completely new to me, but looking at jQuery Mobile, I realized that it might give me more freedom than Sencha with regards to being able to easily style and access the interface elements that I needed for the application. The only downside I could see was that, at the time, it was in Alpha 1 release, indicating that there might still be some bugs (which turned out to be true and I had to work around them while developing). As of this writing, jQuery Mobile is now in Alpha 4.1.

PhoneGap

Because I wanted to deploy my application on the Apple App Store, I had to find a way to somehow turn my mobile application into a native(-like) app. PhoneGap to the rescue. PhoneGap gives the developer the ability to wrap a web application (written in HTML, CSS and JavaScript) into a native shell that gives it the needed characteristics in order to push it to the App Store, the same way as you would if it were an Objective-C application. In addition, PhoneGap provides a JavaScript bridge, that lets you access native device capabilities (i.e. access to the contact list on the device) from within your application using JavaScript.

Lessons learned and “What’s next?”

Initially I made the decision to go with jQuery Mobile because I felt it would give me more flexibility with regards to being able to easily build up my interface elements, since the framework lets you build a mobile web app very much the same way you would build a web site or web app for the desktop. With Sencha Touch, it seemed that it would have been more difficult to come up with a non-standard interface (like I wanted to use) for my app, since all the control is in JavaScript, with very few things defined in HTML and CSS. Alternatively, I probably could have used Titanium as well, but again, I felt it would have been more of a challenge to get the positioning and styling of all the elements the way I wanted it—since Titanium also has an ‘all JavaScript’ approach.

Adopting early has its downsides

As I mentioned earlier, the slight downside to using jQuery Mobile was (and still is) that it was in an early Alpha release. I actually started developing with Alpha 1, meanwhile it is in Alpha 4.1. I only tried to upgrade once, about half-way through development, and noticed that lots of things had been broken by the update. So I reverted back to Alpha 1, and worked my way around the bugs and the missing features that just weren’t there at the time. Since I would like to also offer the application on Android phones at some point, I need to upgrade eventually, but I think I will wait until the framework is at least out of its Alpha state.

Bridging the gap

I am, however, very pleased so far with PhoneGap. Getting it installed was easy and building the application out of XCode code is very straight forward as well. All I had to do was copy my HTML, CSS, JavaScript and image files into the www folder of the project and hit ‘build & run’. Granted, I am not using the PhoneGap JavaScript bridge in this application to access native device features (yet) and I also haven’t used PhoneGap for building BikeNav for Android (yet), so there might be potential hurdles to overcome in this regard. But from what I have seen so far, the combination of jQuery Mobile and PhoneGap works very well for me.

In terms of new features, I would love to do some research on what options there are (if any) to do ‘text to speech’ in JavaScript (for reading out driving directions) as well as integration of Google Street View images into the application. If you like to bike (and you own an iPhone and live in the US or Canada), I would certainly encourage you to download it, try it out and give me feedback! Thanks.

What are phone web based application frameworks?

Essentially, these are frameworks that provide developers coming from a web development background a certain set of tools to use their current skillset (HTML, CSS, JavaScript) to build native or native-like mobile applications. PhoneGap and Appcelerator Titanium are the most popular amongst all the frameworks out in the wild. I got to play around with both of them recently and I am going to share a summary of my findings and a look from 10,000 feet at the two below.

PhoneGap

PhoneGap, developed by Nitobi Software, gained a lot of popularity in the web development world, because of exactly what got me interested myself. On their website, it says “Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iPod touch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.”. Sounded exactly what the web developer but wannabe-mobile-developer needs.

PhoneGap projects require the underlying SDKs (e.g. iOS SDK) to be installed and typically building the application happens from an IDE, e.g. Xcode. The developer puts his files into a www folder in the project directory. When building, PhoneGap then renders these files inside a native WebView provided by the OS-specific language (either Objective-C or Java). It exposes access to certain native device features, like Contacts, Accelerometer, Camera and Notifications, through the PhoneGap JavaScript API.

The actual interface of the app, however, is styled with ‘the usual suspects’, meaning HTML and CSS. Because of the fact that UI elements are styled with CSS, these can look significantly different to native OS interface elements (e.g. buttons), as well as the performance might be not as good as if native elements were used.

In the end, a PhoneGap application is essentially still a web application, wrapped inside a WebView. It still remains a web application that is displayed through rendering of HTML, CSS and JavaScript using a browser instance on a mobile device. It currently supports development for the iPhone, Google Android, Symbian OS, BlackBerry and Palm operating systems.

Example

The following example code is taken from PhoneGaps API documentation to illustrate the syntax of how a PhoneGap application is put together. In this specific case, the API is used to find all contacts with the name ‘Bob’ in any name field:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <title>Contact Example</title>

    <script type="text/javascript" charset="utf-8" src="phonegap.js"></script>
    <script type="text/javascript" charset="utf-8">

    // Wait for PhoneGap to load
    //
    function onLoad() {
        document.addEventListener("deviceready", onDeviceReady, false);
    }

    // PhoneGap is ready
    //
    function onDeviceReady() {
        // find all contacts with 'Bob' in any name field
        var options = new ContactFindOptions();
        options.filter="Bob";
        var fields = ["displayName", "names"];
        navigator.service.contacts.find(fields, onSuccess, onError, options);
    }

    // onSuccess: Get a snapshot of the current contacts
    //
    function onSuccess(contacts) {
        for (var i=0; i<contacts.length; i++) {
            console.log("Display Name = " + contacts[i].displayName);
        }
    }

    // onError: Failed to get the contacts
    //
    function onError() {
        alert('onError!');
    }

    </script>
  </head>
  <body onload="onLoad()">
    <h1>Example</h1>
    <p>Find Contacts</p>
  </body>
</html>

Appcelerator Titanium

Appcelerator Titanium was launched with the same promise like PhoneGap, namely to provide web developers, familiar with HTML, CSS and JavaScript, a tool to use these technologies to develop mobile applications on iOS and Android. In a way, Titanium reminds me of J2ME Polish, a library for Java Development on mobile devices that enables the developer to create native UI elements and style them using a CSS-like syntax. Similar to PhoneGap, Titanium provides a binding layer that maps JavaScript function calls to natively available APIs. However, here is where the similarities end. The main differences to PhoneGap are:

• Truly native applications. Unlike PhoneGap, Titanium actually translates the code into native application code. The application code, written in JavaScript, is being interpreted during runtime and through a bridge layer, function calls to Titanium.some_function invoke native application code under the hood.
• Just JavaScript, no more HTML & CSS. Previous to version 1.0 (current version is 1.5), Titanium followed a similar approach to what PhoneGap was doing. The application code would consist of HTML, CSS and JavaScript, whereas native device services were exposed using a Titanium specific JavaScript API. With version 1.0, HTML and CSS are gone. Code is written in pure JavaScript, using mainly functions that the Titanium API exposes. Apart from using it to access special device features (such as the camera), it also enables the developer to render native UI elements (such as tables, buttons, native maps etc.).

The obvious advantage of a native application is performance. The UI will perform much better if native OS elements are used, compared to rendering HTML, CSS and JavaScript in a browser instance to e.g. create a button. As a side effect, the native look-and-feel can easily be maintained.

Unlike PhoneGap, building and packaging does not happen inside an IDE, but through a special piece of software called Titanium Developer. This is the tool to set up new projects, configure, test and package them. Any IDE of your choice can be used to write the application code.

Example

Appcelerator provides a plethora of examples, all bundled up in their Kitchen Sink demo application, which can be downloaded from GitHub. The following example, taken from Kitchen Sink, shows how to hook up an event listener, using the Titanium API, and display an alert window:

var win = Titanium.UI.currentWindow;

var l = Titanium.UI.createLabel({
	text:'Shake your phone',
	top:10,
	color:'#999',
	height:'auto',
	width:'auto'
});

win.add(l);

Ti.Gesture.addEventListener('shake',function(e)
{
	Titanium.UI.createAlertDialog({title:'Shake',message:'it worked!'}).show();
});

Conclusion

Both Phone Gap and Appcelerator Titanium give web developers the opportunity to create mobile applications without the need to learn Objective-C or Java. After the build process, both frameworks provide the developer with a packaged application that can be installed on an actual physical device and published (e.g. using the Apple AppStore).

PhoneGap supports more Operating Systems and lets the developer essentially set up his application project like he would set up a website (e.g. with index.html, css, img and js folder etc.). PhoneGap applications are then wrapped by the framework inside a WebView during build time. This means that, upon execution, the rendering still happens inside a browser instance, which interprets the HTML, CSS and JavaScript. Compared to a truly native application, this likely means slow performance and additional effort to re-create a native experience.

Appcelerator Titanium only supports iOS and Android. Any application code is (as of version 1.0) written in pure JavaScript using mainly Titaniums JavaScript API. It seems more like a native code (Objective-C or Java) abstraction layer than code that resembles anything someone would recognize from the web development world. Unlike with PhoneGap, the developer ends up with a final software product that is truly native to the respective operating system. Because native elements are used for the interface (e.g. buttons, tables, views), the performance is better and no effort needs to be put in to recreate any native experience using HTML, CSS and JavaScript.

Finally, it highly depends on the requirements of the product which framework to go with. If the goal is to support as many operating systems as possible, then PhoneGap is probably the way to go. If true native-ness and performance is important, then Titanium will be the better choice. It is also important to note that only PhoneGap still holds true to their promise that a web developer can quickly jump in and use his skills to develop a mobile app. With Titanium, all the application code will be JavaScript, even the styling of elements happens through function calls (which is, arguably, still better to having to use Objective-C). An important factor for deciding which way to go would also be whether the respective JavaScript API provided offers the functionality needed for the application.

Resources

• Wikipedia: multiple phone web based application framework
• PhoneGap
• PhoneGap JavaScript API docs
• Appcelerator Titanium
• Overview over the Appcelerator Titanium architecture
• Titanium JavaScript API docs

The application on the mobile phone would give you a list of restaurants, bars, cafes etc. in your proximity, as well as details about their type of cuisine, opening hours, price range etc. and how other people have rated that particular place. Based on whatever the occasion was—whether you are planning a relaxed dine-out with your family or having a more intoxicated night with friends—the tool would recommend you the best place in your area.

While I was working on the prototype, writing my thesis and then putting the layout together in InDesign, I wasn’t thinking that a publisher would ever get interested in my work.

But the less you expect something, the happier you are when it actually happens. About 2 months ago I received an email from VDM Verlag in Germany saying that they found my thesis in the library of the university and would be interested in publishing it. “How awesome is that!”, was about the reaction I had. After putting all the required details about the book into their online system and reformatting a few things to fit their requirements, I got the confirmation that everything looks good and it is off to the printers.

And now, just in time for Christmas , I am happy to see my book being available on Amazon.com and Amazon.de. It is in German, so sorry to my non-German-speaking friends. I will most likely never reach the author status of my colleague Christian Heilmann, who wrote about 167 books about web development related topics, but I am very happy to see this and it makes me feel proud to see that all the work I put in at that time is now available to a wider audience. It is a really great feeling and I feel very content how it all turned out.

I would like to take this opportunity to thank Karl-Heinz Weidmann, who was my thesis advisor, and Werner Flatz, who I worked together with during the development of my application.

For a couple of years we have heard from experts that using mobile devices for using the Internet will become increasingly popular and will move peoples using habits away from the desktop and into the mobile world. Apart from Japan, this is not quite true yet. Mobile devices such as PDAs, cell phones and pocket computers are getting more and more popular and feature-rich, but it still seems quite tedious to browse web sites on small screens with limited interaction capabilities. Apple with its iPhone has done a great job and we can only hope that others will follow in terms of anticipating how users would like to use a mobile device and which features would help them in doing so.

From a developers point of view, it is not only time consuming, but also expensive to consider a fair share of devices out there for testing. Different resolutions, different screen sizes and different browser implementations form a pretty high number of combinations a developer has to cater for. Unless you have a very high budget for testing, this is not gonna be possible.

That is where device emulators and browser simulators come in handy. Luckily for a whole lot of devices out there, software programs exist that replicate the behavior of such a device on your computer screen. Whereas in device simulators you actually are able to navigate and interact with various parts of the underlying operating system (Windows Mobile, Symbian OS etc.), browser simulators provide you just with the interface you most likely will also find on a particular device (e.g. BlackBerry).

Below you can find a list of emulators and simulators which let you inexpensively test how your site will be displayed on the device. Unfortunately, all of them, except the emulator for the iPhone, can only be installed on Windows.

Windows Mobile Emulator

Installation

To install the Windows Mobile Emulator, first you need to download and install the following components:

• Virtual PC (for network capability)
• Emulator with Emulator images

Network Configuration

After installing the two items above, you can find the Emulator Images under Programs > Microsoft Windows Mobile 5.0 Images, which gives you a list of images for different types of devices, e.g. Pocket PC. When selecting one of these images, it fires up the Emulator and loads the respective device image. But before you can use it to test your own site, you need to configure the Network Settings to ensure proper connection to the Internet through your computer. For this, you need to do the following after the device has been booted up the OS:

1. Chose File > Configure > Network in the Emulator Application window
2. Check “enable NE2000 PCMCIA network adapter and bind to” (if you are using the Pocket PC image, it might be different for the other images)
3. Select your computer’s network connection card from the list (e.g. Intel PRO) and hit OK
4. On the (emulated) device itself, locate the “network card” settings dialog (on Pocket PC: Settings > Network Card)
5. Here, select “connect to: The Internet”
6. select “NE2000 compatible Ethernet driver”

Now you should have a connection to the Internet from the emulated device and can use Internet Explorer on the device to test how your site would look like on e.g. a Pocket PC.

I just noticed that there are more up-to-date version of the emulator and device images available from Microsoft. I have not actually installed and tested these, but I am just hoping the installation is as straightforward as with version 1.0 that I used.

iPhone

The oh so beloved iPhone also has an emulator on its own, which is called iPhoney. It can easily be downloaded from marketcircle.com and installed, but only on Mac OS X. The look and feel is pretty nice and neat and it also supports the physical device capability of switching from portrait to landscape mode when rotating the device. In the Web Development circles I heard rumors that iPhoney is, despite the slick look, not providing accurate results and is mere a simple browser window re-sizer than actually providing a correct implementation of the browsing capabilities of the physical device.

Opera Mini

Opera has a big market share when it comes to browsers on mobile devices with its Opera Mini. On their site, Opera offers an Opera Mini Demo/Simulator which can be used for testing your Web site. You can even call that site by using a parameter in the URL to call your site straight away, e.g. ?url=http://www.klauskomenda.com. Other people have also had a look at that Simulator and even provided an alternate implementation.

Blackberry

You can download one of the many simulators they have on their web site after registering with their developer network. After that, download and installation is pretty straightforward and you can then find the simulator under Programs > Research In Motion > BlackBerry Device Simulators.

The look and feel of the device emulator is pretty great and gives you a good understanding of what capabilities the physical device really has. Unfortunately, I was not able to get a connection to the Internet (from what I have learned you would need to connect to the BlackBerry MDS Connection Service, but how?). So, to keep it short, no testing on BlackBerry. Nice simulator though.

ACCESS NetFront

Another emulator for mobile devices is provided by ACCESS. The ACCESS Netfront browser emulator can be obtained from their web site, and can be launched by just running the executable from the ZIP archive. Upon launching the application, it took me a couple of minutes to figure out that hitting F1 actually gives you a menu from where you can select “URL” and type in the URL of your site.

Openwave simulators

From what I have heard, Openwave is also pretty popular on mobile devices and on their website, they offer a simulator for download (but you need to register before you can do so). I downloaded version 7.0 and I was a bit disappointed by the look and feel and the capabilities it provides. I am not really sure if that is the default or if there are newer versions which can provide more functionality when it comes to rendering Web pages.

Nokia simulators

Nokia, as one of the leading mobile phone makers, provides a decent selection of SDKs on their developer network, but unfortunately the device emulators included within these SDKs are built for actual application testing (written in e.g. J2ME) but not for testing Web sites using a mobile browser. So the only simulator I was able to find was the Nokia Mobile Browser Simulator 4.0 as part of the Nokia Mobile Internet Toolkit 4.1. They were made publicly available May 13, 2003 and July 2, 2004…so not the newest ones, I would say. Before downloading the Browser Simulator, you need to be registered with the Forum Nokia and request a serial number (in the sidebar, where it says “Request serial number for:) for the Browser Simulator.

The downloaded package is pretty small and after unzipping it, you can simply run the executable to install it. During installation, it will ask you for your Forum Nokia username and the serial number. After the installation, you can find the simulator under Programs > Nokia. The simulator itself is pretty disappointing cause it offers an interface with fits to the date of publication of the simulator and, more importantly, I was again not able to connect to the Internet. All I would wish for is that Nokia would update their standalone simulator to the newest models as soon as possible.

I just learned on their Forum, that the emulators provided with the SDKs actually provide full device capability, but I have not had the time yet to download one of these bundles and check for myself. SDKs are available, e.g. for Java (Series 80 and Series 60).

Further reading

• CSS tutorial on Media types
• 7 usability guidelines for websites on mobile devices
• Make your site mobile friendly
• Usable web pages for mobile devices
• ready.mobi (a tool for testing the mobile-readiness of web sites)
• Mobile Web Book (book by Cameron Moll)
• How to Install BlackBerry Simulator, Pocket PC Simulator, and Nokia Emulator