//richinternet.blog

Viewing By Entry / Main
Friday, October 15, 2004
Advanced RIA engineering: applications that run in the Browser and in Central

One of the most overlooked things about Central 1.5 is probably the fact that it is fully ActionScript 2.0 compatible. Combined with some best-practice design patterns it's now pretty easy to expand a Central application's field of operation into the browser - and vice versa. In one of our latest projects we went just that way: we needed to build a client software that runs in the browser and in in Central. Both versions needed to share the basic appliaction logic but have to be specific in their concrete runtime environment.

So basically we needed an application that behaves differently in different environments (Browser, Central) but still they should provide common interfaces to work on. We ended up with a the following setup:

A FlashPaper version of the above diagram is available here.

The main application ConcretePortableApp implements a comon interface PortableApp to ensure that the needed methods are available to the Client (in this context the term 'Client' refers to the part the of software that acts as a single entry point, e.g. a UIObject instance that initializes the rest of the application). The main application also defines the default behaviour of the application.

The main application is extended by two subclasses, CentralApp and BrowserApp. Both overwrite or extend the default behaviour according to their needs. For example, CentralApp also implements the mx.central.Central interface and initializes the Central environment during startup. Because both subclasses extend ConcretePortableApp they are also of type PortableApp. This means if we create instances of the sublcasses both will be compatible with our common interface.

This finally leads to the AppFactory class. The AppFactory uses logic to determine which class to instantiate according to the current runtime environment and returns an object of type PortableApp to the Client (again this is possible because of the implemented interface). That way the Client does not need to know in which runtime environment the application is running and can happily work with it.

I hope you found this article interesting - and if you have any comments or questions please do ask!

Dirk.

Comments

So, in fact, it's a short of abstract factory, isn't it?.

It's a god example of how a good structure can make our code much easier to maintain


Yes - it's an abstract factory that hides all the implementation details.

Dirk.


This is a great article, Dirk. There should no longer be any doubt that design patterns are a huge boon to ActionScript developers. By using the proper patterns from the start, you make it much easier to extend your apps to the desktop and easily leverage whatever extra functionality is exposed there.


Great example, I mean, that flex has a good model to fit on central enviroment, as well I tought Macromedia had tought too when they were developing the new central 1.5 to fit on flex app.




Sun Mon Tue Wed Thu Fri Sat
   1234
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

About this blog
www.aws-blog.de
www.richinternet.de
www.flexforum.de
www.die-flexperten.de

AIR (10)
Apollo (3)
BlazeDS (8)
Breeze (1)
Central (5)
Cocoon P2P (1)
ColdFusion (55)
Flash (61)
Flash Media Server (8)
Flex (170)
Flex Trace Panel (6)
FXUG (3)
J2Flex (4)
MAX (31)
Mobile (1)
mxmlc (1)
Other topics (47)
Plugins (9)
Video (7)


Recent Flex Technotes
Recent ColdFusion Technotes
Recent Flash Technotes

http://www.aws-blog.de
http://www.die-flexperten.de
http://www.flexforum.de
http://www.flex.org

Aggregated by fullasagoog.com
Aggregated by MXNA

Short Mode | Full Mode

Herrlich & Ramuschkat