How much of an impact will migrating to Flex 4 have on our code base? We have about 40k LOC written in Flex 3. I'm hoping that there are no breaking changes in the Flex SDK, and that we can smoothly transition to the new features of Flex 4 while minimizing any disruption. From what I've read Adobe is developing a new set of GUI components called 'Spark' but I'm hoping our existing stuff can co-exist with the new components.
Spark and MX components can co-exist within the same application (and even within the same MXML files). There are some changes to how CSS works because CSS namespaces are now supported, and you will encounter a small migration step there.
In terms of choosing Spark versus MX, Adobe recommends keeping your existing code that already uses MX components the same. There's no need to make everything Spark immediately. You can make incremental changes as the need arises. For new development, you should use Spark when possible. However, the Spark components in Flex 4 will not have 100% feature-parity with MX, so you will likely encounter some situations where you need to continue MX components for the time being.
You can move to Flex 4 without adopting any of the new stuff. You can keep the 2006 namespace so that you don't have to update your MXML files. Also you can optionally use the Spark components. The only major benefit of doing this is the faster compiler. It will also allow you to progressively move to the 2009 namespace and Spark.
Related
I've worked extensively with MX and Spark frameworks and both work fine for me. I am about to start a very large project in Flex where speed and file size are going to be critical factors. I am not going to use Adobe Catalyst.
Is there any reason I should use Spark for this application rather than MX?
Is there any reason I should use Spark for this application rather
than MX?
Adobe has stated that Spark is the future. The MX line is receiving no new components; and many expect to the be deprecated at some future point.
Spark also provides a significantly more flexible skinning architecture.
Spark components are architected in a way that is supposed to be more light weight; sort of like a "Pay As You Go" architecture, so you aren't dragging lots of functionality along that you don't need. A good example of this is that scrollbars are separate from containers.
Spark also provides you with greater Flexibility for deployments. Only spark components are supported on Mobile devices, for example.
If speed and file size are critical factors, you may want to reconsider your use of Flex, though. There are a bunch of alternate ActionScript frameworks such as Reflex, that are written for simplicity and performance.
I had many issues found in migration from Flex 3 to Flex 4. I had done some logic in flex 3 but while migrating the same code to flex4 it is not working. Please help me out how to do the exact migrating or have any tool for migrating the code from flex3 to flex 4.
There are many advantages of Flex 4, one of which is Skinning, which is a huge plus for code reuse but also separation of concerns (separate the view/styling from the component behavior). There's also FXG (mxml based vectors) that can be used with Catalyst to easily skin components from illustrator.
Flex 4 is definitely the future and what you should strive for, but it does bring forth a lot of changes, so the con here is that it's very hard to convert a Flex 3 app to Flex 4 without redoing some code. It's a different mentality altogether and it needs to be adhered.
There are no quick tool to convert your component logic.
On my expirience most of the things I had to fix on my project when migrated to Flex 4 were related to parts of code that were actually work arounds for some strange behaviour with scaling/resizing of components in Flex 3, which was resolved in Flex 4. Overly it wasn't hard, there are no major changes in logic, just improvements and some bugs fixed, and possibly few new bugs made :)
When migrating to Flex 4 it's not neccessary to change your components to Spark ones, you can still use your MX structure.
New components use a different layout, you build them a bit differently
* you cant use Spark's ComboBox/DropDownList as in MX, since you need IList objects as data provider
* Resize/Scale and measures work as they should now, in both MX and Spark components
* you can't add directly some of MX components to Spark containers as you could in Flex 3
* you use addElement instead addChild for Spark components
* in Flex 4 they introduced FTE, with superior text render quality, lifting the limit of 127px font size, but now if you embed fonts on runtime (I do) you have to use CFF flag
I think that migrating to Flex 4 worth the hassle, just if you decide to use the latest SDK build (4.5) you may encounter some issues, 4.1 is a safer call at the moment, tho I'm using 4.5 knowing of the risks.
Also, where do you start if you want to create a complete Flex 4 skin? Is there a list of all the "pieces" (component parts) you need to create graphics for somewhere, or some complete, example skins out there to use as a template? And do your skins render correctly in Flash Builder Design View? (including embedded fonts)
Most people will point you to Flash Catalyst, but the last time I looked it was not all-inclusive in terms of creating a complete skin/theme, not to mention other issues inherent to 1.0 software. I start by copying the default skin files and modifying them, as well as creating a new CSS file based on the defaults.css file that comes with the SDK. The trickier part is that not all components (Tree, DataGrid, DateChooser, ColorPicker, etc) are available as Spark components, which means to have a complete skin/theme you need to create a bunch of mx skins as well. Bottom line: If you are serious about doing this properly, you'll need to spend a lot of time understanding defaults.css and the skin classes it refers to.
To answer your original question, my personal workflow is to create a mockup of the skin in OmniGraffle, then use that as a guide to modify copies of the default skin files (look in spark.skins, and mx.spark.skins) by manipulating the mxml directly (as opposed to using a graphical tool such as Illustrator or Catalyst.)
Hope that helps.
Basically, you have many options when skinning Flex 4 apps :
Using "general" styles (chromeColor, selectionColor, focusColor, ...). This is usually called "Styling" instead of Skinning because you only change the overall look of the application. It's by far the easiest way to change the appareance of your application quickly without knowing anything about FXG, MXMLG, ... The drawback is it will still look like a Flex app, but with different colors/fonts
Using Adobe tools to produce FXG files. These tools can be Illustrator, Photoshop, Flash CS5. You design each of the spark component with these tools and export the result in .fxg format. FXG is great because it's optimized, but you can't use things such as Data Binding in it
Write your skin in MXMLG , by hand (starting from scratch or copying the default spark skin) or with the help of Flash Catalyst. Catalyst can take your Illustrator or Photoshop design and convert it to MXMLG. Experience shows it's still painfull, even with the last version. And you often end up doing things like this.
In our team, there is no such thing like designer/developer workflow with Flash Catalyst. The next version looks better but it's still far from what Microsoft is doing with Visual Studio/Blend.
That being said, the new Spark architecture is awesome. Skinning is much easier, flexible and readable. With this architecture, a developer codes the component and the designer skins it only by knowing the contract (skinparts, skinstates, data)
This also true for views if you use the Presentation Model pattern.
There is no "template" skins as the one available in Flex 3 because skinning doesn't use symbol anymore. What could be done though is a Flex 4 style explorer.
A final word, it has already been said here, but don't forget that with the current version (4.1), there is no spark equivalent for all of the components, so you will still use Flex 3 skinning techniques for components such as DataGrid, Tree, ...
This is where I normally "start"
http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html
Once I figure out what components I have to skin, and I can't change what I want to change in Flex with CSS, then I go into Flash and start breaking the components apart and tweaking them.
http://www.adobe.com/devnet/flex/articles/skins_styles.html
(Also, I've never had anything render "correctly" in design view)
I have a project where we are trying to skin Spark components from a third party library that are built up from the drawing API primitives. Our first attempt involved creating a Flex skin (SWC) in Illustrator/Flash and applying that skin to the Spark components via CSS. We found that even with only a single instance of one of the components skinned in this way on stage, the application was brought to it's knees. For example, it failed to respond in repaint scenarios in a timely manner, and exhibited all the symptoms of being hung.
Our next approach will be to recreate the same skin artifacts in MXML classes that are in turn associated with the third-party components. Although the complexity of some of the skins leads me to believe that we might not avoid performance problems with this approach either.
My question is the following: Is there a correct or recommended way to apply either a SWC or based skin to a component that is built up from the Spark drawing API to begin with? Even as I ask the question I recognize that the approach means using the Spark drawing API in two places and will probably have unexpected consequences.
I've had good luck building the skins using MXML skin classes that inherit from s:Skin in terms of rendering performance. The recommended method (from Adobe) is to start by copying an existing skin file from the SDK and modifying the MXML to suit your needs. Regarding drawing, FXG works very well for defining how you want the skin to be drawn. FXG is XML based, so you don't need to write ActionScript to do your drawing, like we used to do for Flex 3 programmatic skins. You can also create skins using Adobe Catalyst. I have not used Catalyst, so I can't speak to its effectiveness, but many people seem to like it. Hope that helps.
What are the key differences between Flash and Flex? I have over five years experience with flash and feel very comfortable developing with it and ActionScript3. I find myself more and more curious about Flex and want to know when it is best to use flash or flex. Also, is everything that can be done with MXML, able to be done with AS3? I have a strong understanding of AS3 and OOP and would like to know the diffrences between using AS3 and MXML in Flex.
Flex is great if you quickly want to build a UI, you can mock up a functioning UI in a couple hours. Since it still can be limiting for some custom UI's it's not perfect for everything but if something should "look" more or less like an application and fit in a grid it's super quick to mock up the UI in MXML. Also don't be intimidated of how most Flex apps look (ugly, imo), you can customize everything or easily create your own components.
Putting actionscript in mxml is the same as putting css or javascript in html = really bad. Unfortunately even Adobe has this in multiple examples (probably mostly because it's easier & faster for demostrations).. My personal opinion is that this applies to bindings too, as i don't want to put my data in the UI (mxml).
As an experienced developer I'm sure you don't do any development on the timeline (to clarify the Flash = timeline misconception). Still with Flex you have the UI separated in a framework that handles a lot of the burden with layout so that you can concentrate on the business logic. The rest of the workflow is close to what you probably already have with Flash.
It depends on what kind of applications you are developing now with Flash. I have been a Flash developer (mainly applications) for 7 years. I must honestly say that I was extremely glad when Flex 2 was released because it had the component framework (good components, layout managers, ...) I did not have in Flash. This is IMO the biggest difference between Flash and Flex (or the Flex framework).
MXML is a real blessing, especially when using data binding. In the end, everything is compiled down to ActionScript (check the -keep compiler option), but MXML just saves you so much time.
Flash and Flex provide different ways to produce different things. I am not familiar with Flash, but I would expect that it is dependent on a time-oriented way to produce something, whereas Flex is geared toward more traditional software development. That is, rather than dealing with time and frames in Flash, one is dealing with describing where components should be placed with MXML and how those components work with ActionScript.
One should also be able to write a Flex app with just AS3 and no need MXML.
The main difference between AS3 and MXML in Flex, as far as I know, is that MXML is not intended to be used with application logic, but rather it is intended to be used like HTML/CSS in web pages and puts components and content onto the Flex app. ActionScript is used to program behaviors, components, and other things outside or what MXML does. Thus, if you want to attach an event to a component one would write ActionScript code.
Hope that helps. I am still learning about Flex myself.
Some other differences that come to mind:
Flash allows you to create graphical assets and then work with them immediately. To use those same things in Flex, you need to use Flash to export them to a swf or swc first.
Flex has a layout manager, so applications that have variable window size are waaaay easier to make. For instance, you can take a window and set it to 90% width of the window, and it will change size... not scale mind you, but actually change its width as the window is made larger or smaller. This is not easy outside of the Flex framework.
Data Binding in Flex is a huge timesaver. It essentially creates all of the code you'd need to write in AS3 by simply saying blah="{foo}" The curley braces denote "bind to this".
The Flex Debugger is vastly superior to the Flash one. There is also a Profiler.
Since I started with Flex and not Flash, I'm not sure what kind of IDE is best for Flash dev, but the Eclipse based Flex Builder is quite nice. The code hinting is great. Subclipse integration is great.
Really, Flash and Flex are different beasts. You should know and understand AS3 if you want to use Flex, and since you do, you're in a perfect position to take advantage of Flex's features. Flash is not going anywhere as a tool for making more visually creative pieces, but Flex offers a lot of advantages for application development.
I prefer Flash IDE vs Flex (aka Flex Builder aka Flash Builder for my comment)
In general i would say it depends on the size of the project.
I find it easier to start and finish small projects quickly in Flash.
I would advise Flex for larger projects because it has various debug tools that can save you plenty of time (although i would still just use Flash my self)
But maybe if you really get used to flex, that might not matter.
some Cons of Flex from my experience.
When working on a team of 4 on a
large project, Flex failed to keep
the project
settings from one computer to another. (we shared files using SVN)
Flex constantly conflicted with SVN for us.
I felt distant from the art assets.
some Pros of Flex
being able to follow variable references from one class to another at the click of a button.
being able to easily see many variables while debugging. w/o needing to trace them.
and Flash used to not have Custom Class Code hinting, but now with CS5 it does.
I think you can use the newest features of Flash Player w/o waiting for a new Flash CS#, for example MoleHill (a new 3d api that uses the GPU) has a beta release out right now. and i think the Flex SDK can already use it.
hope this helps.
it should be noted that I am a rare case that doesn't prefer flex, most people strongly prefer flex, so you should give it a try at least.
MXML compiles to action script so it's really like a higher level version of that. So, yes, everything that can be done with MXML can be done with actionscript (but not the other way around).
Flash CSx:
GUI\Layout: Basic GUI class framework
Graphical Content: Great for editing graphical library objects with or without animation
Code: Lacks a good code editor
Flex/Flash Builder + Flex Framework:
GUI\Layout: Advanced GUI class framework and layout engine (Flex)
Graphical Content: Lacks drawing capabilities of Flash, but you can include Flash generated graphics by exporting them for ActionScript into a SWC and importing/referencing the SWC in Flash Builder.
Code: Much better code editor than Flash; not sure if it's on par with FlashDevelop
Other: Supports MXML, which is basically just another style of laying out content. Instead of writing a bunch of "c = new C()", "c.prop = x", "c.addChild"... you can structure display objects and thier children using XML constructs, and the MXML compiler will convert it all back into the less-readable, but basically the same AS3 code.
These technologies are all related and interoperable. They are natural and predictable extensions of the Flash player and ActionScript techonolgies, but for some reason Adobe developed the Flex/Flex-builder/MXML technologies as a totally separate product, and market it as something totally new and oh-so-amazing. Whatever. So now we have to go back and forth between the two to use all the features, which is LAME. They also have to waste time and resources developing unnecessary, but helpful, packages like the "Flex Component Kit" to reduce the number of steps necessary to get Flash content into Flash Builder.
You have to go back and forth between these applications, because of their mutually exclusive features -- Flash Builder lacks graphics editing, and Flash CSx lacks MXML and a good code editor -- but they're interoperable in the sense that you can use Flex classes in Flash, Flash classes (and their embedded graphics) in Flex, you can use Flash Builder and MXML without Flex, etc.
I think they need a single, truly integrated Flash IDE, so they need to merge Flash Builder into the Flash CSx editor.