I was able to use Charles Proxy to see that the application wasn’t even making the requests to the server, meaning it must be an issue with AIR rather than local or remote DNS, or web servers.

My requests were being made by the HTTPService class, and I couldn’t find any properties of methods that where related to caching, however I did find that URLRequest had two properties, useCache and cacheResponce.

 
var urlRequest:URLRequest = _new URLRequest();
urlRequest.cacheResponse = false;
urlRequest.useCache = false;

This is quite handy, although it didn’t seem to work for me, and also wasn’t idea for the situation I was in. After doing some digging on the web I found the classic solution of adding a random number to the end of the URL

 
 
 
 var urlRequest:URLRequest = _new URLRequest('http://www.example.com/');
 urlRequest.url += '?nocache=' + Math.random() * 100;

Again this isn’t ideal and could lead to problems, especially if you don’t know what server or URL the requests may be sent for. There is a chance the nocache (or any) variable could cause problems.

Eventually I noticed that the URLRequest’s cacheResponse entry on livedocs had a “See also” pointing to flash.net.URLRequestDefaults.cacheResponse. This solved all my problems, and is essentially a default for all URL requests made my AIR.

The properties appear to be static variables so you can set them like so:

1
2
3
4

 
// Turn caching off for AIR
URLRequestDefaults.cacheResponse = false;
URLRequestDefaults.useCache = false;

This only needs to be done once, so you can add it to your applications start up cycle.

Update framework

When using the ApplicationUpdater (without the UI), you can easily force the install of all updates, but this isn’t very user friendly, and not a great experience. Often it’s far too time consuming to write your own UI for the update framework, so ideally I wanted to create a way of supporting required updates whilst using the existing UI as much as possible.

In order to do this I wrote a decorator for the ApplicationUpdaterUI which added the new event RequiredStatusUpdateEvent. This is dispatched when the updateDescriptor file is downloaded and includes the value of a new node called required (which you need to add to your update.xml file):

 
<?xml version="1.0" encoding="utf-8"?> 
<update xmlns="http://ns.adobe.com/air/framework/update/description/1.0"> 
	<version>2</version> 
	<url>http://www.pixelbox.net/demos/extendedAppUpdater/ExampleAirApp-2.air</url> 
	<description>
		Version 2
		- Lots of great new features
		- Required security patch
	</description>
	<required>true</required>
</update>

The text “true” will translate into a Boolean set to true, anything else will be false.

You can then add a listener for the (along with any default events), to tell your user they have to update to the new required version. This can be as simple as:

 
           private function onUpdate(event:RequiredStatusUpdateEvent):void
            {
                if (event.required && event.available)
                    // Required update available 
                else
                    // There isn't a required update, so leave it up to the ApplicationUpdaterUI
            }

From a UX point of view this works rather well. You can choose how your application responds to a required update, and don’t need to force the install in the background and restart the app. I like to change the state of the app, as well as letting the ApplicationUpdaterUI window open. If the user upgrades through the default UI, great, if not they will be presented with a new app state, telling them there is a required update, perhaps even why it’s important. You may even want to let them do some things but not others (such as letting them save their work, or finishing their current workflow). Either way it gives your app the choice of how it wants to behave.

I have created a little example app (with view source enabled) that uses the this code, as well as a .swc and the example app as a project.

• Example AIR Application
• Extended Updater swc file
• Example Air App project
• Example update descriptor XML file

If you install the above air file, you will be able to check for updates and receive a required update. When this happens the app’s main function is disabled and a message displayed telling the user to upgrade.

Please let me know if you have any questions, or would like to add to this little framework, good luck. If you want to create your own without using the default UI check out this article on Black Pepper

NOTE: I have since discovered the Capabilities class that has a boolean called isDebugger. Therefore you can do this like so:

if (Capabilities.isDebugger)
{
trace('This app is running in the ADL');
}

Original post:

I recently came across the situation where I wanted to detect if my AIR application was running, “for real” or running in debug mode (in the Adobe Debug Launcher ADL).

With a standard Flex > SWF project you can change the HTML of the debug template to pass through a debug=true variable. However with an AIR project you don’t have this luxury.

The reason I want to do this, is I don’t want some things to happen when I’m debugging (such as sending stats to the server) and I don’t want to have custom variables or comment out code incase I forget to turn them back on before pushing live. By having a way of checking if the app is running in the ADL you can optionally stop things, safe in the knowledge that when they go live they will work.

I searched the web to see if there was a way to tell if AIR was running in debug mode, or in the ADL or was even a release build, but I couldn’t find a specific API call. What I did find is a number of methods that only worked if running in the ADL. All I had to do then was find one that returned different values depending on that fact. The Error class has a method getStackTrace() that return null if not running in the ADL and a string if it is, this was perfect and can be used like so:

if (new Error().getStackTrace() != null)
{
trace('This app is running in the ADL');
}

This code isn’t perfect, in the future the getStackTrace method could start working when not running in the ADL. You could also combine a few ADL specific methods, for better piece of mind. If you know of a better solution please let me know!

I hit a problem with the user dragging folders, as they are handled as a file with a property of directory. In order to iterate through an array of these files and folders I needed a way to turn an array of files and folders into an array of just the files.

In the following function you can pass it an array of files and it will flatten it, but returning an array of just the files. It also removes hidden files!

		/**
		 * This function takes an array of files and folders and retuns an array of just files
		 * This function also removes hidden files
		 * @param files
		 * 
		 */		
		private function _cleanFileArray( files : Array ):Array
		{
			var arrayToReturn : Array = new Array();
 
			for each ( var fileOrDir : File in files )
			{
				if( fileOrDir.isDirectory )
				{
					// If we find a directory, call this method again to extract the files
					// This will recurse until there are only files in the returning array
					var subArray : Array =  this._cleanFileArray( fileOrDir.getDirectoryListing() );
					arrayToReturn = arrayToReturn.concat( subArray ); // Combin the files with the arrayToReturn
				}else if( fileOrDir.isHidden ){
					// Skip hidden files
				}else{
					// If we have a file add it to the array of files to return
					arrayToReturn.push( fileOrDir );
				}
			}
			return arrayToReturn;
		}

You could turn this into a static function on a helper class if you want. Tags: Removing folders from file list, extracting files from folders, flattening folders, removing hidden folders.

Using Bindable variables and properties in Flex (Action Script 3) is great, it saves a huge amount of time adding events left right and center. However today I had a problem where I wanted to use a setter for a variable. In order to do this I made it private and used a getter and setter function, allowing me to add some logic when setting the variable.

The problem however is that private variables are unbindable. You will get a warning on anything bound to it, saying it will not see changes. There is a very simple way to get around this, but making the getters and setters bindable.

[Bindable]
public function set yourVar ( s : String ):void
{
//Some logic can go here
_yourVar = s;
}

public function get yourVar ( ):String
{
// Some logic perhaps
return _yourVar;
}

By putting the [Bindable] tag before the function (I assume you only need it above one), any variables bound to yourVar will work. You don’t need a [Bindable] before your declaration of the private _yourVar and you should use yourClassInstance.yourVar when binding, rather than _yourVar.

Hope that helps someone.

Now before I start there is one thing to look out for. I first wanted to change the background colour, and kept getting a flash of that Windows 98 turquoise before it change to my new colour… This had me really confused for a while, until I realised that the auto generated HTML that Flex Builder 3 creates has that same colour as it’s default background… Doh! (You can also get the compiler to change this, see the gotoAndLearn example for more info)

Quite a few of the settings of the loading screen can be set through the mx:Application tag, in your Application Class’s MXML. The most obvious being the background colour. This is also where you can specify your own download screen, or as Adobe call it, “DownloadProgressBar”.

At the highest level a Flex application is a two frame movie clip, the first frame being the aforementioned, “DownloadProgressBar” and the second being your Application class. In order to draw images and a progress bar on your loading class thing, you will need to extend the Sprite class (like a movieclip without frames) and implement the IPreloaderDisplay. ( Holy object orientation Batman! Don’t worry you can just copy my example and ignore that if you want!)

When creating your own “DownloadProgressBar” you need to keep it lightweight, otherwise you will have to make a “DownloadProgressBar” for that! Also some elements of the Flex framework won’t be available when it starts, so don’t go too crazy!

The first step is to add this to the tag in your Application’s MXML file

preloader="com.example.preloaders.myDownloadProgressBar"

Once this is added your application will use your custom “DownloadProgressBar” Class, rather than the default one. This means you can do lots of stuff yourself with the information provided, such as total to download and total downloaded, in addition to some events called at various stages of initilisation.

Download the Download Progress Bar example class here. I have commented as much as I can, and will try and put a demo together soon.

Other examples:

• http://www.onflex.org/ted/2006/07/flex-2-preloaders-swf-png-gif-examples.php
• http://flexiblemyself.blogspot.com/2007/10/custom-preloader.html
• http://iamjosh.wordpress.com/2007/12/18/flex-custom-preloader/
• https://defiantmouse.com/yetanotherforum.net/default.aspx?g=posts&t=82
• http://www.gotoandlearn.com/play?id=108

I used the example to return a set number of days since one of our issues launched, by sending the function the number of days and the starting date.

/* This is a public static function so it can be called from my
utility class of useful converts and such! */

public static function returnDateXDaysFromY( x:Number , y:Date ):Date
{
  var xDaysFromY:Date = new Date(); // Date to return
  // I have removed a call to a function to set the time to zero, you can get caught out with summer time etc
  x = ((((x * 24)* 60) * 60) * 1000); // Turn days to miliseconds
  xDaysFromY.setTime( x + y.getTime() );
  return xDaysFromY;
}

Hopefully someone else out there will find this handy :)

I though I would be a good idea to write a few methods in my personal utilities class, simple stuff like returning yesterday, tomorrow or this time next week etc. After a bit of research I found that some time constants have already been defined in the Action Script 3.0 cookbook utils. If you don’t have it then these are the constants for various amounts of time.

	public static const MILLISECOND:Number = 1;
	public static const SECOND:Number = MILLISECOND * 1000;
	public static const MINUTE:Number = SECOND * 60;
	public static const HOUR:Number = MINUTE * 60;
	public static const DAY:Number = HOUR * 24;
	public static const WEEK:Number = DAY * 7;

With these handy chaps you can easily get a date variable for yesterday or tomorrow or in 7 days:

	//Replace DateUtilities. with this. if you are including them in your own class

	var yesterday:Date = new Date();
	yesterday.time -= DateUtilities.DAY;

	var tomorrow:Date = new Date();
	tomorrow.time += DateUtilities.DAY;

	var weekToday:Date = new Date();
	weekToday.time += DateUtilities.WEEK;

Neat hu!

In a rather large step backwards in marketing and buzz word… well, buzzing, Adobe have changed the name of Apollo (their code name) to Adobe Integrated Runtime or AIR.

I guess you could have seen this coming as the .air extension has been used for the install files since day one, although I thought Apollo was kind of cool.

To find out more check out the AIR info page and see what sorts of demo launch applications they have. The thing that is going to annoy me now though is people saying Adobe AIR, as Adobe will be repeated twice… but hey!

After buying some books (more on them later) and .net magazine (again more on that later) we made a quick exit and cursed the fact we couldn’t get tickets for the, “sold out” development evening.

By chance one of the organizers from the event popped into our offices to check out Ceros and Tom managed to ask him to get us on the guest list for the evenings event, result!

To be honest I didn’t know what to expect, and apart from Aral I knew very little about the speakers. The discussion was chaired by John Davey who did a fantastic job, both entertaining and netural, dispite there only being about 30 people who actualy turned up, lucky we got in! The talk centered around Open Source, and what it really meant. Although discussion often focused on how it’s a viable thing to do, why do it, why care as a user, and various other discussions that will never be answered in my mini review at 11:52 at night… or in fact ever!

I was lucky enough to have a long talk with David McAllister, Director of Standards and Open Source, at Adobe, after the formal discussions had ended (he was in the room when the term Open Source was coined!!!) which was fascinating, and to be honest left me feeling a little inadequate.

It was also great to catch up with Aral and meet Carlos Ulloa and Tink, oh and also get some free food, drinks… and a bag ;)