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);
        }
    }
}

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

A few major differences

I am not going to go into all the things that are different between YUI2 and YUI3, this is beyond the scope of this post. There is already lots of documentation on YDN and a very good video covering lots of questions like “So whats different?”. Just a few key things to note:

• YUI3 is majorly different to YUI2. It is basically a new library and thus also, in a lot of ways, works completely different than its predecessor.
• To avoid conflicts between the two libraries, the global YAHOO object (used in YUI2) is now YUI. This also allows to have both YUI2 and YUI3 on the same page.
• Every piece of code you write needs to be wrapped in the following statement: YUI().use([YUI3 modules I want to use], function (Y) { ...my code here... } );This, in theory, makes creating namespaces, like we did in YUI2, unnecessary.

A Simple Example: JavaScript Countdown

Just to play around with it and start with a pretty basic example, I wanted to do a countdown in JavaScript. How would I do that using YUI3?

Step by Step

The following steps would need to get executed in order to make this example work:

1. Put basic markup on the page, which marks the start time of the countdown, e.g. 30 minutes and 0 seconds.
2. Have one function, decreaseSeconds that decreases the seconds and call this function every second (or 1000 milliseconds).
3. If the seconds counter reaches 0, decrease the minutes using decreaseMinutes.
4. Stop the timer if minutes and seconds reach 0.

Basic Markup

As said, the markup on the page already serves as the start time for the countdown and is pretty simple:

<div id="countdown">
        <span id="min">30</span>:<span id="sec">00</span>
</div>

Putting YUI3 on the page

In order to put YUI3 on the page, we need to include the YUI Global Object:

<script src="http://yui.yahooapis.com/3.0.0b1/build/yui/yui-min.js" type="text/javascript"></script> 

And just to verify this is working, we will add some debugging code on the page:

YUI().use("node", function (Y) {
    alert("YUI3 is here!");
});

Just a few words on this. The first argument of the use function, in this case “node”, tells the YUI instance which modules to load. As it will turn out later, the node module, together with the functionality that the YUI global object provides, are enough to make this example work. The last argument here is a callback function, which has the YUI instance as an argument. In this function is where your code lives and has access to the YUI3 instance and modules, if loaded in. More on this in the documentation.

So we got the basics covered, YUI3 is on the page and we can move on to the program logic.

Setting up variables and functions

First I am going to set up some variables that I am going to need throughout the code:

var minutes = Y.get("#min"),
    seconds = Y.get("#sec"),
    timer,
    liftOff = false;

As you can see here, YUI3 gives you the ability to access a DOM element using CSS selectors out of the box. Y.get(“#min”) returns a node (in YUI3 terms) which wraps the underlying DOM object. But be aware that this object here is not the DOM object itself, which is different to what YAHOO.util.Dom.get(“min”) would do.

We will also set up the decreaseSeconds function and the timer:

function decreaseSeconds() {
    // get current seconds value
    var secs = seconds.get("innerHTML");

    if (secs === "00") {
        // move to 59
        secs = 59;
        decreaseMinutes();
    } else {
        secs--;
        if (secs < 10) {
            secs = "0" + secs;
        }
    }

    if (!liftOff) {
        seconds.set("innerHTML", secs);
    }
}

timer = Y.later(1000, null, decreaseSeconds, [], true);

Instead of talking about the program logic, which should be pretty straight forward, I would like to highlight YUI3 specific things here:

• Setting up the timer using Y.later is pretty easy and comparable to YAHOO.later in YUI2.
• As the node returned by Y.get is not the DOM node, doing something like seconds.innerHTML does not work. In fact, it will return ‘undefined’. If you do a console.dir(seconds) you will discover that this does not look like a DOM object at all, but is, as stated above, a YUI node instance wrapping the DOM element with id=”sec”. So instead of doing .innerHTML, we need to use seconds.get(“innerHTML”) to access the content between the opening and closing tag.
• Likewise, to set content using innerHTML, we need to do seconds.set(“innerHTML”, secs).

This is something to get used to at first. Because in YUI2, people (including me) were used to have the actual DOM object at hand and perform native DOM operations on it. This is not possible anymore with YUI3. It is still possible to access the underlying DOM objects, see Luke’s comment.

After setting this up, we can move on to adding the functionality for decreasing the minutes and making the countdown work.

Making it work

Here is the code and logic for decreasing the minutes and canceling the timer if 0 is reached:

function decreaseMinutes() {
    var mins = minutes.get("innerHTML");

    if (mins > 0) {
        mins--;
        if (mins < 10) {
            mins = "0" + mins;
        }
        minutes.set("innerHTML", mins);
    } else {
        timer.cancel();
        liftOff = true;
    }
}

Pretty straight forward and also uses the wrapper methods to access DOM functionality. It works now, but we are not quite finished yet.

Modularizing

As you can see, all the code is currently inline on the page and gets executed as soon as the page loads. This is suboptimal. What I used to do using YUI2 is creating a module specific namespace and then call a public method (made available through the use of the Module Pattern) on the page that needed that functionality. So for this the module would be, e.g.:

YAHOO.Klaus.Countdown = function () {
    ... my code ...
    return {
         init: init
    };
}();

And then, on whatever page I want to use it, do:

YAHOO.Klaus.Countdown.init();

I was curious how to achieve something like this in YUI3.

I came up with a solution but I am not sure if this is the suggested way of doing this. I hope it is, as I couldn’t find a different way of doing it. The secret is to add the “module” you created as a module to YUI3, like:

Y.add("Klaus.Countdown", init);

The second argument is a function name to be executed when the module is being invoked used the use() function.

So what is left to do is saving the countdown code to a separate file and then call the module from within a script block on the page:

<script type="text/javascript">
    YUI().use("Klaus.Countdown");
</script>

So we are done and hopefully happy with our first steps in YUI3.

Conclusion

I have deliberately chosen a simple example to start with to avoid frustrations coming out of having to learn and getting used to too many things at once. Like with every new piece of software, getting started “somehow” in the first place is critical and finding out how to achieve things without running into too many roadblocks at once. How easy or hard it is to use YUI3, I have yet to determine when probably facing more complex examples, but I believe this simple examples gives a sneak peak into what awaits at the end of the line.

Resources

• YUI3 on YDN
• YU3 API Doc
• YUI Blog
• Belorussian translation of this article kindly provided by Patricia Clausnitzer and http://www.fatcow.com/

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.

It is quite similar to a couple of tools that are already out there. JSLint looks for issues in JavaScript code and checks for adherence to a certain set of code standards. PHP_CodeSniffer, a PEAR package, provides similar functionality for PHP files (but is also able to check JavaScript and CSS). Then there is CSSTidy, a parser and optimiser for CSS, which e.g. compresses hex values for color declarations and provides different levels of minification (removing comments, whitespace etc.).

Essentially, what I wanted to achieve with CSS Reviewr is to not only point out issues in the code based on the experiences and the reviews we conducted at work, but also to provide explanatory text for each finding (much like how the W3C Validator does it for HTML). In one or two sentences, I wanted to explain why this is an issue and how it can be resolved. From my perspective, this is ideal for a developer who might not be familiar with a certain best practice or convention. By reading the explanation and maybe following a link to a page that provides more details, it has a certain learning effect to it.

CSS Reviewr, as it is stated on the page, is not a validator. It is encouraged to run your code through the W3C CSS Validator first, before checking it using CSS Reviewr.

Last, but not least, I would like to thank the real brain behind this: Sam Riley. I had the pleasure of working with him on Yahoo! Answers and I was and am still really impressed by his sheer endless knowledge of the ins and outs of CSS. Knowing that I would not be able to just turn to the side and ask him whenever I have a question related to CSS (because I relocated from London to California), I wrote this tool also to store his CSS knowledge somewhere for myself, so I could still use it here in the US So a big thanks to Sam!. Also thanks to Eva-Lotta, who kindly offered to do some visual design work for this in her spare time.

The tool is in beta right now and I have already identified some bugs myself that I need to fix at some point, providing I find time for this. Getting some early feedback from colleagues, I have also received the following feature requests:

• Indentation check (selectable option)
• Check (background) images used in the code are akamized/on a content delivery network (CDN)
• Fonts should not use uppercase characters (e.g “Arial” should be “arial”)
• Limit the amount of errors shown to 50 to prevent browser (FF2) from crashing. Add something like: “More than 50 issues found. Fix the issues above first before checking your code again.”
• Having a ‘Do it!’ button by each issue to make the suggested modification to the code, and then have a textarea at the bottom where you could copy out the fixed version

Suggestions, bug reports and all kinds of feedback welcome. Just leave a comment below. Thanks and happy holidays!

Description

Shrinkr does two things:

1. It reduces the file-size of your CSS and JavaScript files through minification, i.e. stripping out unnecessary content like white-space and comments
2. It then takes those files and concatenates them into one single CSS and one single JavaScript file
3. Those files are then getting stored as css-min-[timestamp].css and js-min-[timestamp].js on your server. The reason for the timestamp is that whenever Shrinkr creates a new file, it is ensured that a user agent doesn’t still use a cached version of the previous files but, because the name of the file has changed, retrieves the latest version from the server

The first measure reduces the file-size by stripping out things from files that are not needed by the browser in order to interpret them. Whitespace and comments are for developers, not for the browser. They can safely be removed, which reduces the file-size and thus the consumption of bandwidth.

In the Yahoo! Exceptional Performance Rules, it says that one should aim to reduce the number of HTTP requests in order to make a page load as fast as possible. Shrinkr does that by concatenating all the files into one single file (one for CSS and one for JS). So instead of having 10 CSS files, you will end up having only one.

Shrinkr also adds an action to wp_head and wp_footer in order to tell WordPress to include those files upon page load in the appropriate section of the page. CSS files should be included in the head of the page, JS at the very bottom as per the Yahoo! Exceptional Performance Rules.

Because of the fact that you will end up having all your CSS and JavaScript in one file and on one line (because all the carriage returns etc. have been stripped out), it makes debugging kind of difficult. For that reason, you should only activate that plugin on the live version of your site and keep the files separated on your development box.

Further details about the plugin can be found on the Shrinkr plugin page. It would be great if you could try it out and give me feedback, either by leaving a comment here or using the contact form. Thanks!

Resources

• Best Practices for Speeding Up Your Web Site
• Yahoo! UI Library: YUI Compressor
• JSMIN, The JavaScript Minifier
• Minify!

There are three ways to generate a favicon:

• Photoshop (or any other graphics editing program)
• Online tools
• On the fly

Photoshop

I say Photoshop here, because that is what I am used to, but essentially you could use any graphics editing program out there. Essentially, when you have your graphic ready, you could just simply save it as a PNG or GIF. Well, you can do that, but that won’t work in Internet Explorer.

To make your favicon display in every browser, you need to create an ICO file. To do that with Photoshop, you can install a plugin that helps you do so.

Installing the plugin

First you need to download the plugin from Telegraphics for whichever version of Photoshop you are using. Extract the ZIP file and move the plugin file into the “File Formats” folder inside your Photoshop Plugins folder:

• On Windows, ICOFormat.8bi (the path should be similar to: C:\Program Files\Adobe\Adobe Photoshop CS2\Plug-Ins\File Formats\)
• On OS X/Classic, icoformat (CS2/Mac version is ICOFormat_cs2.plugin)

After you have done that quit and relaunch Photoshop, if it’s already running. To check if the plugin is installed correctly, go to Help > About Plug-ins. In this list, the ICO plugin should appear.

Saving your graphic in ICO format

There are some constraints as to which images are eligible to be saved in ICO format:

• The ICO format does not allow images more than 255 pixels high or wide.
• Only Bitmap, Grey Scale, Indexed and RGB mode images, no more than 8 bits per channel, can be saved as ICO.

If the graphic you created meets those requirements, you can go to “Save” or “Save As…” and select “ICO (Windows Icon) *.ICO” from the list of available file formats. The size of the final image should either be 16×16 or 32×32 pixels, larger images would just need to be scaled down by the browser.

Online tools

Following is a list of tools on the web that make it even easier to create favicons. In principle, you can upload an image file that you already have to the service, which will create a favicon file from that image.

• Favicon Generator
• Favikon
• favicon.ico Generator
• FavIcon from Pics

On the fly

Using the data URI scheme, it is possible to include data items, such as an image, inline on a webpage, without actually referencing it as an external resource. The format for that URI scheme is:

data:[<MIME-type>][;base64],<data> 

The W3C Validator for example makes use of this. If your markup validation fails, the red square displayed in the address bar is referenced as:

<link rel="icon" href="data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%10%00%00%00%10%08%02%00%00%00%90%91h6%00%00%00%19IDAT(%91c%BCd%AB%C2%40%0A%60%22I%F5%A8%86Q%0DCJ%03%00%DE%B5%01S%07%88%8FG%00%00%00%00IEND%AEB%60%82" type="image/png" />

In the example from the W3C Validator, the data for the favicon is represented using ASCII encoding, but could also be encoded as base64, which would then look like this in the HTML source:

<link rel="icon" href="data:image/png;base64,/9j/4AAQ..." type="image/png" />

Referencing it in HTML

When you have your favicon file, place it somewhere on your webspace of your site (it does not have to be the root directory) and then reference the file in HTML (in the head of the document) like so:

<link rel="Shortcut Icon"
      href=""http://example.com/favicon.ico"
      type="image/x-icon">

If you now go to your site and refresh the browser, you should see your icon showing up in the address bar.

On a sidenote: if you ever wanted to play Defender displayed in a 16×16 pixels favicon, you can do so now. Not necessarily useful for everyday websites, but a great demo of what can be done with favicons.

Resources

• How to Add a Favicon to your Site – QA @ W3C
• Mysteries Of The Favicon.ico — How To Create A Favicon In Photoshop
• Creating favicons with Adobe Photoshop and GoLive

Apache

OSX already comes with Apache installed, it is just a matter of starting the server. You can do this if you go to System Preferences > Sharing and check “Web Sharing”. The Apache default page should now be displayed at

http://localhost

Later on, you can use the following commands to start, stop or restart Apache:

$ sudo apachectl start
$ sudo apachectl stop
$ sudo apachectl restart

If you would like to change the DocumentRoot of the server, you need to edit the httpd.conf file:

$ sudo vi /etc/apache2/httpd.conf

In here, you need to change the DocumentRoot setting:

DocumentRoot "/Users/myUser/myNewWebroot/"
<Directory "/Users/myUser/myNewWebroot/">
...
</Directory>

PHP

PHP comes bundled up with Leopard as well. The important things to know here are where it got installed and where to find the configuration file.

Most likely, it got installed to:

The configuration file should be located at:

You only need to make sure that Apache knows that PHP is available, so edit httpd.conf:
$ sudo vi /etc/apache2/httpd.conf

And add the following lines (in the appropriate sections, to keep things tidy):

Finished with that, restart Apache, empty the browser cache and then load a php file for testing if it is correctly interpreted.

MySQL

Download the most recent dmg image from the MySQL site.

Before actually installing MySQL, I found it helps to restart the computer before proceeding with the installation. When running through the installation wizard, MySQL will get installed to:

So, for example:

Also, a symlink should have been created:

You should also install the Preference Pane, which comes with the installation package as MySQL.prefPane

To start MySQL manually, run the following command:
$ sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

You should also add MySQL to $PATH:
$ vi ~/.profile
$ export PATH=$PATH:/usr/local/mysql/bin
$ source ~/.profile

To check whether that was successful, run:
$ echo $PATH

The default settings for the root user are:

• Username: root
• Password: [leave blank]

Add-on: PHPmyAdmin

To get PHPmyAdmin installed, which comes in handy for managing your database(s), download the latest package from their download page. Extract that package to a directory somewhere in your DocumentRoot.

Open config.sample.inc.php with an editor of your choice and add the following details for your MySQL installation:

/*
 * This is needed for cookie based authentication to encrypt password in
 * cookie
 */
$cfg['blowfish_secret'] = 'whatever'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

$cfg['Servers'][$i]['user']          = 'root';
$cfg['Servers'][$i]['password']      = ''; // use here your password

After you made those changes, save the file as config.inc.php.

PEAR

PEAR should also already be available on your Mac. The location is probably:

It is a good idea to add the path to PEAR to $PATH, similar to setting the path for MySQL (see above). In addition, upgrade PEAR to the latest version like so:

$ sudo pear channel-update pear.php.net
$ sudo pear upgrade PEAR

Resources

• Installing MySQL on Mac OS X (MySQL Reference Manual)
• Installing MySQL 5.0 on Max OS X 10.5 client
• Installing MySQL on Mac OS X
]]> http://www.klauskomenda.com/archives/2008/10/07/installing-apache-mysql-and-php-on-leopard/feed/ 21