Deploying Your Application (Open Source Flash Development) Part 2

Transferring your files

Using Ant, you have a few options for uploading files to your web server. You’ve already seen how the copy tag allows you to copy files to different directories. Ifyou have a file share available to you on the web server, you can simply use this method to copy the files to the correct location. This is rarely practical, since most of the time you won’t have access to a file share on your web server. You could also use the ftp task to transfer the files over the FTP protocol. This has the benefit of being usable on nearly any web hosting setup. However, it’s not the most secure option, since your username and password are transmitted as clear text, and if it’s possible for an attacker to snoop on your traffic, they can harvest this information. The last option is using SFTP or SCP over an SSH connection. This provides strong encryption and even implements some simple compression to help speed your transfer. I’ll cover both options here.

Using Ant and FTP

Ant comes with an FTP task built in, but it’s considered an “optional” task. What this means is you have to download some extra files into your Ant distribution to make it work. If you read the documentation on the Ant website at http://ant.apache.org/manual/OptionalTasks/ftp.html, you will see that it requires the following:

■    A networking library called commons-net. You can download this library from http:// commons.apache.org/net/.

■    A regular expression library named jakarta-oro. You can download this library from http:// jakarta. apache.org/oro/.

Download both of those libraries, unzip them, and place the .jar file in your ant/lib directory. Once you’ve done that, you can begin using the Ant FTP task. An example follows:

The parameters to this command are as follows:

■    verbose="yes": This tells Ant to issue a higher level of logging so you can see errors, warnings, or messages about current progress.

■    passive="yes": This instructs Ant to use passive instead of active FTP transfers. Depending on the server you’re connecting to, one option or the other might not be available.

■    remotedir="/www": This tells Ant where to put the files on the remote server.

■    server="www.yourserver.com": The server attribute specifies the host name of the server to connect to.

■    userid="ftp_login" password="ftp_password": The userid and password attributes specify your login credentials to the remote server.

■    fileset dir="staging" />: The fileset tag (or multiple fileset tags) specifies what files to copy from the local machine.

In this example, we specified both the username and password, but you could have also specified those as parameters and placed the values in an external properties file like so:

Then you could create a file called build.properties and place the following content inside it:

This gives you the benefit of not storing your username and password in the build.xml file, making it safe to share with others. But it still has the drawback of having your username and password in a file where anybody who uses your computer may find it.

If you don’t like the idea of storing your password in a file on your computer, you can use the input task to cause Ant to prompt for it every time it’s run:

All the previous examples upload the entire site to the staging server. Oftentimes, you want to transfer only the files that have changed. The ftp task has a property called depends that will check the time stamp of the file on the server and compare it to the time stamp on your local copy and upload only the newer files. However, this method can be fragile, because the time of your local computer and the server might not be in sync. A better method is to use the modified subtag of the fileset tag. The first time the modified tag runs, it creates a file listing the checksums of all your files. A checksum is a short string automatically generated based on the content of a file. The next time the modified tag is encountered, those checksums are compared to the current checksums of your files to determine whether they’ve been modified and need to be re-sent. An example follows:

When using the modified tag, make sure to use a different cache file for each location you upload to. In this example, you want to upload to a staging and a production web server. Ifyou were to use the same cache file for both and upload your files to the staging server, everything would work fine. But if you then tried to upload to the production server, no files would be transferred because the checksums in your cache would match the checksums of the file, making Ant think it had already sent those files. Ifyou ever need to transmit all the files again, you can simply delete your .cache file, which will cause Ant to “forget” which files it sent. A full example of the deployStaging and deployProduction targets follows:

 

 

 

Using Ant and SFTP/SCP

More and more web hosting companies are starting to support connections to the web server over a secure SSH connection. By using this type of connection, you can use either SFTP or SCP to copy your website files to the server. Like FTP, using either SCP or SFTP with Ant requires you to download and install an extra library. The required library is called JSch, and you can download it from http://www.jcraft.com/jsch/index.html. To install it, just download the jsch.jar file and place it in your ant/lib directory.

SCP and SFTP are similar protocols and can be used interchangeably most of the time.

They both work over an encrypted SSH connection, and they both transmit files.

When choosing which to use, keep these factors in mind. Secure Copy (SCP) is more widely available and is best when transmitting a few small files. Secure File Transfer Protocol (SFTP) isn’t available as often but is optimized for big groups of larger files.

To use either SCP or SFTP, you use the scp Ant tag. An example of SCP usage follows:

To use SFTP instead, simply add an sftp parameter:

You can employ all the methods you used in the FTP example to pass a username and password. You can also use the modified tag to send only those files that have changed. A full example of deployStaging and deployProduction using SCP follows:

 

As you can see, transferring files over SCP, SFTP, or FTP all have about the same complexity. Since both SCP and SFTP transmit your files and user credentials in a secure fashion, it’s highly recommended that you choose one of those methods.

Executing commands on the server

If you are using one of the SSH-based methods for transferring files to the server, then you likely also have access to execute commands over SSH. You can accomplish this through Ant using the sshexec task. For instance, you could update the date/time stamp on a file called lastUpdated by executing the touch command like so:

Using the sshexec tag, you can perform nearly any type of operation that you can while using the command line. Here are some ideas of things you may want to try:

■    Back up your web space or database.

■    Delete files that are no longer needed.

■    Use image tools to periodically generate images based on some external input.

■    Keep multiple servers all synchronized.

To find out the commands to perform these tasks, consult the documentation for the operating system that your web host uses.

Be careful when using sshexec since any command run through it is immediately executed on the server. You could accidentally modify or delete important files without any confirmation message.

Excluding files

Sometimes you want to make sure some files aren’t transferred to the web server. Usually, it’s easiest to simply not include those files when copying them to your staging directory. But other times it’s easier to exclude those files while transferring. Since the copy, ftp, and scp Ant tasks all use a fileset to determine which files to copy, you can use the excludes child of that to specify that some files shouldn’t be copied. Extending the deployProduction target to exclude some common files that you don’t want to transfer might look like this:

As you’ve see in this topic, using Ant to publish files to your web server can standardize your release process, leading to fewer bugs and higher quality.

Deploying desktop applications

Most Flash development is focused around web-based applications, but there is a growing trend to use Flash for desktop applications as well. Two projects of late have been created to address this market. Adobe has produced a technology called Adobe Integrated Runtime (AIR) that allows Flash or HTML-based applications to be deployed to the desktop. Some components of AIR, including the ActionScript 3 compiler and the Flex library, have been open sourced by Adobe. Still, other components such as the AIR runtime remain a proprietary solution.

If you’re looking for a fully open source desktop application solution, then Screenweaver is for you. It’s a piece of software that acts as a bridge between the Neko virtual machine and the Flash browser plug-in. The Neko VM is the runtime environment used for haXe applications that run on the native machine.

To get started, there is a detailed tutorial for downloading and installing Screenweaver that you can access by clicking the Tutorials link on the Screenweaver website (http://screenweaver.org/).

How it works

Your desktop application will be split into two parts. A front-end, which generally contains the user facing part, and the back-end, which generally handles the I/O, window management, and any other non-UI functionality.

For the front-end, you write your Flash application and publish a SWF just like you normally would while working on a web-based project. This SWF either could be identical to a web-based version or could take advantage of some of the    additional features that Screenweaver gives you.

To create the back-end, you write a small amount of loader code in haXe that will bootstrap your application. Itwill start up the Screenweaver subsystem, create a new OS window, load the Flash plugin, and finally load your SWF into that window and allow the user to interact with it.

You can also allow the loaded SWF to access functionality defined in the back-end Screenweaver application. To do this, you define haXe methods on a haXe object and add that haXe object to a list of objects the Flash application is allowed to access.

The following sections will walk you through creating the Screenweaver loader and then adding some loader/application communication.

One of the benefits of Screenweaver is that you can write both your UI and back-end logic using the haXe programming language. In the example in this topic, I’m assuming you’re using ActionScript to create your front-end SWF. But you could also use haXe to create that SWF, allowing you to work in the same language and environment for both sides.

Creating the front-end SWF

This topic will use a modified version of that to demonstrate Screenweaver; the source of that simple application follows:

As you can see, this is a very simple example that, when compiled, displays the words “Hello, World” in an 800X600 SWF. In a real-world Screenweaver application, you can create as complex an application as you do for the Web.