You can read all the details, download the library together with sample code, and read the full JavaDocs here: MidMaps – J2ME Google Maps library.

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.

Start downloading the new release from Forum Nokia: API Bridge release 1.1.

Then, check out this informative Wiki articles, that explain how to build a new, custom plugin and how to use it from JavaScript:

• APIBridge Plug-in API
• Creating APIBridge JavaScript Binding Code

For more information about API Bridge, check out its Forum Nokia page.

Basically, when you want to extend the functionalities of a WRT widget or a Flash Lite application, you have two options:

• Platform Services
• API Bridge

Both of them provide a set of tools and libraries that, added to your applications, allow them to access more functionalities than the ones that each technology naively supports.

So, which approach is the best one? It’s not easy to give a unique answer to this question, so let’s go into details.

Ease of use

The Platform Services library is available from more time, and there’s a well established set of resources and code examples that will help you to quickly get your functionalities ready and running.The primary source of information is Forum Nokia Library, that has a detailed references of APIs and useful sample code. Then, also Forum Nokia Wiki provides an extensive set of examples that cover all the possible usage scenarios. Even if there is some little parts where this information could be improved, you shouldn’t get much in trouble when using Platform Services in your application.

API Bridge is a fresher technology, released on November 2009, and so it’s harder to find complete documentation and usage examples. Anyway, Forum Nokia released a set of libraries for various platforms (Flash Lite, Web Runtime and Java ME) that will definitely help in starting to use API Bridge.

Device support

Platform Services are fully supported starting from S60 5th edition devices, but are also compatible with a subset of S60 3rd edition Feature Pack 2 devices: the full list of supported devices is available here: Web Runtime 1.1 compatible devices. This means that you can use them only on the touch screen Nokia devices.

On the other side, API Bridge can work on all devices starting from S60 3rd edition Feature Pack 1 onwards, so meaning:

• S60 3rd edition Feature Pack 1
• S60 3rd edition Feature Pack 2
• S60 5th edition

Available features

Current Platform Services (version 1.0) allow to access a wide set of features:

• Application Management
• Calendar
• Contacts
• Landmarks
• Location
• Logging
• Media Management
• Messaging
• Sensors
• System Information

It is currently available also a beta release of Platform Services 2.0, that adds to this features’ set also the access to the device camera.

API Bridge, instead, has a more limited set of functionalities, currently including:

• Capture of photos, videos and audio streams
• Files uploading
• Files reading
• Image resizing
• Location
• Logging
• Media Management

Supported technologies

Platform Services are currently available for Flash Lite and Web Runtime applications.

API Bridge libraries have been released for Flash Lite, Web Runtime and Java ME. Generally speaking, the API Bridge engine, working as a local HTTP server running on the device, is accessible from all technologies.

Overall considerations

The current implementation of Platform Services and API Bridge don’t allow to decide which approach is the best one, and there is no need to do it anyway. Right now, if you’re working in Flash Lite or Web Runtime, and as long as your set of target devices support them, you can benefit of both technologies, including the two libraries in your application.

Talking about future perspectives of both approaches, we can see both of them evolving in more mature products.

Platform Services 2.0 is already available as a beta release, so you can already start experimenting with the new APIs and features, including the access to the device camera. On the other side, API Bridge promises to allow everyone to create custom plugins, through the ECOM interface, as reported on Forum Nokia Blogs.

Concluding, Platform Services, with the already mature and features-rich library, surely represents a simpler approach for developers who don’t want to deal with Symbian building and packaging, while API Bridge, with its plugin architecture becoming mature and open to developers, could definitely end up to be the best ally to allow widgets and Flash Lite apps access more and more features.

X1 Mobil allows to discover all the secrets of the new BMW X1, together with launch events, sport news, travel information and much more, with just a few clicks.

The current version is compatible with various BlackBerry and Java ME enabled devices. Check out the app download page for more details: BMW X1 Mobil download page.

Feedbacks are welcome!

With version 0.3.5 it’s now possible to manually set the preferred timezone from the application Settings screen. To do so, you have 2 choices:

• If you want to use the timezone sent by Google Calendar server, you can set to “Yes” the “Use server timezone?” option
• If you want to explicitly set your timezone, then set the previous option to “No“, and then specify your timezone offset in the “Timezone” field

If you have problems with timezone in your GCal client, then you should definitely update. Just update from within GCal (“Options” -> “More..” -> “Check updates”), or download version 0.3.5 from here:

JAD file is also available for download here: Gcal JAD download.

Give it a try and, if you still get error messages while logging in, leave a comment here specifying the exact message you get. Thanks!

JAD file is also available for download here: Gcal JAD download.

• Wrong saving of “All day” events
• Wrong time of events saved on device calendar
• Various other unhandled Exceptions that were causing crashes of the application

In this release, a first support for previous Nokia Series60 editions (specifically: 1st and 2nd editions) has also been added, so you should now be able to use Gcal on your beloved Nokia 6600

And, for those who still experience problems, more meaningful error messages have been set, so that it’ll be easier to spot out and solve the issues. So, when reporting a problem, please also add the exact error message you get in the related error popup. Thanks!

If your mobile phone also needs a JAD file, you can download it from here: download Gcal JAD.

Most of the work was done to improve device compatibility and fix bugs on specific handsets (e.g.: BlackBerry devices, Nokia E61, and many more).

Release details

New cool features are introduced:

• Touch-screen support: if you have a device supporting touch, now you can easily interact with Gcal with stylus/fingers!
  Touch gestures are also implemented: go from a day to another simply swiping!
• Event saving on local calendar: you can now save an event on your local calendar. If you’re creating a new event, just check the “Save on local calendar” option. Instead, if you’re viewing a saved event, choose “Actions” -> “Save locally” from the options menu.

New settings are also available:

• Font size: introduced to improve readability, and to allow users with touch-screen to have larger touchable areas
• Alternative soft-keys: devices without hardware soft-keys can now use ‘*’ and ‘#‘ keys to substitute them, and so use Gcal without any more problems
• Show only calendars with events: this will allow users with a lot of calendars to show only the ones actually selected in the “Filter calendars” screen, greatly improving events readability

Among the fixed bugs:

• Calendar loading errors on various handsets
• Filters scrolling and selection in calendar filtering screen
• Screen size/orientation changes are now better handled

Give your feedback

A lot of new features are still under development, and surely a lot are the missing features that you would like to see into your Gcal. Just leave your comment here, and your feedback will be surely considered for the next Gcal releases!

JavaFX is an expressive rich client platform for creating and delivering rich Internet experiences across all screens of your life. [...] With JavaFX Mobile, Sun is bringing expressiveness to the most powerful and pervasive mobile platform. On mobile devices, JavaFX runs directly on Java ME to take advantage of its ubiquity, security, and highly capable feature-set.

To get an idea of what you can do with JavaFX, you can look at the samples posted on JavaFX website, shipped with the source code used to achieve these results. They’re just impressive!

Can’t wait anymore? Then download JavaFX and start learning!