Whenever I write a class, I typically write a usage example prior to writing the class itself. I want to understand what the class will be like to work with, its behavior/interface in development. With OOP it is so easy to hop right into building class after class but actually seeing usage really helps me get the interface right and makes development much easier. On Thursday, before writing the class version of f.net.Load, I showed Doug Winnie how this might work as an example. He notices I hadn’t written the classes yet and that it would be a great feature to actually generate classes from usage. hmmmm…

So this idea of “Usage Modelling” has been stuck in my head for a few days. How could I write usage examples with modelling classes and generate classes the support this behavior? Instead of UML or modelling could one use usage examples to generate classes? It wouldn’t generate the logic within methods but would generate a very solid start to a set of classes. Basically writing code to generate better code.

This is possible with flash.utils.Proxy where you can catch all interface interaction on a class and simply send class text to the output panel. Based on the type passed in methods or get/set behavior you can type the class properties dynamically, setting a string would type a property as a string. Here is some some “Usage Modelling” usage:

import f.model.UsageModel;

UsageModel.start();

//model the events Class
LoadEvent:* = UsageModel.create( ‘f.event.LoadEvent’ , flash.event.Event );

//consts in caps
LoadEvent.OPEN = ‘f.events.LoadEvent.OPEN’;
LoadEvent.CLOSE = ‘f.events.LoadEvent.CLOSE’;
LoadEvent.PROGRESS = ‘f.events.LoadEvent.PROGRESS’;
LoadEvent.SUCCESS = ‘f.events.LoadEvent.SUCCESS’;
LoadEvent.FAIL = ‘f.events.LoadEvent.FAIL’;
LoadEvent.INIT = ‘f.events.LoadEvent.INIT’;

//instance use
var loadevent:* = new LoadEvent( LoadEvent.FAIL );
loadevent.data = {};
loadevent.loader = {};
loadevent.percent = 0.75;
loadevent.bytesLoaded = 34;
loadevent.bytesTotal = 56;
loadevent.bytesAvailable = 56;
loadevent.error = ‘woops’;
loadevent.status = ‘status 23′;

//denote start of Class
Load:* = UsageModel.create( ‘f.net.Load’ , flash.events.EventDispatcher );

//define class data
Load._Public = true;

//static use
Load.AMF = “f.net.Load.AMF”;
Load.amf( LoadModel.AMF , “http://onflex.org/f/Load/test.amf” , function(){} );

//instance use
var load:* = new Load();
load.url = “http://onflex.org/f/Load/test.amf”;
load.parameters = { method:’post’, data:{ a:12345 }};
load.resultFormat = Load.AMF;
load.addEventListener( LoadEvent.SUCCESS , loadSuccess );
load.addEventListener( LoadEvent.PROGRESS , loadProgress );
load.addEventListener( LoadEvent.FAIL , loadFail );
load.addEventListener( LoadEvent.OPEN , loadFail );
load.addEventListener( LoadEvent.CLOSE , loadFail );
load.load();

UsageModel.print();

And no I haven’t written any classes yet, the irony.

Cheers,

Ted

This morning I uploaded build 33 of FDOT with many changes including f.net.Load instance support. The library simplifies the loading of all types of data from text to binary to swf and images. Also during this release I learned Git and posted all code to GitHub. Also included is a simple app that tests all funtionality and provides some great examples to help you get started. You can find the test apps in f.tests.*, enjoy. Here are the changes:

Download at GitHub

– Added instance support f.new.Load! new Load();
– Added simplified event types FAIL,PROGRESS,SUCCESS,OPEN,CLOSE,INIT (Thanks Ben Garney!)
– Added f.event.LoadEvent for typed events
– Added XMLDocument support in f.Load.xmldoc
– Added loadResult constants to Load
– Moved loadError constants to LoadError
– Renamed f.Load.xml to f.Load.e4x
– Added FDOT_Tests to run all tests
– Added f.tests to hold all test examples for instance and static use

Next in f.net.Load adding caching, queueing in build (34). Then adding more types, CSV, YAML, AMF, Serialized. (35)

Cheers,
Ted

Today I posted build 32 for public download of Project FDOT( f.* ). FDOT is a collection of ActionScript 3 classes that make hard things easier.

DOWNLOAD FDOT_BUILD_32

The first release includes 3 classes:

f.net.Load – Load text to binary with one method call and one callback.
f.net.Message – Simple callback messaging for classes.
f.data.ObjectStore – Simple object database for storing anything.
(Includes an awesome JSON lib by Darron Schall via as3corelib )

The first thing that you will notice in FDOT is a sharp departure from OOP and addEventListener in preference for simpler method calls and the use of callbacks. I have long felt that addEventListener is overkill and with the addition of method closures, callbacks are a very underrated technique. Loading external data in Flash Player used to be drop dead easy, like no think easy. Today it isn’t, it typically requires you to subscribe to 5 events create 5 methods all typed to catch different events and even then knowing what to do when things happen leaves many frustated. Why was this so easy before? Why do we need to do all this work just to load data or swf files?

The thing is that having great low level networking classes is great but we need to build simpler code upon these. That is the intent behind f.net.Load. Simplify the loading of all types of data into Flash Player. Make it clean, orthogonal, and easy to use. Here are some samples:

//note that all Load methods have the exact interface!
Load.text( url:String , callback:Function , params:Object=null );

//text
//load text via post using this.load method as callback
Load.text( ‘test.txt’ , load , { method:’post’, data:{ a:1 } } );

//json
Load.json( ‘test.json’ , load , { method:’post’, data:{ a:1 } } );

//xml
Load.xml( ‘test.xml’ , load , { method:’post’, data:{ a:1 } } );

see a trend yet?

//querystring
Load.querystring( ‘test.qs’ , load , { method:’post’, data:{ a:1 } } );

//stream
Load.stream( ‘test.png’ , load , { method:’post’, data:{ a:1 } } );

//image
Load.image( ‘test.png’ , load , { method:’post’, data:{ a:1 } } );

//swf
Load.swf( ‘test.swf’ , load , { method:’post’, data:{ a:1 } } );

//binary
Load.binary( ‘test.png’ , load , { method:’post’, data:{ a:1 } } );

The best part is that you need only one method to handle all callbacks. Here is how it works. Simply define a method with a single Object as its parameter, your done. Based on the ‘type’ property within the object passed in the callback you get different data. Some callbacks are for Load.PROGRESS, Load.OPEN, Load.HTTPSTATUS and you can use these constants to filter like so:

public function load( event:Object ):void
{
    if( event.type == Load.COMPLETE ){
        trace( ‘ < loadMovie COMPLETE: ' + event.data );
    }else if( event.type == Load.PROGRESS ){
        trace( ‘ < loadMovie PROGRESS: ' + event.percent );
    }
}

When Load.COMPLETE is passed, you get event.data, and when Load.PROGRESS, you get event.percent, event.bytesLoaded, etc within the passed object. I have been thinking about making a single callback Event type to make this easier still but that is for a future version.

In the build there are samples of every feature of the FDOT library. I am working to add in ASDOC comments and get the initial documentation generated too along with some late breaking additions of Load.amf, Load.csv, and Load.yaml, pending massive disruptions. Also planning to expand the features within the parameters argument to support PRAGMA headers, Caching support via ObjectStore, and a server side proxy to allow for full REST support ( I might need some CF/PHP/JAVA help there).

I would ask that if you find any bugs, email me at ted@adobe.com. Plans are underfoot to move this under GITHUB later today but some networking is holding me back, ugggh.

The goal here is to make hard stuff simpler so you can spend your time making awesome complex stuff. Loading has been a huge barrier for Flash Player since ActionScript 3 arrived and I would hope this helps a bit. Long story short simplicity and ease of use are driving all API decisions on FDOT, and if you see a simpler path, I am all ears.

DOWNLOAD FDOT_BUILD_32

It has been a blast working on FDOT and it is great to set it free as open source under a BSD License. Use it as you wish and send me feedback on what to do next.

Cheers,

Ted

My blog at onflex.org and onflash.org gets a ton of comment spam. Depending on the day I get upwards of 100 spam comments on my blog daily. I filter comments on my blog to remove the spam and publish all comments posted. As many know, I am fairly open to feedback and am very open to hearing alternative points of view even ones of violent disagreement. I thus have not and do not filter based on opinions expressed. Simple as that.

The ethical line here is very important to me and to see that questioned today is disturbing. For the many that know me, this is something that I would never do and a line I would never cross. To be accused of wrongdoing seems amiss. Worse is that after publishing a comment to this blog post, it has not been published by the blog owner.(NEW: Comment has now been published)

So long story short, if you want a comment posted, post one.

Regards,

Ted

Since writing “The future of the Flash Platform” there has been a ton of new discussion on Flash and ActionScript, which is really awesome to see. One frustration expressed was that new/unknown developers feel left out of the dialog and are seemingly overlooked within the community. There is a secret to getting noticed in the Flash community and it starts with sharing code.

In every single case, without exception, the thought leadership within the Flash/Flex community rests with those that share code openly. It isn’t some elitist club, but rather those that share gain influence and respect with the community. When you share code you get lots in return. The quality of the software you write gets better, you learn new things from others, you begin to meet others within the community, new opportunities find you based on your contribution, and most importantly, you gain respect for your contribution. Even if your code isn’t the best, mine isn’t, sharing will help you improve and it will help someone learn something new.

In many companies, sharing code is prohibited. Talk to your boss and ask if you can share generic examples without company specific information. Make her realize that sharing will enhance the quality of your code internally and help you become a better developer. Either that or share enough code on off hours and you will find yourself a better job.

So if you want to be the next Keith Peters, Grant Skinner, Joshua Davis, or if you just want a better job or influence within the platform, share some code. It will change your career, it changed mine.

Cheers,

Ted

One issue that has always troubled me is that within class based apps communication between class instances isn’t simple. I want a simple system, where you can send a single message to a named instance or broadcast a message to all listeners. Also within the message I want to send an object allowing data to be routed around the application. Today I wrote a class called Tubes that does just that.

com.diverted.messaging.Tubes

Lets take a look:

//import the class
import com.diverted.messaging.Tubes;

//to start receiving messages, simply add a name and a method
Tubes.add( “root” , this.tube );

//send an object to all receivers
Tubes.send( { type:”paymentRecieved” , amount:34.52 } );

//send an object to particular instance
Tubes.sendTo( “accountant” , { type:”paymentRecieved” , amount:34.52 } );

//to stop receiving messages
Tubes.remove( “root” );

I like the simplicity of Tubes because once you import the class, you can message within the application easily. The method passed into Tubes.add is called with a single object argument so you can structure the object as needed.

Cheers,

Ted

Having been involved in the Flash Platform for many years, I have witnessed future releases being defined both inside and outside Adobe. If there is one truth, customers(designers/developers paying or not) influence everything Adobe does. Teams internally pay extremely close attention to our developer/designer/project innovation and stay constantly tuned into where innovation (your work) is headed and what problems you are having. Instead of blazing headlights(new ground) or chasing taillights(follow the leader), Adobe (and Macromedia before) is focused on real customer need.

So how does the future get defined?
This is where YOU get involved!

Truth is you are building the future today and when you are vocal about your needs, Adobe teams listen. Adobe doesn’t build the product we want to build, rather we build tools and technologies to help you exceed expectations in the market. No joke. To get involved in defining the future of Flash Player, Flash, AIR, Creative Suite, Coldfusion, (NAME THAT PRODUCT HERE), you need only get public with your needs. File Enhancements, File Bugs, Blog, twitter, and lobby for your features/needs. And like clockwork you will influence the platform and its direction.

Take a look at the following (small set of example):

In May of 2003, I was very angry at MovieClips
In Nov 2004, I then started complaining about lack of a Proxy class in Flash
In March 2008, Andre Michelle decided to make some noise. Now he wants threads, awesome!
In April 2008, Grant uncovered a bug, it was fixed in next player release.

Some campaigns of note defining the future:
In May 2009, Grant got fed up with idle CPU use.
In Feb 2009, many want private constructors in AS3!
in March2009, Chuck Freedman had enough and wants Microphone!

In every case above, work has been done to fix these and make Flash a better platform. Many times key external developers work directly with engineering to get these problems identified and solved. The thing is we are just not public about it. The road to getting things fixed is a windy road balanced by priority and limited by time and resources, that aside, the teams listen if you get vocal and if you file enhancements. But only IF YOU DO…

So this is my official call for you to step up get involved. Get vocal and define the future! I can tell you firsthand that it works every time. The future of Flash Platform is defined by you, not in some conference room in some Adobe office.

WARNING: If you complain too much and log enough bugs, you might find yourself working here too.

Cheers,

Ted