• Save
David Coletta Architecting A Shared Codebase For Browser And Desktop Final
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

David Coletta Architecting A Shared Codebase For Browser And Desktop Final

on

  • 3,703 views

Learn from our experience in adapting a complex codebase like the application Buzzword to run also as an Adobe AIR application. This session addresses the architectural challenges of developing SWF ...

Learn from our experience in adapting a complex codebase like the application Buzzword to run also as an Adobe AIR application. This session addresses the architectural challenges of developing SWF files to be shared between browser and AIR versions. We’ll cover user interface considerations, such as reconciling a single browser window with multiple AIR windows, and technical issues, like problems with the Singleton pattern when using multiple native windows. Other topics include abstracting code that must call AIR only APIs and packaging code into modules that load over HTTP for browsers and load from the file system under AIR.

Statistics

Views

Total Views
3,703
Views on SlideShare
3,610
Embed Views
93

Actions

Likes
3
Downloads
0
Comments
1

14 Embeds 93

http://adipan.blogspot.com 48
http://adipan.blogspot.in 16
http://adipan.blogspot.hk 5
http://www.slideshare.net 5
http://adipan.blogspot.co.uk 3
http://adipan.blogspot.com.au 3
http://adipan.blogspot.jp 3
http://adipan.blogspot.nl 3
http://adipan.blogspot.de 2
http://adipan.blogspot.ca 1
http://www.rapidor.com 1
http://www.lmodules.com 1
http://duk2srv0124 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hi Mr. David Coletta,

    Thank you for giving this presentation. This is very helpful in clearing some of design issues in my own project.
    I was going with the 'Empty Shell and filled with Swc' approach based on the Todd Prekaski's 'Building Flex and Adobe AIR app from the same code base' article.
    But I am very intrigued with 'Browser SWFs included AIR file' approach.
    Please correct me if my understanding is wrong, you basically just have one AIR project that contains all AIR implementations. And on each of your module's functionalities, you extract them out to an interface and then have Flex-specific and AIR-specific class implements the interface.
    The part that I have a hard time in understanding is having all AIR implementations in one AIR project. What happens to implementations that need to access some user-defined classes that's located inside the project module?
    For example:
    Project Module A
    -------------------------
    public function implementThis(pUser:User):void;
    //Class User is only located in Project Module A

    So how does the AIR project access that 'Class User' that lives inside project Module A?
    I hope you could help me in clearing that out.

    Thank you very much!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

David Coletta Architecting A Shared Codebase For Browser And Desktop Final Presentation Transcript

  • 1. Architecting a Shared Codebase for Browser and Desktop Replace with a graphic White Master David Coletta 400px tall & 290px wide Sr. Computer Scientist Adobe Systems Incorporated ® 1 Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 2. About me Developer and co-founder at Virtual Ubiquity, Inc.  Career focus on collaboration software  Background in C++ and web applications  Started using Flex 2.0 alpha in January 2006  Joined Adobe in December 2007 via acquisition  Blog: TheJoyOfFlex.com  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 3. Core message Respect the platform. ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 4. Challenges User interface design  Shared code packaging  Abstracting the AIR APIs  Implementation issues  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 5. User interface design Browser AIR ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 6. Demo Demo ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 7. Some UI considerations between browser app and AIR app Installation  Automatic updates  Menu bars  Multiple windows  Transition from browser to AIR app  Opening hyperlinks  Remember-me handling  URL display  Going to sleep and waking up  Modal dialogs  Language preference  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 8. Shared code packaging Two models explored:  Browser SWFs included in AIR file and loaded at runtime  Mostly empty Applications and Modules with code linked from shared SWCs  Browser SWFs included in AIR file was preferable for us  We were already building separate modules  Looser coupling leads to faster builds  But requires use of Ant or similar tool for both development and production builds  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 9. SWF loading Browser Organizer.swf FrameCSS.swf Resources.swf Loads Loads Buzzword.swf Frame.swf Editor.swf EditorFonts.swf PDFexport.swf AIR Buzzword.air Buzzword.swf Frame.swf Organizer.swf Editor.swf EditorFonts.swf PDFexport.swf Resources.swf ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 10. Project structure Frame.swf, Editor.swf, and Organizer.swf copied here by Ant Buzzword.swf and Frame.swf built here Editor.swf and Organizer.swf built and loaded from here in browser version ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 11. Abstracting AIR APIs Tempted to write code like:  if (isAIR) {...} else {...} Problems with this approach  It won’t work in shared code because the shared code doesn’t have access to the AIR APIs  Too easy for developers to forget that it’s shared code  Alternative approach  For each area of functionality, create an interface with two implementations  Create a broker for accessing interface instances  Put all the AIR implementations in the AIR project  Example: IPersistentSecureToken  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 12. PlatformBroker PlatformBroker subclasses subclasses AIRPlatformBroker FlexPlatformBroker ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 13. IPersistentSecureToken IPersistentSecureToken implements implements BrowserCookie EncryptedLocalStorageCookie Uses ExternalInterface to Uses AIR make JavaScript calls that EncryptedLocalStore API to save and restore tokens save and restore tokens ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 14. Singletons Very convenient!  Can lead to problems when in multiple-document application  Example: frame interface  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 15. Rich-text clipboard support Browser implementation  Flash Player does not provide much clipboard handling support at all  Need to cheat with hidden DIV or IFRAME  Extremely fragile  Limits range of supported browsers  AIR implementation  Problematic because AIR Clipboard API only provides raw HTML  Need to run HTML through some kind of normalization process  Easiest approach is to run it through an HTMLLoader  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 16. More implementation issues (if time) Relaunching  Using the AIR update framework  Loading Flex menus and native menus from a single model  Internationalization and localization  Runtime CSS vs. compiled CSS  Idle tracking  ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.
  • 17. Core message Respect the platform. ® Copyright 2008 Adobe Systems Incorporated. All Rights Reserved.