Typinator and Flex

My colleague Doug McCune sent out a link last week to a product called Typinator.

Typinator is a tool for Mac OS that auto replaces character strings that are typed anywhere in Mac OS. In the videos below you will see a few ways that Typinator can be used in a Flex development environment.

Class Templates: If you're tired of formatting your classes to read a certain way, why not setup a template with Typinator?

In this example you'll see "-pc" expanded to a full class template.

Infrequently Used Syntax: If you're like me, there are a few syntactical parts of ActionScript that you use infrequently. I generally have to look these things up in past source code or LiveDocs. Typinator is a great way to create a shortcut for those items.

In this example you'll see "-ra" expanded into the remote alias meta data tag.

In this example you'll see "-emd" expanded to the event meta data syntax.

I've been using Typinator for a while now and it's become a useful development tool for me, even actions as simple as correcting functino to function (a common misspelling for me).

[UPDATE]

I shared my post with Ergonis Software and their CEO and Frounder Christoph Reichenberger replied with a very helpfult tip. Typinator allows you to specify an alternative cursor position after it has replaced the phrase you type.

If you look up at my remote alias example, you'll notice that I used the left arrow key to backup to the appropriate spot to type the classname. In the revised example below you'll see that after typing "-ra" the cursor is automatically positioned where I'd like to start typing the name of the alias.

Thanks for the tip Christoph, much appreciated.

Cairngorm Top 5 Tips - Number 4 - The EventGenerator

The last tip in this series was #5. The AnnounceFaultEvent (read more).

and now for tip #4:

The EventGenerator

The EventGenerator class provides a mechanism for defining sets of Events to be dispatched either sequentially or in parallel. The EventGenerator is defined declaratively in MXML. The generator provides an aggregated result response when the last event in the set has finished. It is still possible to attach responders to your individual events, as per normal in the UM Cairngorm world. (I'll cover the Event-Responder relationship in more detail in a later post.)

There are couple of dependencies to the EventGenerator pattern. I consider these requirements good practice anyhow, but you should keep them in mind.

1. Define your event as a subclass of UMEvent not the Cairngorm Event Class
2. Define your command as a subclass of the UM Command class instead of implementing the Cairngorm ICommand interface.
3. Invoke super.execute() in your command execute method.
4. Invoke notifyCallers() in your command class when the command has finished executing.

And now for the example...

View the Application | View the Source | View the Docs

EventGeneratorExampleApplication - Defines the generators and the handlers functions for their results.

GetConfigurationEvent and DownloadSomethingEvent are basic Event classes that map to ConfigurationCommand and DownloadCommand, respectively. Both of these commands are implemented using the pattern I described in the dependency list above. Let's take a look at the ConfigurationCommand as an example.

As you can see, ConfigurationCommand overrides the execute method and invokes the super execute method. Finally, when the delegate has returned a response notifyCaller is invoked. This is the signal the EventGenerator needs to know that the command has finished executing. If the generator is triggered as a sequential dispatcher notifyCaller() signals the generator to dispatch the next event in the series. If the generator is running in a parallel mode, notifyCaller() is used to keep a count of the event / command pairs that have finished. When all the events have signaled a finish, then the generator will dispatch the aggregated result signal.

The delegate used (EventGeneratorExampleDelegate) is fairly straight forward. It uses a URLLoader to download a couple of files from the same server that the application is deployed on.

Up next, #3 Data Translators.

Cairngorm Top 5 Tips - Number 5 - The AnnounceFaultEvent

Several months ago we had a Flex Frameworks roundup at our local Adobe User Group (RMAUG). I presented on the Universal Mind Extensions to Cairngorm and have since had a few requests for more info on the extensions. In this post I will explain my top 5 favorite ways to implement Cairngorm features in a Flash Application built with Flex many including elements from the UM Extensions.

So, without further delay...

5. The AnnounceFaultEvent

Error handling can often be an overlooked item when building a Flex application. The AnnounceFaultEvent class in the UM Cairngorm Extensions provides a nice way to generically handle faults. In fact, the UM implementation of Command has built-in support for the AnnounceFaultEvent. If a FaultEvent is passed to the fault method of the Command (via the IResponder interface), an AnnounceFaultEvent is automatically dispatched through the FrontController.

In a standard Cairngorm implementation a Command instantiates a Delegate and invokes a method on that Delegate to perform the action that the Command is responsible for. Typically, the Delegate will inform the Command that either a result returned form the operation or a fault returned from the operation. Because Flex is based on asynchronous communication the Command's call to the Delegate cannot be blocking (ie wait for a response). So, we need a way to signal to the Command that the operation has finished and deliver the result (or fault) of the operation. The common way to accomplish this task is using the Responder pattern. A Responder is a class of object that has both a result and a fault method. The idea is that a caller maintains a reference to the Responder instantiation, and the callee notifies the caller via this object. In the UM Extensions, the Command class will automatically fire an AnnounceFaultEvent when a Delegate passes back a FaultEvent to the Command.

Here's the example:

View the Application | View the Source | View the Docs

AnnounceFaultEventExampleApplication dispatches a AnnounceFaultEventExampleEvent

AnnounceFaultEventExampleEvent is handled by CairngormTipsFrontController

CairngormTipsFrontController instantiates AnnounceFaultEventExampleCommand

AnnounceFaultEventExampleCommand calls exampleOperation on AnnounceFaultEventExampleDelegate

AnnounceFaultEventExampleDelegate responds with a FaultEvent

The FaultEvent is handled by FaultCommand



Tip #4: The EventGenerator is coming soon... It's out now

Dynamic, Persistent Skins with Degrafa

Degrafa is a declarative graphics framework for Flex. This means that programatic graphic instructions like:

graphics.lineStyle( 1, 0xffffff );
graphics.moveTo( 10, 10 );
graphics.lineTo( 30, 30 );
graphics.lineTo( 10, 30 );

can be expressed in simplified and elegant MXML source code.

From this post you'll take away an intro to Degrafa, how to dynamically modify your Degrafa skins, and how to persist those dynamically modified skins.

To start with, let's take a look at a simple Flex Button skinned using Degrafa:

View Application

In this example I'm using three Degrafa classes: GraphicBorderSkin, SolidFill, and RoundedRectangle to create the skin:

ButtonSkin.mxml

Then, that skin is applied to a Flex Button in:

ButtonSkinExample.mxml

GraphicBorderSkin is one of a few classes that implement the IGraphicSkin interface. These classes are the foundation for a Degrafa skin. Extensions of IGraphicSkin classes are typically written in MXML. For this example I've extended GraphicBorderSkin to add a few bindable properties for width and height. If you're interested in that implementation, take a look at the BaseGraphicBorderSkin in the source code.

SolidFill is fairly self descriptive. As you can imagine, it fills an area with a color. SolidFill may also have an alpha quality.

Finally, the shape of our skin is implemented using the class RoundedRectangle. RoundedRectangle implements the IGeometry interface, the classes used in the tag to draw the shapes of the skin. In our example there are 3 RoundedRectangles, each with increasingly more rounded corners. Each of these three shapes map to three states of the Flex Button; upSkin, overSkin, and downSkin. These shapes are filled using their respective SolidFill instances upFill, overFill, and downFill.

With just a little extra work we can make this skin dynamically configurable. The first step is to create a model to externalize the data of the skin. Our data model includes 9 properties:

This class is called ButtonDynamicSkinData. The next step is to have our skin bind to the values set in ButtonDynamicSkinData. You can view this in the ButtonDynamicSkin class:

The final step is to create a few controls to modify the values in the model. I've added these controls to the Application class ButtonSkinDynamicExample... and voila:

View Application

The final step is to persist this data and load it at a later instantiation of the skin. There are many ways to persist data in Flex. For this example I've used the simple approach of persisting the data via url encoded variables. In the final example a button labeled "Goto New URL" is added. If you modify the settings of the skin and then click the button, a new instance of the application loads with the persistent skin that was modified.

To facilitate the persistence I've added two methods to the class ButtonDynamicPersistentSkinData. The method toUrlVariables() expresses the data model as URLVariables and the setValues() method sets each property of the model based on the values of the URLVariables method parameter.

View Application

This example shows a method for implementing a fully dynamic and persistent skinned Flex application.

The source for the examples in the post can be found here.

More links:

Degrafa Samples
Degrafa Downloads
Degrafa Docs

This post is a result of recently using Degrafa to implement similar features on a project I was working on. I was very pleased with how rapid the development process was, as well as the opportunity it gave for an elegant skinning solution. Degrafa comes highly recommended by me for any Flex project.

Merapi Update

It has been far too long since I've blogged about Merapi, so I thought I would share what's up with the project. First off, the next release has been coming soon for far too long. That is my responsibility and I apologize to everyone that's been waiting on the new build. However, there is good news! The new release is now live on the site. Go to www.merapiproject.net and check it out. You can sign up for an account if you aren't already.

It's really great to see the Flex community cranking out cool examples with a technology that you've created. This is most definitely the case with the recent “Cocomo ready” Air Wiibot. These guys mashed up Cocmo, Flex, and Merapi to control a Lego Mindstorm robot with a Wiimote. So what's Cocmo for? They've used Cocomo for live video conferencing as well as the ability to control the robot remotely. So, if my friend Jordan happened to have Nathan (our Lego Mindstorm robot) at her house, I could fire up this app at my house and control Nathan remotely using a Wiimote... really cool stuff. Here's the YouTube video:

MAX Recap

For those of you that missed MAX there was a lot of Merapi action, here's a quick recap.

First off, Tour De Flex.

Tour De Flex is an application created by Adobe used to explore components in the Flex community. Adobe used Merapi to connect the Eclipse plugin portion of the application to the Tour De Flex AIR application. You can get Tour De Flex at: http://flex.org/tour and read more about the Merapi integration on Holly Schinsky's blog here: Flex/AIR to Java Communication Using Merapi.

Moving right along... There were a few new demos and a couple of Merapi announcements at the sessions we gave at 360 | MAX. One of the first demos I showed was Outlook integration. Here's the YouTube video:

The next new demo was Excel integration. If you pay attention to the video on this one you will notice one of the announcements we made at MAX, Merapi is now in the browser! In this demo you will see a Flex browser application interact with Excel:

Thanks again to Universal Mind and Adobe for supporting me at MAX.

Coming up...

FlexCamp Chicago 1/23, FlexCamp OC 1/31, and 360 Flex | Indy 5/18-20 (probably)

I'll be presenting at each of these conferences (assuming Tom and John let me in again.. they have yet to announce speakers) ;)

There will be some especially interesting announcements at FlexCamp Chicago. Make sure you turn out if possible, otherwise, watch the blogosphere for the recap.

Thanks to everyone who has been using Merapi and giving us feedback on the framework. The creativity, ingenuity, support, and patience from the community has been excellent.

Enjoy the new release!

The Brightkite Wall

In late 2008 Brightkite engaged Universal Mind to develop an application called The Brightkite Wall. The Wall is a Flash Application built using Flex.

For those of you unfamiliar with Brightkite, here's a quick overview:

Brightkite is a location based, micro-blogging, social networking platform. Unless you've been living in a cave for the last five years, you're probably familiar with sites like MySpace and Facebook. One of the features of these sites is something called a status. The status you set is meant to reflect something about your mood, or what you're up to, i.e.. "Adam is writing a blog post". This concept is similar to an away message on an instant messenger account. The first site to gain traction as a platform that specializes in status updates was Twitter.

Brightkite retains the idea of status updates and friending other Brightkite users, but adds the concept of a "check in". When you "check in" in Brightkite you're saying where you are, geographically speaking. So, status updates (called notes in Brightkite) are posted from a place. This means these notes often have an annotative quality about the place where the user is checked in. Brightkite users also have the option of posting photos at a Brightkite location. There are a lot more features in the Brightkite platform including: an iPhone application, a mobile site, and integration with other social networking platforms: Facebook, Twitter, Flickr, and Fire Eagle. To find out more about Brightkite sign up for your free account at: www.Brightkite.com.

The Brightkite Wall is a kiosk-style application that provides a feed form a place, a person, or for search terms in the Brightkite ecosystem. The application was built using Adobe's Flex 3 Framework for building Flash Rich Internet Applications.

One development challenge we faced was to implement a user interface that scaled in size regardless of the resolution of the display it was running on. Because the Wall can be launched on any machine, those machines might have a display like a small laptop screen or up to a large projection display. The Wall user interface needed to scale appropriately for each use case. This means fonts, images, and skins all need to look, relatively, the same one any given display size. Although this feature isn't extremely difficult technically, it is a bit tricky. However, Flex does offer some advantages when it comes to implementing a UI like the Wall.

Another challenge was implementing an application that would execute in a full screen mode and reliably for a long period of time. To achieve this requirement we implemented a "BoundedList" UI class that automatically disposes of unused list items, but also allows for various transition effects to be applied as new items appear in the lists.

The data source for the wall is the Brightkite RSS feed. The application is parameterized to allow for dynamic configuration (on launch), of the RSS feed, polling rate, Brightkite place, and the size of the bounded lists. The parameters are passed using Flash variables and accessed on the initialization of the application.

Although The Brightkite Wall is a fairly simple Flex application, built in just a few weeks, it is a great example of how Flex can fit into a platform. Many companies rely on Flex for their entire product line, and it is often a great choice for many products. In the case of Brightkite, they had a specific problem to solve and Flex happened to provide an excellent solution for the problem.

The Wall is still in beta and Brightkite needs your feedback on the kinds of features you'd like to see in the next version.

The Brightkite blog: http://blog.brightkite.com
Brightkite on Twitter: http://www.twitter.com/brightkite