How AIR should NOT be used

Just checked out the Shu player. It`s an application that packages your AIR application as a standalone application and extends it`s functionality a bit.
This might sound intriguing first but it really only shows how people are not getting the advatages of AIR. Why is this a bad solution?

  • standalone means the AIR runtime is packaged into your app which bloats the installation size. This is one main advatage of AIR. You install the runtime once and then all the AIR apps are small in size
  • You`ll loose the smooth seamless installation functionality of AIR apps
  • What about autoupdate?
  • What if the runtime updates?

In the end this is nothing more then the good old projector tools and I think if you want something like this there is nothing better than Zinc 3.0.

That said I kind of understand the motivation behind this tool. On the first glance it adds some of the most missing features to AIR mainly being able to run native programs.
But as it at the same time destroys the real power of AIR this is a no go for me. Keeping thumbs crossed that AIR 2.0 soves this by adding those features.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

18 thoughts on “How AIR should NOT be used

  1. I hate the concept of having to install Air before installing the real software, must be a major turn down for non-tech-saavy end users
    oh I miss the Screenweaver days…

  2. I agree and disagree on this. First, I agree that in general – you lose a lot of capability with this – and that I hope this issue is resolved in AIR 2.0.

    However, I know of at least two projects that I have worked with where AIR does 98% of what the client needs. Also, in one of these cases cross-platform compatabilility is not a concern.

    There are use cases for tools like Shu – and hopefully Adobe can expand on what it offers and do some truly amazing things in AIR 2.0.

  3. interesting – complete different opinion. But if you like Shu than why AIR at all? I mean there are so many tools out there that can do it (e.g. Zinc) much better and just including AIR because it sounds good does not work for me.

  4. @David: totally agree with you here. I`m sure we get this stuff in AIR 2.0. I mean currently it`s a 1.0 release – lot`s of nice stuff still to come I guess.

  5. My (fairly extensive) experience with Zinc found it to be pretty buggy and unreliable. I was also in an environment until recently that was 100% Windows so cross platform was not a concern. Cross platform should be a capability of AIR, not a requirement/limitation.

  6. I find your arguments to be only valid for public facing apps. In a corporate environment where the internet is not accessible a tool like shu makes the install much easier.

  7. I saw the link to the Shu site yesterday as well. I was intrigued given that there are some limitations with AIR as of V1.

    Regarding your points:
    Size of install: I’ve not worried about install size in years, and I don’t know the install size of the Shu wrapper, plus the AIR runtime, plus any code that I write, so unless it’s in the multiple hundreds of MB, I don’t see it as an issue for me, how that pans out for folks in general, don’t know, but for me not anywhere near a deal breaker.

    Seamless install: It appears to me that there is no install process at all, you just run the application, so I could see an argument being made that that is better for the user.

    autoupdate: as there is no mention about autoupdate, or lack thereof, I can’t readily dismiss Shu because of that, and wouldn’t include it in any list, as from a developer standpoint, making the new build would be taking the same about of time, and depending on the specific implementation Shu uses, it could be fairly easy to add functionality to get the updated bits. So for now, not an issue for me.

    Updates to the runtime: It is my understanding that AIR updates will install as a separate runtime, leaving the “old” runtime in place. I’m not sure if an application installed under an “old” runtime will automatically use the “new” runtime. For now, this is an open question for me as well.

    My first issue with this was how can they bundle the runtime with their application. SO I did a little checking and it appears that Adobe does allow this if you’ve gone through the redistribution licensing agreement:

    However, the Shu site makes no mention of them having the agreement, and until I get around to sending them them if they do have that agreement in place, then for me as a self-protection measure, I’d not go with Shu, just now.

    Will have to think if there are other issue I may have, but I’ll definitely be checking this project out to see if it will be beneficial for any projects I’ll be working on.

  8. I just want to make one thing clear. It was never my intention to offend the smart people that build Shu. I think they did an awesome job. I just don`t understand why to use AIR for this kind of stuff if everything that makes AIR unique doesn`t count for you? I think with Shu these apps become traditional desktop apps and for this kind of stuff we already have lots of options.

  9. the most AIR weakness is extendible missing.
    becaus it is one desktop software, the most need is to integrate with desktop flexiblily.
    such as call C/C++ .dll/.so

    I hate this missing…

  10. Thanks for pointing Shu out. I’m working on a DVD photo gallery project that needs to allow a user to save a photo from the DVD to their system. But, because AIR requires an install, I had been planning on using Zinc. In some cases like mine it is unreasonable to ask a user to install the AIR runtime just to play an interactive DVD — so Shu may make it easier to deploy air apps into more situations. It may be part of AIR 2.0 — but thats not here now 😉

  11. Yeah I have to be honest I was quite confused when I saw shu-player.

    Mixed emotions, not exactly sure how I should feel about it.

  12. I think you miss the point – Shu is enabling us to do all AIR does and more. It is /adding/ functionality, not taking away.

    “You`ll loose the smooth seamless installation functionality of AIR apps”
    If you call end user having to install your app a benefit!

    “What about autoupdate”
    Why auto update an app not installed?

    “What if the runtime updates?”
    If you use Shu I presume your app will keep working – regardless of any runtime on the system, as Shu embeds runtime AFAIK.

    You state Zinc 3 being good. In my (and others) opinion this is simply untrue. We have had bug after bug from this product.
    We recently switched to Janus for swf2exe.

    With there now being an air2exe tool, we have a far better choice. Surely that can only be a good thing.

  13. An interesting concept and one that we will look at. We built our first AIR application, and of course the client didn’t like all the install dialogs, etc. So this gives us another option to look at. Some clients want the application to run off the CD (in the process a db could be copied to the user area to store information). Although I have not investigated, this solution may allow you to protect with SecuROM, so if the CD is copied, it won’t work.

  14. Hi, just wanted to get out the word that there is actually a new air2exe application out that runs a bit faster and definatly smaller. If anyone is interested in testing out the demo it’s available at

  15. It’s been a year and half since any comments… anybody want to update us on Shu versus airAveer? Good, bad and the ugly?

Leave a Reply

Your email address will not be published. Required fields are marked *