Home > Flex > Building both a browser and an Apollo version of your Flex app

Building both a browser and an Apollo version of your Flex app

December 13th, 2006

We are building our applicationapollo_logo_white_2[5] in Flex, and it will run in a web browser using the Flash 9 plug-in. But we are also getting ready for Apollo, which adds a whole bunch of additional APIs that we can use to access platform-specific features like local files and the clipboard, but without having to write separate Mac and Windows code. (Apollo is currently in private beta: more info on Adobe Labs.)

These two targets create a configuration challenge for us. While we are furiously writing code for our browser-based product as a SWF, we also have to be able to build a different configuration of our software that makes a bunch of additional API calls that are not present in the core Flex/Flash libraries, and builds an AIR file (the cross-platform binary for Apollo) instead of a SWF.

We imagine that our users will probably go back and forth between the browser version of our product and the Apollo version. So the right way to do this some time down the road will probably be to build most of our application as a library of common code that can be downloaded once and then used by either the browser plugin (SWF) or the Apollo binary (AIR). The project for the AIR file will have just the code that is specific to Apollo in it.

But that’s down the road. For now, we want to be able to build both versions, upgrade to new drops of Apollo code easily, and above all avoid having to create Apollo branches just because of a few differences.

The solution I ended up with was to create a separate project for the Apollo version, set up an “additional source folder” that points to the source of our core project, and then put only the Apollo-specific code in the Apollo project. This approach leverages the new extensions to Flex Builder 2.0.1 that allow it to create Apollo projects and export AIR files from them. This simplifies the process of building an Apollo app in general, and in particular makes it a lot easier for us to create an Apollo version of BuzzWord without branching the source.

Here’s an outline of the process to start with the core project and end up with an AIR file. This assumes that you have installed the Apollo extensions to Flex Builder, or perhaps are using a version of Flex Builder that comes with those extensions already.

1) In Flex Builder, create a new Apollo project named ApolloClient. In the New Apollo Project wizard, when it asks for additional source folders outside of the main source folder, specify the core project as an additional source folder.

2) Copy the root .mxml file(s) from the core project to the Apollo project, as well as any files they include. Add references to any classes that must be loaded dynamically at runtime rather than statically linked.

3) Add an application icon file at the root of the ApolloClient project. (For M2 I used the same icon file that we had been using for M1.)

4) There will be some ActionScript source files that call Apollo-only APIs. As a general rule the technique is that when a core class would make such a call, then it should be subclassed (or perhaps replaced) in the ApolloClient project. These classes must live in the ApolloClient project, not in the core project.

5) There will be core code that will have to decide whether to instantiate a core class or a subclassed class from Apollo. It may be deciding based on whether the app is connected, or based on whether it’s running under the Flash Player or under Apollo, or some other criteria. If it decides it needs to instantiate a class that lives in the ApolloClient project, then inside a try/catch block it calls getDefinition on the class, passing in the fully qualified name. Assuming the test was based on whether the app is connected or on whether it’s running under Apollo, then the catch block doesn’t need to do anything, because it should never happen.

6) To build the AIR file, right-click on the ApolloClient project and pick Export…, then pick “Deployable AIR file” from the list of export destinations. Make sure to check the icon file in the list of files on the left. (Don’t check anything else.)

Note: the ApolloClient project for Apollo M2 is currently checked in, but I suspect that it will need to be recreated periodically for future drops of Apollo.

Technorati Tags: , ,

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • StumbleUpon
Author: David Coletta Categories: Flex Tags:
  1. December 14th, 2006 at 07:14 | #1

    FYI, AFAIK it is not possible to sign up for an private beta for Apollo software at http://labs.adobe.com/wiki/index.php/Apollo

    It is only possible to add yourlself to the mailing list to get notified when public beta release of Adobe Apollo will be published to Adobe Labs.

    Any chance to join a private beta of Apollo by me to get a solid look ahead is Apollo software capable to fit my company needs?

  2. December 14th, 2006 at 09:30 | #2

    hmm..it still requires some effort to do that…wondering, if we can figure out a way where it can be done with minimum effort…..

    BTW! I don’t know if it is good to talk about a Apollo internals or development releated stuff on blogs. I know there are many developers who want to play with it but they can’t.. After reading these kind post they might feel bad :)

    -abdul

  3. December 14th, 2006 at 09:50 | #3

    Argh !
    Now I *really* want to get my hands on Apollo !

  4. December 15th, 2006 at 03:03 | #4

    I am still thankful for sharing those “early” experiences of building the product targeted for Web and desktop from the same codebase.

    That’s exaclty what my company wants to do :)

Comments are closed.