3 Replies Latest reply on Jun 10, 2008 5:28 PM by theLoggerGuy

    Killer argument to use AIR over dotNet

    theLoggerGuy Level 1
      There's a rumbling in management. The pointy haired fellows have heard of dotNet, but not AIR - disaster! I have just spent the last 18 months figuring out Flex and am delighted with its power and ease of use. I have been commissioned to make a desktop app (features include a database and charting) and I would like very much to use AIR. I must convince management of the virtues of AIR and the "it will be cross platform" is not cutting the mustard.

      I would welcome any and all suggestions.

        • 1. Re: Killer argument to use AIR over dotNet
          slaingod Level 1
          To be honest there really isn't one. AIR is nice and all, but it seems to be mostly a response to C#/.net than anything else, especially with MONO bringing C# to the masses. (That said, 'Silverlight' (isn't a flash a silver light?) is MS's response to Flash/Flex in the browser.)

          Actionscript is a little more fun for me to code in than C# for instance, but C# has a crapton more functionality than AIR will ever have: just look at all of the AIR questions in this forum like 'how do I print without a print dialog?' AIR is great for quickly leveraging Flex skills to make a usable cross platform app, and possibly using some Flash animations and flash/flex components. But C# has a huge component base as well, and access to a lot of low-level features when you need them.

          And IMO, Visual Studio kicks Flex Builder in the butt, both in terms of functionality/ease of use, and in footprint...Animation/Tweens/Effects is .Net's one big missing functionality set, at least cross platform, as WPF isn't available everywhere ( I think WPF is what allows animation more easily anyway :)

          That said, I spend most of my time doing Flex, so it is disappointing to have to say these things.
          • 2. Re: Killer argument to use AIR over dotNet
            egeddes Level 1
            I feel your pain. Cross-platform really means nothing in a monolithic WinXP environment (for example).

            I'm betting you, like most developers (myself included), would be tempted to rattle off a bunch of geek-y stuff like AIR is easier to develop and deploy (if nothing else, due to a framework that DOESN'T try to do everything), auto-update capability, built-in SQLite, etc.

            But none of that really matters to policy and finance folks (e.g. traditional management). It's about business. Value. Money. It's about capturing as much value as possible from as few resources as safely possible to make as much money as possible.

            With that in mind, easier development and deployment might make an impression, but focusing on less complexity -- less things to break -- might get you further. Auto-updating could be a selling point, unless they consider updating workstations one of the jobs they're paying IT Staff to perform. SQLite? Not a selling point to the uninterested ledger-jockey.

            Depending on the environment, security could be easier to implement in an AIR app — in part because the AIR environment is another layer between the app and the OS.

            I believe that one selling feature is the ease with which many AIR apps can be converted to browser apps, and vice-versa. With .NET, it's not quite that simple, and to do it right, will require starting nearly from scratch. Silverlight is getting there, but it's not there yet.

            Browser-based apps may not be on the radar yet, but they could be in the future. And once an app runs in a browser with Flash Player, it can run on a wide variety of portable devices. And if the application in question is going to be used outside the office, if it isn't running AIR or is browser-based, the updates must first be installed on each machine.

            There may be industry-specific advantages as well. If, by chance, "logger" in your username refers to logging, as in wood, then pointing out that ESRI has devoted significant resources both to ArcWebServices, and more recently the Flex API for ArcGIS Server. Internally, they really dig Flex, and we can expect to see a lot more of it from Redlands.

            If, on the other hand, "logger" refers to server logs, then it may be worthwhile to point out the benefits that some of the big-boys mention when discussing their new Flex interfaces. Oracle, IBM, BEA, etc. All Flex Kool-Aid drinkers.

            A serious overachiever might make two apps, then ask the client which they prefer. If for no other reason than the most basic user experience is more pleasurable in many AIR apps than in many .NET apps, AIR stands a good chance of being selected.

            Then again, this kind of situation is indicative of bad corporate management. I'll bet you a dollar, none of the suits pushing .NET have a single argument to present other than "Microsoft made it so it has to be [good|safe|solid|] for business". Push it back on them. Get them to tell you why .NET. Specifically. Make them prove their point. Their position is likely one of inertia.

            That said, they may have very good reasons for using .NET. If you have an IT architecture built around .NET, BizTalk Server, and all that BPM goodness, then the arguments for AIR must be all the more refined.

            But if the Finance Department has SharePoint installed and thinks they are "collaborating" and "enterprise", then you may just suggest that the entire application you're being asked to do should just be done in Excel. After all, it's already installed in all the workstations, right? And it'll fake a database and do charting? Why not?

            Any argument they use for why Excel would be a bad idea, could likely be thrown back as arguments against the typical .NET app and in favor of an AIR app.

            Just a thought. Good luck.
            • 3. Re: Killer argument to use AIR over dotNet
              theLoggerGuy Level 1
              Thanks for taking the time to give me such detailed answers. I was unaware of the Updater class and it all adds up - if anyone has ever coded an installer from Windows 2000, to XP, to Vista the installation experience can be a nightmare.