Deploying Your Application (Open Source Flash Development) Part 3

Creating the Screenweaver back-end

The back-end will handle loading the Flash plug-in, creating a window, and exposing any extra haXe functionality to the front-end that you need. To create it, using your favorite text editor, create a new file named App.hx. Enterthefollowingcode into that file:

An explanation of the source follows.

This calls the init() method on the Application class in the swhx package:

It initializes the Screenweaver system. During this initialization, Screenweaver searches the system for a compatible version of the Flash browser plug-in. The init() method has two optional parameters: a version number and a file location. Ifyou specify a version number (such as 8 or 9), then that will cause Screenweaver to look only for Flash plug-ins meeting that version requirement. Since this example is trying to load an ActionScript 3-based SWF, we require version 9 of the plug-in. You can also optionally specify a path to the plug-in if you want to search for it in a nonstandard location.

If Screenweaver fails to find a suitable version of the Flash plug-in, then it will automatically attempt to download a version from Adobe’s web server. If this happens, the plug-in will be saved in a file called flashplayer.bin in the same directory as your application.

This creates a new native system window that will host the Flash plug-in:

The Window constructor takes four parameters: a window title, the initial dimensions (width, height) of the window, and an optional set of flags that define how the window behaves. Those flags are all constants in the Window class and can be a combination of the following:

■    WF_FULLSCREEN: Causes the window to take over the entire screen

■    WF_TRANSPARENT: Causes the window to have transparency

■    WF_DROPTARGET: Allows the window to participate in drag-and-drop operations

■    WF_PLAIN: Provides a more lightweight chrome around the window

■    WF_ALWAYS_ONTOP: Causes the window to appear on top of all other windows

■    WF_NO_TASKBAR: Causes the application to not appear in the Windows taskbar

If you want, you can have multiple windows in a single application. One common use of that is to display a simple splash screen while your main application is loading. Let’s look at the next line:

A RemotingServer acts as the gateway for communication between the Flash application and the back-end code. You can learn more about this in later sections. The next few lines get things running:

This creates a new Flash virtual machine on the given window, using the given RemotingServer. It sets the source SWF location and starts up the Flash VM allowing your ActionScript in the SWF to begin executing. Onto the last lines:

Finally, you display the window and start up the main event loop. The call to loop() will block until the window is closed or the application is closed through code. After that completes, the cleanup() call frees any memory that was being used by Screenweaver to run the Flash application.

Compiling the Screenweaver back-end

You use the haXe compiler to compile the App.hx file you just created into Neko bytecode that can be run by the Neko virtual machine. To compile the sample application, you would use the following command line:

The -neko app.n part tells the compiler to output a Neko-compatible file called app.n. The -main App lets the compiler know what class it should use as the main source file. The rest of the command line specifies two haXe libraries required for Screenweaver applications. When you issue this command, the compiler should silently return. If it displays any errors, check for typos or installation problems.

Once you’ve compiled the application, you can test it by running it directly through the Neko runtime by issuing the following command:

This should launch the Screenweaver application, which then creates a new window and loads your Example.swf into it to resemble Figure 6-1.

Figure 6-1. The example SWF running inside a native OS window created by Screenweaver

Interacting with the Screenweaver application from Flash

So far, all you’ve been doing is simply running a SWF. The only feature you’ve used that a simple projector doesn’t give you is the ability to decide when and where the windows get created. The real power of Screenweaver is that it allows your Flash application to communicate with the underlying Screenweaver loader to execute functionality not provided by the ActionScript API. For instance, you might want to read or write to a file on the local file system.

If you remember from the simple example, you created a neko.net.RemotingServer object in the haXe code:

The RemotingServer class provides a gateway from the Flash VM to your Screenweaver code. By adding classes to the RemotingServer, you make those classes available to the Flash VM. For instance, you could create a new method in the App class and add it to the Remoting server as such:

Here you created a new method called logText that takes a string and appends it to a file called log.txt. Then you added the App class to the RemotingServer object, giving it a name of App.

To call this from your ActionScript code, you need to use the Screenweaver ActionScript API. Assuming you’ve installed haXe and Screenweaver already, you can find a copy of this in the haxe\lib\swhx\1,1,2\api\actionscript\AS3 directory. Either copy it to your source directory or configure your ActionScript compiler to include it in the classpath. Once you’ve done this, you can modify your ActionScript code to use the API as so:

 

 

The Api.init() call initializes the Flash/Screenweaver connection. The Api.call() line calls into the Neko runtime and runs the Api.logText method with the given parameter. Ifyou now compile the Example.swf and App.n files and run the application, a new file named log.txt will be created with output similar to the following in it:

Using this method, you can take advantage of all that the haXe/Neko environment provides.

Distributing your desktop application

Requiring a user to execute a command line to run an application is usually not an acceptable solution. To solve this, Screenweaver comes with a precompiled boot loader that includes the Neko VM and required libraries to make Screenweaver work. You can find this in the haxe\lib\swhx\1,1,2\ tools directory.

To distribute your application, all you have to do is copy the files from that tools directory, your. swf, and your .n file to a directory. The tools directory includes executables for both Windows and OSX that will load your App.n file and launch your application. All you need to do is double-click that executable to launch the application. You can optionally rename the Windows executable and OSX bundle to reflect the name of your application.

In this topic, you learned how to distribute a Flash application in both website and desktop scenarios. You looked at a staging strategy and the Ant script required to make that happen. You also looked at how you can distribute a desktop-based application using haXe and Screenweaver. In future topics, you’ll learn how to use open source tools and libraries to create more complex and interesting Flash applications that include features such as complex server communication and 3D graphics.