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.)
No comments:
Post a Comment