Updates from July, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • pit 12:35 pm on July 9, 2010 Permalink | Reply
    Tags: , , , , flex, , nokia devs   

    NokiaDevs offers full FDT licenses to two lucky Flash Lite developers! 

    If you’re a Flash, Flash Lite or Flex developer, then you should definitely join the contest launched by NokiaDevs: you can win a full FDT 3.5 Pure license (working also with FDT 4 beta versions), with just a tweet or a Facebook message!

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

     
  • pit 5:15 pm on May 25, 2010 Permalink | Reply
    Tags: community, mobilerevamp   

    Mobile development revamped, on MobileRevamp.org 

    A new community for all mobile developers, designers and everything-else gets officially launched today, thanks to the efforts of Giorgio Natili, Leonardo Risuleo, and Alessandro La Rosa (me ;) ): http://www.mobilerevamp.org

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

     
  • pit 6:26 pm on March 23, 2010 Permalink | Reply
    Tags: admob, , ,   

    AdMob launches Flash Lite SDK! 

    Good news for all Flash Lite developers: AdMob officially launched its Flash Lite SDK!

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

     
  • pit 12:18 pm on March 17, 2010 Permalink | Reply
    Tags: , bada, developers day, ,   

    Samsung Bada Developers Day: all we need is… a new OS? 

    Recently I had the opportunity of attending the Samsung Bada Developers Day in Milan, and I would like to share my first impressions about the Bada OS.

    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.

     
    • Alessandro 1:10 pm on March 17, 2010 Permalink

      Ciao Alessandro,

      great information! I knew about FL 3 support, but the access to other API it’s new!! Very cool.
      Alessandro

    • pit 1:16 pm on March 17, 2010 Permalink

      Yes, it’s definitely cool :)

      I’ve still not tested it by myself, but it seems that you have an open communication channel from Flash Lite to C++ to pass any kind of commands between the 2 layers. Will post here as soon as I have more information!

  • pit 6:29 pm on March 12, 2010 Permalink | Reply
    Tags: 10x10, , , ,   

    New Flash Lite application: explore the world by images with 10×10™ Mobile! 

    Leonardo recently released a new, cool Flash Lite app for S60 touch devices: 10×10™ mobile!

    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!

     
  • 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.

    • Diogo Moreira 2:13 pm on June 7, 2010 Permalink

      Hi Alessandro, Is there anyway to change themes phone using APIBridge by requisition for wrt ?
      I wait answer, Thanks !

    • pit 2:38 pm on June 7, 2010 Permalink

      Yes, by implementing a custom plugin you can also let a WRT widget change the device active theme. This Forum Nokia Wiki article could help for the C++ part:

      http://wiki.forum.nokia.com/index.php/TSS000456_-_Changing_the_active_theme

    • Pedro Cardoso 6:49 pm on June 25, 2010 Permalink

      Hi,

      I’m trying to use APIBridge on my app as you explain on this post, but whenever I try to do a function call (ie: retrieve the list of photos, or resize an image), the app crashes without any warning. Just quits and that’s it. The APIBridge detection is working as you outlined.

      Do you know any way I can troubleshoot, where/if any logs exist that explain the cause?

      Thanks a bunch.

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
shift + esc
cancel