Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve got a HTML/JS (YUI framework) photo-organizer that needs access to the local FS. Should I move HTML/JS to AIR, or bite the bullet and “port” it to Flex AIR?
I know what the marketing says, but I want the real answer — what an I “giving up” by going HTML/JS AIR? I’d like to get some feedback from people with deep experience building HTML-based AIR apps.
I don’t think you’ll see many issues in using the HTML AIR mode, AIR uses the Webkit engine under the covers iirc, which can work well enough, and has most of the same native features of the Flash/Flex built applications. You’ll also see most of the HTML5 features you’d find in Safari. I would say if you need animations that Flash will generally run better than Canvas at this point… There’s plenty of examples of ExtJS and other frameworks running on AIR.
As to what you are giving up, I don’t think you’d lose anything from an HTML to HTML/AIR standpoint. You could gain a lot of what you gain in having an application in general based in Flash over straight HTML. In flex specifically controls and other features can be more readily tweaked than standard HTML controls. The animation tools in Flash are much nicer. ActionScript doesn’t line up to JS on a one to one basis, so there may be issues with code. Dealing with remote content/data is actually a little nicer imho in AS over XHR, though only when dealing with XML.
From an administrative standpoint, going to AIR with HTML from an already written application is probably the shortest path. If you REALLY needed to, you could convert later, and a lot of the underlying logic would be worked out. Time to market would be shorter with whatever is closest to what you are already using more often than not.