Image from http://failblog.cheezburger.com/

On our developer website, we provide a seamless solution consisting of replacing the Google Maps library for Android with a web view integrating the web version of Google Maps. More information can be found by following this link.

That said, a fellow Italian developer (the maker of Prezzi Benzina), just sent me detailed information on how they easily replaced Google Maps with Open Street Maps, a free worldwide map providing open data under the ODBL (Open Data Commons Open Database License).

The result? Outstanding! And since it is a very common issue faced by many Android developers making use of Google Maps in their Android applications, we wanted to share in this blog how they did it.

Download

First of all, you must download the Open Street Maps library from the following link: https://code.google.com/p/osmdroid/

You can either download the jar ready to use osmdroid-android-3.0.8.jar or download the source code and compile it (recommended).

Step 1: Layout Change

Pretty easy. You code goes from

<com.google.android.maps.MapView
        android:id="@+id/mapview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:apiKey="@+string/mapviewkey"
        android:clickable="true" />

to

<org.osmdroid.views.MapView
        android:id="@+id/mapview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent" />

Unlike Google Maps, no key is needed for OSM.

Step 2: Modify Import

Most class names remain the same, so it’s very straight forward..

Your code goes from:

import com.google.android.maps.GeoPoint;
import com.google.android.maps.MapController;
import com.google.android.maps.MapView;

to

import org.osmdroid.util.GeoPoint;
import org.osmdroid.views.MapController;
import org.osmdroid.views.MapView;

In addition, you might want to add the following:

import org.osmdroid.views.overlay.ItemizedIconOverlay;
import org.osmdroid.views.overlay.ItemizedIconOverlay.OnItemGestureListener;
import org.osmdroid.views.overlay.OverlayItem;
import org.osmdroid.views.overlay.OverlayManager;
import org.osmdroid.views.overlay.mylocation.GpsMyLocationProvider;
import org.osmdroid.views.overlay.mylocation.MyLocationNewOverlay;

WARNING: resources

The default class for resources is: DefaultResourceProxyImpl. It handles English only, so you probably have to create your own with the proper translations.

    ResourceProxyImpl resProxyImp = new ResourceProxyImpl(this);

Step 3: Map Customization

From

mapView = (MapView) findViewById(R.id.mapview);
mapView.setBuiltInZoomControls(true);
mMyLocationOverlay = new MyLocationOverlay(this, mapView);
mapView.getOverlays().add(mMyLocationOverlay);

to

mapView = (MapView) findViewById(R.id.mapview);
mapView.setUseSafeCanvas(false);
//enable zoom controls
mapView.setBuiltInZoomControls(true);

//enable multitouch
mapView.setMultiTouchControls(true);
//GpsMyLocationProvider can be replaced by your own class. It provides the position information through GPS or Cell towers.
GpsMyLocationProvider imlp = new GpsMyLocationProvider(this.getBaseContext());
//minimum distance for update
imlp.setLocationUpdateMinDistance(1000);
//minimum time for update
imlp.setLocationUpdateMinTime(60000);       
mMyLocationOverlay = new MyLocationNewOverlay(this.getBaseContext(),imlp , mapView, resProxyImp);
mMyLocationOverlay.setUseSafeCanvas(false);
mMyLocationOverlay.setDrawAccuracyEnabled(true);

mapView.getOverlays().add(mMyLocationOverlay);

Step 4: Add Marker

In OSMDroid there are some classes ready to use. The best is ItemizedIconOverlay.

Create an overlay and add it to the map:

ItemizedIconOverlay markersOverlay = new ItemizedIconOverlay(new LinkedList(), myMarker, null, resProxyImp);
mapView.getOverlays().add(markersOverlay);
Add markers
OverlayItem ovm = new OverlayItem("titolo", "descrizione", new GeoPoint(s.LatitudeE6(), s.LongitudeE6()));
ovm.setMarker(myMarker);
markersOverlay.addItem(ovm);

Of course, this is just the basic part of the story. There is much more available on OSMDroid – feel free to explore and bring your Android app to BlackBerry 10 easily!

What’s Count.ly? It is a real-time mobile analytics platform that shows information by using eye-catching visual elements. Görkem provided me with a test account and after logging in, I was very impressed by what I saw. The UI is gorgeus and the amount of useful and critical information a dev can get about their app is impressive.

Moreover, it’s an open-source project in which the team aims to discuss the future of Count.ly in an open, democratic environment. They offer the developers the opportunity to take part in the community, to send bug reports, feature requests, to provide fixes and best practices. It collects data from mobile phones, and visualizes this information to analyze mobile application usage and end-user behavior.

Having the ability to see how your users behave is critical for the success of an app. Developers can get a clear picture on what’s working well and what’s not working, what their users like the most, what the least/most used feature is and, last but not least, how much time people spend in your app and doing what.

When we met, BlackBerry 10 was not supported yet, but they were very interested in investing in our new upcoming platform (after the conference, even more!) and for that reason, twenty days after, they finally published their first SDKs for BlackBerry 10.

What’s so special with Count.ly?

• It has a dashboard
  • where you stay up to date
  • where you can easily monitor your data with graphics
  • which shows you everything at once with no need to dig in several pages
  • where you can track unlimited number of applications and switch between your apps, games and ebooks

• It has a special user behaviour stats experience in which;
  • you can track and visualize your users’ behaviours
  • you can see your application’s in-app performance
  • you can understand your customer’s behaviour and where user left off
  • you can observe your players closely to ensure success and maximize your online game revenue

• You can build better apps, games and ebooks;
  • by measuring and evaluating mobile app engagement as it enables optimization of mobile content
  • by exploring where a spike occurs and by personalizing and optimizing your app according to stats
  • by the help of the support that Countly offers for leading smartphones (iOS, Android, Windows Phone and BlackBerry)

• You can produce electronic reports with customizable charts and tables, showing how your application performed for a given period, add / remove pages through report generator.

Also, Count.ly is free. You can install Count.ly in-app analytics tool on your server to track unlimited number of mobile applications, if you want.

Here is what Onu Alp, Soner, co-founder of Count.ly, told me:

“The best feature of Count.ly is custom events: we help developers identify in-app purchase patterns, defining the best flow for payment. This is a crucial factor towards maximizing revenues in e-books and games. We are thrilled with what BlackBerry provides in their next-gen mobile OS, and decided to invest in BlackBerry 10 SDK. Being the most complete open source, real-time mobile analytics app in the world, we believe Count.ly will provide a lot of value for BlackBerry 10 developers”

If you are a BlackBerry 10 developer looking for a good option for in-app analytics, Count.ly is definitely a great choice. The team is also very accessible and happy to help if needed.

You can download the Countly WebWorks SDK from GitHub here, while the Cascades SDK can be download from here.

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.

In a Flash Platform blog posted earlier today, Adobe® laid out their plans for Adobe Flash® Player on mobile devices. Many of our developers may be asking themselves whether and how they are going to be affected by Adobe’s decision to no longer adapt Adobe Flash Player for mobile devices to new browser, OS version or device configurations.

What I would like our developer community to know is that RIM will continue to support developers who have built Adobe Flash-based apps on our platform. As an Adobe source code licensee, we have a lot of leverage through our own integration and support of Adobe Flash and will continue to provide our desktop-class Flash experience to our customers. On its end, Adobe will continue to support the current BlackBerry® PlayBook™ tablet configuration.

We are excited to see Adobe focusing their efforts on HTML5, and on bringing their world class development and design expertise to HTML5 and mobile. As many of you noted, at BlackBerry DevCon Americas this year we strongly emphasized HTML5 development, and all of our platforms include best-in-breed HTML5 browsing capability, based on the WebKit engine. We believe that HTML5 is the future of mobile, and are delighted to be aligned with Adobe on this.

If you have a question, don’t hesitate to send it over.
– Alec Saunders, VP of Developer Relations and Ecosystem Development

Building on the momentum of our extremely successful Web Development and Toolkits webinar , we will be hosting our second ever developer webinar on Tuesday, October 20th, addressing mobile design considerations for application development. Read on for a more detailed overview of this live and free webinar.

Presenter: Sarim Aziz, Senior Application Development Consultant, Developer Relations
Panelists: Mike Kirkup, Director, Developer Relations
Date: Tuesday October 20, 2009.
Time: 2:00 pm – 3:00 pm EST.

Overview:
Join us in an online discussion for BlackBerry Java developers which will help you better understand mobile application design considerations through a review of best practices and real world examples.

We’ll help you address design considerations specific to mobile applications, from Network Communication and User Interface, to Data and Memory management. We’ll also take a look at how you can leverage the BlackBerry Java Development Tools for debugging and optimizing your BlackBerry applications.

After the information presentation, developers will have an opportunity to interact with BlackBerry experts in a real time Q&A session. What are you waiting for? Click on the link below for registration information!

BlackBerry Developer Webinar: BlackBerry Java Development Tools