The Good, The Bad, and The Ugly of Flex “Hero”


This article is from the perspective of someone whose AS3 and Flex experience is measured in months. This is meant to show those who aren’t long time Flash developers what they can expect with Flex “Hero”, Flash Builder “Burrito”, and Air for Android. But I didn’t go in alone, the Adobe community is full of smart and helpful people, just check my to see some of the names that helped. Particular thanks to , , and .


Recently I wrapped up my first Flex “Hero” Air for Android app, Repper. You can read my earlier blog post about it to download, get source code, or just learn more about it. I learned a lot about mobile development and deployment, but I want to talk specifically about Flex “Hero” and Flash Builder “Burrito”. Here’s this developer’s experience and perspective with using Adobe’s workflow for mobile development.

The Good

  • The Flash Builder “Burrito” workflow for building Android apps is fantastic. It was a breeze to setup a basic project and be testing it live on my Droid X. Some of the specific things I really liked were:
    • Pre-built templates for projects, components, skins, item renderers, and more speed up the development process
    • Built-in emulation for various Android devices
    • Testing on a device is very easy to set up
    • Managing Flex states through the Design View can be helpful in visualing layouts
    • Offers the familiarity and plugins of Eclipse
  • ViewNavigator and View make navigating through applications using multiple views simple. Using simple functions like pushView() and popView() you can move through your application and pass data with ease. Check out these posts for a more in depth look at this powerful and intuitive interface:


  • PersistenceManager alleviates the hassle of trying to manage data between view states by using Local Shared Objects. Even when your mobile OS decides to close your app for memory or power shortages, the PersistenceManager will preserve your designated data. Check Jonathan Campos’s post on it for more details: Flex 4.5 PersistenceManager
  • Flex 4 skinning is pretty damn nice, especially for someone like me who is about 95% developer, 5% designer. Using MXML and AS3 you can create design and graphics for your components, keeping them separate from your UI’s layout and logic. This means you can effectively create vector skins using the AS3 drawing classes. No more importing images just to create gradients and rounded corners. Not as big a win for designers, but the pure developers out there will love this. Check out Ryan Frishberg’s article for more details: Introducing skinning in Flex 4. The screenshot showing Repper below highlights entirely programmatic design.
  • Repper with Flex 4 Skinning

  • Multiscreen development potential is very appealing and Adobe is working to grow it further. Christian Cantrell’s demo video below shows what Adobe Air is capable of in terms of “code once, deploy everywhere.” Android, iPhone, iPad, Blackberry Playbook, Desktop, and web are all valid targets for your single code base. While this is very exciting, it is also very young. Take this all with a grain of mobile salt as this topic shows up again in the “Ugly” section.
  • The Bad

    • Lack of native component support can be a deal breaker for some people building mobile apps. Its not for me nor for lots of people who are comfortable building their own components, but many want the native experience. But all hope is not lost with the following AS3 libraries available that emulate native components:

    • Nick Jonas

      Kevin Hoytandroid-components
    • Flex “Hero” is missing some core components that mobile developers will be expecting to be present. I for one was not expecting to have to build a modal select list from scratch. Unfortunately, though, Flex “Hero” does not contain the mobile equivalent of a combobox. You can create it with their scrollable List component paired with a semi-transparent background, but it would be nice to have this out of the box. Other notable absentees are sliders and tabbed layouts.
    • Not all native APIs are supported. While this should be expected in a cross platform framework, it can sometimes lead to unexpected roadblocks. In my case, I have only numeric input in my app. I wanted to default the soft keyboard to the numeric keyset. Unfortunately this is not possible in Air for Android. It takes some AS3 parlor tricks just to keep the soft keyboard closed when you don’t want it open on a TextInput focus. There’s even more to worry about with Apple development, but I’ll mention that in the “Ugly” section.
    • Simple things can be complicated. Take for example closing an app when a user leaves with the back button. Seems easy enough, but it takes 3 event handlers to do it properly and even this method is not without its problems. Check out the code I used below, thanks to Tom Krcha:
      protected function mobileapplication1_creationCompleteHandler(event:FlexEvent):void
                      NativeApplication.nativeApplication.addEventListener(Event.ACTIVATE, handleActivate, false, 0, true);
                      NativeApplication.nativeApplication.addEventListener(Event.DEACTIVATE, handleDeactivate, false, 0, true);
                      NativeApplication.nativeApplication.addEventListener(KeyboardEvent.KEY_DOWN, handleKeys, false, 0, true);
      private function handleActivate(event:Event):void
              NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.KEEP_AWAKE;
      private function handleDeactivate(event:Event):void
      private function handleKeys(event:KeyboardEvent):void
              if(event.keyCode == Keyboard.BACK)
    • Debugging on a device can be tricky. So tricky in fact that I never got it working. In all fairness, I didn’t try to diagnose it any further after the getting the initial error because the app I was building was so simple. But the fact remains that it didn’t work out of the box for me. Maybe your experience will be different and I welcome anyone to call me an idiot and tell me what I did wrong.

    The Ugly

    • Universal mobile device support is minimal at this point. Android is covered pretty well up through the Air 2.5 SDK, but iPhone/iPad only support Air up to version 2.0.2 via the Adobe Packager for iPhone. This leaves out key APIs like camera support and video/sound capture, not to mention the bevy of bugs and gotchas that you have to watch out for. The workflow for deploying apps to iOS devices with the packager is also no picnic. While the Blackberry Playbook is proudly supporting the Adobe developer community, there’s been no official announcement, though there has been mention, of Flash or Air being on Blackberry smart phones.

      Long and short, you aren’t going to be hitting the widest part of the market when compared to other mobile frameworks like Appcelerator or PhoneGap. And even if you do, I’ve experienced first hand how users can be put off by having to install Adobe Air on their phone for the sake of an app. Until Air for mobile devices support becomes more common place, it may be viewed as an unnecessary evil by many mobile users.

    • Performance can be a problem for even the simplest apps. This for me is the most critical area that needs to be improved before people will take Air seriously as a mobile framework. Simple things like view transitions, scrolling, button interactions, etc… have a noticeable sluggishness that users won’t stand for. Even the cream of the crop among Flex Hero apps, like Jonathan Campos’s nearly 100K user base NetFlix Queue Manager, is not immune to these problems. Though a majority of the comments are very complimentary, the few detractors have a very common message: we don’t want to install Adobe Air and we find it slower than native apps. Are these types of comments the whole story? Absolutely not. Does that mean they can be ignored? Absolutely not. The vocal complainers, though not always very helpful, can sometimes spur the necessary advances that can take a product to the next level.


    Hey Adobe, fix the ugly, stay on top of the bad, and keep highlighting the good.

    While I am far from swearing off AS3 and Flex development for mobile devices, I think Adobe has a long way to go before it will be able to bring in a significant amount of non-Adobe developers. Their mobile platform and workflow seems as though it caters entirely to existing Flash and Flex developers. There just doesn’t seem to be an effort to bring in new blood from the outside. And if that remains the same, Appcelerator, PhoneGap, Sensa Touch, jQuery Mobile, or whatever other platform that comes next and engages larger cores of developers will take away valuable relevance in this land grab for mobile supremacy.

10 Responses to “The Good, The Bad, and The Ugly of Flex “Hero””

  1. Great overview, Tony. I think this is a balanced perspective- interesting to hear from someone without the decade or more experience with the Flash Platform that most Hero devs are coming to the table with. A lot of us are just used to dealing with ‘gaps’ :)

    I agree that there are some problematic omissions in the component set on mobile. I definitely have found myself needing a mobile slider now and again! Most of the Bad is actually acceptable to me as a developer since there are no show-stoppers here… and this is still beta (granted people are not letting that stop them from building stuff with it!).

    I can say for certain that Adobe is working on a few of the things you point out here and personally have high expectations for the final release of the mobile Flex framework.

  2. Matthew Fabb says:

    Great write up! Thanks.

    RIM’s CEO Mike Lazaridis has said they plan on using the QNX OS for future BlackBerry smartphones. The soundbite that a lot of tech blogs picked up on is that RIM see the QNX as their mobile OS for the next decade. Unfortunately, there’s no timeline of when this new BlackBerry OS will be on smartphones. It seems to be that the reason Flash or AIR isn’t on the current BlackBerry OS 6 is because RIM will be abandoning that OS for QNX. That RIM doesn’t want to spend time integrating Flash or AIR on something that they aren’t sticking with long term.

    Hero is certainly still missing quite a few needed components and hopefully these will come with later SDK updates. It has been frustrating as I work on a PlayBook app with Hero, seeing all these new components and features added to the Flex Hero spec, while the last two SDK updates have excluded the mobile files. In the documentation, they do mention that they are targeting the next version of Flash and AIR with Flex Hero, so it could be that new components are targeting the next version of AIR (2.6? 3.0?).

    Flex Hero mobile and AIR certainly have great potential in the future, but definitely right now still has some limitations.

  3. Mike Slinn says:

    Great article, well considered. Given Adobe’s impressive commitment to mobile, I expect that the issues you raise will be addressed over time. I would add that for programmers who are already facile with Flex / AIR development, it is a very productive prototyping environment. If go to market is immediate and budget allows, native implementations for targeted platforms could follow. I have done AIR and Java development for Android and they each might be the appropriate technology choice depending on business factors and technical requirements.

  4. Great overview and your perspective is very realistic and reasonable in my opinion. Now, I will point out that the only public release of Burrito and Hero (for Mobile anyway) was back in October for MAX and should be considered an early beta at best. So, while I can’t make any promises, I can say that you can expect to see many improvements when all is said and done. :)

    Brian Rinaldi
    Web Community Manager
    Adobe Systems

  5. Fabien Nicollet says:

    Very good article, sums it up. Some components are still missing from Hero but some specs are already written that explain what’s coming up in the future releases:
    iOS dev can be very disappointing now but the new version of the packager should fix some of theses issues (H1 2011 hopefully!)


  6. Hey Tony,

    Thanks for the great blogpost. Keep the feedback coming as it’s really helpful. As Brian said, the public release of Burrito and Hero was a few months back. With regards to performance, we’ve been making lots of progress. Specifically we’ve put a lot of engineering time into improving view transitions and list scrolling, and I think that time has been paying off, so stay tuned!

    Ryan Frishberg
    Flex SDK Engineer
    Adobe Systems

  7. Andrew Shorten says:

    Hi Tony,

    Further to comments from other Adobe folks about improvements we’ve made since the public preview release, we just announced that we’re expanding our private pre-release program, so if you or others would like to get access to later builds of Flex SDK or Flash Builder you can submit a request to join.

    More information here:


    Andrew Shorten
    Group Product Manager, Developer Tools

  8. PIA Blog / Productivity by Design » Notre Revue de presse (18/02/2011) says:

    [...] met l’accent sur le développement d’applications mobiles multi-plateformes.  Consulter l’article  Gérer et accéder facilement à vos asDocCette application Air devrait ravir plus d’un [...]

  9. Cool Stuff with the Flash Platform – 2/10/11 | Finding Out About says:

    [...] Lukasavage takes a look at the good, bad, and ugly of the current state of Flex “Hero” and Flash Builder “Burrito.” He offers some very good feedback, though one must take [...]

  10. PIA Blog / Productivity by Design » Développez mobile avec Flex Hero et Android says:

    [...] Références le même sujet :Améliorer la qualité de vos projets avec Flex PMDAdopter Flex 4 en toute sérénité (2/5) : Les layoutsAdopter Flex 4 en toute sérénité (1/5) : Retour d’expérienceComment intégrer des composants Flex 4 dans SharepointAutomatiser la production de vos applications Air [...]