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!

Forget everything you know about working with maps and BlackBerry WebWorks. Mapping just got real, real easy!

We heard you ask for an easy way to integrate mapping services with your BlackBerry WebWorks applications, and today I’m happy to announce that on BlackBerry 10, the process has become much simpler.

We’ve put together a straight-forward sample application that will show you how to integrate with a few of the services out there:  Google Maps, Bing, Leaflet, and OpenLayers.

If you’ve been following the progression of the BlackBerry WebWorks framework, you’ve probably noticed an awesome amount of transparency. Open web standards are lovingly embraced and adopted here at RIM. Even the framework itself is staged publicly on GitHub.  Continuing this theme of openness and following web standards, the maps samples we’ve released are not platform specific.  Whether you’re writing an exclusive BlackBerry app, or planning on targeting multiple platforms using Cordova (previously known as PhoneGap), these samples are most definitely for you!

For each service, you’ll be able to learn how to:

-          Setup a mapping service to use to in your app

-          Find the users location with HTML5 Geolocation

-          Perform a search for nearby points of interest

-          Display push-pins on the map, showing the search results.

The goal of this sample is to show you how you can quickly integrate maps into your app and have it perform great in WebWorks for BlackBerry 10.

When it comes down to picking which service is right for your app, it’s completely up to you.  One of my teammates, Jim Ing, wrote a really in-depth article on maps, comparing services and much more.  I strongly recommend checking it out “Lightweight Maps For Mobile”.

Check out the sample, in action!

Download the source code.

Ready to add some maps to your app? Download the source code from our GitHub repository!

Calling all Native developers!

Have you been yearning to contribute to the BlackBerry 10 cause but weren’t sure how?  Why not take this WebWorks sample, and build a Native version?!  If you’re interested, get in touch with Shadid Haque (@ShadidHaque) on Twitter.

If you’ve got a success story, have a question, or just want to chat about apps, hit me up on Twitter @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.

Hello developers – I have great news! As part of our continuous effort to improve our map client and the data services behind it, we have added some really exciting features to our BlackBerry® Maps offering. Whether your application uses an embedded MapField or simply invokes BlackBerry Maps to render map data, you can start taking advantage of these new features today!

First, the data coverage has been extended by adding 34 new countries, including Australia, Brazil, Argentina, Uruguay, New Zealand, The Philippines and Taiwan. I have no doubt that the addition of these new countries in our database will open up a lot of opportunities for app developers in those regions. The figure above shows the current coverage of the BlackBerry Maps service.

After carefully listening to your comments and feedback, we have also spent a significant amount of our efforts to optimize the visual appearance of the maps with a stronger rendering engine as well as with a new color scheme. New POI databases for hospitals, universities/colleges, police stations, train/subway stations, shopping centers, parking, parks and airports were also added wherever available, in order to make the maps as meaningful as possible to the end user. The screenshots below highlight a few of the many visual changes that went in as part of this update.

Please note that, in order to enable the extended coverage and visual optimization, you will first need to update your device as instructed below:

Updating BlackBerry Maps with BlackBerry® Device Software 4.7 or Lower

1. From the home screen, go to Maps.
2. Press the [Menu] key and select Options.
3. Press the [Menu] key and select Clear Cache.
4. Select Delete when prompted to delete cached entries.

Updating BlackBerry Maps with BlackBerry Device Software 5.0 before Bundle 1057

Update your BlackBerry Device Software to the latest version, available here. If you do not wish to update your software, you can follow the instructions below (for the BlackBerry Device Software 5.0 after Bundle 1057) to receive the additional map coverage and new map design. However, the new POI icons will not be available.

Updating BlackBerry Maps with BlackBerry Device Software 5.0 after Bundle 1057

1. From the home screen, go to Maps.

2. Press the [Menu] key and select Options.

3. Press the [Menu] key and select Clear Cache.

4. Select Delete when prompted to delete cached entries.

Updating BlackBerry Maps with BlackBerry Device Software 6.0

1. From the home screen, go to Maps.

2. Press the [Menu] key and select Options.

3. Press Global Map Options.

4. Press the [Menu] key and select Clear Cache.

While we try our best to support new features on all OS versions, it is important to note that some of these features are not available on legacy OS versions. Please use the table below to determine which features are available for the OS version you have.

I am very excited about these new features and am really looking forward to any comments you may have!

Ever wondered how to query for location without being dependent on GPS? Well, look no more: we’ve introduced a brand-new feature that is capable of getting you a location fix in seconds using nearby cell tower information. The new Geolocation service is now part of the Locate Service. The best part? It’s free to developers!

Users can be indoors with no GPS coverage, but your app will still be able to guide them to restaurants or points of interest (POI) around them. Although the accuracy of the fixes obtained from the Geolocation service may not always be as high as with GPS, it has use cases for apps that require highly accurate GPS fixes as well as apps that do not. Apps that require high accuracy can use this service to quickly show the user an approximate location while it waits for a more accurate location fix using GPS. This can offer a huge user experience improvement. For applications that do not require high accuracy, this service can be leveraged as a simple yet effective mechanism to provide location information.

To take advantage of the Geolocation service, you simply need to ask for a location fix via your LocationProvider or BlackBerryLocationProvider using the appropriate Criteria, or BlackBerryCriteria for the Cellsite mode. It is important to note that this service requires BlackBerry® Application Platform v5.0 or higher and users must be signed up with a carrier that has enabled these capabilities.

You can also consider combining the Locate Service with the BlackBerry® Maps Service to offer a variety of features from navigation directions to POIs. The BlackBerry Maps Service complements the Locate Service by providing map displays that can be invoked or embedded to indicate a user’s location. Please refer to net.rim.device.api.lbs.MapField class and the net.rim.blackberry.api.invoke package for details on APIs related to Map Service.

In BlackBerry Device Software, we’ve also enhanced the existing Geocoding functionality provided by the Locate Service. Using the net.rim.device.api.lbs.Locator class, you can now ask for reverse geocoding in addition to the geocoding functionality we already offered. Reverse geocoding is capable of converting latitude and longitude to a meaningful address. One of my favorite features of the new reverse geocoding functionality is that you can ask for contextual location information at a variety of levels from the street address to the state depending on the granularity required by your application. As a developer, you are able to take advantage of this service with a single method call while we do all the heavy lifting behind the scene.

These new features and capabilities are a great extension of all the work we did within the last year on our location-based services environment. In BlackBerry Application Platform v5.0, we introduced an extension API to the standard Location API (JSR 179). This extension API is much easier to work with and creates new opportunities for all application developers to leverage location within their apps. Please refer to the net.rim.device.api.gps package in the API documentation.

In addition to the extension API, we introduced a set of flexible Location Picker UI components that integrate seamlessly with the BlackBerry Maps and Contacts applications as well as with the GPS capabilities of the device. Check out the net.rim.device.api.lbs.picker package in the API documentation for more information.

The combination of the Locate and Maps Services opens the door to contextualized and location-aware applications that go above and beyond what is available today. We are very excited to hear your feedback on these new capabilities and how you plan on using them within your application.