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?

Microsoft endorses the Flash Platform

Check out Microsoft's pre-release of the latest version of their Internet Messenger software brought to you using the Adobe Flash Platform.

InfoWorld announces Flex is better

Flex 2 is out the door and the response from the press is positive. This article by InfoWorld says Flex 2 is better than the previous version, mainly because of the new pricing, according to InfoWorld.

Unfortunately the apparent indecision at Adobe Marketing about whether to position Flex against Ajax or as a technology complimentary to Ajax shows up in the articles that are appearing in the press.

Jeff Vroom's video interview on TheServerSide.com also conveys some pretty confusing messages to market about what Flex is all about. Is a Flex application browser-deployed? Not according to Jeff. Insensitive to the enthusiasm in the industry for loosely-coupled systems, Jeff positions Flex as a environment for building tightly-coupled applications.

Microsoft's anti-Adobe podcast

Anyone at Adobe who's unaware how effectively Microsoft get their anti-Adobe message across should take time to listen to last week's .NET Rocks! podcast about Virtual Server. The presenters get so emotional about the Adobe dispute that they have to bleep the transmission. Man, these guys are not happy. They're only warming up at start of the broadcast. Listen through to the end for the heavy stuff. I figure Adobe must be doing something right!

Flex 2 - What's in it for .NET developers?

There's a lot of buzz in the market about user interfaces and improving the user experience. With Microsoft recently announcing its intention to rebrand Windows Presentation Foundation (WPF) as .NET V3.0 and with Adobe's new licensing strategy for Flex, we're going to see a lot more IT budget being spent on improving the user experience in the near future and a lot of developers making technology choices in this area.

Flash Everywhere

Developers working on applications for use outside the corporate firewall will typically choose HTML today because the browser is one of the few run-time environments that's universally available on users' desktops. WPF will offer an alternative in the future but developers should not overlook the powerful run-time environment that's already present today on 98% of users' desktops, the Flash Player.


Unfortunately Flash suffers from a brand problem since it is associated in most developers' minds with banner ads on web sites and isn't something that springs to developers' minds when they think of real applications. The reality is that the Flash Player is a a very attractive choice for the presentation tier of n-tier enterprise applications, especially if the presentation tier of the application has to be made available outside the corporate firewall and may need to run on Windows and Mac. Flash integrates well with .NET servers so the combination of Flash and .NET for multi-tier applications means that developers can leverage the productivity benefits that .NET offers on the server while leveraging the ubiquity and power of the Flash Platform on customers' desktops.

Flash as a Smart Client

Adobe positions Flex as a platform for the development of rich internet applications or RIAs. Rich because Flex applications provide a richer user experience more akin to traditional Windows applications a and internet because a Flex application can be zero-touch deployed to a browser. Microsoft would call Flex a smart client technology.

The run-time environment of a Flex application is similar to a Windows.Forms application where the the UI components are bound to a data model modified by event handlers. Flex applications run in the browser but, like Ajax web applications, don't need to do postbacks to the web server to change their state. As a consequence UI developers with experience of developing in Windows.Forms (or Java Swing) applications will find the Flex programming environment much more familiar than traditional HTML-based web development.

The design-time environment, on the other hand, has more in common with ASP.NET, where the static layout of the interface is described declaratively using an XML-based markup language and the dynamic aspects of the interface are defined in event handlers written in code. In Flex the event handlers are written in ActionScript, which, despite its name, is not a scripting language but a compiled and strongly-typed, object-oriented programming language like C# and Java. Additioanlly many of the things that are hard work in Windows.Forms, such as data binding, are much easier to do in Flex.

So Flex combines the stateful run-time model of Windows.Forms, the declarative design-time model of ASP.NET and the zero-touch deployment model of traditional HTML web applications. Best of all, since Flex applications run in the Flash Player, the powerful drawing, video, visualization, animation and charting capabilities of Flash, previously only available to Flash animators, are now available to your application's presentation tier via the Flash class library.

Integration with .NET servers

Flex applications communicate with the server tier using either XML Web services (SOAP over HTML) or XML over HTTP. An optional server product called Flex Data Services (previously called Flex Enterprise Services) provides additional support for Adobe's own protocols (AMF and RTMP) that support pub-sub messaging, data push and remote access to server-side objects. Flex Data Services is currently only available for Java servers but there are commercially available and an open source implementations of Flash remoting for .NET servers. For many applications, XML Web services and XML over HTTP are more than sufficient and since .NET provides good server-side support for XML/HTTP and SOAP/HTTP, you can quickly build an server tier to support Flex applications in .NET.

A new Flash IDE

Before the advent of Flex, developing Flash applications meant using an IDE designed for animators and that was hard to learn. Over the years a number of open source IDEs have emerged that make the task of developing Flash application less complex. Nonetheless Flash is a skill-set that is still rarely found outside of the media industry. Flex Builder is the new IDE from Adobe that makes the task of developing a Flash-based presentation tier a snap for programmers more used to Eclipse and Visual Studio.

A new Flex licensing model

The first version of Flex required a server license which made it hard for developers outside large companies with big budgets to justify adopting the Flash Platform for application development. In Flex version 2 Adobe has has adopted a similar licensing model to the model used by Microsoft for .NET (and Sun for Java) with a freely downloadable and freely redistributable run-time environment and freely downloadable SDK. The new Flex licensing model means that Flex applications can now be deployed on a regular webservers like IIS.

If you want to start building Flex applications with .NET check out my tutorials.