When displaying a map in a Java ME application, it can be useful to be able to intercept events generated by the interaction of the user with the map itself, and the MapComponent and EventListener interfaces give complete support for keyboard and touch-based events.

Check out the full article, showing how touch events can be used to add markers to a map, and let me know your comments: Handling map events with Java ME Location API.

The MapProvider and MapUrlProvider abstract classes are used to provide the data needed to display custom map tiles, that can be used to replace the default map tiles, or displayed above those one, so creating overlay map levels.

When using the MapUrlProvider class, the only needed information that the class must provide is the URL of each tile, that will be used by the class itself to retrieve and create the associated Image object.

The article published on the Nokia Developer Wiki, with both client and server code, shows a possible usage of the MapUrlProvider class to create an overlay level over a map: Implementing a custom MapUrlProvider overlay with Java ME Location API.

PositioningManager, together with the PositionListener interface, allow to get asynchronous and periodical updates about the user’s position, and so allowing to build location-based services in a simple and effective way.

The new article published on Nokia Developer Wiki explores the main features of PositioningManager, and shows how to build a simple service that detect and draw the user’s movements on Ovi Maps: Using the PositioningManager from Java ME Location API.

While the previous two articles focused on the MapCanvas object, showing how it can be used to show a map on a classical LCDUI Canvas screen, today’s article shows how to build a custom map Form Item, extending the CustomItem class, so allowing to show and interact with a map on a classical LCDUI Form screen.

The article, with complete source code and downloadable MIDlet, is available here: Creating a custom Map Item with Java ME Location API.

This new article covers the main aspects involved in calculating and showing a route on a map, by allowing the user to navigate through the maneuvers of the calculated route.

The full article with source code and a downloadable MIDlet is available on Nokia Developer Wiki: How to calculate and show a route with Java ME Location API.

I’ve recently started to publish a set of articles on Nokia Developer Wiki that show the various features of the API in action. You can read the first one here: Geocoding an address with Java ME Location API.

Check it out and let me know your comments.

The video below shows how the component behaves on a Nokia N8 device.

Check out the full article on Forum Nokia Wiki: simple QML View Manager.

You can see a video of the CoverFlow component in action on a Nokia N8 device below.

The full source code is available here: Building a CoverFlow component with QML.

Changes in this last release include:

• Samples and packaging information for Platform Services 2.0
• Guidelines and how-to’s for home-screen widgets
• Optimization of performances and battery life

If you’re a mobile Web developer, check it out!

For single-person and small developer teams, the whole Symbian process could be a not suitable option. For this reason, I’ve looked for an alternative deployment approach that could bypass this process. The approach presented here is based on a delayed deploy model, meaning that the API Bridge engine is not deployed with your application, but in a successive moment: actually, it is deployed only when the application needs it.

How this can be achieved? Basically, there are 2 possible options to implement this model, and they’re based on:

• AppManager API from Platform Services
• Local HTTP calls

Using the AppManager API to check API Bridge

If the target devices support Platform Services, the AppManager API can be used to retrieve the list of installed applications, and so to check if API Bridge is installed on the device itself.

The code below shows how this can be achieved by using JavaScript in a WRT widget. The same approach can be easily ported to ActionScript, and so used in a Flash Lite application.

var apiBridgeFound = false;
var apiBridgeCheckError = null;
 
var so = device.getServiceObject("Service.AppManager", "IAppManager");
 
var criteria = new Object();
criteria.Type = 'Application';
 
var result = so.IAppManager.GetList(criteria);
 
if(result.ErrorCode == 0)
{
	var iterator = result.ReturnValue;
 
	var application;
 
	while((application = iterator.getNext()) != undefined)
	{
		if(application.Uid == '0x20023710')
		{
			apiBridgeFound = true;
 
			break;
		}
	}
}
else
{
	apiBridgeCheckError = result.ErrorMessage;
}

The code works by checking the UID of all the installed applications, comparing them with the API Bridge UID (0×20023710). This code snipped defined 2 variables, that can be used to check for API Bridge availability:

• apiBridgeFound: if true, it means that the API Bridge engine is installed on the device. If false, the API Bridge engine is not installed.
• apiBridgeCheckError: if not null, it means that there was an error while checking for API Bridge, due to the AppManager API. In this case, the application cannot actually know if the API Bridge engine is installed or not.

So, once these 2 variable have been set, the application can perform the most appropriate operation, based on the AppManager call result. The code snippet below shows a possible implementation:

if(apiBridgeCheckError != null)
{
	alert("There was an error! " + apiBridgeCheckError);
}
else if(!apiBridgeFound)
{
	if(confirm("You have to install API Bridge to continue, press OK to download it"))
	{
		widget.openURL('http://www.yourserver.com/APIBridge_v1_1.sis');
	}
}
else
{
	alert("API Bridge is already installed on the device!");
}

And below you can see this code running on a Nokia 5800 XpressMusic:

Using local HTTP calls to check API Bridge

Since the API Bridge engine works as a local HTTP server running on the mobile phone, the other possible approach is to make an HTTP request, and to check if any response from API Bridge comes.

Note: this approach works by using the API Bridge default port (9080). There are no guarantees that this port number is fixed, and that it will not be changed in future API Bridge releases. For this reason, my advice would be to use this second approach only when Platform Services are not available.

The code below shows how to make a request to the local API Bridge HTTP server, and how to check if it’s running or not: if it is running, the response status of the XMLHttpRequest object has to be different than zero.

function pollApiBridgeServer(_callback)
{
	var request = new XMLHttpRequest();
 
	request.open("GET", "http://127.0.0.1:9080", true );
 
	request.send(null);
 
	request.onreadystatechange = function()
	{
		if( request.readyState == 4)
		{
			if(request.status != 0)
			{
				_callback(true);
			}
			else
			{
				_callback(false);
			}
		}
	}
}

The approach described here can be used also when using API Bridge from other languages, as Flash Lite or Java ME. Anyway, when working with Flash Lite, in the scenario where API Bridge is not yet installed, you will incur in the typical (and horrible) error popups, that will inform you (and so the user) that the network call failed.

How to use the code above? First, define a callback:

function pollApiBridgeCallback(apiBridgeInstalled)
{
	if(apiBridgeInstalled)
	{
		alert("API Bridge is already installed on the device");
	}
	else
	{
		if(confirm("You have to install API Bridge to continue, press OK to download it"))
		{
			widget.openURL('http://www.yourserver.com/APIBridge_v1_1.sis');
		}
	}
}

Then, just call the pollApiBridgeServer() method by passing a reference to this callback:

pollApiBridgeServer(pollApiBridgeCallback);

Pros and cons

Using one of the two approaches discussed above as some important advantages over the standard API Bridge deployment mechanism:

• You don’t have to build a SIS package
• You don’t have to sign your application to distribute it
• You will save money

On the other side, these approaches have the main drawback on the user-experience side, since your users could be asked to download and install an additional component when they start to use your application. Anyway, this event will happen only once at most, so it could be considered reasonable in most scenarios.