Posts Mentioning RSS

  • pit 10:35 am on February 18, 2010 Permalink | Reply
    Tags: , , ,   

    Deploying API Bridge apps the easy way: the delayed deploy model 

    When developing a Flash Lite, Web Runtime or Java ME application based on API Bridge, one of the things you know you’ll have to deal with is the Symbian packaging and signing process.

    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.

     
    • Pat 4:16 am on March 1, 2010 Permalink

      Hi Alessandro , I’m trying to understand how to package/install a custom API bridge with a J2ME app. A specific post about that would be great. Thanks.

  • pit 11:17 am on February 16, 2010 Permalink | Reply
    Tags: developers guide, flash, , ria,   

    Rich Internet Application developer’s guide for Nokia devices 

    Forum Nokia has recently published a very informative guide about developing RIAs for mobile devices: A developer’s guide to creating Rich Internet Applications for Nokia devices.

    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!

     
  • pit 11:03 pm on February 14, 2010 Permalink | Reply
    Tags: , location, ovi maps   

    Ovi Maps: a flexible platform for web and mobile location based services 

    This week Forum Nokia Wiki features an article explaining the opportunities that the Ovi Maps service offers to web and mobile developers.

    Ovi Maps offers a complete and flexible platform to build rich location-based services. By providing a consistent set of components and libraries, Ovi Maps allows developers to build both a web a mobile version of their applications with minimum effort.

    Interested in what can be done with Ovi Maps? Here are some links taken from the article:

    Next steps? Check out the whole article: Ovi – Opportunities for developers, and then sign up for the Ovi Maps beta program!

     
  • pit 5:51 pm on February 12, 2010 Permalink | Reply
    Tags: , testing, tips   

    How to speed up deploying and testing of your API Bridge-based applications 

    When working with API Bridge applications, you need to package them with the API Bridge engine within a Symbian SIS package each time you want to deploy it on a device. This could actually be a big drawback when developing a new app, since it greatly slows down all the building and deploying process.

    This is right, but luckily enough there’s an alternative, really easy approach to test your API Bridge-based applications on your devices. The picture below should say it all:

    It couldn’t have been simpler:

    1. Deploy the APIBridge SIS (APIBridge_v1_1.sis for API Bridge version 1.1) on the device, only once
    2. Deploy your application (Web Runtime, Flash Lite or Java ME) as you would have done without API Bridge, all the times you want
    3. Done!

    By deploying the APIBridge engine separately, you can actually save tons of time during all the development phase, since you don’t need anymore to package your apps in a classical Symbian package. Hurrah!

     
  • pit 7:32 pm on February 11, 2010 Permalink | Reply
    Tags: , , , , ,   

    API Bridge version 1.1: plug-in creation package released! 

    The announced new version of API Bridge is out! With the new 1.1 release it is finally possible to create custom plugins that access all the Symbian functionalities, so practically opening up the doors to a new generation of Flash Lite, Web Runtime and Java ME applications.

    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:

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

     
  • pit 11:58 pm on February 9, 2010 Permalink | Reply
    Tags: , , , , ,   

    How to use Nokia API Bridge in Flash Lite with FDT 

    API Bridge is a Symbian engine that exposes a set of native functionalities to Web Runtime, Flash Lite and Java ME applications. Nokia has recently released an ActionScript library that allows to easily integrate APIBridge functionalities in a Flash Lite application.

    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:
    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:

    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!

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel

Switch to our mobile site