Knowledge has no limits but still in your opions, what are the basic requirements for an individual, where he can call himself a flex developer. To make it a bit concrete lets say after having a 2-3 years experience.
In my perspective it should be something like below. It is a very (very) rough idea and please let me know your views and suggestions on this.
BASIC:
(1) Knowldge about basic GUI components like tab, vbox, etc. Their properties and the ability to decide which component suits better in a condition.
(2) Knowledge to use services like HTTP, wsdl, remote objects, etc.
(3) knowledge about basic event handling mechanisms and bindings.
(4) Knowledge about basic Object Oriented principles.
EXCITING:
(1) Knowledge about advanced GUI components.
(2) Knowledge about architectures like cairngorm, live cycle data services, etc.
(3) Knowledge to write custom components and renderes and using advanced properties of components.
(4) Knowledge about Design principles.
Also, are there some FREE online tests/certifications etc where one can test his/her flex/as skills ?
Thanks in advance.
Someone who has been coding with Flex daily for 2-3 years should have a pretty deep knowledge of the framework. They shouldn't just know how to use the framework but also how the framework itself works and how to extend it. If they don't, you probably don't want to hire them. :)
Advanced Flex developers should understand how UIComponent works and be able to explain the purpose of all these methods:
initialize
stylesInitialized
createChildren
invalidateProperties / commitProperties
invalidateSize / measure
invaldiateDisplayList / updateDisplayList
setActualSize
getExplicitOrMeasuredWidth/Height
validateNow
getStyle / setStyle / clearStyle
They should know what the Flex "invalidation model" is and how it affects the "invalidate" methods and their counterparts. They should also be able to discuss a few of these topics:
How does container layout work? How does a Box container decide how to position and size its children?
How do Lists display their data and what makes item renderers special? How is a List different from a Repeater?
It's impossible to cover all of the things that a Flex dev should know in a short post here but having a deep understanding of UIComponent, its lifecycle and the invalidation model is super important.
Related
I am making a game. And this time trying to implement menu (-->tutorial) -> game-> scoreboard -> game over
screens.
These screens themselves are quite different in terms of structure. So i am not sure if states is a 100% correct approach here (as I understand states are good for similar layouts) From the other hand many of them has back button to return to previous state, e.g. in tutorial I will have start game and back to menu buttons, etc.
I wonder if there is a clear solution for a problem like this? Maybe there is a special library to handle such cases?
State machines (not only for visual states) are a good solution to implement the behavior of encapsulated components, such as buttons or - in your case - menu items, perhaps even some of your game logic. They can be described independently for each component, and they help to keep your interactions organized, and thus to prevent errors.
State machines are difficult to maintain, however, when you are looking at an entire application: The interactions are usually multi-dimensional (i.e. not only one component is involved, but many, and at different levels in the hierarchy), and when all the different players are taken into account, the resulting state machine will soon become very complex.
From my experience, it is best to use an event-driven approach combined with Model-View-Controller architecture for your application logic, and use state machines at the component level. I would advise to look at some of the existing Model-View-Controller frameworks for this, most notably RobotLegs, PureMVC and Parsley (though to me, Parsley seems a little less complete than the other two).
I think I'm overusing the Flex states model. The way the Spark architecture teaches it, states should mainly be used for changing the visual appearance of a certain component. However, being overly excited about the simplicity of using Flex states, and also willing to reuse existing object instances at runtime, I made my components really "thick", injecting different view models, as well as other stuff, based on a certain state change. This created a bunch of problems with synchronization, so I decided to subclass and specialize instead of relying on states that much.
In general, as a rule of thumb, where should the boundary between states and subclassing be put?
Well, from what I understand, you have a huge view that you now want to use inheritance to split it up? Won't that still make your component heavy and hard to manage?
The better solution here is to use composition, not inheritance. Create new, self-managing and small components that come as a whole into a larger one. There really shouldn't be a 'boundary between states and subclassing' because they do 2 completely different things. One is for view based changes while the other is to add functionality.
I think you're just really mixing up your OOP concepts and should really stop what you're doing and go over the theory a bit before continuing. If you continue on your current path, you'll end up where you're heading; spaghetti code.
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.
From what I understand a framework reduces complexity in areas that are common, like a log-in system. I use ASP.NET MVC at work and have done some work in Zend Framework but do not get how a framework helps with client side development. The reason ASP.NET MVC is used at work is for Unit Testing - does a Flex framework help with this too?
Please let me know why I should or should not use a framework with Flex?
The short answer is: it depends on the framework. :) My thoughts below:
Flex is itself a framework, and you can write reasonable applications without the need for any additional framework. Flash has a built-in event model that allows for bubbling events, so you can dispatch an event in a deeply-nested user interface component and have a listener higher up in the hierarchy that handles the event. The event handler can delegate to your model, which retrieves data from the server, and Flex's binding support can ensure that your views are appropriately updated from the model. I think it's important to understand that Flex applications can and should be written more or less according to that approach, and that any additional framework should help facilitate that approach, rather than providing its own way of doing things that ends up coupling you to the framework.
That being said, an extra framework that helps facilitate this approach can absolutely provide value. I would recommend Mate or Swiz because I think they achieve this goal. They don't try to reinvent the wheel or replace parts of the Flash / Flex APIs; instead they complement them. The dependency injection features make it much easier to provide data to your views, but without coupling them to any framework. There are a number of utilities available to make it easier to work with remote services. They also have a utils to facilitate testing or even persisting data in shared objects.
I have also worked with Cairngorm in the past and I would not recommend it. CG is notorious for requiring you to create a ton of classes that adhere to CG-specific APIs and requiring you to use many of their Singleton implementations which make your app brittle and hard to test in isolation. It is based on a number of J2EE patterns which fell out of favor in the Java community at least 5 years ago.
I've read a little about PureMVC and while I can't speak to its invasive nature, I think that reinventing the event model (called "notifications") is silly and couples you to their framework. Sure, you can say it "insulates" you from the Flash event model in case it changes, but I'd say the odds of PureMVC changing their notification model is far more likely than Adobe changing the event model. :)
If you've ever tried building a slightly large application, or one at all complex, things can quickly get out of control. I don't know how many projects I bailed on when I was first starting out because I didn't know patterns, or how to make parts of the system communicate without being tied to each other, or dependent on each other.
So, basically a framework is a collection of patterns put together. Theoretically, if you learn to follow the "rules" of a (tried and true) framework, your app will not get out of control to the point where you find yourself fixing one bug and causing two. I've been there and it's not fun.
I also found that by learning to use a framework you initially don't have to know so much about the patterns behind what you're doing. But before long you'll get a good handle on the patterns used and you'll be able to apply them in new situations or find a better pattern. So it's a good learning tool as well.
I'm sure people will have arguments against using frameworks -- this is just my experience. But if you become familiar with a few, you will likely find that one might be suitable for one project but not another.
As far as Flex frameworks, I personally like PureMVC. In all honesty the only other one I've given a good amount of time to is Cairngorm. But I like PureMVC because it feels right to me, but also it's generally not dependent on so much on the built-in Actionscript classes. For example, it uses it's own notification system. So if the notifications change in Flex, they'll still work in your PureMVC app. Also, the creator Cliff is super helpful in his forums, and he's really passionate about it. And the documentation is great.
I recommend coming up with a super basic app, and building it without any frameworks, then again with a couple others. You don't have to finish the app, but just get a feel for what's behind the frameworks.
You may find value in using a framework if:
You work in a team environment and want to be sure everyone uses the same approach
You have a large, sophisticated app and want to communicate effectively between parts of the app
You want to be able to hire additional programmers and have them be productive quickly
You want to ensure your application is built with a proven architecture
You want to leverage the knowledge of design patterns and solutions that are known to work well
You want to simplify a complex application
Here's a great article on Flex frameworks.
Flex Framework Comparison
And, I agree with the conclusion...Mate is a great Flex Framework.
Another interesting framework not mentioned in this article is Spicefactory's Parsley.
I use PureMVC (which is an MVC-framework for Flex) for my larger applications. Like 99miles stated, it depends on the application size.
If you just have to make a (relatively) small tool/application, you can get it going with just Flex. But if you want to create a large, complex application a Framework might come in handy.
The main reason I use PureMVC in Flex is because of the Model-View-Controller architecture. This separates the presentation layer from the business layer and works a lot with events and notifications. This gives you a lot of control in creating reusable classes/controls in Flex in a relatively simple way.
As I said before, for a small tool/app/website I wouldn't recommend using a framework, because in that case it might be to time consuming and complex. But for the larger applications, frameworks are quite handy.
More information on the MVC architecture can be found here.
Hope this helps :)
I've just found out about View States in Flex (v3.0), but I am not really sure how widely this is used in real-world applications. Is it a good practice to use it? Are there any pitfalls such as maintainability for instance?
I also used states in an enterprise-level app. But very lightly.
States can be really useful to clean up your code for some cases. There is a performance down side, if a state adds a child, the child will not be removed from the list until you go back to that state and and add a new child.
I think states can be useful if you need to enable/disable make visible/invisible a bunch of components back and forth (depending on a state). This is the ideal use-case of states in Flex.
I've used states heavily and find them a far more elegant solution that lots of conditional code. Indeed, I initially avoided them for some of the reasons given above, but after the app became very complex, with multiple variant "states" I realized that I was fighting the framework.
Frankly, I'd make the same observation about bindings. If you don't understand some of the subtleties, they can be your undoing, it's true. However, writing your own code to achieve the same thing seems like duplication of effort. Take a look at the generated code sometime and also read some of the good deep-dives on bindings out there.
I started using states in my app (enterprise-level application) in various places, and have since refactored them all out. Most of my MXML has been replaced by pure AS3 components, and I'm skeptical of binding and the flex component lifecycle. There's a lot of convenience tricks advertised in the Flex framework that begin to feel cumbersome and slow once you really start using them.
Like anything, your own mileage will vary. They might be useful if you can avoid the "everything is a nail" syndrome. Maybe I couldn't.