Related
they both seem to accomplish the same things with different syntax, whats the point of using two different technologies. Please highlight every possible benefit of using mxml. Also are there scenarios when one is more beneficial than the other and why.
Please clarify this runtime behavior of mxml vs AS3 as discussed in Oreilly Flex 4 Cookbook page 1:
" Many newcomers to Flex wonder how MXML and ActionScript relate to one another.
The MXML compiler (mxmlc), after parsing through the different idioms, translates
them into the same objects, so that this:
<s:Button id="btn" label="My Button" height="100"/>
and this:
var btn:Button = new Button();
btn.label = "My Button";
btn.height = 100;
produce the same object. The major difference is that while creating that object in
ActionScript (the second example) creates the button and nothing else, creating the
object in MXML adds the button to whatever component contains the MXML code.
The Flex Framework handles calling the constructor of the object described in MXML
and either adding it to the parent or setting it as a property of the parent. "
Usually,
MXML is used to build the user interface
ActionScript is used to code the logic of your application
Of course, you can also build the user interface with ActionScript but :
it will take you more time
MXML views are easier to read than AS views
In terms of user interface, ActionScript should be used only to manage view elements (add, remove, ...) at runtime.
Edit
Within a Flex application, one is expected to favor using mxml over AS, provided both uses are available. In case mxml doesn't provide a solution , the user can fallback to AS3. Flex is a framework, therefore you would expect that the emphasis is put towards mxml, rather than AS3. Like most frameworks , the idea is to hide the details in order to facilitate design and supposedly make programming more accessible.
Everything comes at a cost though, you can't really expect mxml to be faster than AS3 since it's built on top of it. A logical conclusion would be to decide on a case basis. What are your app requirements, is there really a performance gain in using this component or not etc... Apart from the fact that Flex as a whole is bound to be slower than AS3, I don't think you can set general rules. One could add that if one is worried about performance, why choose Flex in the first place...
End of Edit
The Flex framework is geared towards building RIAs, therefore it comes with a bunch of components to that effect and mxml which mainly deals with the layout of these components, Actionscript being the language the Flex framework is built upon, will typically be used for the logic of your application.
The question is not really why choose one over the other. It's the same approach you would have if you decide to develop using a language directly or using a framework based on this language. It's like comparing JQuery & Javascript or CodeIgniter & PHP .I don't mean to imply that the reasons to use JQuery are the same regarding using Flex. Whilst JQuery will attempt to hide browser specificities and make JS more accessible , Flex's purpose is entirely different.
If you're developing RIAs, Flex makes sense, if you're developing games, not really. All you can do with Flex can be done with AS3 , only you wouldn't want to spend time developing DataGrids or HBoxes whilst you could spend more time on your app structure & design.
On the other hand, if you're developing a website or a game , you wouldn't want to add the weight of the Flex framework to your swf, simply because you've added a few Image components and a couple of Labels.
Flex is not adapted to every situation, unlike my previous Javascript or Php examples , Flex's purpose is not to make the language it's based upon more accessible or easier to deal with. Flex has a very specific target.
A similar question might be "what is the advantage of using HTML over Javascript for the UI?"
I suppose you are really asking "what is the advantage of using a declarative UI over an imperative one?"
Declarative UIs are more like configuration -- no logic (or in the case of MXML, very little logic). Declarative UIs separate the specification of the view from the behavior and data.
Tooling almost always prefers declarative UIs as well, because declarative specs tend to be extremely well suited to serialization... much easier for a tool to update MXML than ActionScript with properties and such.
As you get more familiar with the concept, declarative UIs start to feel more natural, and most people tend to prefer them.
Productivity, you create view elements with MXML faster than with AS3.
Under the surface MXML get's converted to the same AS3 bytecode as if you'd write in plain AS3 so the question if MXML makes the app slower comes down to how well the Flex compiler does the conversion.
As for the original question I would say that MXML is for visual development but as said before you hit the limits when trying to create custom components.
Personally I write Flex apps in 99.9% plain AS3 because I can't stand MXML. The only MXML file is the required Entry class so the compiler knows it should be a Flex app that it compiles.
Either way your app is going to get converted to an ActionScript object.
The advantage of using MXML is user friendly and more control on the look and feel of application. sometimes its easy to fix issues aligining your components on the right pane or panel with MXML.
The advantage i see using actionScript is command over your application, you have more control. Sometimes your MXML does not get you the itch of what you are looking and actionScript gives you more power.
I would suggest you to play with both to build an application which can give you less headache and better results.
None, Flex is for learning, as you learn more you use more .as and then one day... you use 0 Flex.
For one it's slow.
(edit - answer to comments)
'Why is flex slow' - it creates computer generated .as code. Equivalent functionality in .as is faster and smaller.
'MXML separates UI from code' - I'd say no it does not. First of ... it's XML.
If you are new, check out other frameworks, like Away3d, FDT and MinimalComponents. As you get more advanced, you use less MXML and one day no MXML, you are writing pure .as.
Anything in Flex can be done in HTML5/.js better. Also .as is much better than HTML5/.j
It's like a learning tricycle, and good for corporate developers that do drag and drop, they think of themselves as programmers. Software engineers... don't stay with Flex for long before evolving.
Here: http://www.youtube.com/watch?v=TL2t8eOs1XE
I feel sorry for you if you stay in Flex and don't advance.
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)
This may be more of an opinion poll than a question, but here goes. I have a fairly complex Flex application that uses many different components. I want the application to be able to custom styling and/or skinning. I also want to be sure that the styling approach makes the most efficient use of system resources (memory, CPU, network), and that it does not adversely impact performance.
We currently are using a hybrid approach to styling the application that uses both CSS and a Flash skin created in CS3. It seems odd to me to have a two-pronged approach to styling an application and ideally would like to settle on one approach or the other. Can someone outline the advantages and disadvantages of using either exclusively CSS or a Flash skin? Is there a justification for using both within the same app?
Using CSS exclusively seems advantageous because it is approachable by anyone with a basic understanding of other uses of CSS, especially when using the Flex 2 Style Explorer. On the other hand, I know that the CS3 skin we use declares up/over/down/disabled/pressed skins for each component where these states are needed and Flex manages the transitions to the appropriate skins as each state is (de)activated. However, my impression is that creation of a Flex skin in CS3 requires somewhat specialized skills and tools.
So what would you recommend for styling a Flex application if performance, customization, and efficient resource utilization are priorities?
First, I would suggest using Flex 4 if you haven't started already. Flex 4 is just about to be released.
With Flex 4, they have a whole new skinning architecture. This means you'll never use Programmatic Skins again. Plus they have Advanced CSS Selectors, so you can do way more with CSS in Flex 4. Programmatic Skins are very hard to make dynamic anyways. In the end, you'll end up creating an architecture like Flex 4 Spark Skins if you try to abstract out the logic for Programmatic Skins.
Customization
What we're doing to make Flex 4 Skins and Styling as dynamic as possible is the following:
Style Palletes: Either static classes, or XML files
Custom Skins
CSS
Style Palletes: These are static classes that hold all of the variables you use in either CSS or Skins. For example, you can have a ColorPalette that has all of your colors: public static const ColorPalette.BRIGHT_RED:uint = 0xff0000;, etc. You can then use these in Flex 4 Skins via binding, such as <mx:Button color="{ColorPalette.RED}"/>. The only problem with static classes is they they're not dynamic (you couldn't define an arbitrary number of colors for them). Same with XML: you'd have to hard-code (eventually) a certain XML structure in order to use them in Skins. You could even have the XML define ColorPalette values (so ColorPalette.ACCENT_COLOR could be set to anything from XML (gold, bright blue, or any accent). Fun stuff.
Custom Skins: Flex 4 allows you to easily skin all the Flex 4 and Flex 3 (datagrid, accordion, etc.). So if you don't like how Panels only have 1 drop shadow and no gradients, you can add a background with 4 gradients and 2 dropshadows (for 2 angles of light), and maybe some rollover effect. And then you could apply your ColorPalette.BRIGHT_RED to the shadow (or a glow :)). And you could have XML configure the ColorPalette settings. Here's a cool custom Flex 4 Skin
CSS: Then in CSS, you could write a very simple Palette parser that applied your ColorPalette values (for example) to CSS. Check out the Degrafa CSS Skin for some code examples.
Performance
The only problem with Palettes and CSS is performance. By definition, static class and binding decrease performance. Binding causes lots of event dispatching in the background, so things like <mx:Button color="{ColorPalette.RED}"/> decrease performance (not noticeable of course, since there are much worse applications, such as using built in Adobe Tweens), but it does to some degree.
Same with CSS. In Flex, every CSS Selector (Panel { properties:values... } is converted into an Object. So if you have 100 selectors, you get not only 100 extra object, but 100 extra classes in your application, at least! And that definitely adds to your swf size. And all of their properties are dynamic, and by definition, dynamic classes are slower than non-dynamic classes. Plus, setting a style (with setStyle(property, value) in Flex is very slow because you have to loop through all the children. If you're setting styles via an admin system (or something like Flex Style Explorer like you suggested), then you don't really care. But because they use setStyle(), you can see a decent performance hit when changing styles.
So if performance was a super big issue, the best option would be to hard code every style value, and not change styles at runtime (who needs to do that anyway (unless your in the admin section)?). How do you hard code styles while still remaining agile? Use Palletes (ColorPalette.BRIGHT_RED) and the like, and convert the binding expressions (<mx:Button color="{ColorPalette.RED}"/>) to static declarations via some preprocessor (I use ruby to compile my swfs, so I just match patterns and replace). So it'd convert <mx:Button color="{ColorPalette.RED}"/> to <mx:Button color="0xff0000"/>, and you get a performance boost.
In the end though, it's best to create custom skins and define the styles there, either through:
static declarations <mx:Button color="0xff0000"/>
palette declarations <mx:Button color="{ColorPalette.RED}"/>
xml declarations <mx:Button color="{myxml.#button_color}"/>
Then you can define some really cool and advanced skins and have them wired up to a palette or xml file and have the user edit that. Trying to build a very cool and modular skin/styling system with Flash or Flex using their built in stuff is not easy (nor desirable). So it's best to
create a set of skins (and package them up as a theme)
wire skins to xml
let user modify xml
Avoid CSS, it's too processor intensive, unless you need advanced selectors like you'd use in HTML because it does make life easy. But for modularity and customizability (and performance), create Skins and wire them to XML.
I myself create a basic theme that I can use in all of my client projects, something that defines my style. That consists of 3 packages (myskins, mx, spark). In there, I copy/paste all the default Flex 3/4 skins and start customizing. You can download a Scale 9 Skin Project for free to have most components ready to skin and test. Then I just merge my design (photoshop or whatever) into Flex however you choose. For all the colors I reuse, I add them to a palette and eventually to XML. Then if I need a slightly different skin and I use that multiple times, I use CSS to define a new style for a skin (maybe a list with no background color or border). My CSS is very lean. Then I can just copy/paste my theme/palettes/css to new projects, modify it as needed, allow the user to edit the colors and positions via xml (or an admin interface) and I'm ready to go.
You can't do that much with just CSS.
Hope that helps.
Lance
I've always exclusively used CSS. You stated it best that it is approachable by anyone. We can delegate the design to people that have no idea how to code in actionscript and they have no problem working with the css and the style explorer (updated for flex 3 at http://examples.adobe.com/flex3/consulting/styleexplorer/Flex3StyleExplorer.html, haven't compared too much to find out whats different vs the flex 2 version).
If performance and flexibility are the two most important considerations for your skins, you should consider Programmatic Skins.
See: Programmatic skinning - QuickStart
To quote Adobe:
"One advantage of programmatic skinning is that it provides you with a great deal of control over styles. For example, you cannot control the radius of a Button control's corners with style sheets or graphical skins, but you can by using programmatic skins. You can also develop programmatic skins directly in your Flex authoring environment or any text editor, without using a graphics tool such as Adobe® Flash®. Programmatic skins also tend to use less memory because they contain no external image files."
Fore more info, you can also read "Creating programmatic skins" in the Adobe LiveDocs Help Docs.
Can anyone tell me what is and isn't recommended when it comes to mixing in classes from the mx package in an Actionscript only project?
Specifically I want to use AsyncToken, IResponder and HTTPService classes in the mx package in an Actionscript project.
I guess the mixing problem comes when you need to use mx.* classes, but you're on a pure as3 project.
If it's as3, you can still make an actionscript flex project, using the framework.
When it comes to Flash, you can either export a SWC with your actionscript exported (linkage setup) and add that to your flex project.
Again, if your project weighs more on the flex framework than on flash, you might find the Component Kit handy.
But if it's a Flash IDE more oriented project ( as in simple data coming in, mostly design work, not much nerdy stuff to it ), using a few mx.* classes, just for the HTTP service, doesn't make much sense. The problem comes with the fact that flex is a framework, therefore things rely on each other to work well, like a brick tower...brick upon brick, upon brick...
and since it's code you're working with, things are somewhat dynamic, but still not much cement...so you might end up wasting more time finding all the flex dependencies and getting them to work outside the medium they were made for, rather then building some of the functionality by hand.
If you need an as3 only implementation for WebService, Carlo Alducente has one.
HTH
The non-visual mx classes should work fine in a AS3 only project. But they have a lot of dependencies so you SWF will be bloated.
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.