We have a very big application which built on flex 3 SDK. What are all the pros and cons if we don't migrate and continue using flex 3 SDK.
Here are some questions:
1.Can we sustain without migrating from flex 3 to flex 4 for at least 5 years?
2.Can we upgrade to Flash Builder 4.6 + SDK 4.11 ?(but continue to run the flash builder in backward compatibility mode)
3.Is there any future support issues for application that are built on Flex 3 SDK.
Here are some points i read in stackoverflow:
If Adobe didn't seem to be pushing so hard for us NOT to use Halo, I think I'd be comfortable with that. But since they say in the actual docs that we "shouldn't use such and such" Halo components and should use the Spark ones instead, it's worrisome. It also seems like support for Halo in FB has become an afterthought (I can't get design mode to display a Halo style, even with Halo selected as the theme), so Adobe's making it difficult just to continue using it. Personally I don't see why we can't have two parallel component sets since Halo's design may work better in some use-cases. – Crusader Aug 21 '10 at 2:59 1
Actually the wording Adobe authoritatively uses (say if you're going to use "Canvas") is "use spark.components.BorderContainer instead". Well what if we don't want to? They haven't explained why we should use Spark instead, and due to it's "half complete" status now with tons of missing components, I don't really like the idea of almost guaranteeing maintenance work and updates needed to my code once SDK 5 comes out. On the other hand if we just use Halo permanently (assuming Adobe isn't going to pull the rug from it later, who knows), the code is "done" the first time. Frustrating
Thanks in advance.
Two things I particularly like with Flex4 in contrast to Flex3 (No matter if Adobe or Apache Flex) is that the new Flex4 components (Called Spark components) are much more lightweight implementations. The coolest new concept introduced with Flex4 however are the skinnable components.
It allows you to implement your components completely independent from the look & feel of the component (Skin). You can locate a components skin in separate modules which allows you to implement an application and depending on the client to load a "desktop", "android", "ios" or whatsoever skin-module which completely changes how your component looks and is used. Most skinning approaches of other frameworks merely allow one skin or can only change the formatting (colory, borders, margins, font sizes). In flex you could have a dialog displaying 20 Input fields at once in the desktop skin, but on mobile one, you have a step-by-step wizard approach only displaying 5 of them per page (just as an example).
Especially with the FalconJS initialive at Apache Flex it will be possible to have the compiler generate not only flash, but also a HTML+JS+CSS based output. I doubt this will be possible for the old Flex3 components.
The downside is that if you get used to Flex4 and you have to work with any other technology, you will be missing a lot of stuff. I at least got addicted to some of the concepts pretty fast.