Down to the last 5 (Cheap) tickets left for 360|Flex. Register now, save $100 and get the same awesome content for a little less coin. Act fast, these last tickets won't last. When they're gone, the regular price of $599 kicks in.
Come on out and hear me give advice how not to hurt yourself with code, in my "Ouch, it hurts when i do that" talk.
I'll be presenting my freshly revised "How Not To Code Flex Applications" twice in the next few days. Tomorrow, in the boston area at RIA-Unleashed and then next week at Flash Camp Wall Street.
c'mon by and see us at one, if not both of these great events
I'll be giving a free full-day, hands-on training session, where experienced ColdFusion Developers can learn how to build their first Flex application using the latest Flash Builder 4 beta software. This training is designed to help experienced ColdFusion developers get started in understanding how to add rich UI to existing and new ColdFusion applications.
Date / Time
Thursday, November 19
Hyatt Regency Chicago on the River Walk,
151 East Wacker Drive,
Chicago, IL 60601
Registration: 8:30am
Registration
http://www.adobe.com/go/flextrainingforcfdevelopers
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.
For the 9th year of the last decade I'll be speaking at Adobe MAX, being held this year in Los Angeles, between October 3rd and October 7th. This time, adobe has asked me to present two sessions, one an "Intro to Flex 4," and the other a session on "How not to code Flex Applications." You can find information on registration and everything else at max.adobe.com
If the schedule stands as planned, I'll present my "How not to code" 10/6 at 3pm, and my "Intro to Flex 4" 10/5 at 11:30am
In case you are wondering, here is what I have spoken on in years past...
More details available on Labriola's blog and openSource.adobe
The Flex Builder needs to know if you, the flex community want FlexUnit 4 to be supported in FlexBuilder 4.
Spend a few minutes reading about FlexUnit 4, and if you would like flexbuilder to support it, you can cast your vote for it here
They are selling fast, and it promises to be jam packed with geeky fun! I'll be giving my session on How Not to Code Flex Applications, and doing a joint presentation with Mike Labriola on cleaner living with Flex Unit 4.
What does $550 buy you at 360|Flex Indy? - http://tinyurl.com/rxtkb9
So stop reading this and buy your tickets already, ok?
As a member of the development team for the Major League Baseball MLB.TV project, I've had a somewhat unique perspective on the successes and failures of the project. There is a bit of backlash in the blogosphere about the technologies surrounding the players, and the inherent superiority of one technology over the other. This post examines only the technologies involved in the situation, and not any of the underlying business decisions surrounding it.
So, what is so difficult about broadcasting MLB.TV? Funny you should ask, regardless of all the Flash vs Silverlight debate that has surrounded the MLB.TV launch this year, the player itself represents only about 10% of the complexity. So, how does it all work? There are a series of inter-related processes involved.
