MXML-G - An XML abstraction of the Flash Player drawing API (and then some)

February 26, 2008

In Deepa’s talk @ 360 in Atlanta she also goes over MXML-G… which is really just a beautiful abstraction of Flash’s drawing API using XML.

It’s very cool. Very handy for rapid prototyping and skinning.

Thermo is essentially an eclipse plugin that heavily leverages MXML - G.

Update: I talked to Deepa… she mentioned that it actually includes “more” than the drawing API currently offers…


Flex for Mobile Announced @ 360Flex in Atlanta

February 26, 2008

This is a awesome news… !!

Today at 360 Flex Deepa Subramaniam announced that Adobe is working on a mobile version of Flex.  They are taking into account the ramifications of creating a mobile framework for Flex 4.  This does not mean that it will be released at the same time as Flex 4 but they are accounting for it in the planning as they are for Thermo which is scheduled to be released on the same timeline as the Flex 4 release.

The items that Deepa said they were going to implement were…

  •  Eclipse based
  • ActionScript MXML / AS3 Editor
  • Debugger
  • Profiler
  • Support for lower memory devices as well as higher memory devices

This is HUGE news for Flex developers to be able to create applications for Mobile Devices….

Next is AIR for Mobile??


Flex Builder source code derived from Eclipse is available.

December 11, 2007

So I know this has been blogged about before… but I feel like it’s a relatively obscure little gem in the Flex/Flash world so I thought I’d throw it up on the wall again with the hope that it might give other people the desire to create useful Flex/Flash/AIR plug-ins.

One of the readers of my last post on my Flex Builder 4 wishlist commented that Flex Builder shouldn’t be built on Eclipse and Adobe should open it up to other vendors such as JetBrains (of IntelliJ/ReSharper fame). While I am a huge fan of ReSharper and IntelliJ… I believe the reasons for having the Flex Builder code base built on the Eclipse platform far outweigh the benefits of having it be built as an IDEA plugin.

The largest reason being that the Eclipse core is open source and according to the EPL any code derived from the Eclipse source must also be open source. This means the core of Flex Builder… the Eclipse code that was derived for Flex Builder… which includes editor code, debugger code, workbench code… must also be open source.

You can find the Flex Builder 2 source based on Eclipse 3.1.2 here: http://www.adobe.com/go/4b243413

Aside:

The flexibility of the Eclipse platform to adapt itself as development tasks evolve will be a cornerstone to it’s usefulness as an IDE and will act as a catalyst to propel the evolution of Adobe’s Flash/Flex/AIR tooling. Evidence of this can be found in an excellent plugin built by Stephen (Spike) Milligan (main contributor to the CFEclipse plugin) at http://www.yellowbadger.com/ which was targeted at the Flex 1.x/AS2 framework and built on the Eclipse platform. I had discovered and was using this plugin a full year before the Zorn (Flex Builder 2) release had been rumored. I was also using Eclipse for all my Java development at IBM and lately… I’ve been using it to teach myself Ruby. Having one editor with multiple perspectives for doing radically different development projects is my dream come true. Eclipse is not without it’s fault’s and does have some shortcomings (It can be a memory pig with a capital P1GB). But ram is cheap… Who doesn’t run 2 gigs?


Flex Builder 4 Feature Wish List

December 10, 2007

The Flex Builder IDE is something I use for hours on end every day. Having used other IDE’s (Eclipse, IntelliJ, and VisualStudio) for various languages such as Java, C# as well as ActionScript… if Flex Builder was able to simply duplicate some of the features of these IDE’s and plug-ins then it could significantly increase developer productivity. Since the JetBrains (maker of IntelliJ) Resharper suite of extensions is the most intelligent list of IDE productivity enhancements… I’ll make use of it here to explain my wish list.

1. Code Templates : http://www.jetbrains.com/resharper/features/code_templates.html

2. Quick Fixes : http://www.jetbrains.com/resharper/features/code_analysis.html#Quick-Fixes

3. Better refactoring support : http://www.jetbrains.com/resharper/features/code_refactoring.html

4. Better Navigation : http://www.jetbrains.com/resharper/features/code_templates.html

5. Clickable stack traces in the console

6. Better Code Selection : http://www.jetbrains.com/resharper/features/coding_assistance.html#Extend/Shrink_Selection_full

7. Unit Testing Tool Support : http://www.jetbrains.com/resharper/features/unit_testing.html

8. Unit Test Code Coverage Tool: Alex Uhlman is developing one (Adobe Consulting)

9. TODO/FIXME Plugin: http://www.jetbrains.com/resharper/features/navigation_search.html#ToDo_List_full

a. One was written by Dirk Eismann (used to work on the FB team @ Adobe) you can find it here: http://www.richinternet.de/blog/index.cfm?entry=06D9E73F-BF55-CE91-017BD895EBAAD5CB

10.Integrated support for WebORB’s data services (.NET, Ruby, PHP, Java)

11.Edit and Continue.. almost forgot :)

12.And then all of the above… for JavaScript editing for AIR apps.


## “WE” Can Help Deliver Flex 3 ##

June 10, 2007

OK people… The Flex team has been busting it for us for 3 years… Let’s see if we can lend a hand and help them get it released to GA before MAX. :)

Flex 3 is an open source project and anyone can contribute to it. This is such an enormous plus for Flex I wanted to make sure everyone remembered.

Currently it’s limited to submitting code on a bug report but they have said they will open the repo to commits in the future.

Read this first: https://bugs.adobe.com/confluence/display/ADOBE/Home

Adobe has opened the bugbase here: http://bugs.adobe.com/flex/

Roadmap (What to help with): https://bugs.adobe.com/confluence/display/ADOBE/Flex+3+Planning

Submitting code in a bugreport:

When submitting source code with your bug reports please keep the following in mind:

  1. Your source code should compile and run. Of course if you’re demonstrating a compiler error it doesn’t need to compile. But to demonstrate a runtime bug your code should execute at least to the point of failure. The less time an evaluator needs to spend creating the proper scenario the more likely it is to receive attention.
  2. Smaller is always better. The less code you need to submit to demonstrate a bug the easier it will be for a developer to evaluate the issue.
  3. If you need to submit a whole project attach a single zip instead of multiple files. Once again, reduce the project as much as possible so that only relevant code is included.
  4. All users of the bug system can view your code, do not attach confidential source code to a bug.

Personally… if I get one line of code in the Flex 3 final release… that I can say I wrote… It would be like … a piece of the world to call my own.

I’ve been working with Flex non-stop since it was in beta in Feb 04′. I’ve written ActionScript for Fortune 50’s in Boston, NYC, Jersey, Oakland, Michigan and San Jose. I co-founded a company that was based on Flex consulting services. I haven’t had a home for the past 2 years. I’ve been roaming the U.S. building Flex applications. I’m helping to write a book on Flex 3 and AIR for Wrox press. I’ve met the Flex team. (Matt Chotin is really that nice and Deepa really is that cute.)

Flex has been my world.

To watch the technology grow… the process grow… how quickly it’s matured into a powerhouse web technology… has been a rocket ride. To be able to give back to the technology that’s basically transformed my life… Sign me up.