This content has been marked as final. Show 4 replies
The user downloads a .air file, and then install's the application in his/her Start Manu (win)/Applications folder(osx).
Just like any other application.
So they need be given a link to the server and directory where the application is stored, similar to when I give them a URL that they save as a "Favorite" in their browsers. Then it downloads the current version of the .swf file to their workstation if their cached version is out of date. Is this right?
I'm afraid you are picturing the architecture in the wrong way. An AIR application is essentially a traditional desktop application -- you just create them with what have traditionally been web-based technologies. There are also many APIs and a built-in security model for network and Internet interaction which make it easier to develop an AIR-based desktop application that can safely access networked content.
Your main application SWF (or HTML file) is installed with the application, not downloaded. You could download additional modules and execute them in the privileged application sandbox, but there is a security risk that either your server being hacked or a man-in-the-middle attack could result in a forged module being downloaded and executed instead of the original. I believe Flex intends to implement signed modules to mitigate this risk, but until this feature is available, it is better to install all the application logic as part of the application. AIR includes an update framework for updating an installed application, but for user experience reasons, you probably wouldn't want to update the application too frequently.
All that said, if what you really want is a customized browser for your web application, you could write such a thing using AIR (using the mx:HTML control, for example) and have that hardcoded to access your web application.
Thank you, Joe. That helps a lot.
I have a large extranet application that we distribute to web servers at several remote locations around the world, and then the local users access the application from their local web server. The reason everyone doesn't get the app from a central web server is that communications aren' always reliable to some of these remote sites, and they need to get work done when they are disconnected from our main servers in the US. Each site's data replicates with our central office.
The reason I was interested in AIR is that the browser-based interface, page navigation, and state maintenance have never been sufficiently robust to fully satisfy our needs. The reason we didn't go wth a traditional desktop application was the need to deploy it to every desktop with each new release. I was hoping AIR architecture could get us around that problem, but it looks like it would not.
Now I need to go back to my development team and see it AIR offers any benefits for us. Our clients are all Windows-based, so the runs-on-anything benefit of AIR is not important for this application. If other benefits exist, then I'll go ahead with some prototyping.
Thank you very much for your explanation.