<?xml version="1.0" encoding="iso-8859-1"?>

<rdf:RDF 
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns="http://purl.org/rss/1.0/"
>
		
		
		
	<channel rdf:about="http://www.richinternet.de/blog/index.cfm">
	<title>Richinternet Blog</title>
	<description>The Rich Internet Dev Blog</description>
	<link>http://www.richinternet.de/blog/index.cfm</link>
	
	<items>
		<rdf:Seq>
			
			<rdf:li rdf:resource="http://www.richinternet.de/blog/index.cfm?mode=entry&amp;entry=9D486E1A-A9CF-673F-9941EE719FAE197B" />
			
		</rdf:Seq>
	</items>
	
	</channel>
		
		
		
		
		
		
		
		
		
		
		
  	<item rdf:about="http://www.richinternet.de/blog/index.cfm?mode=entry&amp;entry=9D486E1A-A9CF-673F-9941EE719FAE197B">
	<title>Advanced RIA engineering: applications that run in the Browser and in Central</title>
	<description>&lt;p&gt;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&apos;s now pretty easy to expand a Central application&apos;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 &lt;b&gt;and&lt;/b&gt; in in Central. Both versions needed to share the basic appliaction logic but have to be specific in their concrete runtime environment.&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;img src=&quot;http://www.richinternet.de/blog/img/uml.gif&quot; width=&quot;506&quot; height=&quot;529&quot;&gt;
&lt;p&gt;A FlashPaper version of the above diagram &lt;a href=&quot;http://www.richinternet.de/blog/img/centralUML.swf&quot; target=&quot;blank&quot;&gt;is available here.&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The main application &lt;b&gt;ConcretePortableApp&lt;/b&gt; implements a comon interface &lt;b&gt;PortableApp&lt;/b&gt; to ensure that the needed methods are available to the &lt;b&gt;Client&lt;/b&gt; (in this context the term &apos;Client&apos; 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.&lt;/p&gt;
&lt;p&gt;The main application is extended by two subclasses, &lt;b&gt;CentralApp&lt;/b&gt; and &lt;b&gt;BrowserApp&lt;/b&gt;. Both overwrite or extend the default behaviour according to their needs. For example, &lt;b&gt;CentralApp&lt;/b&gt; also implements the &lt;b&gt;mx.central.Central&lt;/b&gt; interface and initializes the Central environment during startup. Because both subclasses extend &lt;b&gt;ConcretePortableApp&lt;/b&gt; they are also of type &lt;b&gt;PortableApp&lt;/b&gt;. This means if we create instances of the sublcasses both will be compatible with our common interface.&lt;/p&gt;
&lt;p&gt;This finally leads to the &lt;b&gt;AppFactory&lt;/b&gt; class. The &lt;b&gt;AppFactory&lt;/b&gt; uses logic to determine which class to instantiate according to the current runtime environment and returns an object of type &lt;b&gt;PortableApp&lt;/b&gt; to the &lt;b&gt;Client&lt;/b&gt; (again this is possible because of the implemented interface). That way the &lt;b&gt;Client&lt;/b&gt; does not need to know in which runtime environment the application is running and can happily work with it.&lt;/p&gt;
&lt;p&gt;I hope you found this article interesting - and if you have any comments or questions please do ask!&lt;/p&gt;
&lt;p&gt;Dirk.&lt;/p&gt;</description>
	<link>http://www.richinternet.de/blog/index.cfm?mode=entry&amp;entry=9D486E1A-A9CF-673F-9941EE719FAE197B</link>
	<dc:date>2004-10-15T17:50:30-02:00</dc:date>
	<dc:subject>Central,Flash</dc:subject>
	</item>
		
	 	
		</rdf:RDF>
	

