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.

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.

Kamarov: Give me a stopwatch and a map, and I’ll fly the Alps in a plane with no windows.

from The Hunt for Red October

While there are great posts out there that look at the visual appearance of the map imagery and their readability the topic of this post are the APIs themselves, their capabilities and features and how easy they are to use from a developers perspective. I have put together a little side-by-side comparison, inspired by Sergey Chernychev’s work, to see how common tasks can be performed with the different APIs.

Ovi Maps API

Ovi, Nokia’s brand for their internet services, opened up its Ovi Maps API and their documentation just recently, in December 2010. The API documentation consists of a Developer’s Guide, Maps API Playground and API Documentation. The Developer’s Guide gives a short overview over the API and its capabilities with little code snippets. The aim of the API Playground is to give the developer an interactive interface to play around with code examples and edit code on the fly and see how it impacts the behavior of the example. Finally, the API documentation lists the class hierarchy and methods available for the developer as part of the API.

While I can see the good intentions of providing that API Playground, I actually believe it does more harm than good. For me personally, the way Ovi presents these examples and then having to click on a “code” button to see the code (without being able to easily do “view source”), is frankly, quite annoying. Also, there are not that many examples to begin with, compared to what Google Maps offers. I feel that having separate, distinct URLs for each example (as opposed to a sophisticated JavaScript-heavy interface), where you can do “view source” and easily follow what is going on, is much more helpful. Additionally, compared to how many classes and functions are available in the API documentation, this is, by no means, reflected in the examples. There is also no search functionality in the API docs, which makes them quite cumbersome to use.

With regards to the code, I noticed that upon instantiation of the Ovi map, the developer has to add the zoom control as well as the map type selector (for map, satellite and terrain view) in additional steps in the code, as well as the actual ability for the user to drag the map. I feel like these should come by default when instantiating the map.

// instantiate the map
ovimap = new ovi.mapsapi.map.Display(Y.Node.getDOMNode(Y.one('#ovimap')), {
    zoomLevel: mapOptions.zoom,
    center: [mapOptions.lat, mapOptions.lng]
});

//add direct mouse interaction
ovimap.components.add(new ovi.mapsapi.map.component.Behavior());

//add the zoom bar
ovimap.components.add(new ovi.mapsapi.map.component.ZoomBar());

// add map type selector (for map, satellite and hybrid view)
ovimap.components.add(new ovi.mapsapi.map.component.TypeSelector()); 

I also encountered a weird behavior, which I feel is a bug: when zooming into the map, either by double-clicking with the mouse or using the zoom control, the zoom control disappears (at least in my comparison example). But I would attribute that to the fact that this API is very new and I would think this will be fixed soon. Looking at the playground, Ovi Maps seems to offer some interesting features in addition to standards like routing, placement of markers, rendering geo shapes and exposing map events in JavaScript. Included in the API are the abilities to render SVG and text inside a graphics context (which might just be an abstraction layer to native SVG capabilities in the browser), as well as an abstraction layer for canvas (at least I believe that is what this is).

The quality of the imagery is not that outstanding, however, the satellite images Ovi has for Europe are much better than what, e.g. Google offers. You can see for yourself if you search for Helsinki in my comparison example and zoom in to the max on both the Google and the Ovi Map.

Resources

• Ovi Maps API
• Ovi Maps API Playground
• Ovi Maps API documentation

Yahoo Maps API

The Yahoo Maps API has not received an update for quite a while, the version I had included in my old post was 3.4, the most current one is 3.8. Besides the Ajax API, Yahoo Maps still offers the Flash version (although one could argue how useful this still is, considering how powerful JavaScript has become in recent years), as well as a REST API for requesting static map images (great for non-JS solutions) and support for GeoRSS.

The landing page for the Ajax API documentation has a lot of copy & paste examples right there, including a small description and a unique URL to display the full example. They also offer a bunch of cheat sheets, which I personally don’t use because they get outdated quickly (I’d rather have good up-to-date online documentation with explanatory examples and well-structured API docs). You can download the examples plus the cheat sheets bundled together in one zip file to explore on your own machine.

The actual API documentation is, by far, not as fancy as Ovi’s, but it somehow serves me much better. For example, if you would like to know which method to call in order to set the zoom level on the map, I just use Strg+F (or ⌘+F on Mac) searching for ‘zoom’ in the browser. After a few hits on ‘next’, I found setZoomLevel(zlevel). Without having to click myself through a class hierarchy structure.

Similar to Ovi, Yahoo Maps requires that type, zoom and pan controls are added separately and are not part of the initial instantiation.

// instantiation
ymap = new YMap(Y.Node.getDOMNode(Y.one('#ymap')), YAHOO_MAP_REG, new YSize(500, 300));

// center on default location
ymap.drawZoomAndCenter(new YGeoPoint(mapOptions.lat, mapOptions.lng), 8);

// add controls as ymaps does not provide them per default
ymap.addTypeControl();     

// Add the zoom control. Long specifies a Slider versus a "+" and "-" zoom control
ymap.addZoomLong();            

// Add the Pan control to have North, South, East and West directional control
ymap.addPanControl(); 

Together with Bing Maps, Yahoo Maps also requires an API key in order to actually use the API. The key needs to be part of the URL when requesting the Yahoo Maps API JavaScript.

It terms of available functionality, one can tell that this API has not received any major updates in a while. Apart from the what you would expect from a maps API (display of markers, info windows, polyline overlays), it does not have any outstanding additional functionality, in fact, it actually lacks the ability to get directions (even though the web interface offers that). And looking at the map imagery, especially looking at the satellite images, other providers provide much more detail.

Another interesting fact is that the Yahoo API is the only one amongst the 4 whose zoom level scale is somewhat reversed, meaning a zoom level of 1 corresponds to the closest view, whereas zoom level 16 means zoomed out to continent level. What I find really nice though, is that the Yahoo API has a geocoder built-in, in contrast to some of the other APIs. So if I have a location input field, I can just pass whatever the user typed in to the drawZoomAndCenter function, like so:

ymap.drawZoomAndCenter(
    "San Francisco",
    zoomLevel
);

Resources

• Yahoo Maps Web Services
• Yahoo! Maps AJAX API Getting Started Guide
• API Reference Manual

Bing Maps API

With the launch of its search engine Bing, Microsoft also redid what was Live Search before and released Bing Maps. The API, to develop web applications, is currently in its 7.0 version and its MSDN style documentation still makes me think I am in the year 2000—despite visual changes and redesign of the MSDN site. The first thing Microsoft points out in the “Getting Started” guide is that you should please sign up for an API key. The documentation provides a few examples, which should be taken with a grain of salt, as all of them include the Bing Maps JavaScript in the <head> of the document, which is a bad idea for performance reasons. It is also kinda tedious that they don’t provide the developer with actual pages where they can see the examples in action, but instead they make you copy and paste the example to your own machine and fill in your personal API key in order to see what is happening. The API reference is fairly well structured and clear, however it also lacks a search functionality (although, because it is not that massive, it might not be required).

Instantiation of the map is pretty standard, however centering the map on a new location based on user input is not. In fact, what you need to do is include a script element dynamically, which points to the Bing geocoder webservice, and provide a JavaScript callback for the JSON-P response (as shown in this example) Something that should really be abstracted within the API.

In addition to the standard map functionality, Bing Maps also offers a directions service, custom tile layers and displaying localized maps.

In the interface itself, the API offers a so-called Bird’s eye view, which is essentially a hybrid view (satellite plus road data/labels) which switches over to an angled view, similar to what can be seen in Google Maps and Google Earth, when the zoom level is high enough. I was very impressed by the image quality here, for both cities in the US and Europe (you can see for yourself, searching again for “Helsinki” in my example and zooming in to the maximum level on Bing Maps, with the map type set to “Bird’s eye”).

Resources

• Bing Maps APIs Overview
• Bing Maps AJAX Control, Version 7.0
• API reference
• Wikipedia article on Bing Maps

Google Maps API

Last, but not least, in my personal opinion the Google Maps API is still king amongst all the Maps APIs out there. The amount of functionality offered by theGoogle Maps API family and the JavaScript API itself never ceases to amaze me. With the current version 3, no API key is required any more, which makes inclusion of the JavaScript and getting started even easier.

Google is often criticized for is very developer centric approaches and interfaces, but the sheer amount of documentation they provide for developers plus they way they present it makes it very smooth and easy to use their API. The have a guide for new developers that covers the basics and standard functionality and an API reference (similarly structured like the one from Yahoo). But probably the best part of the docs are the examples. Well structured, with unique URLs for the developer to look at with just one click and digging deeper by doing a simple ‘view source’.

With regards to functionality, the Google API really offers everything you could ask for from a Maps API—and more. Just to name a few that strike me as quite impressive are additional map layers, provided by KML or Google Fusion Tables as well as Bike Paths and Routes. You can create a custom map type with different styles, get the elevation along a certain path and include the all so beloved Street View. In addition, the API performs great on mobile devices.

The imagery of the satellite images is still very good and the readability of the map view has already been discussed on 41latitude.com. It would be great if Google would expose Google Earth views through the JavaScript API as well (for angled views, similar to what Bing offers), but this is exposed through the Earth API, which is separate from the JS API. It is however seems to be possible to integrate the JS API with the Earth API, although the example is referencing the JS API version 2, which is deprecated.

Resources

• Google Maps API Family
• Google Maps JavaScript API V3
• Google Maps Javascript API V3 Reference
• Google Maps Javascript API V3 Examples

Conclusion

If you are looking for a generic map solution for your site or application, the Google Maps API is the way to go. It incorporates features that will most likely cover close to 90 percent of the use cases out there that relate to map applications. However, you might have very specific requirements, that Google Maps might not be able to fulfill to the fullest extent. If you need an API that provides great map data for Europe, then you might want to consider the Bing Maps API, which has great satellite imagery of European cities. The Ovi Maps API has just been released, but has some innovative approaches in there, whereas the Yahoo Maps API, because it has been neglected for quite some time, has been falling a little bit behind when it comes to state-of-the art features. If you want to read more about the topic of maps, especially regarding their readability and quality of imagery, I suggest you check out Justin O’Beirne’s site, where he shares a lot of his thoughts on this topic.

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

Stoyan Stefanov, a colleague of mine at Yahoo!, recently published Object-Oriented JavaScript. Personally, the book about JavaScript I was waiting for. A while back, I read and reviewed Jeremy Keith’s DOM Scripting, which is the perfect introduction as to how developers should use JavaScript these days in a browser environment. Progressive Enhancement was one of the key concepts in there. So after getting the basics covered, my expectation was that Stoyan’s book provides me with supporting material for intermediate to advanced JavaScript programming tasks. Does it deliver? We will come to that very shortly.

Contents

Chapters 1 to 4 in his book cover a brief history about JavaScript and the basic elements of the language, like variables, primitive data types, conditions and loops as well as functions and objects. The latter already have their specialties in JavaScript and Stoyan explains those special characteristics.

Chapters 5 and 6 are devoted to prototype and how inheritance works in JavaScript, a very essential thing to cover when we are talking about advanced techniques.

Chapter 7 talks about what readers of DOM Scripting might still remember, namely how JavaScript can be used to access and manipulate specific elements in the DOM. The author also takes a look at Events and the ever popular XMLHttpRequest.

And finally, the highlight comes last, Chapter 8 deals with what hardcore programmers were waiting for: Coding and Design Patterns. Having done a little research about this myself, I found it great that Stoyan documents concepts that have become good practice in the JavaScript world, like namespacing and creating public and private properties and methods. In the design patterns part, he talks about Singletons amongst various other patterns at the programmers disposal.

The book closes with a quite comprehensive appendix, which includes listing reserved words, referencing built-in functions and objects and regular expressions in JavaScript.

Rating and Reasoning

My Rating: 9 out of 10

Even though it states that “no prior JavaScript knowledge is required”, I would say that is a bit of an understatement. If DOM Scripting was your first JavaScript book then I would put the following equation on the board: DOM Scripting + experience with these techniques in The Real World (meaning on actual live projects) = ready for Object-Oriented JavaScript. Don’t get me wrong, Stoyan covers the basics (variables, conditions etc.) in the first few chapters, but after that, the learning curve gets pretty steep and I believe it is safe to say, without any prior knowledge, you will put this book back on the shelf, left frustrated.

I have worked on a couple of minor web projects before Yahoo! Europe hired me in May 2007, so to this date, I believe I was able to acquire some experience when it comes to using JavaScript on high-scale websites. From my perspective, the first couple of chapters was a nice refresh on the topic, but only then, in Chapters 5 to 8, things got interesting with bits and pieces in there that helped me closing some knowledge gaps about certain concepts, which is really great. This, again, supports my feeling that this book is not meant for every JavaScript developer out there, independent of whether it is a newbie or an advanced developer. I feel that people with probably a couple of years experience might get more out of it than someone who just delved into JavaScript a month ago.

It is difficult to come up with concrete examples to explain this, and this observation is highly subjective of course, but I feel that the way the book is done and written, it feels a lot “drier” and less “exciting” to read compared to DOM Scripting. Which, again, if this targets JavaScript beginners, should not be the case. But I believe the more complex the material gets, the harder the job becomes of having to thrill and excite the reader.

What I really like about the book is that basically all the examples Stoyan gives, you can type into the Firebug console right away to try out for yourself. As I am a believer that you learn new skills most effectively by actually doing something and play with it, I am pretty sure this is a good way of imparting knowledge.

Conclusion

If you are a Web Developer with several years of experience on the job and with JavaScript and you want to move your knowledge level up a notch or two, this book is for you. If you want to play with the cool kids, then get this book. If you are more or less new to the JavaScript world, you might want to consider starting with DOM Scripting first and getting experience using those techniques on real world projects, before diving into the advanced concepts discussed in Object-Oriented JavaScript.

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.