Flex

Flex/AIR Application Scope Tips Posted in Adobe Flex, Flex/AIR with tags AIR scope, application scope, Flex scope, nativeApplication, outerDocument, parent, parentDocument, scope on January 27, 2009 by devgirl

Since I’ve been developing in Flex, the one thing I’ve been trying to get a better handle on is how to go about accessing what I need and when. After digging in to the Flex SDK a bit, I have come to some conclusions on different properties and objects that can be used in different scenarios. The following summary is what I came up with and would like to share with others that may find it useful. mx.core.Application.application The highest level root application object for a Flex application. This can be used to access the root application object regardless of where you are within a component or subapplication. It can be referenced via the fully qualified name, or in cases where you will use it multiple times, import mx.core.Application and use Application.application to reference the root app variables or methods. For instance: <mx:Script> <mx:Button label="Say Hello" click="Application.application.sayHello();"/>

where sayHello() is defined in your root application code… this property is especially useful for your projects where you have custom components or classes that need to access a shared set of data that is defined in the root. NativeApplication.nativeApplication A property you access within your AIR app that retrieves properties specific to that AIR application. For instance, it can be used to get at properties such as the application descriptor, the publisher of the AIR app, main application icon or menu. You would also use this Singleton object to add event listeners for actions specific to the AIR app, such as the app exiting (NativeApplication.nativeApplication.addEventListener(Event.EXITING, onExiting);). outerDocument The outerDocument property is used to access functions and properties defined in your main MXML file when the scope within your code block might have changed, such as when using the <mx:Component> tag . The Component object causes the MXML within it to be treated with a new document scope, so while it may seem you can access your functions defined in your main MXML file normally, you will not be able to unless you

prefix it with the word outerDocument such as in the following code excerpt. Without this keyword, you will receive a compiler error stating ‘Call to a possibly undefined method <methodName>’ <mx:Script> <mx:DataGrid id="dgData" dataProvider="{photosColl}" width="100%" height="100%" doubleClickEnabled="true" alternatingItemColors="[0xFFFFFF,0xEEEEEE]" doubleClick="navigateToURL(new URLRequest('http://smugmug.com'))" variableRowHeight="true" color="#000000"> <mx:columns> <mx:DataGridColumn headerText="Image" width="80"> <mx:itemRenderer> <mx:Component> <mx:Image source="{outerDocument.createUrl(data.server,data.id,data.secret)}" horizontalAlign="center" verticalAlign="middle"/> <mx:DataGridColumn dataField="title" headerText="Title" width="300"/>

parentApplication This property can be used to access the application object containing the enclosed object. This could be the top-level application object, but in the case where an application loaded another via the SWFLoader, it will be the currently enclosing application object. An application’s parentApplication will either be the application object that loaded it, or null if it is the top-level app. parentDocument

The parent document object for the given Flex application, MXML component or AS component, and only valued when isDocument() is true. The top-level application will have a parentDocument of null. parent Parent is used specifically for UIComponent classes or those extending from them to indicate the parent container or component for this UIComponent. The parent object type is always a DisplayObjectContainer. WindowedApplication This is the core class of an AIR app, and the object you are using when specifying ‘this’ in your AIR app. It implements IWindow as well as extending the Application class, so it serves two purposes, essentially wrapping the initial NativeWindow AND the NativeApplication objects. One big thing to note here, is that only events from the inherent NativeWindow are dispatched from the root WindowedApplication object, which differs from a browser application which dispatches events for ALL windows associated with that root Application. This is an important distinction to be wary of when developing multi-windowed applications.