In the past months I’ve written some articles (here, here and here) about using FDT as the primary IDE for Flash Lite development, and my overall impression with the whole IDE was (and is) absolutely good: being an Eclipse-based IDE, you can find all the powerful Eclipse features, plus a lot of added functionality specific for Flash developers.

Contest details and rules are available here.

Good Luck!

With different backgrounds, we all aim at providing useful information about the mobile environment, in all its aspects. From its manifesto:

The aim of this community is to share as much as possible information related to the mobile development using all the social networks and the new capabilities of the NET to make easier find updated contents and to create a deep feeling of connection between developers.

The journey is at the beginning, hope you’ll join in!

The funny thing is that Flash Lite is mentioned as an “emerging” platform, even if it’s not that young

From the official announcement:

In 2009, we reported an installed base of 80+ million devices with Flash Lite support in Japan. To download the Flash Lite SDK, log into your account, select the “Sites & Apps” tab, and click on the “Add Site/App” link. On this page, you can register your Flash Lite app and then download the SDK.

This will finally allow all Flash Lite developers to easily integrate AdMob advertising into their applications and games, without the need to implement this functionality from scratch.

After the announcement of in app purchasing for Flash Lite from Kuneri, this is a big step towards the monetization of Flash Lite content, and will hopefully help the Flash Lite developers’ community to grow further.

Maybe we won’t become all billionaires, but who knows?

First of all, let’s say that Bada is all but a new OS: Bada is actually a refactored and readapted version of the OS used for years by Samsung as their legacy OS. The good news is that now it has been made available and open to all developers, that can use all the APIs that were previously accessible to Samsung and its partners only.

When I say open it means really open: API set is impressive, and it seems there’s actually nothing that has been left out. The comparison with other “modern” OS (e.g.: iPhone and Android) shows how Bada gives to developers a new level of access to the device and its features.

Bada applications are built by using C/C++ code, but there is a good news for non C-speakers: Bada devices come with Flash Lite support (Samsung Wave ships Flash Lite 3.0) and you can package a Flash Lite application into a native one, and distribute it on the Bada App Store. But the good news are not ended, since the Bada architecture allows Flash Lite content to access every native API! This is huge, and as a Flash developer I cannot be more happy of this!

Coming to the downsides: Bada applications cannot run in background, so no real multitasking is allowed. When an app goes in background, it is simply paused, and you can resume it from the active apps list. As for the development part, the SDK has currently some glitches, as the necessity to be restarted each time an application has to be deployed. Anyway, being not a final release, we can expect improvements in the next versions.

Summarizing it up, the first “contact” with the Bada environment was good: the OS is powerful and open, with the Flash Lite support and native API access being actually the best parts in my opinion. The current only Bada device (the Wave) is fast, responsive and with a nice touchscreen (differently from what seen on some recent Samsung models, see H1).

What remains to see is if all this good stuff will be able to gain a decent market share, and so if it’ll be worth to invest time and money on it.

10×10™ (‘ten by ten’) is an interactive exploration of the words and pictures that define the time. The result is an often moving, sometimes shocking, occasionally frivolous, but always fitting snapshot of our world. Every hour, 10×10 collects the 100 words and pictures that matter most on a global scale, and presents them as a single image, taken to encapsulate that moment in time. Over the course of days, months, and years, 10×10 leaves a trail of these hourly statements which, stitched together side by side, form a continuous patchwork tapestry of human life.

The app is available for free on both Ovi Store and GetJar. Here is a short video of 10×10 Mobile running on a Nokia N97: smooth, isn’t it?

Good job Leo!

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.

The document focuses on three kind of applications: websites, web apps, and stand-alone Adobe Flash applications, covering all topics involved in design and development of a RIA, from development tools to user experience design and evaluation, from testing to going to market.

Mobile offers significant opportunities for RIAs. The ability to access data and information anywhere there is a suitable network connection is of significant appeal to mobile users. The knowledge that their data is also securely stored on a remote server, regardless of what happens to the mobile device, is a significant attraction as well.
With many hundreds of millions of Nokia devices already in the market place that can run RIAs now, there has never been a better time to go mobile with your RIA.

Check it out!

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.

In this article I’ll try to explain how to setup and develop a Flash Lite application that uses APIBridge, by using FDT.

If you want to know how to configure FDT (and Eclipse) to properly develop Flash Lite application, you should read this article: Web Runtime and Flash Lite integrated development on Eclipse.

Setup the project in FDT

First of all, you need to download the API Bridge FlashLite library from Forum Nokia: API Bridge Flash Lite Library and Sample Code. The package also contains useful sample code that will definitely help.

Now, create a new Flash Lite project within Eclipse.

Then, open up the API Bridge package downloaded from Forum Nokia, and copy the “si/” folder to the “src/” folder of your Flash Lite project.

Once copied, you should notice some errors in your FDT project, as shown in the picture below.

These errors are due to the “mx.*” package, that is not included in the ActionScript classes shipped with FDT. To solve this error, you have to tell FDT where to find these classes.

First, let’s copy these classes from the Flash IDE to a dedicated folder:

1. Create a folder called “mx_package/” somewhere on your machine
2. Go into “<FLASH_IDE_PATH>\en\First Run\Classes\” folder
3. Copy the “mx/” folder inside the “mx_package/” folder created above

Now, configure FDT:

1. Go into “Window” -> “Preferences” -> “FDT” -> “Core Libraries”, open the “Path variables” panel and select “New…”
2. Enter “MX_PACKAGE” as name, and select the “mx_package/” created above as folder
3. Once done, your Core Libraries should look similar to the picture below

Now, what remains to do is to add the MX library to the Flash Lite project. Go into the project’s properties and, in the “FDT Build Path” section, select “Add Linked Library…” -> “Add…” and pick “MX_PACKAGE”.

Done this, all the errors should have gone away from the project. Hurrah!

Patching the mx.utils.Delegate class

The MTASC compiler is stricter than the compiler you can find within the Flash IDE. For this reason, the mx.utils.Delegate class needs to be slightly modified in order to make it properly compile with MTASC.

Specifically, the ‘create()’ function needs to be adjusted as follows:

static function create(obj:Object, func:Function):Function
{
	var f = function()
	{
		var target = arguments.callee.target;
		var func2 = arguments.callee.func;
		return func2.apply(target, arguments);
	};
	f.target = obj;
	f.func = func;
	return f;
}

Patching the si.apibridge.APIBridge class

For the same reasons explained above, also the si.apibridge.APIBridge class needs to be patched to work with MTASC.  To do this, open APIBridge.as and replace the setPort() function with this one:

	private function setPort(): Void
	{
		var portVars:LoadVars = new LoadVars();
 
		portVars.load( portPath );
 
		var pushErrorDelegate : Function = Delegate.create(this, pushError);
 
		portVars.onLoad = function( success )
		{
			if (success)
			{
				var portData:String = portVars.toString();
				portData = portData.substr(0,portData.indexOf("="));
				trace(portData);
				APIBridge.BridgeURL += portData; 
 
			}
			else
			{
				trace("Error loading Port");// The data didn't load
				pushErrorDelegate("1","Error loading port, using default 9080");
				APIBridge.BridgeURL += "9080";
			}
 
		}
	}

Once done, just create a new MTASC launch configuration and check that the project properly compiles. If it doesn’t, re-check the steps above.

Using API Bridge Call Log service in Flash Lite

Now, we’ll see how to use an API Bridge service, the Call Log one, in Flash Lite.

First, let’s create the main project’s class. In this example I’ll call it ‘MainMovie’.

import com.jappit.flashlite.apibridgetest.Logger;
import com.jappit.flashlite.apibridgetest.CallLogRetriever;
 
class com.jappit.flashlite.apibridgetest.MainMovie
{
	public static function main(container : MovieClip) : Void
	{
		Stage.align = "TL";
		Stage.scaleMode = "noScale";
		container.createTextField("tf", 1, 0, 0, 360, 500);
		var textField : TextField = container["tf"];
	}
}

The TextField instance will be used to show the events retrieved from the device logs. Now, let’s create a separate class, EventsLogRetriever, that will take care of calling APIBridge, and of managing its responses. Its constructor is defined to accept a TextField as argument, and it will use it to print out the API Bridge response.

import mx.utils.Delegate;
import si.apibridge.*;
 
class com.jappit.flashlite.apibridgetest.EventsLogRetriever
{
	private var textField : TextField;
 
	public function EventsLogRetriever(_textField : TextField)
	{
		this.textField = _textField;
	}

Now, it’s time to define the method that will call the API Bridge engine. Each call to an API Bridge interface must typically define two handlers: a success and a failure handler. The error handler receives a single argument, containing the data of the occurred error. About the success handler, it receives three arguments:

1. the transaction ID, that must be used to uniquely identify the transaction that is calling the handler (useful in scenarios where multiple transactions are active concurrently)
2. the event ID, that identify the state of the event
3. an object containing data returned by the API Bridge call

Said that, the EventsLogRetriever class will end up containing these 3 methods:

public function retrieveEvents() : Void
{
}
public function onApiError(outParam : Object) : Void
{
}
public function onApiSuccess(transactionID:Number, eventID:String, outParam:Object)
{
}

Starting with the retrieveEvents() method, it has to:

• instantiate APIBridge, passing a reference to the error handler as argument
• grab a reference to the Logging service
• define which kind of log events it wants to retrieve
• call the GetList() service method

So, the retrieveEvents() can be implemented as follows:

public function retrieveEvents() : Void
{
	var _onApiError : Function = Delegate.create(this, onApiError);
	var _onApiSuccess : Function = Delegate.create(this, onApiSuccess);
 
	var bridge:APIBridge = new APIBridge(_onApiError);
 
	var logging = bridge.Service("Service.Logging", "IDataSource");
 
	textField.text  = "Retrieving phone numbers ..." + APIBridge.BridgeURL;
 
	var filter = {EventType:0};
	var inParams = {Type:"Log", Filter:filter};
 
	logging.GetList(inParams, _onApiSuccess);
}

Coming to the error handler, let’s just implement it to make it show the returned error data:

public function onApiError(outParam : Object) : Void
{
	textField.text  = "APIBridge error " + outParam.ErrorCode + " " + outParam.ErrorMessage;
}

Now, the success handler. First, it has to check if the returned API Bridge data contains an error, and this can be done with the same logic used in the error handler above. If no errors are detected, the handler can retrieve the actual returned data, contained in outParam.ReturnValue, and loop all the returned log events.

public function onApiSuccess(transactionID : Number, eventID : String, outParam : Object)
{
	textField.text = "Results: " + outParam.ReturnValue.length + "\n" ;
 
	if (outParam.ErrorCode != 0)
	{
		textField.text = "Error: " + outParam.ErrorCode + ", " + outParam.ErrorMessage;
		return;
	}
	else
	{
		var outList = outParam.ReturnValue;
		var outputEntry = null;
		do
		{
			outputEntry = outList.next();
 
			if (null != outputEntry)
			{
				textField.text += outputEntry.Direction + ": " +
					outputEntry.Description + ", " +
					outputEntry.PhoneNumber;
 
				textField.text += "\n";
			}
			else
			{
				break;
			}
		}
		while (true);
	}
}

Done this, the EventsLogRetriever is ready to be used, and to do this it’ll be enough to add this two lines to the static() method of the MainMovie class:

var retriever : EventsLogRetriever = new EventsLogRetriever(textField);
 
retriever.retrieveEvents();

That’s all!

Build and deploy

Once the Flash Lite app is ready, just build it using the MTASC launch configuration created before.

Now the tough part: to make the whole thing work, it is necessary to package the Flash Lite application with the API Bridge engine. To do this, there are various options:

1. Build a Flash Lite launcher in Symbian C++. These Forum Nokia Wiki articles explain how this can be done:
   • How to make Flash launcher with Symbian C++
   • Create Flash Applications with Carbide.c++
2. Package the Flash Lite application in a WRT widget, and then package it with the API Bridge engine. This approach is described in these articles:
   • How to use FDT and Aptana to create a Flash Lite enabled WRT widget: explains how to package Flash Lite in a WRT widget
   • Build your first Web Runtime widget with APIBridge: explains how to package a WRT widget with the API Bridge engine

Both the approaches can equally work, so feel free to choose the one you prefer

Once deployed on a device, just run it, and you should see this:

1) The Flash Lite app starts, and the API Engine is initialized

2) The API Bridge engine asks the user for permission to access sensitive data

3) And here are the retrieved log events!

First of all, be sure to have installed all the required Eclipse plugins, as described here.

Create a new Web Runtime widget

To create a Web Runtime widget, just open up the “New Project” wizard and select the “New Nokia Web Runtime Widget”.

The wizard will now let you choose from some predefined widget templates. In this article, it is enough to start with an empty widget.

And finally enter the name and identifier of your new widget. The identifier has to be a string in the reverse domain format, and will uniquely identify your own widget.

Once created, the widget’s structure should be the one shown below.

Create the Flash Lite content

First, create a new Flash Lite project by using the “New Flash Project” template. Then, create the project’s main class. One example is the MainMovie class shown below:

class com.jappit.flashlitetest1.MainMovie
{
	public function MainMovie()
	{
	}
 
	public static function main(container : MovieClip) : Void
	{
		Stage.align = "TL";
		Stage.scaleMode = "noScale";
		container.createTextField("tf", 1, 0, 0, 100, 100);
		var tf : TextField = container["tf"];
		tf.text = "I'm the Flash Lite content!";
	}
}

Changing the MTASC launch configuration

Now, the MTASC command has to be changed a bit, so that the generated SWF will automatically end up in the Web Runtime widget project’s folder.

To do this, open up the MTASC launch configuration, and change the generated SWF path to be a subpath of your widget’s main folder. You can see an example of the command in the picture below.

Now, run the project launch configuration, and check the widget’s folder: the SWF generated by MTASC should be there, together with the other widget’s files.

Including the SWF content in your widget

Forum Nokia Wiki has a comprehensive article explaining the possible ways of integrating Flash content into a Web Runtime widget. In this article the first described approach, the same used on the Web, is implemented.

So, take the widget’s index.html file, and add this HTML code:

<object id="MyFlash" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="200" height="200" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0">
	<param name="align" value="middle" />
	<param name="allowScriptAccess" value="sameDomain" />
	<param name="loop" value="false" />
	<param name="menu" value="false" />
	<param name="quality" value="high" />
	<param name="wmode" value="opaque" />
	<param name="bgcolor" value="#ffffff" />
	<param name="src" value="default_mtasc.swf" />
	<param name="name" value="Finish" />
	<embed id="MyFlash" type="application/x-shockwave-flash" width="200" height="200" src="default_mtasc.swf" name="Finish" bgcolor="#ffffff" wmode="opaque" quality="high" menu="false" loop="false" allowscriptaccess="sameDomain" align="middle"></embed>
</object>

Packaging and deploying

If all went well, all is ready to be packaged and deployed.

Right click the project, choose “Package widget”, deploy and enjoy!

You can download the widget built in this article here: Flash Lite enabled WRT sample widget.