Once you crack open the specification, and start mapping it to the bytes of your test file, you’ll find the basic pretty straightforward. There’s a header section that identifies the file type, then one or more file descriptors (IFD), and of course the image data itself. How that image data is stored is up to you, and the TIFF specification provides lots of options, but since I wasn’t interest size, I just went with raw RGB. There’s a section in the specification that talks about how this choice is formatted, among which are the required markers in the IFD.

Markers follow a twelve (12) byte pattern, where there’s two bytes that say what the marker holds, two bytes that say what the data type of the marker is, four bytes that say how many of said type exist, and then another four bytes that hold the actual value. That is, that hold the value most of the times, and there’s where I got stuck. The are certain markers that don’t fit into four bytes. Say for example, an array of three values that specify color depth - red, green and blue as three two byte (short) values equals six bytes needed.

In these cases, the value contained in the marker is a pointer, or file offset, to the actual values. As an example, the required bits per sample marker (258) there’s supposed to be three values of eight (8). Depending on the file you’re looking at in your trusty hex editor, you’ll find any variety of values that don’t look anything like “8” or any derivative therein. In this case, and a few others, the value is actually a pointer to the place in the file where you can actually find the three “8” values (as three consecutive shorts). It’s subtle, but critical in getting the format of the file correct.

Yeah, I know, you’re bored. This is a lame discussion of pointers to offsets, and the values you’ll find there. Not particularly exciting (but very helpful if you’re like me and blow half a day figuring it out). What is exciting is that since I don’t worry about compression, the encoding of the file is lightening fast. A 640×480 image takes under a second to encode. The resulting 900 kb can then be uploaded to a server for further processing. Worth consideration if you’ve ever hit the lag associated with the other encoders out there. Okay, here’s the code (and an example below), go have fun.

To be sure, I’m not an AFCS master by any stretch of the imagination. I’ve long since got a handle on the messaging systems offered by BlazeDS and it’s big brother LiveCycle DS, but these are both very granular approaches. By comparison AFCS accounts for access control, permissions, control management and more, before it even gets to sending a message. While it sounds overwhelming, it’s really great to not have to think about how this happens in a system where there might be a large number of collaborators.

I should also note the Sean Hess’s ongoing AFCS tutorial helped me immensely! I don’t know if it is Sean’s intent or not, but his tutorials seem to approach AFCS from the point of view of somebody coming from Blaze or LiveCycle, and at the same time each tutorial is laser focused on a specific task. I highly recommend Sean’s tutorials if you’re getting started with AFCS.

It turns out that there’s a lot of ways to synchronize data with AFCS. The SharedPropery class and it’s subclass BatonProperty were really appealing at first, but I ended up using a separate Baton and CollectionNode. The concept of a “baton” is to handle who’s in control of a piece of data, such that two participants don’t try to edit the same piece of data at the same time. The collection node is a marker for data off in the AFCS cloud. For the purposes of this demonstration it’s what I use to send change messages. To get logged in then, and setup the baton and collection node, you’re looking at roughly the following lines of code.

<!-- Authenticator (room setup to auto promote -->
<!-- Connection to AFCS -->
<!-- Collection node to share data -->
<!-- Baton to control who is editing -->
<rtc:AdobeHSAuthenticator 
	id="auth" />
<rtc:ConnectSession 
	id="session" 
	authenticator="{auth}"
	roomURL="{ROOM_URL}"
	synchronizationChange="doSync( event )" />		
<afcs:CollectionNode 
	id="node" 
	sharedID="sharedCalendar"
	connectSession="{session}" 
	itemReceive="doReceive( event )"
	synchronizationChange="doNode( event )" />
<afcs:Baton 
	id="baton"
	batonHolderChange="doBaton( event )" />

I spend a lot of times in meetings, or in transit to them. Suffice to say, for those of you that hate meetings, I’m generally the cause of them. It’s my job - interrupt your otherwise normally scheduled project, to inject an air of possibility and vision. Or chaos. You know, it’s all good. Anyways, as you might imagine, my life revolves around my calendar. When I heard that iLog was releasing a calendar control with Elixir 2.0 I instantly got excited about the possibilities. For what it’s worth, the list of controls that comes with Elixir is astonishing, and there’s a free 66 (?) day trial available as well. An editable calendar in a “month” view is as simple as the following.

<!-- iLog Elixer calendar control -->	
<ilog:Calendar 
	showEffect="{fadein}"
	id="calendar"
	bottom="72" 
	left="40"
	right="40" 
	top="40" 
	dataProvider="{appointments}"
	startTimeField="start"
	endTimeField="end"
	summaryField="summary"  
	mode="month"
	visible="false"
	itemEditBegin="doBegin( event )"
	itemEditEnd="doEnd( event )" />

To populate the calendar, I load an ICS (iCalender) file via HTTP, and parse it as raw text into “event” objects. I’ve written about working with ICS file before, so I’ll spare you the details, but in general, ICS files are text where individual lines contain the data. A little state machine makes processing the file a snap. Also, it is worth noting that HTTPService is capable of loading any text, it just turns out that most of the time you’re working with XML, and you want an object model. Not so here, where I just want to handle the raw text myself, which HTTPService can accommodate as well.

<!-- Collection to hold appointments on calendar -->
<!-- Service to fetch calendar -->
<mx:ArrayCollection id="appointments" />
<mx:HTTPService 
	id="svcCal" 
	url="data/tripit.ics" 
	resultFormat="text" 
	result="doCalendar( event )" />

// Handle the load of the data file by parsing the appointments
public function doCalendar( event:ResultEvent ):void
{
	// Break data into discreet data lines
	var line:Array = String( svcCal.lastResult ).split( CR_LF );
	var vevent:VEvent = null;
 
	lblStatus.text = "Parsing calendar file into appointment collection...";
 
	// Build appointment object from lines of data
	for( var a:Number = 0; a < line.length; a++ )
	{
		// Put the object into the collection when the data has been parsed
		if( line[a] == END_VEVENT )
		{
			appointments.addItem( vevent );
			vevent = null;
		}
 
		// Parse the lines of data between a begin and end marker
		if( vevent != null )
		{
			vevent.parse( line[a] );
		}
 
		// Found a new begin, so setup a new appointment object
		if( line[a] == BEGIN_VEVENT )
		{
			vevent = new VEvent();
		}
	}
 
	lblStatus.visible = false;				
}

At a high level, I’ve not gotten a connection to AFCS, put a calendar on the screen, and loaded and parsed some event data to display. Now all that’s left is to let people edit the calendar on their side, and then notify everybody else that a change has been made. The bulk of this work lies in two methods. The first is one to send the changes, which makes a duplicate of the changed event data and sends it along as a message on the collection node. The second is the logic to receive changes, find them in the data model, and apply the update.

// Called when a calendar item has been edited/changed			
public function doEnd( event:CalendarEvent ):void
{
	var mess:MessageItem = null;				
	var update:VEvent = new VEvent();
 
	// Create a representation of the change to pass to other clients
	update.start = event.startDate;
	update.end = event.endDate;
	update.summary = event.item.summary;
	update.uid = event.item.uid;
 
	// Sends changed data
	mess = new MessageItem( "appt", update );
	node.publishItem( mess );				
}	
 
// Called when the appointment node has changed
// Updates calendar if necessary
public function doReceive( event:CollectionNodeEvent ):void
{
	var item:VEvent = null;
	var update:VEvent = null;
 
	// Make sure this is an appointment value
	if( event.item.body.start == undefined )
	{
		return;
	}
 
	// Do not need to register changes if I made the change
	// Do need to release the baton so others can edit
	if( baton.amIHolding )
	{
		baton.putDown();
		return;
	}
 
	// Find a match in the data model for the changed appointment
	for( var a:Number = 0; a < appointments.length; a++ )
	{
		item = appointments.getItemAt( a ) as VEvent;
 
		if( item.uid == event.item.body.uid )
		{
			update = new VEvent();
			update.start = new Date( event.item.body.start.time );
			update.end = new Date( event.item.body.end.time );
			update.summary = event.item.body.summary;
			update.uid = event.item.body.uid;
 
			// Update the appointment data
			appointments.setItemAt( update, a );
			break;
		}
	} 
}

One weak area that I noticed as I was wrapping up is that I expect event data on the collection node, when that may not always be the case. More importantly is that it could be reused for multiple purposes with a little additional work. For example, when the calendar week selection is changed, I could publish a message to get everybody on the same view. I suspect that I’d probably add a “label” property to the body of the message, and make a “data” property the related object. That’s another task for another day however. If you want the source code, you can right click on the example application to view and download it.

Introduction

Evangelist are people, and like any other person in any other role across a company, they have personal sets of likes and dislikes. These sets of likes and dislikes will likely be what has gotten an individual to the point where they have become an evangelist. That being said, evangelists may have gotten to the role by any myriad of paths.

That path will have been defined by their characteristics as people, and as such not all evangelists are created equal. That’s not to say that one is better than another, but simply that an evangelist will function and work best when aligned with their personal sets of likes and dislikes. This seems like an obvious statement, but it is often overlooked which results in the misperception that all evangelist should behave in a certain manner.

Products are not magically introduced into stardom overnight. Products must evolve through a process of exploration, adoption and eventual market acceptance by lasting the test of time. To be sure, not all products can make the transition effectively, and will either be aggregated by one that can, or simply cease to exist. For the purposes of this discussion, we’ll call that process the product life cycle, and start by defining the various stages.

Market Definition

Early Market

When a product is first released to the market, it enters the “early market” phase of it’s life cycle. In this phase, companies look to the technology as a potential means of competitive advantage. By moving faster, and potentially willing to take on some risk, some companies look to out-innovate their competition by investing in emerging technologies. These companies are willing to forgo solid documentation, potential product quality issues, or even reference accounts.

Popular Market

Over time a product will gain more market share and become more widely known. This is the “popular market” portion of a product’s life cycle. With more market share comes more acceptance of the product and subsequently more deployments. The view of the product will become more legitimate as it evolves to be more feature complete and stable. This stage of the product’s life cycle invites competition to challenge its success as well. With additional competition, also comes the definition of a standard set of expected features.

In my opinion, Adobe Flex as an example, has firmly left the early market phase of it’s life and is now in the beginning stages of the popular market phase.

Mature Market

The final stage in the product life cycle then is the “mature market.” The robust ecosystem of competitive and supportive products now in place will bring with the product an enormous amount of purchasing power. This also ultimately results in a lengthening of the sales cycle as companies dig deep on features and business value. Examples of products in this space today include the relational database and the web browser.

The Maverick

The “maverick” technology evangelist thrives best in the early market phase of the product life cycle. This individual enjoys technology for technologies sake, and requires almost no support. The maverick is less sensitive to corporate messaging, and more inclined to give straight answers regardless of how it may impact a customer’s perception. They will code live demonstrations in front of the customer, and even spend time with the customer creating solutions that fill the inherent weaknesses in the fledgling product.

An interesting characteristic of the maverick is that they immediately see the product’s market benefit. To that end, they may go out and evangelize the product based strictly on the potential. When they encounter technical challenges, they may not know the answer, but they will understand the basis of the question, and they’ll know where to get answers. Where this gets interesting is that if there is no good answer, then the maverick will be entirely up front about it.

Eventually the product that the maverick became infatuated with, will grow into the popular and mature markets. As it does so, the maverick will eventually become dissatisfied with either the role, the product, or both, and move onto the “next big thing.” Depending on the nature of the product, some mavericks may realign themselves with different aspects of the product - those complementary products or features which feel compelling to their nature. As a product matures, mavericks will also be looked upon to help newcomers get up to speed.

The Demo Demon

The “demo demon” loves riding the wave of a product’s growing success as it moves from the early market to the popular market. These evangelists are highly adaptable and can become proficient very quickly with any additional technology. The demo demon perfectly fits the classic “mile wide and inch deep” metaphor. They don’t have to embrace ancillary technologies in order to show how they integrate with their product(s), but simply get deep enough to communicate the key points and value proposition.

To that end, a demo demon will likely have no desire to ever fully master a technology - potentially even the very one(s) they are evangelizing. This type evangelist also loves to travel, and can memorize new demos and scripts quickly.

Demo demons aren’t deep enough technically to do well in the early market where customers require their partners to roll up their sleeves and get dirty. That’s not to say that they’ll be entirely ineffective however as their demo skills will allow them to talk around any remaining product weak points.

The popular market is where the demo demon shines as they eagerly hit the streets. Their mastery of the demos and key messaging are so powerful that they become key contributors to the product’s explosion in growth. The demo demon is slightly ahead of the market in this respect and ready for the next big thing. They can be helpful allies to the product marketing teams in this respect.

In the mature market the demo demon is going to get bored. Long since past will be the days of spinning and weaving a story around the product(s) they once defended through eloquence. Because they’re generally not interested in technical deep dives and the product guts, a demo demon will require a good support organization as their product(s) enter the mature market. In that same sense, these individuals may eventually look to transition to sales representatives.

The Implementor

The “implementor” is well organized, genuinely likes technology, and is steady and loyal to specific products. These individuals could really care less about the next big thing and are completely happy to fully master one technology. The implementor will likely be inclined to stay with a single company for a long period of time. This tenure will make them ideal resources in understanding the history of features and why something is implemented in the product in a specific manner.

The implementor does not perform well in the early market phase of the product life cycle. Their expectations for robust feature depth will not translate well to new products. The implementor will likely care less about a new products proposed innovations and will quickly point out technical flaws.

Implementors may be helpful in the late phases of the popular market, but will have a distinct distaste for the fast pace required to keep up with the growth of the product in the early stages.

The mature market is where an implementor will shine. Being less impressed with fancy features, and short on hype, this is where the implementor hits their stride. This is perfect of course as customers evaluating products in the mature market will expect thorough support. The implementor will also likely be very familiar with the standards now surrounding a product in the mature market. Finally, the implementor will enjoy long-term exposure with a defined set of customers so they can see the growth of projects using the technology they’ve been promoting.

Conclusion

To be sure, there are no hard and fast rules here, and lots of grey area and overlap. If you’re an evangelist however, chances are that one of these groupings will have likely jumped out at you. Though realistically, you’ll probably see yourself playing other roles on occasion due to the nature of the job. This overlap will be especially true if you have more than one product to evangelize, and even more pronounced if those products cross different phases of the product life cycle.

The key to your success as an evangelist will be to take a long, hard look at where you fit, and focus your energies on your strengths.

If you regularly work with an evangelist (i.e. product marketing teams), you might do well to consider where those individuals can best work for you. Don’t try and make an implementor be the maverick. Determine which phase of the life cycle in which your product fits, and then establish a good relationship with evangelists that work best in that environment. If you’ve argued with an evangelist about the qualities or merits of your product, then you were probably talking to the wrong type of evangelist for where your product fits in the life cycle.

If you manage evangelists, then understanding the dynamics of these individuals will get you the most bang for your buck. Not every evangelist fits into one uniform evangelist mold. Different evangelists with different personality characteristics can work towards your mission if you have an honest evaluation of your team. Use these characteristics to align your staff with your mission, and hire accordingly depending on the products you need to evangelize and where they are in the product life cycle.

The other problem is that the samples evolved independently of one another. I built an example that did X, and included its own JavaScript file(s), and images, and CSS, and application manifest file, and so on down the line. Then I moved onto the next example. This meant that each sample had its own dependencies and needed to be updated in several places, not just the code showing how the API worked.

With the release, both of these problems have been solved by unifying the samples into one single application that contains all the smaller samples. Each sample is laser focused on showing a specific part of the API, not a comprehensive example with lots of moving parts. This makes it easier to maintain, but has the added side-effect of making it easier to learn how to use AIR features. It also opens some interesting possibilities as a “viewer” type application.

While I’ve never intended to profit off the samples, I’ve also never officially released them under any specific license. I was also the only holder of the source code, which made it impossible for anybody to really contribute to the project. This update rolls the samples under the MIT license and moves the source code into the public domain on Google Code. If you want to maintain, contribute, or otherwise get involved, just let me know and I’ll add you to the SVN repository.

Building on the backs of giants, I also use jQuery 1.3 for all the event handling in the application. While I’d encourage you to check out jQuery if you haven’t already, knowing it is not a prerequisite to understanding how the AIR APIs function.

There’s now 75 samples included with the application, and there’s plenty of room to grow too. The main areas I’d like help in is adding sections for the asynchronous features of the AIR APIs (e.g. file and database). After that I’d like to add a “view source” option so all you actually need is the application itself. Adding auto update should be in there somewhere as well so folks get updated when the project gets updated. And… Well, like I said, feel free to get involved!

The sales engineer’s role almost always ends when a deal is closed. At that point a technology company’s other departments start to get involved, such as technical support, professional services, training, etc.

How then does this relate to technology evangelism? Quite simply, marketing in the world of high technology faces the same problem. You can make brochures, place banner ads, send out email notifications, and so on all you want. The reality is that at some point there’s a gap between where the marketing message stops and where the target customer (generally a developer or the likes) is supposed to pick it up. This is the genesis for the technology evangelist, whose role it is to continue disseminating the corporate message, but at a technical level.

For all practical purposes, I believe that a better name for technology evangelist is really a marketing engineer. You’ll find these marketing engineers at conferences, user groups, social events, online at social networking outlets, making tutorials, building new demonstrations that show how the technology could work for you (i.e. vision setting), and more. Because these types are generally on stage, in front of a crowd, and highly visible, they’re generally considered “rock stars” and generally have some degree of ego to support that perception.

I would argue then, that an evangelist is only truly successful when their actions are supported by, and inline with, the overall marketing messages of the company.

The relationship between a sales representative and a sales engineer is symbiotic. Fewer deals will close without technical expertise, and fewer deals will be found without the sales expertise. So then is the relationship between the various marketing departments of a company, and that company’s evangelists. Fewer people will know about your product without technical exposure, and fewer opportunities to espouse those messages will be presented without traditional marketing activities.

This goes deeper than simply getting out there and presenting the messages you want, where you want. To be truly successful, the evangelist and the marketing departments must work together in tandem to determine what content should be presented, where it should be presented, and what’s makes the most impact given the messages in the queue and the skills available. How then is success measured? What types of evangelists are there, and how do they work? I’ll look to these topics in the future as I continue an exploration of the business side of technology evangelism.

Note: I’ve talked privately about these ideas at length with numerous members of Adobe and other marketing/technology professionals. I can’t thank those individuals enough for taking the time to hear me out, and to provide constructive feedback. You know who you are. I would however like to single out Andre Charland, who encouraged me to put my thoughts down to be shared with others.

Whenever I make a request from Flickr, I also ask it for the date the image was uploaded. I think take this time stamp, available as milliseconds since the epoch, and compare it to what was last stored in the local file (if it exists). If the file doesn’t exist, or the time stamps are different, then a change has taken place. I update the locally stored file, and then download the image file from Flickr.

Here is where it starts to get really fun.

If the window is open, the window will be sized to fit the image and chrome nearly perfect, and then centered on the screen. Along the way, I also capture the raw pixel data (bitmap data) of the downloaded image, size it to fit an icon space, and put the result in the system tray/dock depending on the operating system. This means that the icon of the application will be constantly changing, and reflect the last access to Flickr.

To take this one step further, if the application has been minimized to the system tray/dock, then whenever a new image is available, the thumbnail of that image will be presented as a notification. The notification window will not include any chrome, but simply be the thumbnail image floating in the corner screen in front of everything else. Since Flickr is ever changing, a new thumbnail is produced with every request from the application (every ten seconds).

If you’d like to view the image presented as a thumbnail, you can click on the notification and the registered browser will open to the image on Flickr. I also take care to clean up after myself so you don’t end up with a bunch of downloaded files hogging up your disk space. In fact, if you find and watch the application storage directory, you’ll probably be surprised at how much activity is seamless going on behind the scenes (in a cross-platform manner to boot).

The result of this application is a psuedo-constant watch on the images coming into Flickr. While it isn’t a particularly useful application, it is actually quite mesmerizing. I found myself intoxicated with the updates on more than one occasion for several minutes. If nothing else it shows a little of the glue that can go on between system tray/docking, icons, and notifications. The full source and packaged AIR application is available for download. Since this is mostly an entertaining proof of concept, I’ve not tested extensively, but have run it successfully on both Mac and Windows.

Finally is the “lightweight” window. This is a window without any chrome whatsoever. In the context of Adobe AIR, this is sometimes valuable; such as when you want to provide your own chrome. When it comes to a notification window, that’s pretty much exactly what you want to do - create a window without any chrome that appears for a specified duration and then closes itself. The “lightweight” window is the option we will use for notifications.

Before you go creating that window however, you will want to consider some other options on the window appearance. Any additional fine grain control you want over that window, as manifest during it’s creation, is set through a series of native window initialization options, which you’ll find in the NativeWindowInitOptions class. In the case of a lightweight window, there’s not much we need to specify here except that the type is indeed “lightweight”.

var options = new air.NativeWindowInitOptions();
 
options.type = air.NativeWindowType.LIGHTWEIGHT;
options.transparent = true;
options.systemChrome = air.NativeWindowSystemChrome.NONE;

You might also want to position your notification window in a specific location on the screen. There are two approaches here. The first is the Capabilities class, which through static properties can give you the screen resolution. If you want to account for the situation where the user has multiple screens, then you will want to use the Screen class. You can access the main screen and get the a Rectangle that represents the viewable space (i.e. taking into account the “start bar” on Windows). If you know how big the screen is, and you know how big your notification window is, you can position it wherever you would like.

var bounds = null;
var screen = air.Screen.mainScreen.visibleBounds;
 
bounds = new air.Rectangle(
	screen.width - WINDOW_WIDTH - 10,
	screen.height - WINDOW_HEIGHT - 10,
	WINDOW_WIDTH,
	WINDOW_HEIGHT
);

At this point, if you went and created a native window using the constructor (i.e. new NativeWindow()) then you’d get your window, but it’d have a Flash stage inside of it. That’s not going to help you use your HTML, JavaScript and CSS any. HTML applications in Adobe AIR display inside of an HTMLLoader instance. You can think of this as the browser’s viewport. The HTMLLoader class actually expects that you’ll want to create new native windows that contain HTML content, and provides a static convenience method to help you out.

var notification = air.HTMLLoader.createRootWindow( 
	true, 
	options, 
	false, 
	bounds 
);

The result of this call is an HTMLLoader instance - specifically, the HTMLLoader instance of the new window you just created. Keep in mind that it’s the viewport, not the native window itself. The HTMLLoader has some additional properties that you might want to set as well, especially in the case of a notification window. The main one is that you will want this notification to always appear over everything else so the user can see it. That is set by getting a reference to the native window, and then telling it to be “alwaysInFront”.

notification.paintsDefaultBackground = false;
notification.stage.nativeWindow.alwaysInFront = true;
notification.navigateInSystemBrowser = true;

The “paintsDefaultBackground” is an interesting property as well. In the case of any native window that is not using the system chrome, you can set the remainder of the window to be transparent. In the case of HTML, you will also need to tell the HTMLLoader, the browser viewport, not to use the default background of the HTML page that it would otherwise put in place. You don’t always need to use this option, but it is handy for cases where you want to infer some style through custom chrome.

The window you just created, whether it be a notification window, or other window, is not going to have any default content - it is just a blank window. The HTMLLoader provides two means to fill that window with content. The first is simply to send the viewport some HTML to display, which happens through HTMLLoader.loadString( yourHTML ). This is great for basic markup, but if you’re doing anything extensive, it will obviously get pretty cumbersome.

The other option then is to have a HTML page assembled that represents what you want your notification window to look like. You can tell your new native window to display that content by calling HTMLLoader.load() and passing a new URLRequest object. The URLRequest is simply a more formal wrapper around a destination to HTML content (content on the web in general, really). If your notification page is local, then you will use the appropriate notation, just like in any other web page. You can also point URLRequest at any other location on the web as well.

notification.load( new air.URLRequest( NOTIFY_SOURCE ) );
 
// Alternatively
// notification.loadString( "Foo.  Bar." );

You’ve finally got your native notification window, sitting pretty where you want it, looking like you want it, and filled with the content you want. The shortcoming now is that it does not go away all by itself. What you will need to do is keep track of how long the window has been open, and then tell it to close itself after that period of time has elapsed. The first question becomes who does the closing?

You have a reference to the native window in the originating application, and you could use that. In this case you also control what content that window is loading, so you could have the window watch our for itself. Generally speaking, I prefer the later as it seems more modular to have the notification window take care of dismissing itself.

The method to do this, regardless of the approach you take is NativeWindow.close(). If you are calling from the originating application, you’ll need to get a reference to the window itself through the HTMLLoader. Reference the code for setting the window to always be in front, as to how to get this access to the native window. If you are going to close the window from the page that is loaded, then “nativeWindow” is just another property like the traditional “window” and “document” properties.

// From within the notification window
nativeWindow.close();
 
// Alternatively, from the originating window
// notification.stage.nativeWindow.close();

Now that you can tell the window to close, you will need to know how long it has been open. You can use the traditional JavaScript method of setTimeout() here, which will work perfectly. Adobe AIR also offers us a more robust Timer class that I prefer to use. Keep in mind that you may not want to close the window automatically at all. Maybe you want to leave it on the screen until the user takes some action to dismiss the window. If that’s the case, don’t forget to include some fashion of button in your HTML page.

var timer = new air.Timer( DELAY, REPEAT );
 
timer.addEventListener( air.TimerEvent.TIMER_COMPLETE, doTimerComplete );
timer.start();
 
function doTimerComplete( evt )
{
	nativeWindow.close();
}

At this point, you have all the tools you need to get going with your own notification windows. I have put together a simple example and made the source available. The example creates a notification every ten seconds. The notification window removes itself after four seconds have elapsed. My notification window stays where I put it, but from here you might explore other options, such as letting the user move the window, and then remembering where they moved it to to the next notification shows up in the same place. The options with Adobe AIR, once you’re on the desktop and out of the browser are limitless.

When I set out to build this I did a little searching first and found a Flex example that originated from Sasa Radovanovic, and that was updated by Jeff Houser circa the Flex 3 Beta 3 timeline. What follows is a migration of that work from Flex to JavaScript, with a lot more verbiage around the why and how of the details. All things considered however, when you develop in AIR, you have many of the same classes available to you in both the Flash world and the JavaScript world. I encourage you to explore what’s available from both APIs.

When it comes to the system tray, it is generally common to have an icon that represents your application. This is important as your application itself won’t show up in the “start bar” when it has been minimized. On Mac, the equivalent is the “dock” and the icon that shows up there is generally the one associated with the application itself. In both cases, you can actually control at runtime how you want that icon to appear. With that in mind, let’s first start by loading our own custom icon.

var imgDock = null;
 
$( document ).ready( function() {
 
	// Loader to load the icon image
	// Use Loader not HTML image to get at bitmap data (pixels)
	var loader = new air.Loader();
 
	// Handle when the icon image is loaded
	// Load the icon image (in this case local)
	loader.contentLoaderInfo.addEventListener( air.Event.COMPLETE, doLoaderComplete );
	loader.load( new air.URLRequest( SPLASH_IMAGE ) );
 
	// Custom event handler for window closing
	// Want to prompt the user to see if they want to close or minimize
	nativeWindow.addEventListener( air.Event.CLOSING, doClosing );
 
} );

You might initially be inclined to use an IMG tag. The problem with this approach is that it doesn’t give you access to the raw pixel data that the operating system will expect. To get at this data we will use an instance of the Loader class. Like most things web, the loader works asynchronously, so we will want to register for notification when the icon is loaded. Since this is local (in this case) it should be nearly instantaneous, but still we need to wait at least that instant.

// Called when the icon image is loaded
// Setup systray/dock actions depending on operating system
function doLoaderComplete( evt )
{
	var isMac = null;
 
	// Get the bitmap data (pixels) of the icon for the system
	// The system will size and convert to the appropriate format
	imgDock = evt.target.content.bitmapData;
 
	if( air.NativeApplication.supportsSystemTrayIcon )
	{
		// Setup Windows specific system tray functionality
		air.NativeApplication.nativeApplication.icon.tooltip = SYSTRAY_TOOLTIP;
		air.NativeApplication.nativeApplication.icon.addEventListener( air.MouseEvent.CLICK, doTrayClick );		
 
		isMac = false;
	} else {
		isMac = true;
	}
 
	// Override the default minimize behavior and use our own
	nativeWindow.addEventListener( air.NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING, doStateChange );
 
	// Setup a menu on the docked icon to restore or close
	air.NativeApplication.nativeApplication.icon.menu = createMenu( isMac );
}

Once our icon has been loaded, we will go ahead and get the pixels, referred to as bitmap data, of the image. We’ll store that in a reference for later use - specifically, we will show the icon in the system tray when the application is minimized and remove it when the window is restored. We’ll also want to put the icon back should the application window be minimized again.

What comes next is the main branch between Windows and Mac, and AIR gives you hooks to find out on which operating system your application is running. The NativeApplication class has a static property for “supportsSystemTrayIcon” and “supportsDockIcon” which represents Windows and Mac respectively. There are also many other useful properties on the NativeApplication class to include a check for menu support, and the flag to start the application when the user logs into the system.

If the application is running on a Windows operating system, then there are some additional options that we can leverage. Notably in this case are putting a tooltip on the system tray icon, and also listening for a click on the icon to restore the application window. Regardless of operating system, we want to catch a minimize gesture from the user and replace the default behavior with our own; namely minimize to the system tray and not the “start bar”.

// Called when the docked icon is clicked (Windows only)
// Calls a shared function to restore the window
function doTrayClick( evt )
{
	undock();	
}
 
// Called when the window is minimized
// Minimizes to systray/dock in place of traditional minimize
function doStateChange( evt )
{
	if( evt.afterDisplayState == air.NativeWindowDisplayState.MINIMIZED ) 
	{
		// Stop the default behavior
		// Call shared function to systray/dock
		evt.preventDefault();
		dock();
	}	
}

While we are at it, we will go ahead and create the menu on the system tray/dock icon for the application on the whole. I’ve made the effort here to track the operating system when I create the menu. This is subtle but important. In the case of Windows the common term to close an application is “Exit” while on a Mac the term is “Quit”. The menu items create here can call the same functionality, that part doesn’t differ per OS, but I wanted to present the user with terminology they’d expect to encounter.

// Called to create a menu on the systray/dock icon
// Takes operating system into consideration
function createMenu( isMac )
{
	var menu = new air.NativeMenu();
	var openItem = new air.NativeMenuItem( OPEN_ITEM );
	var exitItem = null;
 
	// Both operating systems have an option to open the window
	openItem.addEventListener( air.Event.SELECT, doOpenSelect );	
	menu.addItem( openItem );
 
	if( !isMac )
	{
		// Mac provides built-in "Quit" item
		// Create an "Exit" item for Windows
		exitItem = new air.NativeMenuItem( EXIT_ITEM );		
		menu.addItem( exitItem );
	}
 
	return menu;	
}

Before we talk about the actions in those specific menu items, let’s pause and talk about what the application has done so far, and is now displaying.

When the application started, it loaded a custom icon to use in the system tray/dock. Once that icon was loaded, we grabbed the bitmap data for reference, and then proceeded to create platform-specific hooks for the application when hidden; namely the menu. Now the application is running, displaying it’s main window, and expecting some fashion of user interaction. Let’s say the user is next ready to minimize the application.

Keeping in mind that we want this application to sit in the system tray/dock, not on the “start bar” we want to catch the default behavior and insert our own. We’ve already setup the application even handlers for minimize, so let’s take a closer look at the actual functionality. The first step is to prevent the actual minimize behavior, which can be done with the preventDefault() function call. Then to formally “dock” the application, we hide the main window, and associate the icon we loaded earlier with the application.

// Called to put the window on the systray/dock
// Hides window and puts icon in place
function dock()
{
	nativeWindow.visible = false;
	air.NativeApplication.nativeApplication.icon.bitmaps = [imgDock];	
}

Note that AIR can take a variety of sizes for the icon, and that they may differ depending on operating system. On Windows as an example, this icon tends to be displayed at 16×16. On a Mac it is very user-definable and may be anywhere between 16×16 and 128×128. You may want to account for this to get the best display for your icon, but when in doubt, the operating system will actually scale the icon image appropriately.

Now with the application safely tucked away, the user can continue on along with their business. At some point in the future we’ll assume that they want to bring your application back front and center however, and we’ve already laid the groundwork to make this happen. On Windows, clicking the system tray icon will “undock” the application, while selecting the “Open” context menu item on both Windows and Mac will perform the same function.

// Called to restore the window to normal mode
// Shared function called by multiple event handlers
function undock()
{
	// Show the window and bring it to the front
	nativeWindow.visible = true;
	nativeWindow.orderToFront();
 
	// Clear out the systray/dock icon (optional)
	air.NativeApplication.nativeApplication.icon.bitmaps = [];	
}

In the case of restoring the application window to it’s former glory, we’ll first want to make it visible. To make sure the user isn’t blocking our newly visible window with one of their own, we’ll also want to bring our application to the front. Finally we’ll pull any custom icon indicator from the application. On Windows this will remove the icon from the system tray while the window is visible.

You may want to keep the icon in the system tray at all times regardless of state, in which case you’ll not clear the icon. You’d also likely not wait to put the icon in place for when the user minimized the application, and make the assignment as soon as the image is loaded. The real detail here is that AIR doesn’t presume to know how your application should behave. You need to design the behavior you want, while also taking into consideration operating system differences.

Now your user can start the application, “dock” the main window to the system tray, and restore the window through some user gesture (which again is going to differ depending on operating system). How about closing your application once and for all?

// Called when the native window is starting to close
// Prompts the user to see if they want to close or minimize
function doClosing( evt )
{
	var answer = null;
 
	// Stop the default of actually closing the window
	evt.preventDefault();
 
	// Ask the user what action to take
	answer = confirm( "Select \"OK\" to exit or \"Cancel\" to minimize." );
 
	if( answer )
	{
		// If they actually want to close the application
		closeApplication();		
	} else {
		// If they really just want to minimize the window
		dock();	
	}
}

One of the lines of code we didn’t talk about up front was that we added a listener to the native window to catch the closing event. This happens before the window is actually closed, and gives us a chance to more formally handle the event. In this case, we will ask the user if they are sure they want to close. This is a good practice since the user may not know what gesture to provide to actually put the application into the system tray/dock.

Very much like the minimize event, we can prevent the default behavior by calling preventDefault(). Next we can use the good old JavaScript confirm() method to ask the user about their real intentions. If they really want to close the application, then we’ll go ahead and make that call at the application level. If they actually want to put the application into the system tray/dock, then we’ll call the “dock” method we discussed earlier during the minimize operation.

// Called to close the window
// Shared by multiple event handlers
function closeApplication()
{
	nativeWindow.close();	
}

As a summary, we first need to manage a custom icon, potentially at different sizes based on operating system, create the appropriate context menus for the application, and stop some of the default behavior and inject our own.

While that’s it in a nutshell, the variables get involved in how you want your application to behave when running on different operating systems. When does the icon get generated or put into the system tray? What should the context menu say to the user? How should the prompt to stop closing be worded depending on OS? These are all decision you will need to consider as you implement your own approach to docking. I’ve included a sample application with the above behaviors for your use as a template.

Yes, the Flash Player has a limitation in the dimensions of the main rendering pipeline called the “stage”. The stage cannot exceed 8,192 pixels in either width or height, and the total number of pixels cannot be more than 16,777,216. This is especially important if you’re interested in image transformations, and aren’t directly familiar with the dimensions of that content. If the single item you load on the stage exceeds the stage dimension limitations, it won’t be displayed - and you need it to be displayed in order to apply transformations in this manner. Take for example something coming out of the latest digital SLR cameras.

You see, if all you want is to generate a thumbnail of an image file, with AIR, you’ll still have to load it entirely into memory and onto the display list. Then you’ll capture a copy of the bitmap data that represents that image. At that point, the classes are in place to provide a variety of scaling and/or other effects. Once you’ve got it all figured out, you’ll want to encode those bytes into a recognizable format. This in it’s own right is going to take time (in addition to the memory you’re already consuming). Then you get to write the encoded file to disk, which thanks to AIR can be done asynchronously, keeping your user interface responsive.

Should there be alternatives? You bet! And there has been for about as long as image files have been around.

The alternative is to directly manipulate the bytes of the image itself while you’re processing. This is especially effective for image that you want to scale down, removing bytes along the way. This is the road my previous post started down. It reads bytes to determine the specifics. It does not load the images onto the display list. Getting dimensions and file type this way however, is significantly easier than applying actual transformations. The scope of that work is beyond my skills, and really should use the native libraries that already exist to do this work. And therein lies the rub as AIR doesn’t provide native extensibility.

The rest of this post goes to a brief description of how to read in, and scale, multiple images selected by the user. Before I go there however, note that Adobe recently announce Project Alchemy which compiles C/C++ source code to Flash bytecode. It stands to reason that these libraries could be compiled to Flash SWC libraries, and then image files could be manipulated directly at the byte level without loading onto the display list. To date however, this work has not yet been completed.

Selecting, Loading, Resizing and Writing Images

The first objective here is simply to let the user select one or more images. To do this we’ll prepare a file object instance to handle user interaction. We’ll also listen on a button in the HTML page for the user to invoke the selection dialog. When the files are selected, there’s a little trick to handling what the user has selected. The main problem is that if they’ve selected more than one, we can’t work on them all simultaneously because all the processes happen asynchronously to emulate threading.

var browse = null;
var files = null;
var index = 0;
var loader = null;
var output = null;
 
function doLoad()
{
  browse = air.File.documentsDirectory;	
  browse.addEventListener( air.FileListEvent.SELECT_MULTIPLE, doFilesSelect );
 
  loader = new air.Loader();
  loader.contentLoaderInfo.addEventListener( air.Event.COMPLETE, doLoaderComplete );
  window.nativeWindow.stage.addChild( loader );
 
  btnOpen.addEventListener( 'click', doOpenClick );	
}
 
function doFilesSelect( e )
{
  files = e.files;
  index = 0;
 
  loadImages();
}
 
function doOpenClick()
{	
  browse.browseForOpenMultiple( 
    'Select Images', 
    [new air.FileFilter( 'Image Files', '*.gif;*.jpg;*.jpeg;*.png' )] 
  );
}

This means that we’ll need to work on each individual image in turn. To keep track of what file in the list of those selected that we’re currently processing, make sure you store and index at a scope that can be repeatedly accessed. Now that we can process the images in turn, lets next actually load the image. To complicate matters, image loading occurs asynchronously as well. Not only will this trigger when to scale the image, it will also fire the next iteration in our list.

var COMPRESSION = 85;
var MAX_HEIGHT = 100;
var MAX_WIDTH = 100;
 
function loadImages()
{
  if( index < files.length )
  {
    output = document.createElement( 'div' );
    loader.load( new air.URLRequest( files[index].url ) );	
  } else {
    loader.visible = false;
  }
}
 
function doLoaderComplete()
{
  var bmp = null;
  var bmpd = null;
  var encoder = null;
  var img = null;
  var jpg = null;
  var matrix = null;
  var ratio = 0;
  var realHeight = loader.contentLoaderInfo.height;	
  var realWidth = loader.contentLoaderInfo.width;
  var stream = null;
  var thumb = null;
  var thumbHeight = 0;
  var thumbWidth = 0;
 
  if( realWidth > realHeight )
  {
    thumbWidth = MAX_WIDTH;
    thumbHeight = Math.round( ( MAX_WIDTH / realWidth ) * realHeight );
    ratio = MAX_WIDTH / realWidth;
  } else {
    thumbHeight = MAX_HEIGHT;
    thumbWidth = Math.round( ( MAX_HEIGHT / realHeight ) * realWidth );
    ratio = MAX_HEIGHT / realHeight;		
  }
 
  matrix = new air.Matrix();
  matrix.scale( ratio, ratio );
 
  bmpd = new air.BitmapData( thumbWidth, thumbHeight );	
  bmpd.draw( loader, matrix, null, null, null, true );
 
  encoder = new runtime.com.adobe.images.JPGEncoder( COMPRESSION );
  jpg = encoder.encode( bmpd );
 
  thumb = air.File.desktopDirectory.resolvePath( 'thumb_' + files[index].name );
 
  stream = new air.FileStream();
  stream.open( thumb, air.FileMode.WRITE );
  stream.writeBytes( jpg, 0, 0 );
  stream.close();
 
  output.innerHTML = files[index].name + ': ' + realWidth + ' x ' + realHeight;
  document.body.appendChild( output );
 
  img = document.createElement( 'img' );
  img.src = thumb.url;
  output.appendChild( img );
 
  index = index + 1;
  loadImages();
}

In this example, I’ve chosen to write the image files synchronously. It’s very easy and simple code, but I’m making a huge assumption - that the files to write are small and/or are not being written on a network drive. If either of these problems should creep up, we’ll need to introduce one more asynchronous flow. This means that the close the file, after being written, would actually trigger the next iteration. Now you’re talking nested asynchronous processes on an unknown list of files. It only gets more messy if you’re also concerned that the extension “JPEG” that the user selected, is actually a JPEG file and not a “DOC” with the wrong extension.

Bringing this full circle, this is where we come back to native libraries. Between all the potential memory and processing pitfalls, image processing proper in AIR is a little hit and miss. It’s good for basics, but will certainly fail you when you start pushing the envelope. Project Alchemy certainly is a promising light at the end of the tunnel for these purposes. To make it even more exciting, Alchemy is capable of processing data across frame boundaries. Frame boundaries? Yeah, well, let’s not go there; the rabbit hole gets very deep indeed. In the meantime here’s the source for a simple AIR application that does the resizing covered above.

The MAX team has already announced that they’d like your feedback in the guidance of 2009. I don’t know that I’ve ever seen a conference of this scale organized in public, but I complement their vision. Some of the reviews early in to that process talk about presenters that seemed unprepared and criticism on the unconference events. I’d like to call out a few thoughts on these comments.

Presenters were kept to a strict timeline this year. The first scheduled review of content was scheduled on July 18, 2008. That’s a full four (4) months ahead of the actual event. That’s not to mention the actual call for papers. Final content was due September 29, 2008; almost two months before the event. Imagine then, preparing a presentation today, and then being expected to deliver it perfectly two months later, right out of the gate. If you did well on your content, your first delivery might be four months later!

I guess the point is that if the presenters seemed a bit rough on the first day, there’s a reason. I know I felt a bit rough. That being said, as a lab presenter, I was ecstatic to have been able to work with the actual VMWare image as part of the preparation process. Usually you just hand the assets over and hope everything works out as you hoped. I was able to significantly refine my presentations over the course of MAX because I knew my assets on the actual machines of the students. Easily my favorite part of the preparation process.

As for the unconferences, I only attended and presented at the CF Unconference, but I thought it was a great place to talk about those thing that mattered to you. If you’ve ever been to a barcamp or other unconference, the agenda is usually set as part of the opening hours of the event. Unconferences aren’t supposed to be formal events like MAX itself, 360Flex, or others. The thing I really like about an unconference is that I can experiment with new content and content that is maybe too off-track for a typical conference, I thought MAX fit that ideal perfectly.

Conversely, I was a bit let down that the unconferences got so little support. At the CF Unconference as an example, the only way the group would get lunch was to pay for it themselves. Yes, I understand that a typical unconference gets no support whatsoever, but if you’re giving space and equipment, then the MAX staff should at least also pitch in lunch. Keep in mind that you didn’t need a badge to attend a MAX unconference, so I appreciate the balancing act from the MAX staff, but no lunch?

As for MAX overall? Yes, wireless access was abysmal! I’m still not sure why conferences, especially conferences in Silicon Valley continue to mess this up. Attendees want to blog, upload pictures, Twitter, share video and more. No network equals no sharing. No sharing means less community feel, and less excitement from those that couldn’t make the trip. Next year is Los Angeles, CA. Please, give us decent wireless!

Real-Time ColdFusion with LiveCycle Data Services

This is easily one of my favorite subjects. So many ColdFusion developers I talk to are still using XML over HTTP for their Flex applications. A very few have made their way to CFCs and remote objects. Both of those are the very tip of the iceberg! There’s so much more you can do if you embrace the LiveCycle Data Services that’s included with your ColdFusion 8 installation. That’s what this session was all about.

We started with remoting, just to level-set the workflow of connecting Flex to data from ColdFusion. I was pleasantly surprised to find a number of the attendees were entirely new to Flex and Flex Builder. From there we moved into the world of asynchronous communications with a chat application (yes, I know it’s cliche). To show data push, we implemented a ColdFusion Gateway that leveraged threading (introduced in ColdFusion and emulated a long-running server transaction. We capped off the lab by talking about the possibilities and short-comings of all these by themselves, and rocked the house with data management.

AIR Core Concepts for Flash Developers

When Rob Christensen, the AIR Product Manager, asked if I’d be open to presenting a session, I was quick to accept. Having spent my fair share of time in the Flash authoring environment in the past, I thought the topic was very compelling. The lab consisted of six hands-on projects, executed with varying degrees of success throughout the week. I hadn’t considered that a number of the students wouldn’t have had any ActionScript experience whatsoever. I tried diligently, using the assets shipped months earlier on the VM Ware image, to adjust throughout the week, but to varying degrees of success.

The projects in the lab started with exploring how to create an Adobe AIR application using Flash CS4, or the extension available for Flash CS3. From there we moved into local file IO with a basic text editor. Exploring the embedded SQLite database was next with a basic contact manager. We talked about the differences between an actual browser and the HTML rendering engine (using WebKit) while making our own loosely formed version. From there we shifted into Flash Player 10 features, as a major part of the Adobe AIR 1.5 release announced at MAX 2008. We leveraged the new text engine and 3D, before circling back around for deploying an AIR application.

ColdFusion Unconference: LCDS, Threading, Gateways and More

The data push I showed in my Real-Time ColdFusion lab was very formal and very abbreviated over what I actually wanted to show. I used the CF Unconference as my opportunity to explore the full story. That story starts with a simple Flex application to manage GPS data. The problem was that uploading a large data set took time, and I felt uninformed. I wanted to push updates while the database inserts were actually being executed. From there I needed threads to separate the processing against the actual upload. Further on I need to use gateways to push data from the ColdFusion server into the LiveCycle Data Services instance.

The morning of the unconference I also got permission to show ColdFusion in the cloud on Amazon EC2 via Stax. Stax is an upstart that is in part run by the legendary Spike Washburn, who you’ll recall if you were around during the ColdFusion 5 to ColdFusion 6 migration (native to Java). The part of Stax that makes it so exceptionally compelling is that it has an SDK that makes developing on ColdFusion, exactly like developing on ColdFusion locally. That means you can use all your normal tools and workflows during development. I can’t explain the details on this exactly now, but watch for more information as Stax and Adobe figure out the details (such a licensing).

Conclusion

No conference is without it’s flaws, but MAX 2008 was about as exceptional a conference as ever I’ve attended; and given that I attend and present at conferences for a living, that’s saying something. I think being open about the 2009 details will aid significantly in making it even better. I had a ton of labs sessions, and presented at the ColdFusion Unconference. All those presentations, and their code, can be downloaded for your viewing pleasure (Real-Time ColdFusion, AIR Core Concepts, ColdFusion Unconference). I’m not sure what Los Angeles holds for us, but I’m super excited about the 2009 year ahead. Thanks everybody for such a great event!