Ouch, it hurts when i do that
As promised, here are the slides for "Ouch! It hurts when i do that." presentation first delivered at 360Flex San Jose, March 10th, 2010.
As promised, here are the slides for "Ouch! It hurts when i do that." presentation first delivered at 360Flex San Jose, March 10th, 2010.
As you probably know, its pretty easy to use a custom preloader in flex to replace the built in preloader shown as a flex application loads. There are a few tricks to remember with a custom preloader though, remember that the preloader is built to be displayed until the flex framework is done downloading. As such, the preloader won't display until all the classes needed by the preloader are done downloading. For this reason, its really important to remember that your custom preloader class doesn't make use of the flex framework, because if it does, the users will see nothing until enough of the framework has been loaded to display the preloader, and the preloader will only be displayed while the remainder of the framework is downloaded.
Fortunately, the DownloadProgressBar class makes little use of the flex framework, as it extends Sprite, instead of UIComponent, and only utilizes a few event classes from flex, which don't require any additional framework classes. A quick google search can show you dozens of examples on subclassing DownloadProgressBar to create a preloader which matches your application.
A larger challenge is faced when you have additional needs from a preloader. Frequently, we are tasked with writing a preloader which is shown during the initial download, as well as remaining displayed until some startup procedures are complete within the application. Some might try to approach by referencing Application.application within the preloader, to listen for a custom event indicating that the startup procedures are complete. Of course, this is not an ideal solution, as referencing the Application class will link in the mx.core.Applicaiton class, which in turn links in around 170k worth of the Flex framework.
A better approach is to create a new class, which is not linked to the flex framework, which can act as an event bus between the main application and the preloader. If this class is built as a singleton, you can be assured that both the main application and the preloader are accessing the same instance, allowing for a simple and convenient mechanism for the preloader to listen to the main application, without needing any reference to the application or the flex framework.
With this class, when the main application is done with its startup procedure, it's a simple process to get a reference to the PreloadEventBus, set isReady to true, and dispatch an event.
In the custom preloader, you can override the set preload method, and instead of listening for the complete event as the base class does, listen for the INIT_COMPLETE event, which indicates that the application has loaded, and had its initialize event dispatched. In the event handler for this method, you will get a reference to the PreloadEventBus, check if the application has already set the isReady flag to true, and if not, listen for the READY event.
An important thing to note is the lack of call to super.preloader in this overridden setter. If the base classes setter is allowed to run, the preloader will act as initially intended, such that it disappears when the application is done downloading. As the purpose of this preloader is to allow for the application to determine when to hide the preloader and start the app, its important we override this functionality. You may find that you need to listen for other events here, such as ProgressEvent.PROGRESS, FlexEvent.INIT_PROGRESS or Event.COMPLETE. This example shows the bare minimum you would need to make use of the preloader
While its not expected that the application will be done with its initialization procedures before the INIT_COMPLETE, but, based on how the application is built, it is possible. To avoid this race condition, the isReady property of the PreloadEventBus is used, so that the preloader only listens for the READY event if the application is not already done with its startup.
Last but not least is the completePreloader method, which is called when the preloader has determined that the application is ready. With the logic in initComplete, this same method will be used, regardless whether the state of the application was determined by the isReady property, or by listening for the PreloadEventBus.READY event.
Event.COMPLETE is used, as this is the event for which the system manager listens, to know that the preloader is done with its job. By preventing its normal mechanism of dispatching, and only dispatching it when the application determines it is ready, you have a nice clean approach to allow the the preloader to display as long as it needs to.
More details available on Labriola's blog and openSource.adobe
File this under the better late than never...
On September 26 and 27th, the folks who bring you Flex 360, put on a 2 day "Flex Camp" in New Jersery, which went over extremely well. I was presenting on Testing with Fluint (formerly known as DPUint). Of course, I promised my slides and materials would be up on here before the end of the weekend. Well, realizing its over a week later, I'm finally getting them uploaded now.
So, if you were one of the many asking for those materials, here they are.
and found the public beta of flash player 10 was out. How cool is that.
I knew this would be coming before too long, but didnt realize that it would be out so quickly. This new version is filled with lots of new features aimed at allowing greater "expressiveness" in flash player content, such as 3d effects, custom filters, enhanced text rendering, and revs to the drawing API. Of course, like each version before it, FP10 also has lots of performance enhancements. What are you waiting for go get it on adobe labs
I'm particularly looking forward to working with the Advanced Text Rendering features, which promise to allow lots of layout possibilities, including bi-directional text!
more later
I'm a bit late in releasing this news, but our "Flex 3 Training from the source book" was released last week, and is now available from our publisher, as well as the major online bookstores such as Amazon, and Barnes and Noble. Speaking of Amazon, we are currently the #843 best selling of all their books, #15 in the Computers and Internet / Software category, and #8 in Computers and Internet / Programming. Thanks to all of you who have bought our book, and pushed the sales ranks so high.
Anyhow, I know folks have been asking me for months when this book would finally be released, and the answer is, last week.
Enjoy.
Next week I'm off to London to speak at CFUnited Europe, and the following week, I'll be speaking at AJAX World East. In both places, I'll be speaking about the joy that is Flex 3 in all its forms. The CFUnited talk is more focused on how Flex can improve the lives of CF Developers, while the AJAX World one is more focused on how Flex can help RIA developers increase their real world Retursn On Investment from RIA's. On another note, CFUnited has just released the session schedule for their Washington DC Conference in June, and rumor is that the session schedule for WebManiacs should be available shortly.
The WebManiacs 2008 conference schedule has been finalized and registration is open. Early bird pricing ends Jan 31. Consisting of a two-day ColdFusion conference ("CFManiacs") coupled with a three-day Flex conference (FlexManiacs), hosting over 70 speakers and 130 distinct topics (some of which are hands-on), WebManiacs promises to have the most comprehensive coverage of Flex, AIR, and ColdFusion at the lowest price. Seating is limited, so folks should register early in order to get into the more popular sessions.
I'll be speaking on building AIR applications in the first few days of the conference.
1/18 - Flex Camp Chicago
1/24 - Flex Camp Omaha
2/24-2/27 - Flex 360 Atlanta
3/12-3/13 - CFUnited Europe
5/1-5/4 - CF.Objective()
5/19-5/23 - WebManiacs
6/25-6/28 - CFUnited
I've been a bit slow in getting this announcement out, as I see several other bloggers have already posted on this, but the rumors are true. Tapper, Nimer and Associates. Inc. has teamed up with Digital Primates Inc. Some of you may recall, it was just over a year ago that I teamed up with Mike Nimer to form Tapper, Nimer and Associates. It's quite an odd experience for me to go from a solo propietorship to a team of 15 or so developers in about 16 months. With all the great minds from both our companies working together, we will be able to help more customer on bigger and better projects.
Many of you probably know Mike Labriola for his work on custom Flex Components, he has extended the Flex framework in ways that the developers at Adobe never even imagined. He is also frequently speaking at conferences and User groups. Both Nimer and I ran across him at dozens of speaking events across the country, and as we talked, we found there were far more similarities between us then differences.
One of our first meetings at a conference ended up with him as a co-author on the Flex 2 book. A year and a half of meeting at conferences later, and we were helping each other out on projects so frequently that it made sense to explore further integrating our companies. When the opportunity for Nimer and I to join forces with him and his company, it was much too enticing to pass up.
We are looking forward to doing great work together, continuing to build cutting-edge applications for our clients, continuing to teach the world to build better RIAs, and continuing to serve the community.