Colin Moock's guide to Flash for Flex programmers

One of the things that makes me laugh (and cry) about the Flex 2 documentation is that it implicitly assumes that the reader is familiar with Flash. Given that Flex is supposed to be a development environment targeted at traditional developers (familiar with Eclipse and source code control and the like), you'd think that it would be a fair assumption that at least a significant share of the readers of the Flex 2 doc set would be Java, C++ or C# programmers (like me) who are keen to understand how to build rich clients in Flex.

I guess that other newcomers to Flash will probably have the same frustrating time as I did trying to figure out how (and when) the AVM2 dispatches mouse, focus and keyboard events, how to refer to the instance's properties of a symbol created with Flash CS3 using the Flex Component Kit for Flash CS3, and how to write programmatic skins etc...

So I thought a guide to Flash for Flex programmers was needed and I even though about writing one. That is until I read Colin Moock's recently published Essential AS3 book. Section 2 is the essential "missing manual" on the AVM for Flex developers who don't come from a Flash background and Chapter 29 is the perfect introduction to the Flash IDE for Flex programmers.

One day there might be a book on the Flex class library of the same thoroughness and quality.

Flex's DateTimeAxis renders in GMT by default!

I have to admit to that fact that getting used to Flash's Date class has been a struggle, especially in its new localized form. If you instantiate a Date with a single parameter, it assumes the parameter you supply is the number of milliseconds since UNIX was cool, and it also assumes you're specifying the time in GMT. All is fine. If, however, you instantiate a Date with several parameters, (specifying the day, month and tear etc... separately) it assumes that you're specifying the date in "clock-on-the-wall" time. Once you've created the Date object, its toString() method renders the time in "clock-on -the-wall" time.

The fun really starts when you render a collection of Date objects using Flex Charting. Despite the fact that the Date class's toString() method renders UTC times in "clock-on-the-wall" format by default, the mx.charts.DateTimeAxis class renders Date objects in a line series in UTC by default. Thankfully the DateTimeAxis class has a property called displayLocalTime that you can set to "true" to get the Date objects rendered in "clock-on-the-wall" format but it's not the default.

Flex jobs at betfair.com in London, England

I recently joined betfair.com as the development lead for a new team responsible for reimplementing the gaming systems in Adobe Flex. We've already completed a beta and, because of the positive feedback, we now need to urgently grow the development team in London, England.

We're looking for talented developers who have experience of developing service-oriented smart clients in a team environment, ideally with first-hand experience of Adobe Flex2 and Cairngorm but strong candidates with experience of Java Swing and/or Windows Forms.NET will also be considered.

Launched in 2000, betfair.com is the world's leading online betting exchange with customers more than 35 countries. betfair.com provides a similar service for online betting that a "derivatives exchange" offers for the financial markets, just at a much bigger scale (over 1 billion trades were processed on the exchange last year). betfair.com is a profitable company with annual revenues exceeding GBP 140 million (USD 280m).

If you're interested in applying for one of these positions please send your resume to me at graeme dot harker at betfair dot com.

Happy Brithday Flex 2

By my calculation it's exactly one year ago today that Flex 2 went GA. Happy birthday! A lot's changed in a year.

Does Flex need an fconsole (like Java's jconsole)?

As Flex is used for more complex applications and is more widely used in the enterprise I'm wondering how long it's going to be before people want to peer inside the black box of the Flash Player and see how it's working (how the garbage collector's working, how many event/s it's processing and how it's using the operating system's vm system).

Java's addressed this with its JMX framework and the super-cool free jconsole tool that comes with the JDK that charts thread and memory utilization.

Grant Skinner's been writing some cool stuff on the Player's memory management system. This presentation is a must for anyone developing enterprise Flex applications).

How long it will be before people will be asking if Flash Player needs an fconsole?

Did Mark get the idea for Flex from his parrot?

In a interview with Mark Anders in today's UK Guardian newspaper, Mark talks about ASP.NET, Flash as a development framework and his parrots!

The Flex compiler doesn't spot name conflicts

Beware! The Flex 2.0.1 compiler appears not to notice the reuse of the same identifier if decalred as both static and non-static in (what in any other language would be) the same namespace. The equivalent throws a hard compile-time error in both .NET 3.0 and in J2SE 5. The following example compiles without error. Is this a bug or is it supposed to be like this in AS3?

Is Flex's valueCommit dispatched at the right time?

The more I work with validators, the more concerned I am about whether TextInput's valueCommit event is raised at the right time. You could imagine a scenario where a TextInput's text property is only committed when the user is happy with the input and moves focus to another component, at which point the valueCommit event is dispatched. Unfortunately that's not how the TextInput component works. In fact, the TextInput component updates it's text property (and anything bound to its text property) after each key depression. Hence its actually "committing" its "value" after each key depression (when the change event is dispatched). This makes no sense to me at all. Either the valueCommit event is badly named or its dispatched at the wrong time in the live cycle of this component. Thoughts?

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" backgroundColor="white" backgroundImage="">
<mx:Script>
<![CDATA[
private function onChange() : void
{
trace( this.textInput.text ) ;
}

private function onValueCommit() : void
{
trace( "onValueCommit()" ) ;
}
]]>
</mx:Script>
<mx:Label text="{this.textInput.text}" />
<mx:TextInput id="textInput" change="this.onChange()" valueCommit="this.onValueCommit()" />
<mx:TextInput />
</mx:Application>


Are you still using trace() in Flex 2.0 ?

If you're still using flash trace() in your Flex 2.0 applications you should have a look at the new ILogger interface in Flex 2.0. I'm using ILogger for my own components and it's great. It's not hard to learn how to use it, especially if you have any experience of logging with .NET's System.Diagnostics.TraceListener (or with Java's log4j).

Unfortunately, with the exception of the Flex v2.0 Data Services components, I've found that the Flash v9.0 framework runtime itself and the Flex v2.0 components don't log what they're doing and don't use the ILogger interface.

Debugging complex applications with lots of dynamically created nested MXML components would be a lot easier if the framework runtime did an :ILogger.debug("instantiating component") when components were newed, and did an :ILogger.debug("dispatching preinitialize/initialize/creationComplete event") when "lifecycle" events are dispatched on components and logged when the lifecycle methods (createChildren(), commitProperties(), measure(), layoutChrome() and updateDisplayList()) are called by the framework run-time.

Additionally debugging complex data binding would be a lot easier if the mx:Binding component in particular logged each time it was triggered.

Figuring out the sequence of things is proving to be one of the hardest challenges of developing big applications in Flex 2.0.

Why don't more developers use Flex?

Matt Chotin today posted a message from Flex marketing team asking for input from the Flex community on Adobe's marking strategy for the Flash Platform and Flex in particular. I've posted these ideas in this post already both here on this blog and in replies to Ryan Stewart's excellent Universal Desktop column, but I've pulled them together here into one post.


The importance of a good developer network

I agree with Ryan Stewart's comments about the need to learn from Microsoft's (and Sun's to a lesser extent) excellent developer programs. I suspect one of the consequences of Adobe's technical "high-command" being so Java-oriented is that the guys in decision-making positions just don't know how effective MSDN is. For a small annual fee, MSDN subscribers receive every Microsoft product (including Enterprise Editions of Windows Server, SQL Server, BizTalk, betas of Communication Foundation, Presentation Foundation, the lot) through the mail. The weekly .NET Rocks! podcast is hugely popular with over 500,000 weekly downloads and some smart guests.

Adobe's Enterprise Developer Network is fine if you're using LiveCycle but not much good for anything else. If you're building a proof of concept in a corporation your Adobe Flex Builder 30-day trial runs out before you're done building the PoC, never mind selling the concept to the management.

Adobe distributes code for a bunch of kick-ass sample Flex applications to its world-wide sales teams but this code's not available to the community. Sort it out guys. Developers need kick-ass demos to convince internal budget holders to adopt Flex.

What is a development manager's biggest concern about adopting Flash?

Adobe need to realize the importance of getting the ubiquity of the Player message across to developers. If I had to name one "message" that I have found the most effective at getting Flash taken seriously as a development target for the presentation tier, it is the ubiquity of the Player. Adobe has a blind spot here as "designers" in the web industry know about this already BUT DEVELOPERS DON'T KNOW THAT THE PLAYER IS INSTALLED ON 98% OF DESKTOPS. Adobe needs to get this message across more effectively to developers. I give the ubiquity results pride of place in every proposal I make for the adoption of Flash as a platform for enterprise applications.

The importance of selling Flex to the Java community

With the advent of Web 2.0 and the improvements to Microsoft's desktop technologies, enterprise Java developers are feeling the squeeze on the desktop. Many corporations are already migrating their legacy Swing applications to Ajax and Windows Forms. Ajax will be OK as "lipstick" on the JSP "pig" for a while but, unless Java developers get their act together, Microsoft developers will wipe them out on the desktop. There's an obvious opportunity here for Flex to become the Java developer's defense against the Microsoft Presentation Foundation onslaught. The problem is that right now most Java developers don't know Flex exists, and when they do, have completely the wrong idea about what is it, and what it offers them. Understandably Java developers don't yet think of Adobe as a provider of development technologies. Adobe must address that key perception problem.

The importance of leveraging potential industry alliances

There's also a potential mutual co-operation opportunity for Adobe with big technology providers who have a vested interest in seeing Java continue its success. IBM, Sun, BEA spring immediately to mind. Adobe needs to sell those corporations on how Flex can help defend their market share in the new "rich" world. "Is there life after JSPs?" (There's a good title for a billboard.) Why not work with the Eclipse foundation to integrate Flex Builder with the Eclipse Web Tools Platform Project (included in Eclipse, Rational and also now in BEA WebLogic)?

The importance of not giving up on .NET developers

Adobe would be foolish to continue to ignore the .NET developer community. The .NET developer community is HUGE and growing, not least because it's a fantastic development environment and because it's free. It may surprise Adobe but there is insterest in Flex in the .NET community. When I posted my .NET tutorials on my blog it rose to being the 6th most visited Flex blog on Adobe's MXNA aggregator. I find the lack of .NET samples on flex.org completely astonishing. While it's true that many professional .NET developers will be using WPF on the desktop, .NET developers are not all idiots/mindless bigots, there will be many .NET developers who decide to adopt Apollo/Flex for the presentation tier (for lots of good reasons). Let's not concede defeat to WPF before we've started.

The importance of getting Ajax positioning right

Adobe needs to more marketing thinking about Flex' positioning against Ajax. While there are some functionality differentiators for Flex (and these are not well understood by developers), Flex' strongest differentiators against Ajax lie elsewhere. It's in the areas of scalability, performance, documentation and developer tooling where Flex is at it's strongest. That's where the messaging focus should be.

Internationalization

I agree with many of the comments in reply to Matt's original post about the need to make the Flex community appear to be more international. I was pleasently surprised that many of the visitors to my Flex.NET blog were based in Russia, India and Hong Kong. Has Adobe done any geographical analysis of the downloads of the Flex SDK?