Google code sign-up info

Join the Identity Modeller project at Google Code here.

I've also resolved the single-core / multi-core puzzle I think.  A multi-core version of PureMVC is going to be appropriate for a modules based application whether the app has one or many project windows.

Each module can run its own mini-version of the PureMVC framework.

The recommended strategy for modular PureMVC - presenting an interface to the module - is the only option available within the AIR security model anyway, so the multiCore AS3 port of PureMVC looks like a perfect fit.

I'm hoping that we can develop some of our functionality as PureMVC plug-ins.  For example - stuff around history / undo / redo across different modules is going to be a fairly generic solution. The saving of application state (something I love love love about Coda) so that when you start up next time it's just as you left it is also a framework solution that might be of use to other PureMVC users.

I've been thinking about the roadmap and time frame. A couple of people who have expressed interest in being involved are just hitting an intense period of exams and thesis submissions for the next month or so. I think that's potentially a good thing - I believe it takes a while for an idea as complex as this to settle and emerge. My objective then is to remain in planning until the end of June, and work towards a more and more precise definition of the project in that time.

Work begins in earnest at the beginning of July. I'd very much like to get to Alpha in October / November and release the first Beta in time for christmas. Wouldn't that be nice?

PureMVC, and the MDI / TDI quandry.

CarnageBlood recommended I check out PureMVC as a framework, and I'm really grateful for the suggestion because it looks excellent.

I have no doubt that using PureMVC is a good move - it's opensource and we can develop any generically useful extensions as plug ins that will be useful to other PureMVC users.  

The big question I have is single-core or multi-core?  How do these relate to interface possibilities?

My favourite applications appear to be a hybrid of TDI and MDI.  Coda is an amazing one-window-web-development tool that has tabbed browsing of files open in each window - one window referring to a 'site'.  Having multiple windows open means I can entirely separate my work by project / client / server.  I love it.  Each window has its own interface - file browser, search tool, activity etc.  A couple of windows - such as 'clips' - a code snippets tool - are shared across the app as floating panels.

Omnigraffle 5 works in a very similar way. Lots of the interface is wrapped directly around the document, but formatting panels etc are floating shared windows.

I've done plenty of standard MVC development but never a multi-core app.  I'm not even sure that what I'm describing is truely multicore?  Whilst there would be many models, views and controllers, the actual basis of the application is perhaps still a single core?

More reading to be done - and possibly the best way forward is to plan version 1 as single window (apart from interface floaters) tabbed documents style, with the multiple project windows version as a major update.

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.)