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.
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 have a Spark list with a customItemRenderer that is taking a good 3 seconds to initialize with just 50 items.
I'm using Flex 4.5, my ItemRenderer is already very optimized, using as little nesting as possible, fxg and so on.
Is anyone having similar issues?
I've tried almost everything in the book bar going back to mx.
So the issue was due to the way that spark handles styling the issue is detailed here: http://bugs.adobe.com/jira/browse/SDK-29880 and can be sorted by monkey patching with: http://taytay.com/?p=169
Also removing global css selectors "*" helps.
Avoid HGroup and VGroup as much as possible, use absolute layout instead. I've had this same problem at that's fixed most of it for me.
1 hgroup + 1vgroup each three times = 6 automatic layouts PER ITEM. So in total you have 150 objects, WAY too much.
After applying the monkey patch mentioned by Pedro with only modest performance gains (I suppose we had fewer styles, or the performance was fixed in a more recent patch), I continued profiling the initialization of our List instances.
One thing I found is that Flex spends quite a lot of time in UIComponent's initializeAccessibility function, even though our application does not support accessibility in any way (whether applications ought to do that is an entirely different issue).
Merely adding -accessible=false to the compiler arguments cut time spent initializing a particularly heavy list by about a third! Not only that, the whole application in general feels snappier when windows are opened, controls are shown for the first time, etc. If you have no need of accessibility support, you might want to check this out - if you do, I'm sure something can be done to fix the abysmal performance of initializeAccessibility - simply through overriding it in your component implementations, or through even more monkey patching :-)
Are your item renderers checkboxes by any chance? A few folks have recently run into a bunch of performance issues with Spark in general.
http://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-migrating-from-flex-3-x-to-flex-4-x.html
Adobe has been notified, and apparently are working on it:
https://bugs.adobe.com/jira/browse/SDK-29451
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.
I have been seeing some Flex Frameworks, but would like to ask to the programmers and Architects down here on which has suited best in your application.
Cairngorm
Pure MVC
Mate Framework
Custom One.
After using, in turn, all three of frameworks you listed, I can easily conclude that Mate is by far the superior framework. Of course, that's only my opinion and determining what makes a framework superior differs depending on your requirements.
To me, Mate's most appealing feature is how well it separates the different tiers of your application. After becoming familiar with it, I could never go back to using a framework that makes extensive use of global-state "Singletons" (Cairngorm, PureMVC).
However, Mate can probably be a bit difficult getting started with as the documentation is still a bit lacking and outdated, making it hard to know where to find the newest information. Some of the best practices and approaches that have been ironed out are to be found in the Mate forums, requiring some digging through posts. One of the most active users on that forum, Theo, has written a very good summary on the benefits of Mate in the following post:
Flex MVC Frameworks
PureMVC.... I like to have control and not relying on data binding... also since its been ported in different languages it has more value in my book than just a Flex only framework. Overall any MVC architecture is a plus in my book and it comes down to personal coding style/preference.
Cairngorm, and when I can't use Cairngorm (say, when using Flash CS3), I will simulate it (and it is really easy to duplicate conceptually). It is easy to set up, stupid simple, lightweight, and fast. If done correctly, it also forces a VERY clear separation of form and content. It fits in brilliantly with the native Flex classes and exploints data binding to the fullest. Of course, this might have something to do with the fact that it is the standard which Adobe explicitly endorses. Further, it is by far the most popular, which means if you need other people to be brought in and work on your projects, it will be far easier to find people who know Cairngorm than people who know the alternatives.
I find PureMVC incredibly bloated, non-ActionScript intuitive, and generally useless unless you work in a 99% Java company that does a very small amount of work with Flex and you want to have both use the same system.
I don't know anything about the rest.
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 :)