Minimalist Approach to Flash/Flex/AIR Development
DIGG IT!
15
Comments
Published
Wednesday, January 23, 2008
at
3:26 PM
.
When I create software that runs on Flash Player I take a minimalist approach during development. Flash Player has a limited amount of code execution capacity, rendering capacity, and memory storage capacity at any moment in time. Ideally your application never pushes the player to its limits at any single moment in time and thus will run as fast as possible. Should you hit these limits, the player will simply slow down until all the work you are asking it to do is complete. Over time these facts have forced me to think in terms of programming in a minimalist fashion.
The Flash Player uses a logical unit of work called a frame which consists of 2 phases which occur one after another in a loop:
1. Process ActionScript
2. Render Graphics
3. GOTO 1
After each of these phases is a buffer to handle delays ( say you render to much or loop over a ton of data ). When both of these phases have completed we call that a frame. Each SWF file you create has a framerate (frames/second) which represents the fastest rate that the Flash Player will loop over these phases. When Flash Player encounters delays in processing either phase it will elongate the time to process the frame and thus your framerate will slow but will never exceed the framerate set in the SWF file.
Ideally your application never renders or executes too much at a single moment in time. There are several ways to handle this:
1. Minimalism - Never attempt to do too much at one time.
2. Process data across frames ( callLater() ).
3. Time Animation - Use time to animate/render ( flash.utils.getTimer() ).
4. Frameworks optimized for Flash Player (Flex).
Flex was built to handle application behavior in a minimalist fashion if used properly. I continue to see developers execute to much ActionScript on a single event and not think in terms of processing data across frames. Using events properly is a great place to start. Make sure you know how long and how often methods are being called from events. I had a case recently where a developer was using the flash.utils.Timer class and firing tick events every millisecond. Even with the simplest of methods subscribed to this event, it would bring Flash Player to its knees. To help visualize how your application works take a look at the memory and performance profiling in Flex Builder 3 Professional. This toolset was built to let you see what your application is doing at runtime and easily locate performance areas within your application. Better still the profiler allows you to locate performance issues late so you can avoid early optimization and save a ton of development time. I prefer to take a more balanced approach and architect things taking advantage of processing over time and using events carefully. Another big issue is the use of bindings as these generate events when data changes. As they are so easy to create, you can force the player to be processing nearly non-stop with the smallest of data changes. They are very powerful but it is easy to abuse.
To more fully understand this approach I would encourage you to explore and experiment with Flash Player and the Flex 3 Profiler. Once you understand how the player internals work and can see the effect of the code you write, you will understand the benefits of being being a minimalist. Just remember, I am not asking you to give up your worldly possessions but rather think in terms of doing the least to achieve your goals with Flash Player or AIR.
Cheers,
Ted :)
As I was saying to Ryan a few minutes ago in Small Worlds, yesterday I had an online "fight" with a guy who tried to convinced me that FP sucks because his safari crashes every time he visits a specific website. Of course I couldn't know the actual cause of the crash since it was an online talking but when he told me that this happens to him only and every time he visits this site and that he tried it from two macs and happened the same thing I think that the 1st thought that comes in mind is that there is something with this site. So I tried to explained to him the same thing that happens when people accuse a technology because of the bad use that a dev have made..
Hi Ted,
I agree with you. Noticed most of flex documentation hardly deals with he flash Player and it's API.
Framerate, memory management, garbage collection, deleting un-need event listeners,
asset management have always been part of an ActionScript dev's to-do.
I find it a bit confusing why these topics hardly get discussed for flex, how it is not stressed to remove event listeners in MXML
and why swf fileSize (huge if using Flex API) is never adressed.
Somehow, new features get added (like AP framework cashing) but flash player basics remain the same. Always stay in control of your content.
something i keep in the back of my head for sure to improve function & speed.
It's nice to read that some others in this world like slim and light ways of programming... I think that the profiler should be in the base/standard version of the builder... not the professional (really!!! three times the price?!?!?!?). Most of the developers I know would like to buy the new Flex 3 Builder but think that the professional version costs too much for what has to offer. Most of the programmers in flash/actionscript community could benefit having contact with the profiler ...cause most of them are not 'traditionally trained' it's more likely that they don't make the right guess about what's going on inside the software.
Thanks for bringing this to light, Ted. I think with all of the developers coming to Flex from non-Flash backgrounds, the frame concept might be lost to them, especially since Flex doesn't really present that concept, in fact it abstracts it very well.
Devs coming from Flash have already faced this limitation. Not to say that a Flash dev is necessarily better at developing a Flex app, but they hold an advantage in this regard.
> I had a case recently where a developer was using the flash.utils.Timer class and firing tick events every millisecond.
The effects class of Flex dispatches the timer event every 10 miliseconds and after that calls the expensive event.updateAfterEvent() method. How is this different then the example you gave?
Greetz Erik
Anonymous,
The profiler is a very advanced toolset and is not needed for all projects only those large enough to require this type of inspection. The goal was not to raise the price of the FB3 IDE but rather lower the standard price for those new to Flex. Typically developer tools like FB3 Pro cost well over $1000 and we made every effort to lower this. Also remember that once you own pro, upgrading to the next version is a lower step. It is only $99 to upgrade FB2 to FB3 Standard.
Ted :)
If you are building large things I would stongly recommend understanding the Flash Player and what it is doing. Working against a runtime leads to a bad place. Part of the issue is that Flex is so easy to pick up that there is little inital thought about memory and performance and these factors build up until performance lags. As a developer community we need to be more cautious and minimalist about how we write software from the beginning and be aware of the risks in not being constantly vigilant. It does take a balanced approach in terms of productivity and performance tuning.
Ted :)
hi, (offtopic)
i read your blog frequently and find it very interesting BUT...
this counter at the top right is really annoying...
it is disturbing the eye while reading, i always scroll down to hide it !
can u make it less dominant? plz.
"Use time to animate/render ( flash.utils.getTimer() )"
Is there any work being done by the flex framework engineers, to make effects (mx.effects.*) just as optimal? Or are you suggesting that the community only ever use manual animation? :(
(I know some projects won't be affected by using effects)
The profiler is a very advanced toolset and is not needed for all projects only those large enough to require this type of inspection.
This attitude really bugs me. It seems to be a corporate mentality at Adobe. "Oh, you're not working for big company X, therefore you couldn't need any of these useful features, take this crippled version for less."
I think it would be more honest to say: we want to charge more money to those who have it to spend, but still get wide product dispersion, so we produce multiple levels of software. The whole "only advanced/enterprise projects" need this feature is a lie.
The profiler is such an obvious example: even tiny apps often have performance problems. Take the Flex blog reader that chews up memory and massively stalls my Firefox. This could hardly be called a "very advanced" app yet would benefit straight away with being profiled.
Flex Builder has a long way to go in terms of performance and stability before it justifies its price tag. Especially given Adobe didn't pay for 95% of the development by basing it on Eclipse...
Charie,
Flex Builder is commercial software and is intended to save lots of time and money to developers that leverage it. The Flex SDK is free and open source so you can build anything without paying Adobe a dime including competitive tooling to Flex Builder.
The profiler was a very expensive toolset to develop internally and has been in full scale development for 3 years well before FX2 shipped. We put it into the "Professional" version of Flex Builder because it is far more useful for advanced developers and would have resulted in a higher price for the introductory version.
I too wish we could have advanced features shipping for free in Flex Builder but it is difficult to justify ongoing development and investment without ROI.
Also in regard to Eclipse, it is a bit of a misunderstanding but Eclipse ships with little intrastructure for building out language editors. With Flex Builder we had to build up the code model and editors from scratch as the base Java code model is very specific to Java and there is actually very little to reuse. Saying 95% of Flex Builder came in choosing Eclipse is just incorrect. Plus Adobe contributed all changes to Eclipse SDK back into the Eclipse project as open source. Many of the improvement on the MAC platform are a direct result of Adobe's work on Flex builder.
Cheers,
Ted :)
Dear Ted,
I think you are confusing minimalism (good hygenic coding practices) with recognizing the idiosyncrasies of the flash player. The former is an ideal of the academic the latter is an ideal of the hacker.
Flash/Flex stands at a unique point as the language/toolset matures the code can be treated with more formal methods of analysis. However , our code is ultimately handled by the flash player. So I take it by going 'minimal" you mean to understand ultimately how the code is interpreted by the player. This is problematic as there seems to be very little documentation on the flash player other than Tinic's blog.
Also, I believe that the profiler should be free, since the debugging toolset within flash has been rather sparse if not downright unreliable.
Hi Ted,
Thanks for your reply. Interesting to hear about some of the process of adopting Eclipse. I'm also fully aware of the cost of software development and the need to recoup that cost by selling at the appropriate. However I think you misunderstood my complaint.
it is far more useful for advanced developers
My complaint is to do with this way of speaking that you've continued in your response: that profiling (and I've seen the same said with respect to testing, various server-side data services etc) is an advanced feature that the normal developer doesn't need. I don't agree with that assesment at all.
What is really the case is that Adobe wants to sell Flex both to people with less money, and to people with a whole lot more money, and get a higher price from the latter group. I have no problem with this strategy.
I just ask that Adobe people be more honest about it, rather than claiming that only "advanced" users need feature X.
The false argument at the bottom of this is that enterprise users have more complex apps than the small end of the market. Complex/interesting/boundary-pushing software comes vary rarely in the multi-national I work for... (They do have more money of course...)
Charlie
Thanks for bringing this to us, Ted