By now you have surely heard all the hullabaloo around Apple Adobe and iPhone/iPad development. Until recently, Apple's position was understandable from a business perspective, in that, if they allowed Flash applications to run on the iPhone, iPhone customers could use free Flash applications over the web, and not have to buy them from the Apple store.

While this position sucks for apples customers, they remain a loyal bunch, who continue to seek out new ways to tithe to their mothership.

Adobe has been quietly pleading with Apple to reverse this position, but has been working on alternative ways of allowing developers to build applications which can be deployed to the Web, Desktop, or any Mobile device, including those by Apple. Chief among these efforts was the Creative Suite 5 Packager for iPhone which is scheduled for release in the next few days.

Yesterday (4/8/2010) apple announced the iPhone OS4, and release a new set of Terms of Service, which amongst other things, explicitly forbids iPhone/iPad development with 3rd party tools (such as the CS5 packager mentioned above).

This is clearly going to far. Its bad enough that developers who want to build apps for apple devices already need to pay $99 + 30% of all revenue to Apple. Now, they also need to use apples tools to build these applications.

The reaction to this has been varied. The followers of the "Cult of Apple" see this, and everything else Steve Jobs does, as as good move, which will save humanity from itself. Adobe supporters have reacted with outrage, including (but not limited to) Jesse (TheFlashBum) Freeman calling on Adobe to stop developing software for MacOS.

Oddly, many of the MacOS fans I know first switched to Apple from Windows because they despised Microsoft's anti-competitive practices. Funny, of all the anti-competitive steps MS has ever taken have been much less harmful than those taken by Apple recently.

Of course, Apple claims they won't support flash because its not "open." This is hilariously hypocritical, as Apple's devices are the least open things out there. To write an iPhone application, you need to use approved development tools, get apples approval on the software you write, and sell it through apples store. Which of these things seems open to you? Did I mention that the Adobe opened the source code for the Flash Player, when they donated it to the Tamarin project (http://www.mozilla.org/projects/tamarin/). Strange how the closed can criticize the open for lack of openness, and be believed by so many.

As I'm not a MacOS person, I have no Mac to burn in effigy, but instead of buying a new iPod, as I had planned, instead I picked up a ZuneHD. In short, if Apple wants to screw over their customers, I simply see that as between them and their customers, and can only react by not being a customer. However, I wonder where all the new iPhone apps will come from, after Apple is done alienating all the developers of the world.

As promised, here are the slides for "Ouch! It hurts when i do that." presentation first delivered at 360Flex San Jose, March 10th, 2010.

Today, I presented my Flex 4 for Flex 3 developers presentation at FlashCamp Chicago. For those that wanted the slide deck, you can find it here.

In this, I discuss a number of differences between flex 3 and flex 4, and what an existing Flex 3 developer will need to know to start being productive in Flex 4.

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...

• 2009 - Los Angeles - How Not To Code Flex, Intro to Flex 4
• 2008 - San Francisco - Intro to Flex 3
• 2007 - Chicago - Intro to Adobe AIR / Building Desktop applications with HTML and AIR
• 2006 - Las Vegas - Getting Started with Flex Development
• 2005 - Anaheim - Creating Better Performing Flex Applications
• 2004 - New Orleans - Using ColdFusion to Power Flex and Flash Applications
• 2003 - Salt Lake City - XML in ColdFusion / Building Components in Flash
• 2002 - Orlando - Styling a Flash Application
• 2001 - Orlando - Did not speak
• 2000 - Washington DC - Planning a Spectra Application

More details available on Labriola's blog and openSource.adobe