dispatchEvent()™

Since Apollo apps will be run as standalone desktop applications, logging to trace output or a LocalConnection won’t really be useful once the app is installed on the end-user’s machine. It would be great to log (a responsible amount) (if you want) to the resource directory of that application itself. And it would be nice to be able to use built in logging to do so.

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)

As promised I’m back with more goodies! This time I’ve extended the simple window manager to support document windows as well as application windows. I also included a class that binds to your MenuBar in an empty menu and keeps it populated with a list of windows. Clicking a window name in the menu will activate, unminimize, and bring the window to the front.

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.

(more…)

Previously, I was trying to manage multiple native windows in an Apollo app. I found that I couldn’t add Flex components to a new window, and was dismayed. But Danny Dura came to the rescue with a sweet workaround. See the play by play here.

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)

I was just working on a good way to flexibly manage my application’s document windows in Apollo, and when I started trying to throw real windows up, I ran into a wall. The windowing docs clearly showed an example of adding display objects right into the stage of a NativeWindow, but I wasn’t able to spawn windows with views in them. After banging my head for a while, I found the note cleverly hidden at the very top of the asdocs with a bold “Important”! Those tricky Adobe technical writers. Anyway, you can add in an HTML view, or display objects, but apparently those windows run their own instance of Flash Player: you can’t just add in Flex components. I would be curious to find out if cross-window scripting is also impossible now. I would guess so. I’m guessing that getting a unified Flash Player execution environment across native OS windows in all supported OSes is a challenging hurdle (to say the least).

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.

Here’s a really simple trick you can use to prevent the Flex loader from showing when you start up your application. All you have to do is hide the window, and show it when the Application is ready.

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!

I just wanted to pull out a few quick newsworthy items overheard during ApolloCamp.

• Apollo will be public on labs next week just now!
• Flex Moxie (Flex 3) on labs this half of the year! so will CS3
• Apollo 1.0, Flex 3, Philo 1.0 (video application) and Flex Data Services will all come out in the second half of 07.

Obviously, we’re excited about Flex 3, but we’re also a little bit overwhelmed at this point since we’ve just barely got our little brains wrapped around Flex 2. The good news is, Flex 3 is intended to work on the Flash 9 player so it will be more of a component upgrade rather than a full on player/industry/mentality upgrade. I didn’t make it on the Moxie beta so would anyone with hands on experience like to comment?

I’m here in SF at the Adobe Apollo camp which is a big promo event to talk about Apollo. Since it’s NOT NDA’d, I present to you the play by play realtime Apollo Camp report. Click below for more and refresh occasionally to get the latest.

(more…)

Hey! Mims and Roger will be at ApolloCamp. We you. Come say hi!

File Photos for your reference.