First, if you don’t know what I’m talking about, check out the news. I think the best explanation comes from Mike Chambers’ Blog and a corresponding post on the Flex Team’s Blog.

Don't panic! Take a deep breath and look at this cute bunny

Not much has changed with the Flash Platform

If you read closely, not that much has really changed. The problem is perception. Let’s review what is going away and why it’s not as crazy as it might sound.

Mobile Flash Player

Adobe is discontinuing work on the mobile Flash Player. I don’t know the numbers of people building Flash content for Android but I suspect it’s not incredibly high. I would also wager that even Air on Android/iOS is still far from critical mass, but Adobe say they will continue to support this. The desktop Flash Player will stay the same and for the foreseeable future continue to surpass HTML5 in features and cross-platform functionality.

Another way of saying this is that the Flash Platform remains the best choice for the tasks that it was already the best choice for. Mobile was never one of these and some applications, like video players, may have lost that title to HTML5. But in cross-platform, rich-media, deeply interactive experiences on the web, Flash is still ahead of the competition.

Flex is still here

Adobe is discontinuing its support for the Flex SDK. However, it will stay around as an open source project (it was already open source.) It may never get better than it is already, which so far has been good enough to become the platform of choice for many Flex developers.

Flex cannot get any worse than the next version 4.6, which you were probably looking forward to until today. And you know what, that’s okay. We don’t need to be so obsessed with the next thing that we change careers because the next next thing has an uncertain future. I happen to know of some projects that are still using Flex 3 and will probably never upgrade. Why? The user doesn’t know the difference between mx and spark skins.

It may also get better after being untethered from Adobe and in hands of the Flex Community. In other words, we’re in charge now. The Spoon community, who is inheriting the Flex project, already have plans to make a version 5.x.

Fear itself

The real issue now is the way the public will preceive this news. This announcement has sapped the confidence of a lot of people, customers and developers alike. In my opinion, it’s not the time for us to decry Adobe as evil jerks. It is a time for us as experts to try to help our clients, companies and the public to make sense of the news. It’s time to remember that Flash is just a tool in the arsenal of an interactive developer. In fact, Flash’s popularity, due to largely political reasons, has already been on the decline for a while now. But, it will certainly be dead if the Flash users themselves don’t believe in it.

The next time a client wants an awesome, interactive video, 3D puzzle game, website thing I will still recommend Flash. I don’t want to have him tell me “it has to be HTML5″ because he read online that “Flash is dead.” In fact, I think it’s our job to talk about its strengths and its weaknesses in a totally objective way. We should all dwell in the middle ground between Adobe zealotry and jumping on the next bandwagon.

Your next job

I feel hopeful that the shit will not hit the fan, at least not immediately. That being said, I am always an advocate of looking at other technologies and keeping those abstract coding skills honed. Good developers are in a prime position to port our skills to whatever platform comes next, and those skills are almost always in demand. Even HTML5 (JavaScript) apps share a very similar language with AS3 (really AS1). I was able to pick up JQuery and build my first HTML5 project in a matter of a day or two.

As Mike Chamber’s writes:
“I think it is a HUGE opportunity for the Flash community. As browser support for richer content and motion graphics improves, so will demand for designers and developers who have experience working with motion graphics on the web. The Flash community has been doing this type of work on the web for over a decade and is uniquely qualified to fill demand for similar work in the browser. I don’t think it is a coincidence that some of the most cutting edge motion graphics work being done in HTML5 today is being done by developers and agencies with extensive experience in Flash (such as Grant Skinner, Branden Hall, Big Spaceship, etc…).”

Joel Hooks adds some great notes on this in his blog post. I’d like to also add HAXE, Java, C# and Dart to the list of languages that you should be able to pick up with little effort.

The Community

In LA, our local Flex group shut down abruptly after this news was released. I personally feel this was very hasty indeed and wrote a letter about it upon which this blog post was based. I see that a lot of people are really pissed and their identities are in question. If you’re in this position, I would suggest instead of jumping ship, why not continue to talk about how this will impact our jobs and what skills we can port to other platforms. If there really are people out there who are going to lose their jobs over this, and I think it’s too soon to say, we should still be able to support each other as a community.

Even with all this positivity, I still have to agree with @neurofuzzy “Anyone who has ‘Flash’ in your job title, scratch it out and write ‘Interactive.’” It’s something we should have all done a long time ago because I believe we are more than just Flash dudes.

I’d love to hear your thoughts on all of this. Please leave comments. It will be very interesting to look back on this post in 6 months and see whether I was right to keep a cool head or being terribly naïve.

Runtime Environment

SWF Files
Swf files are compressed, multipurpose packages designed to contain the following data: raster and vector graphics, video, audio, text, fonts, animation, and actionscript code. Swfs can be loaded at runtime whenever necessary and can use both static and dynamic linking based upon the compiler settings. The runtime environment uses security sandboxes for loaded swf files. The security settings primarily limit the extent of filesystem access and cross-domain access that swf files can use. Adobe has provided the swf file format spec and has recently provided the FLV video format spec and has declared that they will provide the RTMP spec as well.

Flash Player & AVM2
The Flash Player runtime is a very light-weight, virtual machine and handles system calls. The Flash Player includes both AVM1 (AS1, AS2, for Flash versions 1-8) and AVM2 (AS3 for Flash 9,10+) which processes compiled Adobe Bytecode (ABC). The term AVM stands for “ActionScript Virtual Machine”*. The Flash Player uses a Deferred Reference Counting (DRC) mechanism combined with a conservative mark/sweep garbage collector. The Adobe VM uses both JIT compiling and code interpretation and may benefit from compile-time bytecode optimizations based upon compiler input parameters. AS3 computational performance is generally closer to Java than Javascript [source]. The player also maintains a variable framerate that reflects the time consumed for each frame update [source]. Each frame update consists of multiple stages that include internal player processing, rendering, and author script processing. The program framerate is the principle metric reflecting application performance.

Development Environment

Actionscript API
The Actionscript API is divided up amongst the Adobe AIR environment, the Flex environment, and the Flash environment and the Flash Player. The source for all the packages are divided up amongst swc files. Swc files are pre-compiled catalogs of classes and assets. They are similar to swf files but they are used for compile-time dependency resolution. Furthermore, the native swc’s predominantly contain code and not visual assets. An overview of the Actionscript packages is kept up to date in the Adobe Live Docs.

The Flash IDE
The Flash IDE was designed for designers, artists and animators. So, it is equiped with a layer system which reflects the stage display list and a hierarchical timeline which reflects the temporal nature of the runtime. The objects placed on the stage are represented by the timeline and can be “tweened” (using runtime interpolated 2D geometric transformations or custom shape morphs). The same timeline is also used for object creation and destruction. All stage instances are confined to a small set of native data types including: MovieClips, Sprites, Shapes, TextFields, Videos, and Bitmaps. The IDE also has a library that contains source objects for all stage instances and even instances that aren’t used on the stage. Flash projects often have several build targets (compiled swf files) that use parts of the project codebase. After Macromedia was purchased by Adobe, the Flash authoring environment has been updated to provide much better interoperability with the Adobe Creative Suite.

Adobe Flex Builder
Flex Builder is an Eclipse-based Actionscript IDE for writing and compiling swf files. Flex Builder is primarily designed to build “Flex” projects which can be written in an interface tagging language known as MXML. MXML is a declarative XML langauge used to define interface elements in a project. MXML files provide the “view” in the MVC software design pattern. Flex Builder also provides plenty of useful features like code completion, syntax formatting, active debugging, memory profiling, and project building that expose errors and warnings during development time. Because the Flex framework is not bundled with the Flash Player, Flex projects must statically link to all swc assets specific to Flex which amounts to greater than 500kb. This is very unnatractive for most users, thus Adobe has provided means by which the download can be significantly decreased. Flex Builder is also used to deploy applications for the Adobe AIR platform. Adobe AIR is a desktop runtime that combines webkit with the AVM2 portion of the Flash Player. AIR can be likened to a closed source Java SE runtime but provides a smaller learning curve and greater accessibility than what comes with the Java ecosystem.

Compiler
Since Adobe has launched the Flex platform they have provided free access to their Flex and Actionscript compiler and SDK. They have also provided open source projects under the Mozilla public license. The compiler (mxmlc) provides an impressive amount of flexibility and customization for swf compiling. It can be configured with command line options or a configuration XML file.

* correction 09-12-2009, I had previously stated that the term AVM meant “Adobe Virtual Machine”, this is a mixup. It actually means “ActionScript Virtual Machine”. Thanks dbam.

In the spirit of playing fair, I’d love to hear about your experiences with Zinc – good, bad, or obselete.

I may be in the (rare?) position of being highly interested in two disparate technologies. The first being an online scripting language standard governed by ECMA (used in Javascript & Actionscript). The second, an open standard for real-time rendering governed by the Khronos Group (OpenGL). In recent days these two languages have faced most unfortunate developments. First the ECMA script 4…

On Nov 7, 2006 Adobe announced the contribution of their ECMA scripting engine to the open source community under the name “Tamarin”. Tamarin is also being used as the JS scripting engine for Mozilla Firefox under the name “SpiderMonkey“. It seemed like a good idea at the time of release. But now look at the situation: we have AVM2, directly connected to Firefox AND the ECMA committee –slowing the progress of Actionscript and the Flash Player (and the internet for that matter). Needless to say, this is a disappointment. But it doesn’t end there…

Though having plenty of contributors, the realm of real-time rendering is primarily controlled by Microsoft, Nvida, ATI/AMD, Apple, and (more recently) Intel. Microsoft hasn’t really contributed to the Khronos Group because long ago they decided to pursue their own 3D graphics rendering API known as Direct3D. The evolution of OpenGL has become painfully slow while DirectX and Direct3D are becoming the (de-facto) standard. Finally, the Khronos group promised to improve the long lost API by introducing an object-oriented structure in stark contrast to its current state machine model. That was in October 2007. Last week the specification was finally unveiled and it remains largely the same. Not only is this a big let down, but it will definitely damage all future 3D software and game development releases for non-Windows platforms (including future consoles). Very unfortunate.

DISCLAIMER: Both of these developments are FAR more complex than what this post outlines -and there’s justification behind both developments. But on the whole, they both seem bad for everybody (or just me?).

Actionscript 3.0 and Performance Tuning

AVM2 Overview

There are definitely some big take-aways in these two documents. I would list them here, but then you might not read them for yourself! ;)

The first document is 74 powerpoint slides (prepared by Gary Grossman of Adobe) which is very useful for getting a quick understanding of AVM2 topics such as garbage collection, the benefits of strong typing, the Actionscript byte code (abc) format, the code interpreter and JIT compilation. For an AS3 developer this is a must-read.

The second document is a bit more dense. It contains 108 pages of more formally described underpinnings of the virtual machine. It focuses a lot on how your AS3 code will ultimately be run as processor instructions. Its a great follow-up to the first document. If you’re a geek, I would highly recommend reading this overview.

Take this FLA animation.

As you can see, there is a simple animation using a guide layer and labels on the key frames.

The following SWF uses KitchenSync to control the same ball animation. As you can see, the duration and easing functions of the animation can be controlled. You can even animate backwards!

See it in action.

The source that controls this is here.

package {
	import flash.display.MovieClip;

	import org.as3lib.kitchensync.KitchenSync;
	import org.as3lib.kitchensync.action.*;
	import org.as3lib.kitchensync.action.tweentarget.*;
	import org.as3lib.kitchensync.easing.Bounce;
	import org.as3lib.kitchensync.easing.Cubic;
	import org.as3lib.kitchensync.easing.Linear;
	import org.as3lib.kitchensync.easing.Oscillate;

	/**
	*	Demos the TimelineController which controls the animation of a MovieClip's timeline.
	*/
	public class FlashIntegrationTest extends MovieClip
	{
		protected var test1:MovieClip;

		public function FlashIntegrationTest()
		{
			super();
			// initialize kitchensync.
			KitchenSync.initialize(this, "1.5");

			// add a movieclip from the library
			test1 = MovieClip(new AnimationTest1());
			addChild(test1);

			// define the start and end frame with strings or ints or FrameLabel's
			var startLabel:* = "start";
			var endLabel:* = "end";

			// set up the TimelineController tween target.
			var tweenTarget:TimelineController = new TimelineController(test1, startLabel, endLabel);
			// Animate the ball with a linear ease.
			var tween:KSTween = KSTween.newWithTweenTarget(tweenTarget, "1s", 0, Linear.ease);

			// animate the ball backwards with a bounce tween
			var tween2:KSTween = tween.cloneReversed();
			tween2.duration = "4s";
			tween2.easingFunction = Bounce.easeOut;
			tween2.addTrigger(tween);

			// animate the ball with an oscillator
			var tween3:KSTween = KSTween.newWithTweenTarget(tweenTarget, "10m", "1s", Oscillate.sine);
			tween3.easingMod1 = 0.3;
			tween3.addTrigger(tween2);

			// start the animations
			tween.start();
		}

	}
}

Pretty cool huh? We’re creating a new TimelineController and setting the boundaries of the animation then passing it to a new KSTween object. Each of the three tweens use different parameters and are triggered by the end of the one before it.

You can download the entire thing and play around with it.

FlexBuilder may have its ups and downs but it still remains my pick for best AS3/MXML editor on the market (with TextMate not far behind). Part of the beauty of FlexBuilder is that it’s built on the Eclipse SDK, one of the most versatile and powerful IDEs available, which is not only free and open source, but boasts a wealth of third party plug-ins for every kind of (mostly Java) development. This article will take a look at some must-have plug-ins for doing Flex development as well as some tips for tricking out your development process.

As with all of our entries, your feedback, suggestions, corrections and additions are all more than welcome.

Disclaimer: This article applies to the Flex Builder Eclipse Plug-in version, not the standalone version. If you’re using the standalone version and would like to try these plugins out, I recommend installing the plug-in version. It’s a little harder to use but I think it’s more rewarding in the end. Also, this tutorial was written on the Mac version with Eclipse 3.3 and Flex Builder 3 beta 2 so your experience may vary slightly if you’re using Windows or something else. Furthermore, I am not responsible for any damages or loss of data or anything else that happens as a result of you following the advice in this article – nothing should go wrong however many plug-ins are buggy and may cause eclipse to perform poorly or crash.

Installing FlexBuilder Eclipse Plug-in

To install the FlexBuilder Eclipse Plug-in version you will probably want to first uninstall the FlexBuilder Standalone. You will also need to download and install Eclipse. Important: Eclipse is currently in version 3.3.1.1 at the time of writing. If you’re using FlexBuilder 3, good for you! Go and download the latest version (get the classic distro). However, FlexBuilder 2 does not work on Eclipse 3.3. You’ll need to download the older version 3.1 or 3.2 of the SDK which are hidden deep in the dungeons of the Eclipse Project site.

After Eclipse is installed you can proceed with the installation of the FlexBuilder plug-in. Additional installation instructions can be found on the Adobe Site.

Installing Plug-ins

If you take a look at the Eclipse plugin central you’re liable to notice two things right off the bat. First, there are a ridiculous number of plugins especially for really obscure branches of Java development. Second, the Eclipse site is completely ugly and it’s often incredibly frustrating to use. I’ll try to help you get to the juicy bits quickly.

By far the best way to install Eclipse plug-ins is to use update sites. Update sites allow you to select and download plug-in packages directly from the developer from within the Eclipse program. The update site URLs are notoriously difficult to find due to the Eclipse site’s confusing navigation. For example, I jut tried to get to the update site URL for Europa, a major Eclipse supported plugin, and it took about 4 minutes worth of clicking for me to find it (at best it takes 3 clicks). These elusive links to update sites should, in my opinion, be in big red letters on the front of every project page so in case Eclipse is reading this right now, WTF doodz!?

Once you have the update site URL take the following steps to search the site for updates:

1. Go into eclipse and click on Help > Software Updates > Find and Install… (Help menu? Again, WTF)
2. Select Search for new features to install
3. Click the next > button
4. Click on the New remote site… button
5. Give the update site a label and paste the update site url. Click ok
6. Make sure the site you added (and any other sites you want to update) are checked and click the Finish button
7. On the next screen you’ll see you can choose which features of the plugin you would like to install. For most plugins, you’ll probably want all of them so check the root folder. Note: you may see an error at the top of the window such as FooBar v.0.7 requires plug-in ‘org.eclipse.foobar.core’. If this happens, it can usually be fixed by clicking on the Select Required button which will automatically select the required features.
8. When you’re done selecting features, click Next >
9. ALWAYS CAREFULLY READ EVERY LINE OF THE EULA! then click I accept the terms of the license agreements and click Next >
10. Click the Finish button. You may be asked again about certain features during installation for which you can click Install All to keep going
11. When the installation is done, restart the Eclipse SDK

That’s it in just 11 tedious steps!

To get updates of already installed plugins choose Search for updates of the currently installed features at step 2 and follow the instructions above. If you install a plugin that conflicts with your setup or if you want to temporarily disable or uninstall a plugin, you can always go to Help > Software Updates > Manage Configuration… to manage your environment. Keep in mind that most plugins add new items to Eclipse preferences, the Window > Open Perspective dialog, the Window > Show View dialog or the File > New dialog.

A note about simultaneous releases – Europa, Ganymede, and Callisto

In 2006 the Eclipse Foundation decided to take ten of the most used plug-ins and wrap them into one release so that the plug-ins would update at the same time as the Eclipse SDK. This project was called Callisto. They considered it a great success so they did it again in 2007 and (confusingly) called it Europa. 2008′s project is called Ganymede.

Some of the plug-ins listed below are part of the Europa project (currently, the latest full version release). To install these plugins you will want to check the Europa update site which contains several projects but you should select only the ones you want to install.

Must-have Plug-ins

Notable Mention

One of the most important new features in Apollo is the ability to access the local file system directly. This provides developers with the ability to read and edit text or html files, save preferences locally, store application states as external files, serialize and de-serialize data and much more. This tutorial will cover the File API features in Apollo step-by-step and will serve as a supplement to the talk I recently gave at the New York Flex Users Group.

This tutorial will be presented in multiple sections. This first will cover the File and FileStream classes and the subsequent ones will cover the Flex components used for viewing and accessing the file system and serializing and de-serializing data.

Sample code

FileDemo.mxml

Here is a bit of sample code that walks through several common tasks when working with files. I’ve marked up the code with lots of comments to highlight what’s going on in each step. To run it, use this as the ApolloApplicaiton class for an Apollo project. Note: a new folder called ‘foo’ will appear on your desktop after running it.

Disclaimer and Upcoming features

The code and examples in this tutorial deal with the files stored on your local hard drive. Although none of the code is designed to do so, it may be possible to alter or delete important files with your Apollo application. You will be using this code at your own risk.

It’s also important to remember that Apollo is currently in an Alpha version and prone to changes including additional features. Here is a list of file system functionality not included in Apollo Alpha but planned for version 1.0 (according to Adobe Labs).

• Drag and drop support
• Copy and paste support
• Native file picker dialog boxes
• File extension registration
• Launching an application to handle a file type
• Security model for accessing files

The File class

A File object is a reference to a file or directory in the local file system. Files and directories both use the same type of object which results in a surprisingly simplified way of accessing data. This is an excellent example of the composite design pattern. You can distinguish files from directories by checking the isDirectory property of a file.

The file object also contains metadata for the file it points to (inherited from the FileReference class) including:

• name
• size
• type
• creation and modification dates
• application that created the file

The File class also contains static references to commonly accessed directories in the local file system. These access points are platform independent and should point to the appropriate folder for Mac or Windows systems. (i.e. userDirectory will be c://documents and settings/username for Windows and /Users/username for Mac.) In most cases, you will want to use one of these directories when creating files. These directories include:

• appStorageDirectory – Storage directory unique for each app.
• appResourceDirectory – Application’s install directory
• currentDirectory – Directory from whence the app was launched
• desktopDirectory – The current user’s desktop directory
• documentsDirectory – The current user’s documents directory
• userDirectory – The current user’s home directory

File instances contain methods for creating, copying, and deleting files and folders. These actions that could potentially slow the system down because of large file sizes come in two flavours – synchronous and asynchronous.
Synchronous actions pause all other ActionScript from continuing while they’re processing. For very large files, the app will appear to freeze up while the processing is going on. Synchronous actions, however, are much simpler to write since they don’t require event listeners.

Asynchronous actions use the event framework to notify the application when they are finished so that other code may continue to execute while the action is taking place. Most of these methods will fire a Event.COMPLETE event or a IOErrorEvent.IO_ERROR if they are successful or if they fail respectively.
A general rule is if you’re working with files that are less than 3MB, it’s probably safe to use the synchronous methods. If there is a chance your file sizes will be larger, or if you want the added robustness, use asynchronous.
Here’s a list of methods that come in synchronous and asynchronous forms:

The FileStream Class

The File class provides a reference to a class but in order to work with the data inside the file, you’ll need to use a FileStream object. FileStreams allow you to open a file, specified by a File object. You can choose from four file modes for reading, writing, appending (writing to the end), or editing. To do this, you can use the open() method of the file stream.

Once a file stream is open, you will be able to call one of the many read or write commands to add data or retrieve it. In this case, we’ll use UTFBytes to write string data.

Use the close() method to close the file once you’re done writing to it.

var file:File = File.desktopDirectory.resolve("foo.txt");
var stream:FileStream = new FileStream();
stream.open(file, FileMode.WRITE);
stream.writeUTFBytes("bar");
stream.close();

OK. That’s all for now. Make sure you download the sample code if you haven’t already – the comments there explain much more about the File and FileStream classes.

Next time, serializing AS3 objects to a file.

Additional resources:

• Apollo live docs
• Apollo for Adobe Flex Developers Pocket Guide

I’m pleased to announce the first alpha release of ApolloMail, a cross-platform POP3 / SMTP e-mail client written in Apollo (obviously) in under 500K (and most of that is my gratuitous about banner). It’s just the beginnings, really, but here is a short feature matrix:

• Authenticated POP3
• Authenticated SMTP
• MIME multipart emails
• HTML e-mail rendering
• Image attachments
• Base64 decoding
• Quoted-printable decoding

Features that may be added very soon are:

• Local message store
• HTML e-mail composing
• Rich Text rendering
• Better attachment handling
• Far more robustness

IMAP and SSL are less likely to be added soon. I would like to also use this as a platform to do something new with email, including several unique views which visualize your e-mail life graphically and in three dimensions. Otherwise it’s just another boring e-mail client.

E-mail has been around since 1971 (that’s ten years longer than me!), and it’s been built upon time and time again. I learned a ton about how e-mail works by building this app. On the other hand, I am sure I haven’t covered every kind of e-mail, POP server, or SMTP server; chances are fairly good you will come across an e-mail that this client doesn’t handle. Don’t panic It’s just an alpha. In addition to mail rendering, the error handling while communicating to the server could be better. If you are experiencing trouble, watch the Activity window. Further, the windowing built into this version of Apollo is a hack, so many Flex components don’t work correctly.

There are a number of interesting technologies in Apollo that this app takes advantage of, which I will be sharing all of in the coming days. First, it leverages my windowing framework which I discussed in a bit of depth before. It logs to a file using the File Logging Target I published earlier. It also uses another simple but awesome technique to implement the activity window — a String logger which exposes its cumulative log messages as a bindable variable — so the activity window is a TextArea bound to a log target which filters only a specific category of logging information (while all logs are saved to disk). It extends an abstract preferences class which makes it a snap to bind to, serialize and deserialize application preferences to disk. And of course, it makes heavy use of binary sockets and regular expressions made possible by Flash Player 9.

I’ll be writing more about the technology involved, and sharing more of the source, in another post or two. For now, grab the Apollo runtime if you need it (link has mandatory registration), and take ApolloMail for a spin! Cheers!

Update: This application is made for the Apollo Alpha. If you have the AIR Beta runtime, it will not work. The next version of ApolloMail will be upgraded for this release of the runtime.

ApolloMail (ZIP, 486k, ZIP decompresses to an AIR file, open the AIR file after installing the Apollo Runtime.)

Well, I don’t know why this wasn’t included with Apollo, but it was certainly easy enough to add in. :) I created com.partlyhuman.apollo.logging.FileTarget so you can use the Flex logging framework while logging to a file. It supports all the options of TraceTarget (livedocs), and you can also (optionally) specify a custom filename to log to, or force it to append log output across sesssions.

Here’s how you might put in a file logging target in MXML:

<logging:FileTarget
	filename="error.log"
	append="false"
	level="{LogEventLevel.ERROR}"
	includeDate="true"
	includeTime="true"
	includeCategory="true"
	includeLevel="true"/>

That’s showing off a lot of the options. You could just do <logging:FileTarget/> and all would be fine. And if you haven’t checked out logging in Flex, it’s pretty nice (livedocs). All logging events have a category, so you get a logger for that category then call the appropriate level on it, or call log with the level as an argument. For example:

Log.getLogger("com.partlyhuman.demoapp.MainController").error("initialization failed!");
Log.getLogger("com.partlyhuman.demoapp.Bubble").info("bubble popped!");

You don’t have to be so verbose in your categories, but that’s one way to use it.

This is gonna totally become like, a thing, but… happy logging!

com.partlyhuman.apollo.FileTarget View Source | Download (.as, 3k)

Application windows are windows that can always be brought up, like an activity window, or an about window. When you create an application window, it is created and hidden. Pressing the close button on the window is captured to hide the window rather than allowing it to be destroyed. Thus, it occupies a permanent position on the Window menu.

Document windows are windows which can be created and destroyed. You can have many instances of the same view class. These are useful for new mails or text files or what-have-you.

The main window has a special use. When you attempt to close it, it attempts to close all the child windows as well — so you can have an opportunity to save your unfinished document windows.

This is the windowing toolkit at work on an Apollo app I’m finishing up now. File→New Mail… creates a new document window with the compose view, and adds it to the Window menu. As you change the subject, the title of the window and its name in the Window menu are updated. The Window menu also permanently has several application-wide windows which the close button appears to close. The Window menu brings them and any other window back, even if they are minimized, hidden, or stacked on the bottom.

After the cut, let’s take a look at how this is set up in code.

First, we’ll add the application windows somewhere inside our app’s initialization:

var wm:WindowManager = WindowManager.getInstance();
wm.newApplicationWindow("About", AboutView,
   {maximizable: false, resizable: false, minimizable:false}, 620, 300);
wm.newApplicationWindow("Application Window 1", TestView1,
   {maximizable: false, resizable: false}, 300, 100);

That part looks pretty much like the original window manager from the last post. Now let’s see how we set up a menu item to create new document windows. Here’s the (abridged) XML source of our menu:

protected var menuBarXml:XMLList = <>
	<menuitem label="File">
		<menuitem label="New Mail..." data="newDocument"/>
		<menuitem type="separator"/>
		<menuitem label="Exit" data="exit"/>
	</menuitem>
	<menuitem label="Window"/>
</>;

And the menu bar:

<mx:MenuBar width="100%" id="menubar" labelField="@label"
   itemClick="invokeMenuItem(event.item as XML)"/>

And the event listener:

protected function invokeMenuItem(item:XML):void
{
  var str:String = item.@data;
  switch (str)
  {
    case "newDocument":
      WindowManager.getInstance().newDocumentWindow(ComposeView, "New Mail");
      break;
    //... more cases ...
  }
}

That’s all you have to do to make a new document window! It’s automatically created and tracked by the WindowManager.

Now let’s see what it took to make that empty Window menu live. There’s a utility class, WindowMenuAddon, that takes care of everything for you. All you have to do is create it and give it references to the MenuBar and the node within your menu XML to populate, and it does the rest:

var windowMenu:XML = menuBarXml.(@label == "Window")[0];
new WindowMenuAddon(menubar, windowMenu);

I was pretty happy with how simple this made dealing with windows in the application I’m building. You’ll see that there’s a bunch of methods that let you mess around with windows after they’re created, too, and without bothering to do your own bookkeeping on where they are.

This code was all written last night and I still need to document it and clean it up a little bit, but here it is.

com.partlyhuman.apollo.windowing.* Browse Source | Download (.ZIP, 7k)

I’m developing a window manager to make things much easier for Apollo apps. The full window manager will be up shortly. For now, I have created a simple window manager, that wraps up the many steps necessary to create a window containing a Flex view (and clean it up on destruction!) into a really simple singleton class. The more fully-featured window manager will use this class, but it can be very helpful on its own. It makes creating new windows with Flex views a one-line operation:

var aboutWin:NativeWindow = WindowManagerSimple.getInstance().newWindow(AboutView, "About", {maximizable: false, resizable: false}, 300, 100);

You can use either a class name or a UIComponent instance for the view, and all the other parameters are optional. The window options parameter can accept a NativeWindowInitOptions object or an anonymous object of properties that override the defaults for brevity. See the source file for more info, Javadoc-styleeeee.

Next: A more complete window manager, including application and document windows. Read on.

com.partlyhuman.apollo.WindowManagerSimple View Source | Download (.ZIP, 6K)

At least mine eyes did not deceive me about the other feature I really am looking forward to, native menu bar support. This is more of an issue for the Mac platform since menus are already grouped with the main application window in Windoze.

So these two limitations kind of throw a wrench in what I was trying to do… I guess I’ll do the Windows 3.1 thing and have one big window with a window-docked menu, and containing the document windows as children. The document windows and menu will both be standard flex components within the main Apollo window. Anyway, I’m looking forward to the next public alpha rev! Hopefully it’s on its way :)

Update: I was thankfully wrong about cross window applications, even in the alpha. Adding Flex components requires a pretty straightforward workaround. Daniel Dura’s approach. Todd Anderson’s approach. Ask (a stupid question) and ye shall receive (an answer from the internets)!

Update: Native window saga part two, part three.

In MyApplication-app.xml:
<rootContent systemChrome="standard" transparent="false" visible="false">[SWF reference is generated]</rootContent>

This sets your application manifest to make the root window invisible. Then, you just make it visible when everything’s ready:

In MyApplication.mxml:
<mx:MyApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="window.visible = true"> ...

Easy peasy!