Android application development over Flex/AIR - Tikal FuseDay #3

I have been fooling around with the Hero SDK, AIR 2.5 and Burrito combo for a few months now, but never did something that has real value - it was always some small scale projects, no real-life situations. See related session I lead on Tikal's flex group here.

This Fuse day, I decided to implement a simple RSS reader dedicated to Tikal's community site. These were familiar grounds, and I quickly accomplished a simple Android application that connects to the site RSS feeds and displays a synopsis, it took about 4 hours to implement and I was encouraged with how fast it went.

 

When I came to the point where I wanted to add some more advanced features, like local RSS item caching, things started to crumble.

Since the RSS returns only the last 10 items, I wanted to create a local items cache, have it updated in the background every interval and have the application load items from that cache instead of directly from the RSS feed.

This means a few things:

  • I want it to run on system load
  • I want it to prevent the OS from closing it
  • I want it to poll the RSS feed periodically and update the local cache
     

Android OS controls the running state of apps in the background, and can close them to free up memory. Hence, it's not guaranteed that your application will run forever. Unfortunately, Adobe does not yet provide the APIs to allow implementation as a service (or a widget) and it felt like I crashed into a roadblock. Had it been an enterprise application or something my business depends on in real life, it would have been a real disaster.

 

This lead me to the conclusion that for small scale projects, Flex for Android is great. It offers really fast development and "time to market", as well as all the power of the Flash runtime, animations and the ability to deploy on multiple platforms. But for some larger scale projects that require functionality not provided by Adobe or that you can't say if you will need it or not in early stages of the project, then native is the only way to go. The last thing you want is for your development process to stall because you have to wait for Adobe to provide a missing API.

 

Below is a summary of the pros and cons, as I see them.

  • Flex PROs
    • Write once, deploy everywhere
    • Fast coding
    • Visually pleasing
    • Harness the full power of Flas
  • Flex CONs
    • Limited to the APIs provided by Adobe
    • Must have AIR runtime install
  • Native PROs
    • Access to all device APIs
  • Native CONs
    • Write once, deploy once
    • Use native L&F
    • Know multiple languages to support multiple platforms
    • Work hard to achieve effects and advanced graphics

 

To sum-up, I started the day with great optimism and by the end of the day I was cautiously pessimistic. My feeling is that while it's a good idea, it is not yet 'there' and I'm not sure it will ever get 'there'.
Chances are that Adobe will always be at least one step behind what the different OSs have to offer and you will always have to wait until the APIs you require are supplied and you have no control over the priorities.

 

 Below you can find the source code for the app

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com