| Subcribe via RSS

NativeWindowInitOptions – configure your AIR NativeWindow

August 6th, 2008 | No Comments | Posted in AIR, Actionscript 3.0, Tutorials

In a previous post I listed some code to create and activate a NativeWindow in an Actionscript AIR project without really explaining what was going on behind the scenes. In this post, I’ll explain a little more about the NativeWindowInitOptions class, and how you can control the appearance and behaviour of the NativeWindow that you create.

The code I used in the previous post was this:

var windowOptions:NativeWindowInitOptions = new NativeWindowInitOptions();
var mainWindow:NativeWindow = new NativeWindow(windowOptions);

Fairly obviously, the NativeWindow constructor accepts an instance of NativeWindowInitOptions as its first parameter. In the previous example, I’m not doing anything fancy with the NativeWindowInitOptions instance that I create, I just create a new instance of the class and pass it to the NativeWindow constructor. As a result, all the various properties will have their default values, and the NativeWindow will be totally default. How terribly dull. Here’s a list of properties of NativeWindowInitOptions that you can play with to control how the NativeWindow will look and behave when it’s created….

Continue reading NativeWindowInitOptions – configure your AIR NativeWindow »

Tags: , ,

Creating AIR projects with Actionscript

August 4th, 2008 | No Comments | Posted in AIR, Actionscript 3.0, Flex Builder

If you’re using Flex Builder 3, and you want to create an Actionscript project which will eventually deploy as an AIR application, you’ll quickly find that this option isn’t available when using the Actionscript Project Wizard. There are plenty of posts out there detailing a workaround (for example, see here).

I followed the workaround steps and it seemed to work OK, but when I first published my application… nothing happened. A little icon appeared in my dock, mysteriously titled adl (which I’ve since discovered stands for the AIR debug launcher), but no windows of Flash-based goodness appeared anywhere. After much digging around, I came across this entry in the Adobe Bug System and found the answer buried away in the comments.

When I’d previously created Flex-based AIR projects, I hadn’t really appreciated that the Flex framework was handling all of the window-creating shenanigans on my behalf. Just by making my root MXML tag a WindowedApplication, instead of a “normal” Application, the main AIR window was being created and activated automatically. When you’re not using the Flex framework, you have to do this stuff yourself.

As it turns out, the two most important classes involved in this process are flash.display.NativeWindow and flash.display.NativeWindowInitOptions. A NativeWindow is essentially the window you see on your desktop when you run an AIR application. This includes the menu bar (if any) and the system chrome (if any).

To successfully create and launch a window in AIR, you’ll need to create and activate a NativeWindow object, and then add your Document class (or some Sprite, at least) to that Window’s stage, accessible through the NativeWindow’s stage property. The code will look something like…

// create an instance of NativeWindowInitOptions to pass to the NativeWindow constructor
var windowOptions:NativeWindowInitOptions = new NativeWindowInitOptions();
// create the window
var mainWindow:NativeWindow = new NativeWindow(windowOptions);
// activate the window
mainWindow.activate();
// adds "this" to the stage of the Window we have created
mainWindow.stage.addChild(this);

This code will create and activate an AIR window with default options, and add someSprite to the stage of that Window. From then on, you can continue with your code just as you would in a traditional Flash application and all will work as expected.

I’ll post more about the NativeWindow and NativeWindowInitOptions classes at some point soon….

(Update: Check out this post for more information about the NativeWindowInitOptions class)

Tags: , ,

Flash plays certain MP3s back at double speed – why?

July 27th, 2008 | No Comments | Posted in Actionscript 2.0

A colleague and I recently found some odd things happening with dynamically loaded audio in an elearning application we have been working on. The external MP3s seemed to be playing back at double speed, and as a result the audio was a hideously high-pitched mess. The weird thing was, this wasn’t happening on every machine. Some computers, including mine, would play the audio back fine but a couple of other people were reporting the same problem so we had to look into it. Bah.

After much fiddling, we reached the following conclusions:

  • Flash seems unable to handle MP3s encoded with a variable bit rate (VBR)
  • Flash seems unable to reliably handle MP3s which have a sample rate which is not 44,100 Hz, 22,050 Hz or 11,025 Hz.
  • Additionally, it seems possible that there are certain bit rates which are also not handled well by Flash. We’ve tested files successfully at 40kbps, 80kps, 120kbps (and many other multiples of 40).

(Note: This was happening in an application built with Actionscript 2.0 for Flash Player 8. I haven’t had a chance as yet to see if the same problem occurs in SWFs running in AVM2)

While the problem of the audio playing at double speed did seem fairly hard to recreate, we did find another way of highlighting the problem. The JW Media Player is a popular, open-source MP3/FLV Player and can see be seen in-use all over the internet. From our tests, ‘incorrectly’ encoded MP3 files can also create a problem when played as part of a playlist in the JW Media Player. If the user is listening to one of these MP3s, and moves the seek bar somewhere between half-way and the end of the file, the Media Player incorrectly decides that the MP3 has finished, and automatically moves to the next item in the playlist. Without looking into the code in more detail, this kind of assumes that the information Flash is broadcasting about the MP3 (for example sample length, or current position.) is incorrect, which is causes the MP3 to finish prematurely. Re-encoding the audio to match the criteria listed above will always fix this problem.

(Note: Current versions of the free Audio editing software Audacity, used in tandem with the LAME MP3 encoder, do not allow you to choose the bitrate of the exported MP3. However, the Beta version of Audacity 1.3 does offer that functionality via the Options button in the Export Dialog. The Beta version of this software can currently be downloaded from http://audacity.sourceforge.net/download/.)

Tags: , , ,

XML-RPC in Actionscript 3.0 – couple of gotchas

July 25th, 2008 | 2 Comments | Posted in Actionscript 3.0

As part a recent project, I’ve needed to integrate a Flex 3 application with an existing XML-RPC webservice. Over the years I’ve not done a huge amount of webservice integration with Flash. In the past I would typically choose to send data back and forth from the server using the built in XML or LoadVars objects available in Actionscript 2.0. On a couple of projects, I ended up using the Flash Remoting API and AMFPHP to achieve what I wanted and everything turned out pretty well, and once I integrated an application with some .NET SOAP webservices. But XML-RPC was a new one on me.

Anyway, after a bit of research, I was a little surprised to discover that XML-RPC hasn’t already been supported by the Flex framework, but after looking around I came across as3-rpclib, an open-source library that not only supports XML-RPC, but also AMF0 and JSON-RPC (I’ve currently only used these classes with XML-RPC, so can’t comment on the other formats implements).

So far, the classes have worked really well for me. However I did hit a couple of stumbling blocks along the way which I’ll attempt to detail here.

Continue reading XML-RPC in Actionscript 3.0 – couple of gotchas »

Tags: , , , ,

PureMVC – Multicore vs Standard / Singlecore

July 23rd, 2008 | 2 Comments | Posted in PureMVC

I’ve recently started using the Actionscript 3.0 Multicore implementation of PureMVC in order to use the framework within a modular Flex application. At the time of writing, most of the PureMVC examples and tutorials online are relevant to the Standard, or Singlecore,  version of the framework.

In general, the methodology and syntax is indentical across both versions of the framework. There are, however, a couple of minor differences which are pretty important, as without understanding these little quirks, many of the sample applications built using the Singlecore implementation will break when ported to Multicore.

The Standard version of PureMVC uses Singletons to provide access to the framework’s core actors. Within the framework, access to the Facade, Model, View and Controller are all provided using a standard getInstance method. To allow multiple instances of the framework to co-exist, the Multicore version of the framework uses Multitons, and then access to the various actors is provided within the framework by passing a unique instance key to the getInstance methods. The idea is simple – each separate instance of the framework has its own unique key, and so multiple instances of the actors may co-exist without interfering with each other.

Continue reading PureMVC – Multicore vs Standard / Singlecore »

Tags: , ,