I thought the following discussion was interesting. The question posed was answered by Jesse warden; sometime tough to understand but still a Flash/Flex guru:
I’m asking because I have a client and we’ve developed a massive Flex 3.3 application 150+ screens, and they want to compile it into an AIR application to run on iPad.
Personally, I’m not so sure it’d work, even if they were technically able to get it to run because a lot of the metaphors wouldn’t carry over.
Furthermore, it seems like most of the AIR apps I’ve seen for iOS are super simple, with only a few screens, or using it as a single canvas, etc…
The good: I actually like working with 4.6 now. I’ve wrapped my head around the whole action bar/content, and creating View’s that create View’s. While some things are annoying, the whole default DPI that scales does make things simpler if you’re building corporate apps that have little to no styling/skinning.
For a lot of apps that are simple, re-using the same code base for both platforms is hot. If I needed performance or some specific OS functionality, I’d probably just go native, though vs. the whole Captive Runtime + extension route.
1. skinning. They basically ignored all the lessons learned went back to this insane Flex 3 way of doing things with deep inheritance tree’s you have to learn with some things being styled, and others only partially so. Using protected override to draw background colors… all kinds of stupid, horrible crap that Flex 4 fixed, and they decided to re-break. Major architecture mistake, and not sure what the Apache crew can do to fix it.
2. Android vs. iOS. It’s very clear the design was made for iOS. While some Android specific UI’s are supported, turning off some things (like the ActionBar since Android has a back button) and other stuff makes your code quite unwieldy.
3. video on iOS: Bleh. This was supposed to be Flash/AIR’s shoe-in on the mobile space, but…. http://www.flashstreamworks.com/2012/01/09/the-ultimate-guide-to-understanding-advanced-video-delivery-with-air-for-mobile/
None of the above matters, though. You’re faced with 2 problems. #1 is design. #2 is View/visual architecture. Like you said, the metaphors will NOT carry over. While Flex 4 is massively different than 3 in terms of skinning vs. styling, 4.6’s mobile components are COMPLETELY different. You don’t even use the same application class. While you may be able to use your service layer and some of your application logic, all the View’s will probably have to be re-written.
So while the # of screens isn’t really the issue, the thought of “taking 150 screens” is. Yes, I get you’re summarizing a huge project. My point here, though, is you can get away with murder on the desktop whereas on mobile, you have very little room at all. You can’t cram functionality on the screen like Enterprise Flex web/desktop apps have a habit of doing. Additionally, most large companies don’t employ really good designers, and that’s a big helper here for mobile where investment has huge payoff’s (and I’m speaking payoffs here to helping the developer).
It also depends on what you’re targetting. If just iPad, that’s one thing. Anything Android opens a world of hurt design wise, and as long as ya’ll emulate constraints, the GUI can grow somewhat to give those on various Android devices a decent experience, just like the HTML people are doing for mobile websites. This, however, puts downward pressure on the GUI to make more screens to compensate for the lack of input functionality or you reduce scope.
From a performance perspective, if you’re just using vanilla Flex stuff + some custom drawing stuff, and simple charts, it’s fine.