Archive for the ‘Flash’ Category

DU Visual Media Center Weblog

Friday, July 25th, 2008

I’m taking a moment to highlight the Visual Media Center at the University of Denver and the relatively new weblog maintained by its Director, Leslie Trumble.

The VMC works very closely with those of us on the DU VAGA development team and most of the feedback we receive about the application originates with users from this area.  This week, Leslie writes about two pretty large additions to the application environment; the inclusion of PicLens on digital object search results,  and a standalone application that I’ve been heavily involved in this summer called the DU VAGA Projection System.

What may be of interest to most of my readers is that the DU VAGA Projection System [VPS] is written using Flex and ActionScript 3 for deployment via Adobe AIR.  Though it is not the first application from the university built for the AIR runtime (see the Fridlyand Kiosk software), it is certainly the most complex.

The software takes advantage of a few AIR-specific capabilities including the ability to integrate with the operating system in terms of hardware discovery (and the flexibility to adapt to various configurations), the power to read and write files to a local hard drive, and extensive use of windowing technology.  This application also makes heavy use of Coldfusion 8 and Flash Media Server 3.

I may be writing more on this software and other efforts at the university in the near future.  In fact, many of my recent posts were born directly from work on this specific project.

Visit Unmasked.

Creating a Splash Screen in AIR

Monday, July 21st, 2008

A lot of desktop apps have a splash screen that brands the application while it is loading or performing other processes in the background. Adobe AIR does not have a direct mechanism for this- but the feature can be easily achieved with some nice windowing action.

There are a number of steps to take when preparing your app for this sort of thing. This example was adapted from a much larger application and there may also be some imports and properties that are not necessary for our narrow purpose here. I’m sure my method is not the only one and I’m not saying it’s perfect either! Taking the following steps should produce a similar result though:

1) Edit your application descriptor file to set the initial main application window x and y positions off screen.

1
2
3
4
<!-- The window's initial x position. Optional. -->
<x>-1000</x>
<!-- The window's initial y position. Optional. -->
<y>-1000</y>

2) I have also set an applicationComplete event within the WindowedApplication node.

1
2
3
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:custom="components.*" 
	layout="absolute" horizontalScrollPolicy="off" verticalScrollPolicy="off" 
	showFlexChrome="true" applicationComplete="{init()}" currentState="SplashState">

3) The init function reads as follow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
private function init():void {
	mainWindow = this.stage.nativeWindow;
 
	var splashWindowinitOptions:NativeWindowInitOptions = new NativeWindowInitOptions();
	splashWindowinitOptions.transparent = true;
	splashWindowinitOptions.systemChrome = NativeWindowSystemChrome.NONE;
	splashWindowinitOptions.type = NativeWindowType.UTILITY;
 
	splashWindow = new NativeWindow(splashWindowinitOptions);
	splashWindow.title = "Splash Example";
 
	appSplash = new SplashScreen();
	hiddenCanvas.addChild(appSplash);
	hiddenCanvas.removeChild(appSplash);
 
	splashWindow.stage.scaleMode = 'noScale';
	splashWindow.stage.align = 'topLeft';
	splashWindow.stage.addChild(appSplash);
	splashWindow.x = Screen.mainScreen.visibleBounds.width/2 - 300;
	splashWindow.y = Screen.mainScreen.visibleBounds.height/2 - 200;
	splashWindow.width = 600;
	splashWindow.height = 400;
	splashWindow.activate();
 
	mainWindow.visible = false;
 
	splashTimer = new Timer(1000, 2);
	splashTimer.addEventListener(TimerEvent.TIMER_COMPLETE, removeSplash);
	splashTimer.start();
 
	this.removeEventListener(FlexEvent.APPLICATION_COMPLETE, init);
}

The NativeWindowInitOptions are hugely important as they will render the window chromeless and transparent.

“SplashScreen” is a custom component which simply holds material for display- such as an image or text or whatever you want users to see as a visible splash screen.

Since I am using the ActionScript NativeWindow class here and not the Flex Window component, we must add the display object first to a hidden element in our Flex application. It’s weird but is something you must do if you want your splash screen to be visible when doing it this way.

We then activate our splash window and make the main app window invisible. In the case of this example, I have a timer that runs to determine when to remove the splash screen and bring up the main app window. In most cases, this would instead be reliant on some background process such as a data load.

4) Next comes the function that fires when we want to remove the splash screen and start using our app.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
private function removeSplash(e:TimerEvent):void {
	mainWindow.x = Screen.mainScreen.visibleBounds.width/2 - mainWindow.width/2;
	mainWindow.y = Screen.mainScreen.visibleBounds.height/2 - mainWindow.height/2;
 
	mainWindow.visible = true;
	mainWindow.activate();
 
	splashWindow.stage.removeChild(appSplash);
	splashWindow.close();
	splashWindow = null;
 
	currentState = "LoadedState";
	splashTimer.stop();
	splashTimer.removeEventListener(TimerEvent.TIMER_COMPLETE, removeSplash);
	splashTimer = null;
}

So, we reset reposition the main window onto the screen, render it visible again, and activate it. This will cause it to spring to life and now the app is running for our user. We then perform some cleanup routines on the splash screen and timer objects so they will not linger in memory any longer.

There we have it! I’ve made the source available as a Flex Project Archive.

Flash Player 9 FSCommand() Bug

Friday, September 21st, 2007

I’m working on a rather large AS3 project through Fractured Vision Media which relies on the flash.system.fscommand package to properly transmit data from the application to its container layer. Unfortunately, we’ve come across a bug in which FSCommand calls are ignored! Through some quick research (e.g. Google) it was discovered that more than a few others have come across this problem as well.

The workaround for now is to be sure you are generating unique argument strings to pass through the FSCommand. This could involve changing the case of different characters in your argument string or appending a unique ID bassed off of something like the current time.

Does anyone know the status of this bug? Will it be patched in “Moviestar”? Seems pretty major to me…