Archive for AIR

Flex 3.5, AIR swc & ANT tasks

Posted in Actionscript, AIR with tags , , , on June 8, 2010 by andkrup

I am stuck on Flex SDK 3.5 at work.

Today I wanted to create a code library swc file with some AIR-specific classes and I wanted to write a build file.

It seems that there isn’t an acompc-task included in the Flex 3.5 sdk (3.5.0 build 12683), so I was using the exec-task and wrote arg-tags to expand the list of included library-paths.

External-library-path is a nice alternative to library-path if you do not want to redistribute code existing in other swc files, but I got into some problems when I wanted to use -external-library-path, because the syntax apparently has to be a bit different.

This syntax is valid but doesn’t work:

<arg line='-external-library-path "path/to/my.swc"' />

This syntax is also valid, but appears to be similar to setting the attribute append to “true” in the compc ANT-task:

<arg line='-external-library-path+="path/to/my.swc"'/>

If you have tried to substitute the library-path option with external-library-path you might have found that you have to set append=”true” and apparently this is how the command-line version looks like.

Advertisements

Code distribution strategies

Posted in Actionscript, AIR, Development, eclipse, Flash Extensions with tags , , , , , , , , , , , , on December 11, 2009 by andkrup

With the 4th version of Adobes Creative Suite (CS4), it is very easy for developers to manage code distribution.

The SWC code component

Using the compc compiler from any Flex SDK, you can create a swf code library file (a compiled zip file, containing your compiled classes in an swf file + an xml file describing the contents of the zip file). This shouldn’t be any news for the experienced flash developer.

Distribution

Managing and distributing swc files is easier if you use some of the tools also provided by Adobe CS4, but first lets talk about what kinds of issues we have distributing code library files.

Ease of installation

It is much simpler to click once on a mouse button than it is to follow a lengthy set of instructions. Technical people, such as developers are more or less used to follow a step-by-step guide so we might be inclined to issue step-by-step instructions that really only help to scare non-technical people away.

A similar problem is when you want to update.

Ease of everyday usage

Working with AS3-based projects, developers have it easy with Version Systems, and if everybody in the shop knows how to work with the chosen VS, code distribution and updates aren’t really an issue.
Working with designers, externals and other kinds of people might put up some restrictions in that you can’t trust people to know how to work with the VS. This means that you must find another way to distribute your code library.

MXP Flash extension files

Bold designers usually have some experience downloading and installing extensions and Adobe has put a lot of work into the extension architecture, so devising a strategy upon the mxp file seems a good idea.

Distribution Strategy

The main strategy is this:

  1. Create the Extension so it contains all the functionality required for people to use the code library and some easy ways to do it (for instance; a JSFL script that inserts the path to your swc file in the current *.fla file in the flash IDE).
  2. Deliver the Extension online.
  3. Facilitate an easy way for users to get update announcements.

1. Creating the MXP extension

MXP Extension files can be made easily with the Adobe Extension Manager2. You can google tutorials on how to create MXP flash extension files, if you don’t know how.

The important part is the <files /> tag. This is where the meat of your extension is.

My best take on what file locations are good to use atm are the Flash configuration folder which you can refer to by using the ‘$flash’ template-variable:

<file source = "as3codelibrary.swc" destination = "$flash/Libraries" shared="true"/>

This will install your swc file ‘as3codelibrary.swc’ into the end-users Flash config folder: (OSX) /Users/<user>/Library/Application Support/Adobe/Flash CS4/en/Configuration/Libraries/as3codelibrary.swc, (XP) C:\Documents and Settings\<user>\Local Settings\Application Data\Adobe\Flash CS4\en\Configuration\Libraries\as3codelibrary.swc.

The Configuration folder is really a mess and if anyone knows of any guidelines as to how to treat these sub-folders, please share.

Along with the swc file I also put a JSFL script enabling the user to add the swc into the compile-path of the current *.fla file. This is quite simple:

var myDoc = fl.getDocumentDOM();
myDoc.libraryPath = "$(UserConfig)/Libraries;" + myDoc.libraryPath;
fl.trace("library paths: "+myDoc.libraryPath);
(Notice that in JSFL, we can refer to the end-users Configuration folder by the variable $(UserConfig))

This file goes into the end-users Commands folder:

<file source = "jsfl/<jsfl filename>.jsfl" destination = "$flash/Commands/" shared="true"/>

, and will be available in the ‘Commands’ menu in the Flash IDE after it has been restarted.

2. Deliver the MXP extension online and facilitate updates

If you have ever tried to use Badger to distribute Adobe AIR applications and/or the ApplicationUpdater AIR packages, ou know how convenient it is to distribute applications online.

The basic idea is to do something similar. If you are a gamer and know Valves Steam application, you can catch my drift.

Steam is a small client that receives information about available content from the Valve servers and compares that information with already installed content.

Creating a small content distribution system that can monitor the status of installed extensions and notify the user if newer versions have been uploaded online is very similar.

This is possible because the Adobe Extension Manager saves copies of installed mxp files + a copy of the MXI file that was used to create the mxp file in a folder similar to the Configuration folder. AIR allows us to access the filesystem and parse the mxi-file for version data.

Have a look in the “Configuration/Extensions” folder: (Mac OS X) /Users/<user>/Library/Application Support/Adobe/Extension Manager2/Configuration/Extensions

Digital signage, Kiosks, cell phones and AIR

Posted in Uncategorized with tags , , , on November 6, 2009 by andkrup

I just thought: What if you could go to a record store, see the latest music videos on the big displays, buy the music via an interactive AIR application on the touchscreens  and transfer it to your iphone via bluetooth (or similar).

Why would you bother when you would be able to do exactly the same thing at home on the iTunes store?

Is digital signage something that will sprout and demand new exciting Rich (Internet?) Applications, or will evolution in mobile phones kill it off?

There is probably a big difference in selling physical and non-physical commodities. I assume Digital signage is a good thing (seen from an advertisers point of view) when the client is selling non-digital products. He needs a physical outlet. A store.

But then the creative guy will ask: Ok, people talk about how Digital signage delivers several advantages and all. I would like to do something new and unexpected. I’d like to do something interactive, cross some digital domains, maybe let people get something digital of value while at the physical store, that they can’t get at home while on the internets.

hmmm… this could spin some heads

Creating AIR applications with FDT

Posted in Actionscript, AIR, Bugs & Solutions, Development with tags , , on September 25, 2009 by andkrup

How do you create AIR applications in FDT?

By googling ‘fdt air’, you get these 2 fine links:

http://fdt.powerflasher.com/blog/?p=10

and

http://www.martijndevisser.com/blog/2008/building-air-with-fdt/

These posts are very nice introductions, but there is something you might want to check out.

Flex SDK version

If you decide to use the Flex SDK with the included AIR, you should use the descriptor xml file that is included with the SDK version you are using.

I got some “descriptor version does not match runtime version“- and subsequently “application filename must have a non-empty value“- errors, because the descriptor xml file format was changed.

Using the sample descriptor file included with the SDK, you will be certain that the format fits the adl executable.

Icon problems

I also encountered some difficulties with packaging icons. I got the error “error 303: Icon icons/AIRApp_32.png is missing from package”, which, as it turned out, comes out when there is a mismatch between where the icon files will be placed in the package, and the icon arguments in the descriptor file. It would be nice to look into this further.

One solution is to comment out any icon tags in the descriptor file, package and then unzip the resulting *.air file (as it really is only a zip file) in order to find the location of the icons. Then put that location into the icon tags and uncomment them in the descriptor file.