Archive for Actionscript

Exploring Adobe AIR

// September 23rd, 2009 // No Comments » // Actionscript, Computer Software, Flex, Web Development

Recently, I’ve begun developing a Flex application for the desktop using Adobe’s Integrated Runtime (AIR), which is a local library for running Flex applications. One of the most enticing features of AIR applications is the ability to deploy them cross platform with little to no machine-specific code (except perhaps special keystrokes on Mac).  As well, the ability to store data on the client machine is also extremely convenient.  Gone is the worry of keeping a web interface tuned to the application, which can assist in streamlining development into a more user-friendly product.

The only downside to the desktop application is the lack of custom data that would have previously been delivered through the web interface. At least, that’s what I thought.

My exploration into the AIR libraries and many tutorials on the web is that AIR has built-in, for free, SQLite that will allow an application to store and manage data persistently for the lifetime of the application’s existence on the client machine.  There are some minor limitations from a backend development standpoint (like lack of stored procedures), but nothing that should be a surprise to users familiar with ‘lite’ databases.

One of the difficulties with local storage like this is the fact that sensitive data stored through SQLite is not necessarily secure, since it exists on the user’s machine unencrypted. If this were a regular Flex application, all of the data would reside on a database server we own. However, since this on the client’s side, Adobe has a featured called encrypted local store.  The usage and explanation of this feature is out of the scope of this article, but it’s simply a class with static methods that can “get” and “set” values of any kind into encrypted storage. Perfect for storing authentication tokens, and other similar pieces of data.

With data taken care of entirely through AIR, it leaves the developer available to focus to on the user experience with their application. Which for me, has always been a very difficult part to nail down. I’ve written about GUI design previously, and still learn new things everyday either from coworkers, or my own personal experience with software I use frequently.

Hopefully by year end, Flash Builder 4 (the successor to Flex Builder 3) will be released, but more importantly, a program called Flash Catalyst will also be released (likely in tandem). Judging by the demo videos of designer and developer working together to build a Flex interface, mocking up a realistic interface can include physically converting the items in the mockup into flash style definitions.

The more I watch the demonstrations of this technology, the more tempted I am to put my pet project on hold and wait for these to be released.  The trial download for Flash Builder 4 is available from Adobe Labs, though I challenge anyone to use it for the full 30 days and try to return to the previous version. Luckily, my last install of the trial was interrupted by a failed hard drive – I was subsequently saved from the spoils.

Future posts will explain my experiences with my pet project in AIR, which I hope to release to public use as soon as it’s near stable, likely sometime in the new year.

Component Crazy: Handling Your Growing Flex Application

// September 3rd, 2008 // No Comments » // Actionscript, Flex, Web Development

It’s no surprise to developers that the requirements for an application are bound to change, and it’s because of this fact that there are numerous architectures for developing software applications that can ease the process of adding new functionality. 

For Flex specifically, one such architecture is Cairngorm, which has been described here a few times. But as easy as it is to manage important events in the application, even the best architecture fails to simplify a project.  It always gets to a point where there are too many pages to keep track of.

Using a personal example, the backend administration tool that has been in development for my entire tenure at the company (and as such, requirements have shifted dramatically over this time period) has grown to house a fairly large number of major components. Two types of search pages, two types of master-detail pages, a login page, two types of general site maintenance pages and a number of custom renderers and other compents necessary for image retrieval and display.

How does one keep track of all these different areas that a user is supposed to seamlessly surf through?  At first I had a show/hide game going on, but after about 3 different major compents were in use, the process became unmanageable. 

Then I discovered States.

Using the ModelLocator of the Cairngorm architecture, I decided to hold two significant states: the authentication state, and the application state. Both variables declared as strings.

Here’s how the format of the application implements states:

MainApplication.mxml -> Two states: Valid, or invalid.  

When this loads, it dispatches a Cairngorm event to check if a user session exists (via amfphp, to a Zend_Auth controller), if does then the variable for authentication state in ModelLocator is set to “valid”, if not it is set to “invalid”.

In the MainApplication.mxml file, two states are listed such:

1
2
3
4
5
6
7
8
9
10
11
12

<mx:states>
	<mx:State name="invalid">
		<mx:AddChild>
			<mx:LoginComponent />
		</mx:AddChild>
	</mx:State>
	<mx:State name="valid">
		<mx:AddChild>
			<mx:WrapperComponent />
		</mx:AddChild>
	</mx:State>
</mx:states>

The currentState property of the application is bound to the ModelLocator variable for authentication state. So in the event that this property changes to either of these states, the child component will be loaded.

In the case of the administration tool, one of these is a login form and the other is a wrapper component for the next tier of major components. For this example it is called WrapperComponent. Its currentState property is bound to a separate ModelLocator variable to control the general application state.

This solved the problem of having to manage N different components in a complex administration system, and now the code will only need to manage the application state variable and the rest is taken care of.

For added flair, states can also have transitions set to them. Which if done correctly and sparingly, can really add to the look and feel of an application.

Incident Reporting to RIAs: A Journey

// July 13th, 2008 // 1 Comment » // ASP.NET, Actionscript, Flex, Web Development

Introduction

In February 2007, just a few months after earning my BSc., I was hired by a local custom software development company to assist in the development of several large-scale applications for the international airport, as well as enhancing an internal item-tracking system with ASP.NET.  Using ColdFusion, MS SQL, and the Model-View-Controller architecture it was my duty to help build applications that either managed money or managed incidents.  It was a massive learning experience that I had thought weathered me to the storm of professional software development. However, when the company closed its doors over a year later due, I became quickly aware of how very little I had scratched the surface.

After several intense and interesting interviews at several different organizations, I pursued one position which preferred me to specialize in PHP.

Having only seen PHP and never utilized it, I was apprehensive about pursuing the choice. However, after two interviews and a telephone conference later, it was clear to me they found more interest in me than just my passing knowledge of PHP, but rather in my experience in Object-Oriented Programming (OOP).

A Whole New Can of Worms

Day one on the job opened up a Pandora’s box of research, troubleshooting, and headaches.  I was assigned as an Adobe Flex developer. My requirement was to design, maintain, and enhance an administration tool for a high-profile website in tandem with another developer who was much more experience in the architecture and ActionScript than I was.  The most I’d seen of Flash development was at least five years ago and I made a ball roll across the screen. Needless to say, programmatic development in this language was alien to me.

The most challenging part about this new position was a few things:

  1. The job centered around a single site and proposed future sites
  2. I had never developed any sort of graphical Flash application or otherwise
  3. The usefulness of knowledgeable people was sadly stunted by over-inflated egos

Challenges aside, I toughed out the first month and suddenly found myself really getting the idea behind graphical development. Funny enough, learning the language was the easiest part of the transition, it was everything else that was difficult.

Developing a flash-based image cropping tool was probably the biggest mouthful I’d had to digest in my professional career. At my previous job, there was hardly a task I would’ve had to scratch my head over by the time of my departure, and now in the first week of this one I’ve got the biggest head-scratcher a head’s ever seen.

Once the tool was developed it was integrated into the Cairngorm architecture of our Flash application (a relatively simple MVC system which simplifies scalability), and I was onto my next task.

Unit Testing as a Pioneer

Show of hands on who’s developed unit tests for an application? (probably a good number)

Show of hands on who’s developed unit tests in Cairngorm? (probably a much smaller number, but thank God for FlexUnit)

Show of hands on who’s developed unit tests in Cairngorm to test asynchronous service calls via amfphp? (Oh god, am I the only one?)

Needless to say my next task was nearly as trying as the first, but I was determined to make it happen.

For anyone new to Cairngorm and especially to the idea of testing asynchronous calls to a service, it’s important to remember that not everything anyone else says is right for your application. I’ve tried numerous methods in order to get a proper test done and only after about 3 weeks was a half-solution decided upon.

First and foremost, read through every word of Steven Webster’s starter guide to Flex and Cairngorm and familiarize yourself with the setup, and be absolutely certain you’ve followed his guidelines for developing your application. The next step is to grab FlexUnit, a wonderful testing suite written by the good folks at Adobe to help test-driven developers like myself build a better system.

Once FlexUnit’s installed, look at your code and commence the head-scratching.

Look to part 2 of this entry for some actual code and suggestions to assist your testing needs.