Combining MVC with the AIR sandbox

Identity seems to be an ideal candidate for the Model-View-Controller design pattern.

I recently converted a large application into an Air app and had to grapple with the differences in how loaded content can access the loader Air file.

There are lengthy and comprehensive white-papers available from Adobe, and they do explain the new model very comprehensively, but I feel quite strongly that the 'What's new in AIR?' overview stuff for flash developers should have had the following simple point:

In order for a loaded swf to be able to communicate with the parent AIR file you must create an API class with public functions within the AIR application and assign this to the loaded swf as a bridge.  The only data which can pass between the parent AIR file and the loaded swf is simple type data : Number, String, Boolean. You cannot pass complex typed data between a loaded swf and a parent AIR file.

The implementation of this into our application was initially a bit painful.  The application is a training environment.  The main AIR app loads external swfs of individual lessons and quizzes. The app GUI has all the interface and the loaded swfs basically only contain a timeline with a voice over and animations and a small amount of functionality.  There is quite a lot of communication between the two however - with the loaded swf prompting the GUI to update all sorts of things - messages on screen, navigation state, icons indicating the availability of other resources.

We had previously achieved a lot of decoupling by using events.  In the new model it was no longer possible for a typed object, such as an event, to pass between the swf and the AIR app. Of course it took a whole bunch of testing and digging through various white-papers to realise that this was the issue ... but we got there in the end.

The result is an even more cleanly decoupled app, with less requirement for the animators to put code into their lessons, and the AIR app is at far less risk of being broken by anything they do.  At the moment there is a small loss in compile-time error checking, though I suppose we could define constants within the local lesson to get back what we had with the events.

So - I am thinking about what the AIR security sandbox will mean for Identity.

It makes sense to have a number of the core functions held in separately compiled swfs, so that they can be extended / swapped easily.  This also gives a lot of protection to the core application as it means that only expected data can pass through.  We can check and place limits on this data before it is used within the app.  Lovely.

For example - the ECMAScript-based parser should be able to handle AS2, AS3, AS4 and probably PHP5 and 6, but I haven't a clue what other languages people might find this useful for.  The logic for creating / stripping an AS3 file is quite clear to me - you need a file that defines how a class is built and then you do some regexy things and some iteration through the properties and functions.  How universal that logic is I don't know.  How much customisation you can do without editing the parser, I don't know.  How much benefit coders might get out of editing the parser to suit a specific need, I don't know.  So - if the parser is an externally loaded swf then you can select a parser to use and introduce a layer of flexibility.  You can even build your own.  People can experiment easily with their parser and make public 'improved' ones maybe.  

[I'd love to see a parser that simultaneously builds your asDoc html, for example ... not sure how this would be possible right now, but it doesn't feel completely unrealistic, if the parser simply called file writing functionality within the API].

You can assign a specific API to each loaded swf, but you can only assign one.  So, that API needs to deal with all relevant aspects of Model, View and Controller in one class, though of course it's just a gateway through which simple-typed data passes.

Application-sandbox loaded components do have a lot more potential for interaction with the parent AIR app, but I think the outside-the-app model offers a much more secure and controlled environment for plug-ins, so this seems like the best route.  Identifying the kinds of functionality each of the plug-in API classes needs to have is a pretty big task in itself ... doing the planning for this project is making me more certain that I need this piece of software though!

(For mac users, if you don't already have it then you should check out Omnigraffle Pro 5 - the best piece of software I've ever used just got a whole load better.)

Project language spaces & class interchange

I'm definitely hooked on the idea of being able to model once and export stub code in multiple languages.

The potential benefits in terms of providing shared 'Class swatches' are pretty attractive.  

So far what I'm imagining is that when you start a new project you select a language space for that project.  You would then be able to drag previously defined classes from a classes swatch thingy (best to be specific about the lack of definition here!) into that project - and the app would translate unsupported types according to the type mapping spec for that language. Swatch classes would only be able to be edited within the language space they were defined in - so you couldn't start adding MovieClip types to a class which you've created in ECMAScript.

You would also be able to create a new class 'based on' an existing class in your class swatches - this would import the class types into your project language and allow editing within that language.

Making sense?

Introducing identity modeller

Dauntless pointed out on email that I can't keep calling it "Air UML tool thing" ... and I thought coming up with a half-decent name would take ages, but here I am already, introducing Identity modeller.  Whadya think?

I wanted it to convey the fact that the code and the model are intended to stay in step with each other ... and 'congruent' isn't exactly catchy.

Plus, like all good math-geeks, I'm a long term fan of Euler. Couldn't resist ... sorry!

Air UML Tool : File formats and more on typing

I've been trying to wrap my head around the xmi specification for describing UML models using xml.  The purpose of the spec is obviously to allow models to be imported / exported and switched between different UML tools.

It has given me a focus for the core functionality of the application - to be able to read and write both xmi models and language specific class files.  The application would then also have the ability to write extended xmi files, containing the compliant xmi model stuff but also the project data relating to everything else - non uml stuff to do with getter/setters, positioning, etc etc. 

The language specific element will be provided by external xml configs - one to describe how a class file is structured, and one to map generic types to language specific types.

I've been having a bit of useful exchange with Dauntless on the types issue.  The thinking I have at the moment is that some classes are clearly language specific - anything using or extending MovieClip for example is only useful in Actionscript - whilst other classes might be much more generic, in which case it would be nice to be able to move them across different language projects.  I have a few utility type classes which I use in both AS3 and php5.  

The most basic type set is that provided by UML itself: boolean, integer, float and string.

Then there is the set provided by ECMAScript 4 - discussed in the previous post.

As Dauntless pointed out, Java has useful stuff like Enum. 

I think I've almost reached a clear enough understanding of the multiple-languages issues to be able to post more detail of that tomorrow.

As always - the more the merrier - please chip in if you're interested in contributing.

Meantime - if anyone can think of a good name for this baby ... Dauntless has rightly pointed out that AIR UML Tool is getting a bit dull ...!

AIR UML tool : Working with types across different languages

One of the most obvious changes when switching between AS2 and AS3 is the difference in built-in types.

I'm talking Number vs int / uint. Void vs void.

From time to time I plan something that I want to execute in more than one language - in php5 or Actionscript 3 ... I've been fortunate to be able to leave AS2 behind but I know a lot of people are working on legacy projects.

With Colin Moock already talking about Actionscript 4, the focus for future-proofing seems to be on ECMAScript 4.

The release data for the new spec isn't til December 2008, but I'm guessing the end of the year will be upon us in no time.

Reading through the ECMAScript 4 Overview, it's struck me that building with this spec in mind will force us to include the kind of flexibility that will make it easier to extend this app to other languages.

For example - some of the Number types proposed - byte, int, uint, double and decimal - may not make it into the final spec, and we may continue to have the current AS3 set: int, uint and Number.

If each language contains a type mapping spec for the core types then AS3 can map byte, double and decimal to Number, and if AS4 supports them then they can be supported.

eg:

translations/as2/typeMapping.xml :

<typeMapping>
<type_byte>Number</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

translations/as3/typeMapping.xml :

<typeMapping>
<type_byte>uint</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>Number</type_double>
<type_decimal>Number</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

translations/as4/typeMapping.xml :

<typeMapping>
<type_byte>byte</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>

So far, the types I can identify in the ECMAScript 4 list are:

null, undefined, void

Object

Number, byte, int, uint, double, decimal

Boolean, boolean

String, string

Array

Vector (a strictly typed array?)

Function

Map (binary relations)

Date

RegExp

Name, Namespace, NamespaceSet, NamespaceSetList

Error, EncodingError, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, UndefinedError, URIError

AnyString = (string,String)
AnyBoolean = (boolean,Boolean)
AnyNumber = (byte,int,uint,double,decimal,Number)
FloatNumber = (double,decimal)

XML, XMLList, AttributeName, AnyName

IterableType, IteratorType

I've also spotted a few more in the documentation - FieldIterator and ControlInspector perhaps?

Either way - this strategy allows us to be highly specific in our documentation, and then water that precision down for each language. Of course, coming back the other way it's trickier. Do we want reverse engineering to simply pick the most generic type, or do we need a special comment that can specify how types are backward translated? Something like ... (for AS3)

// *strictType:decimal //
public var salary:Number;

Obviously the app also needs to support types from your own library.

Something else I've noticed is the support for ! ? notation to specify that an object can / can't be null. Eg

// "!" indicates that v can't be assigned null
var v : MyType!

// "?" indicates that v can be assigned null
var v : MyType?

// "!" indicates that this whole class is non-nullable
class MyClass! { ...

The idea is that this will allow earlier detection of null-pointer errors - ideally at compile-time rather than run-time. That would make me very very happy!

----

It's a pain that ECMAScript 4 is still six and a bit months from completion, but I think the rigour that having to build for an almost-complete standard gives us is probably a good thing.

AIR UML Tool : Defining the UML scope

UML 2.0 is pretty vast.

This is an attempt to summarise the parts of the UML that need to be available within the tool. My current thinking is that different languages will have an xml spec file that maps these UML Language elements to the translated element for that language.  We should begin with AS3 as a primary goal, but ensure we support parts of the UML which aren't yet available to actionscript but might be included in PHP6 or AS4.

For example - AS3 doesn't support 'private' or 'protected' on a constructor, so the AS3 xml config might map it to 'public' in this case.  AS3 also doesn't support 'abstract', so that would be skipped when constructing the stub AS3 code.  

The list below is probably incomplete but it's a really good place to begin.  Strict UML terms are given in (brackets).

Stuff

• package
  
• class
  
• interface
  
• property
  
• function (operation)
  

Visibility

• public
  
• protected
  
• private
  
• internal (package)
  

Scope / implementation modifiers

• static
  
• abstract (unsupported in AS3 but we can hope and at least add to comments)
  
• const (readOnly)
  
• binds
  
• dynamic (not sure this has a strict UML equivalent?)
• overrides [thanks dauntless]
• final [thanks dauntless]

Class relationships

• extends  (generalizes)
  
• implements (realizes)

Any glaring errors?  If you're out there following this and it makes sense to you please do speak up, encouragement, questions, interrogation and the pointing out of obvious fundamental flaws are all appreciated.

[edit]: Dauntless has also mentioned composition, which is definitely required within the laying out of diagrams / relationships, but doesn't really map to an AS3 file other than by declaring a property of that type - or am I missing something?  

We'll also need to represent the Aggregation / one-to-many : many-to-many : many-to-one type relationships as well, and also event listener lollipop etc, but again I don't think they map into the final exported AS3 files.

Dauntless also brought up the issue of types - something I've been thinking a lot about and hope to post some ideas for a strategy later today.

AIR UML tool : A clearer concept

To save any confusion - this is just a graphic, a jpg exported from a flash file which has absolutely no functionality and is purely intended to help rough out an interface concept.

I started thinking in more depth about what I personally needed this tool to be able to do, given that I'm pretty happy with my current working strategy but it just feels like there's a fair bit of friction in the system in terms of duplicating work.

So, I went right back to basics - my current process, which I'm sure is not unique, is to use index file cards for a fair bit of my modeling.  On one side I scribble the CRC stuff (Class Responsibilities and Collaborations).  On the other I outline the most important public properties and functions.

At a later stage I do a more formal UML diagram in Omnigraffle, using the UML-General template.  Then, once I'm satisfied that it's close enough to what I'll finally need, I create skeleton AS3 classes in Flash or Flex, and then write in skeleton asDoc comments ... both of which are rather tedious.

Inevitably the coding process throws up unforeseen stuff and functions, structure or even the whole model can be subject to changes.  Unless I am feeling particularly disciplined, many of these changes go mostly undocumented, usually only being written up if the code is then applied to a new project or handed over to a new developer.

I no longer work as part of a large team of developers, so I've only my own experience to call upon, but if there's one thing I've learned in my time as an engineer (in both the physical and the software world) it is to begin by making a product that a single concrete person needs, and not a product that doesn't actually satisfactorily meet the needs of any of a whole bunch of abstract people :)

Where I've landed is that this tool should be like a digital version of my index file card box, which integrates my workflow all the way through from creating CRCs to assembling them into a project, to defining public interfaces on the flip side, to drawing that up in a UML sketching tool, to defining private functionality, to adding comments to explain usage, to generating AS3 skeleton functions with asDoc compatible comments and getter / setter functions where desired ... it has to take care of that whole shebang.

That process has to be 2 way, preferably with 'intelligent' (the magic word for 'haven't defined the rules for this yet') syncing.

Returning to my dodgy graphic at the top - I'm no designer, so will be looking to get some major input on that side - the concept is that you have a bunch of index cards on screen, you click the little arrow in the top right corner to flip 'em round.  They expand and contract to give enough space for the properties / functions.  All the standard spec of UML 2 is available to you and they also have a neat interface (represented by the G S on the right of the properties) for requesting that Getter / Setter functions be created for those properties. 

I'm sure there will be other, sexier, less geeky skins that people want to add later but this one seems like a great one to kick off with because it focusses the mind on what we're trying to do - take the friction out of a tried-and-tested way of working, not revolutionise the whole process!