Versioning Support for Large Applications and Portals

1. Versioning Support for Large Applications and Portals Alex Harui Flex SDK Team Adobe Systems, Inc.

2. About me 7 years writing ActionScript components Wide range of knowledge of Flex SDK topics Managers Events List, DataGrid, Tree Item Renderers SWFLoader Modules Blog: http://blogs.adobe.com/aharui

3. About you Should be comfortable with ActionScript Single-threaded Class definitions Event model Run-time Exceptions Familiar with Flex Managers Server communication classes Willing to find out more about the Flash Player Security ActionScript runtime Not afraid to interrupt me with questions

4. Agenda What do I mean by “versioning”? What do I mean by “portal”? How large is a Large Application? ApplicationDomains What is required to support “versioning”? What are the limitations? SecurityDomains What is required to build “portals”? What are the limitations? Bootstraps

5. Versioning Can mean a lot of things Player versioning: How do I require a minimum player version? SWF versioning: How do I tell what version of Flex built a SWF? Backward compatibility Etc. For this presentation, versioning is “versions of Flex” When we go from 3.0 to 3.x, or 3.x to 4.0, etc. what do you need to do to your application?

6. Portals Can also mean a lot of things: An application where some of the content is from another web domain (mash up) An application showing many different things at once (dashboards) For this presentation, a portal is a main application with almost no content of its own and loads its content via other sub-application SWFs And does not trust the provider of that sub-application And there is limited integration between the application and sub-application

7. Large Application How Large is a Large Application? If you can tell me how big it is, then it isn’t large For this presentation, a Large Application is an application that is comprised of multiple SWFs Versioning issues arise when upgrading those SWFs to a newer version of Flex Portal issues may also arise if third-parties provide some of those SWFs

8. Versioning – Runtime Issues What do you need to do when the next version of Flex comes out? Usually nothing. A release of Flex will not affect your application until you try to re-build your application on that release. Even if you use the shared RSL, there is an RSL per version (including dot-releases) so your application will always load the same RSL bits as it did before But when you finally do re-build be aware that: Default values may change, especially for styles Size and position of your UI controls may change Flex may fix bugs and alter behavior of methods Your application might be depending on buggy behavior and therefore behave differently and even crash or hang These changes can cause your main application SWF and/or other SWFs (RSLs, Modules, etc) to fail to load or run or run as expected

9. Versioning - Compile-time Issues Flex may add APIs If your application also added the same API in a subclass there will be a compile error Flash Player has the ability to hide APIs based on SWF version Flex can’t hide APIs ActionScript doesn’t allow overloading You can add new method parameters as optional parameters… …unless a subclass overrides that method Flex doesn’t want to complicate the code by adding versions to the APIs Can’t do it for properties anyway Makes the code much heavier There is a compatibility-version flag in MXMLC But then you can’t use new features

10. Versioning – Mixing Versions Flex generally expects that all SWFs are compiled with the same version of Flex Significant performance and maintenance benefits to being on one version Some large applications, especially those with content supplied by third-parties, will find it impractical, if not impossible, to re-build all of the SWFs on the same version of Flex Suppose some third-party provided a SWF but went out of business or did not supply source code

11. Versioning – Marshall Plan Flex 3.2 will provide ways to allow an application to utilize sub-applications built with different versions of Flex Flex 3.2 is the starting point, no support for 3.1, 3.0, or 2.x Once you’ve re-built on 3.2, then Flex 4 applications can utilize a sub-application built on 3.2 Flex 4.x, Flex 5, etc should be able to utilize sub-applications built on at least the previous version and hopefully even older versions (going back as far as 3.2) Significant work required to put sub-applications in different application domains yet allow for interoperability Data has to be ‘marshaled’ between application domains Hence the code name for this work is the “Marshall Plan” History Lesson: The original Marshall Plan was a way for post-WWII European countries to co-exist peacefully Our Marshall Plan is a way for different versions of Flex to co-exist peacefully

12. Marshall Plan – How does it work? Each sub-application is loaded into a separate ApplicationDomain Whatever bits implemented some class in that version Flex will be the version that the sub-application uses Data sharing between the main application and sub-application requires marshaling Flex Managers know how to work together to allow for DragDrop, PopUps, ToolTips and Cursors

13. Marshall Plan - Sub-applications, not modules Modules generally require strong-typing More like DLLs in Windows Often optimized to remove duplicate classes found in the loading app Sort of like a class loader in Java ModuleLoader.child usually implements some interface Sub-apps don’t require strong-typing More like separate processes in Windows, with different address spaces Not a common practice to remove duplicate classes SWFLoader.content usually doesn’t matter Therefore, a better choice for putting up a barrier of isolation

14. ApplicationDomain Child ApplicationDomains inherit classes from parent ApplicationDomain SWFLoader defaults to the child ApplicationDomain As the SWF sets up its classes, any class already defined is not added to the ApplicationDomain, even if it is a child. First-in Wins Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent … Container Container Sprite … … … Application Application Event MyApp MySubApp Flash Flex 4 Flex 3.2

15. ApplicationDomain Marshall Plan uses separate ApplicationDomains Sub-application gets the intended version of its classes But a UIComponent from MyApp is not a UIComponent from MySubApp Sprite from MyApp is a Sprite from MySubApp Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent … Container Container Sprite … … … Application Application Event MyApp MySubApp Flash Flex 4 Flex 3.2

16. ApplicationDomain Strong-typing fails MySubApp.mxml: var mainApp:Application = MyApp.application; // error MyApp’s Application class is not the same as MySubApp’s Application class. Effectively, the class names are Application@MyApp and Application@MySubApp Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent … Container Container Sprite … … … Application Application Event MyApp MySubApp Flash Flex 4 Flex 3.2

17. ApplicationDomain Singletons are no longer really singletons MySubApp.mxml ToolTipManager.toolTipDelay = 1000; MyApp.mxml trace(ToolTipManager.toolTipDelay); // 500 (default) not 1000 MySubApp’s ToolTipManager is not the same as MyApp’s ToolTipManager. Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent … … … Sprite Application Application … MyApp MySubApp ToolTipMgr ToolTipMgr Event Flash Flex 4 Flex 3.2

18. Marshaling function dragEventHandler(event:Event):void{ if (!event is DragEvent){ var eventObj:Object = event; event = new DragEvent(eventObj.type); event.dragSource = eventObj.dragSource;… Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent … … … Sprite Application Application … MyApp MySubApp DragEvent DragEvent Event Flash Flex 4 Flex 3.2

19. Marshaling // can’t type parameter as DragEventfunction dragEventHandler(event:Event):void{ if (!event is DragEvent){ // treat event as object, no way to strong-type var eventObj:Object = event; // create event in your ApplicationDomain event = new DragEvent(eventObj.type); // copy known properties event.dragSource = eventObj.dragSource;…

20. Marshall Plan – Limitations Sub-applications, not modules Styles are not marshaled Each sub-application must load its own Styles No inheritance or usage of styles from the main application If the main application loads a style module it will not affect the sub-application (and vice-versa) ResourcesBundles are not marshaled Each sub-application must load its own ResourcesBundles No usage of resources from the main application If the main application loads a resource module it will not affect the sub-application (and vice-versa)

21. Marshall Plan – Limitations BrowserManager (and thus HistoryManager) turned off in sub-applications Only the main application’s BrowserManager can alter the URL fragment You have to design your own communication between sub-application and main application if you want sub-application state represented in the URL fragment Drag/Drop requires marshaling data on Drop The DragManager marshals the DragEvent, but not the data Use systemManager.getSandboxRoot() instead of just systemManager when listening for Mouse and Keyboard events in capture phase You can use stage, but then sub-application won’t work in a Portal Sub-applications must load their own RSLs SWF size is larger because no classes can be shared with the main application (modules usually have shared classes removed) Shared framework RSLs will help

22. From Versioning to Portals Your sub-applications, even though in a different ApplicationDomain, can still access objects and data in the main application and vice-versa Can get the text out a password field Can overlay a password field with another password field and phish passwords Can see all mouse and keyboard behavior in the main application Insufficient security for Portals Third-party content can’t be trusted If sub-applications are loaded into separate SecurityDomains, then with a bit more work, “good-enough” security for Portals Clip the sub-application so it can’t phish outside of its apparent area on screen Sub-applications can do bad things to other sub-applications from the same domain Hence, try to make sure only one sub-application loaded at one time Flash Player 10 has a way to force unloading

23. Portals – Limited Interoperability Focus smoothly passed between main application and sub-application Popup activation on mouseDown works between main application and sub-application Some limited notification of mouse and keyboard activity in other SecurityDomains

24. Portals - Limitations Same limitations as Versioning, plus: Sub-applications are untrusted Cannot access most stage properties, methods and events Cannot access file system or native/desktop features in AIR Cannot get mouse and keyboard events from other SecurityDomains Cannot drag/drop to or from the main application ToolTips, Cursors, Popups and Alerts are limited to the SWFLoader’s screen area Sub-applications must be on a separate domain than the main application Only way to force creation of separate SecurityDomains Sub-applications can cross-script each other if on the same domain You can use separate sub-domains, IP addresses, etc. They can all map to the same machine, but as long as the characters in the domain portion of the URL are different, that will set up a separate SecurityDomain by default

25. Portals – Limitations Dragging and clicking code should use MarshalMouseEvent When you drag the mouse off of an object and release, if you are outside of the SWFLoader’s screen area but still over the main application, you don’t get MOUSE_UP or MOUSE_LEAVE No need for MOUSE_LEAVE, use MarshalMouseEvent.MOUSE_UP MouseEvent.MOUSE_MOVE handlers don’t work outside of the SWFLoader screen area Don’t rely on stage dimensions Use systemManager.screen to determine size of SWFLoader screen area If you put things outside that area it will be clipped Don’t walk parent chains or access SWFLoader.content Or expect SecurityErrors if you do

26. SecurityDomain A SecurityDomain is a “Sandbox” A safe place for you application to play where it can’t be harmed or harm anyone else Sandboxes can “trust” each other (allow access to each other’s data) LoaderInfo.parentAllowsChild, LoaderInfo.childAllowsParent, allowDomain() Trust is not always mutual Default trust depends on how the sandboxes are created LocalTrusted sandbox loading remote sandbox has childAllowsParent = true Remote sandbox loading remote sandbox has childAllowsParent = false Therefore, testing the application from file:// is not the same as testing from http:// You may find tighter security when you finally deploy to http://

27. Demo #1 Draggable Zoom Tool Works great on its own Will it work as a sub-application? systemManager.addEventListener(MouseEvent.MOUSE_UP, zoom_mouseUpHandler, true); systemManager is top of the display list for each SWF, not for the whole application Can’t track mouse outside of SWFs screen area SystemManager MainApp SWFLoader SystemManager Zoomer

28. Demo #2 Draggable Zoom Tool systemManager.topLevelSystemManager.addEventListener(MouseEvent.MOUSE_UP, zoom_mouseUpHandler, true); topLevelSystemManager is top of display list for child applications but not when loaded in a separate applicationDomain Can’t track mouse outside of the SWFs screen area when loaded in a separate applicationDomain. SystemManager MainApp SWFLoader SystemManager MainApp.mxml MySubApp.mxml Zoomer SystemMgr SystemMgr … … MainApp Zoomer

29. Demo #2 (continued) Draggable Zoom Tool systemManager.topLevelSystemManager.addEventListener(MouseEvent.MOUSE_UP, zoom_mouseUpHandler, true); topLevelSystemManager is top of display list for child applications but not when loaded in a separate applicationDomain Can’t track mouse outside of the SWFs screen area when loaded in a separate applicationDomain. SystemManager SystemManager MainApp MainApp SWFLoader SWFLoader SystemManager SystemManager MainApp.mxml MainApp.mxml MySubApp.mxml MySubApp.mxml Zoomer Zoomer SystemMgr SystemMgr SystemMgr SystemMgr … … … … MainApp MainApp Zoomer Zoomer

30. Demo #3 Draggable Zoom Tool systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_UP, zoom_mouseUpHandler, true); getSandboxRoot() is the top of the display list in a SecurityDomain Still can’t track the mouse outside of the sandbox Can’t get MOUSE_MOVE as it would be a security violation Can get MOUSE_UP so we know when to stop dragging SystemManager MainApp SWFLoader SystemManager MainApp.mxml MySubApp.mxml Zoomer SystemMgr SystemMgr … … MainApp Zoomer

31. Demo #4 Draggable Zoom Tool systemManager.getSandboxRoot().addEventListener(MarshalMouseEvent.MOUSE_UP, zoom_mouseUpHandler); Need to use MarshalMouseEvent to get mouseUp from outside the sandbox SystemManager MainApp SWFLoader SystemManager Flex 4 Sandbox Zoomer Flex 3.2 Sandbox

32. Bootstraps Small SWF that has a minimum set of classes to be shared among all ApplicationDomains in a SecurityDomain WebService, HTTPService, RemoteObject and DataService may require a Bootstrap if sub-applications in separate ApplicationDomains are using those services Gets loaded first then loads actual main application One bootstrap per SecurityDomain Doesn’t work across SecurityDomains Main Application uses bootstrap ApplicationDomain when loading sub-applications

33. Bootstrap Both MyApp and MySubApp share the class MyData No marshaling required Adding a small class may still drag in lots of dependent classes Review your link-report and SWF size to be sure Changes to any class in a bootstrap can break other sub-applications Make sure these classes are not likely to change Flash Player MyApp.mxml MySubApp.mxml DisplayObject UIComponent UIComponent Bootstrap.as … … … MyData Sprite Application Application … MyApp MySubApp DragEvent DragEvent Event Flash Flex 4 Flex 3.2

34. Summary Better to do full upgrade of all SWFs when possible If you think that won’t be practical or possible, use sub-applications instead of modules Decide between Portal or Versioning approach Start off using separate ApplicationDomains or separate SecurityDomains Otherwise there could be surprises when you finally do Styles and Resources aren’t shared anymore Some data may need to be marshaled or put in bootstrap Use a bootstrap if you are using RPC or LCDS Names of classes and APIs may change

35. Versioning Support for Large Applications and Portals Q&A