I came across an amazing JavaScript library called Hammer.js which makes it super easy to incorporate gestures into your application with only a few lines of code. The library is extremely lightweight, running ~2KB minified, and handles all of the legwork for you.

Hammer.js supports quite a few gestures too:

• Tap
• Double Tap
• Hold
• Swipe
• Drag
• Transform (Pinching)

Of course, what would touch events be without the actual Event data? When a user interacts with the screen, Hammer.js reports back to you with all of the information related to the touch. You can find out how long somebody touched the screen, where they touched, which direction they were swiping or dragging, the momentum of the swipe, and so on

So, why would you want use Hammer.js in your projects?

It’s lightweight

Sure, there are other libraries out there that handle gestures, but it’s important to think about resources when creating mobile apps. Hammer.js runs about 2kb (minified) and leaves a very tiny footprint.

Simple to use

The syntax is incredibly easy to both use and understand. There’s even a jQuery plugin available if you’re like me and like to take shortcuts in your code.

Plays nice with others

Hammer.js works well alongside other libraries and frameworks. Whether you’re using jQuery, bbUI.js, Backbone.js, or others, you should have no worries that Hammer.js will interfere. It performs very well, and doesn’t get in the way.

Check out my sample app!

I worked very hard for what seemed like minutes, creating an awesome sample app to show how easy it is to use the Hammer.js library. Check it out in our GitHub repo – there’s even a special appearance by the one-and-only Jesse Ariss!

If you have any questions, or comments, feel free to hit me up on Twitter. I like the attention. @chadtatro

Desktop web development is like this…	Mobile web can feel like this…	But mobile should and can be like this…
fairly standard	frustrating	compact, elegant, and functional

So where do we start? Well, when it comes to mobile web apps, file and transfer size matters — the smaller, the better. So the first thing I wanted to do was survey the landscape and compare the size of some of the different APIs that are available. (If I missed some that are lightweight, please let me know.) Although Google Maps is the most popular API out there (and deservedly so), it’s JavaScript API and tile images are quite large. In my tests below, I created basic map pages for a 1024×768 screen using each of the APIs, and I found that Google Maps transfers about 950 KB of data! This can be a problem for smartphones since they have limited memory. Besides causing an application to crash, a memory-intensive app can also chew up precious kilobytes from a user’s data plan, and it can drain their battery faster than they want. Thankfully, we have some choices…

Bing

As we can see from the results, Microsoft’s Bing Maps is a good alternative that has improved a lot since version 6.3. In version 6.3, Bing quietly introduced a “core” version for mobile that stripped out features like drawing lines and polygons. This reduced their JavaScript library from 230 KB to 47 KB! Unfortunately, if you needed some of those features, you were out of luck. But in version 7.0, they cleaned up their API and reduced it to 87 KB (without stripping features). So when you combine that savings with Bing’s smaller tile size, the Bing test map transferred 432 KB — that’s less than half of Google Maps! So I could stop here and just tell you to use Bing instead, but (as you’ll see) it’s always good to look at other options…

Modest Maps

Especially if we look at the API with the smallest library, Modest Maps, is a new library that weighs in at only 40 KB! It was designed to be simple, extensible, and it even works in older browsers like IE7. However, it’s tile size was the largest at 861 KB!

MapQuest

MapQuest is a provider that has been around for a while. Their version 7.0 is the second-smallest library at only 47 KB, but their tile size is the third largest at 852 KB.

Nokia Ovi

So if we’re also looking for an API that has the smallest tile size, Bing looks like the best choice. Nokia’s Ovi tiles are also lightweight at 373 KB, but their JavaScript library is the largest at 151 KB! It’s too bad we couldn’t use Modest Map’s compact library with Bing’s lightweight tiles…or can we? Well, in a way we can…

OpenLayers

OpenLayers, as the name suggests, is a completely free and Open Source library that allows you to switch between different base layers like Google Maps, Virtual Earth (Bing), Yahoo, etc. From a business model, this approach makes a lot of sense because it means you’re not tied to one mapping provider and you’re not as restricted by licensing or forced-API changes. With this approach, you can switch providers without having to completely change your code.

However, OpenLayers supports other maps by creating their own API layer on top of the other mapping APIs. So to use OpenLayers with Google or Bing, you’d have to include their libraries as well! This approach is fine for desktop, but it doesn’t make sense for mobile. Also, OpenLayers is not as well-documented as some of the others, and its API can be harder to learn. But, if you’re doing some serious GIS work, this is an API you’ll want to consider.

Leaflet

Fortunately, a new lightweight library called Leaflet has been gaining popularity because it is a modern Open Source library that uses HTML5 and CSS3. It was designed from the ground up to work in modern and mobile browsers. Since CSS3 is hardware-accelerated on many mobile devices, visuals like zooming and fading will be much faster than JavaScript-based animations.

Also, Leaflet has an easy-to-use API. So just how easy is it to add a map? First, we include the CSS and JavaScript:

                 <link rel="stylesheet" href="leaflet.css"> <script type="text/javascript" src="leaflet.js"></script> 

Then we create a new tile layer specifying the format of the tile URL with some options like maximum zoom level:

                 var tileUrl = "http://{s}.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/997/256/{z}/{x}/{y}.png", tileAttr = "Map data © 2011 OpenStreetMap contributors, Imagery © 2011 CloudMade", tileLayer = new L.TileLayer(tileUrl, { maxZoom: 18, attribution: tileAttr }); 

Then we create the map and add the tile layer to it:

                 var map = new L.Map("map", { center: new L.LatLng(43.6425778753, -79.3870621920), // Toronto zoom: 14 }); map.addLayer(tileLayer); 

That’s it! Like OpenLayers, Leaflet allows you to easily switch between tile providers, but it does this in a much cleaner way — all you have to do is change the tile URL. So you don’t even need to include a vendor’s API to use their tiles. Of course, if you do use another tile provider, make sure you contact them about licensing and include the proper attribution.

                 var tileUrl = "http://{s}.googleapis.com/vt?lyrs=m@174225136&src=apiv3&hl=en-US&x={x}&y={y}&z={z}&s=Galile&style=api%7Csmartmaps", tileAttr = "Map data © 2012 Google", tileLayer = new L.TileLayer(tileUrl, { maxZoom: 22, subdomains: ['mt0', 'mt1'], attribution: tileAttr }); 

So with this simple approach, you can change the base tile layer to almost any provider as long as they are using OpenStreetMap’s “Slippy” tile naming convention, which is pretty much every provider, except for Bing because Microsoft uses a different “Quadkey” convention.

Tile Naming Conventions

Basically, Slippy uses a straight-forward naming convention that looks like this (“mustache-style” URL template):

http://{s}.tile.cloudmade.com/YOUR-API-KEY/997/256/{z}/{x}/{y}.png

where,

• {s} = subdomain
• {x} = x-coordinate
• {y} = y-coordinate
• {z} = zoom level

Here’s an example of an actual tile (near the CN Tower):

http://b.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/997/256/14/4578/5980.png

But if we compare Slippy to the Quadkey format, you’ll notice it’s different enough that we can’t easily use it (at least not with Leaflet — we can with Modest Maps):

http://ecn.{s}.tiles.virtualearth.net/tiles/{style}{quadkey}?g=914&mkt=en-us&lbl=l1&stl=h&shading=hill&n=z

http://ecn.t0.tiles.virtualearth.net/tiles/r03022313122210?g=914&mkt=en-us&lbl=l1&stl=h&shading=hill&n=z

because the Quadkey format works like this:

• At zoom level 1 (of the entire world), there are only 4 tiles (or quadrants) numbered from 0 to 3. At the next zoom level, each tile is sub-divided into “quads”, and so on.
• So the length of the quadkey represents the number of zoom levels.
• The quadkey of any tile starts with the quadkey of its parent tile.
• The first letter (which is not really part of the quadkey) specifies the base map style (r = Road, a = Aerial (Satellite), h = Hybrid (Aerial + Labels)

Although it might be tempting to complain about Microsoft being different, from a database perspective, quadkeys makes indexing and storage really efficient.

Hybrid Approach

Hopefully, that gives you a better understanding of tile structures. Do you see the possibilities? This is AWESOME! This means we can easily interchange libraries and tiles to suit our needs. Essentially, we can build our own “hybrid” API or “mashup” from the best pieces available. So now we can have an API that uses Bing’s tiles, but is even lighter than Bing itself (which was already light to begin with at 432 KB)!

Here are some other combinations that are under 450 KB that you may want to consider:

Since we were able to make Bing lighter, I was curious to see if we could do the same with Google, and the result really surprised me! As you may recall, Google Maps transferred 950 KB, but when I combined Leaflet with Google’s tiles, it only transferred 498 KB! That’s half the size, which is great! But why such a difference?! Well, if we look at the number of requests, it gives us a big clue — Google’s API is loading twice the number of tiles!

At first, I thought it might be pre-fetching or “lazy loading” tiles for areas outside the bounding box in case a user pans or zooms. But when I inspected the extra tiles, I found it’s actually loading another set of tiles for the same area, which I haven’t been able to figure out why — the extra tiles don’t seem to be displayed anywhere. It’s still a map view tile, but it has slightly different labels. Notice the one on the right has “Corktown” and the other one doesn’t?

Tile Set 1 (displayed)	Tile Set 2 (not displayed)
m@174232040&src=apiv3&hl=en-US&x=4580&y=5979 &z=14 &s=Galileo &style=api%7Csmartmaps	m@174000000&src=apiv3&hl=en-US&x=4580&y=5979 &z=14 &s=Galileo &style=api%7Csmartmaps

I’m sure there’s a good reason for this, but I’d be curious if there’s an option to disable that? Either way, the good news is Google’s tiles are not as heavy as I first thought so we can use them with Modest Maps or Leaflet to build familiar-looking mapping applications that will be more lightweight especially for mobile.

Besides being able to switch between providers, this hybrid approach has other advantages:

1. For packaged applications like BlackBerry® WebWorks™, you can locally include the required API files (JavaScript, CSS, and images) with your application so you don’t need to fetch them from a remote server. This makes loading an app faster and reduces bandwidth charges.
2. Another advantage of having local files is you don’t have to worry as much about a provider forcing an API change that can break your customizations. Although, you can usually reference an older API, sometimes a provider will force an upgrade even if you try to reference an older version.
3. In the case of Yahoo! Maps, which discontinued its map service in September 2011, a local version means your app can still work. For example, Leaflet provides a layer control so you can select from different base layers.

These advantages are important especially for enterprise or mission-critical applications that need to minimize risk and downtime. So in the next post, I’ll cover some techniques for adding offline capabilities to your map. Hopefully, with this “best of breed” approach, you’ll be ready to build a map-based app that will feel more like a paper airplane than a paper ball.