AS3 Iterator API Update

I have updated the Iterator API to include a generic CollectionIterator which can be used to iterate over concrete IList implementations such as ListCollectionView, ArrayCollection and XMLListCollection.

I have also removed the abstract base implementation for all concrete Iterators in favor of the IIterator interface.

In case you are not familiar with the Iterator API, it allows developers to traverse an aggregate without the need to expose it’s underlying implementation. Developers can utilize the Iterator API to easily and intuitively iterate over Arrays, Collections and objects with the same Iterator instance. You can also implement the IIterator interface to provide additional concrete iterators in addition to the ones which I have provided; Array Iterator, Object Iterator and Collection Iterator.

A concrete Iterator can be instantiated directly or dynamically at runtime via the IteratorFactory. Typically, developers would type an iterator instance as an IIterator so as to utilize the IteratorFactory to retrieve the concrete iterator types as needed.

I have provided a simple example which contains the compiled source as well as the ASDoc and UML diagram.

source / example
ASDoc
UML

40 years worth of Objects

Of the many facets of software development which I take part in my true passion has always been Object Oriented Design, that is, I naturally tend to gravitate towards the design, relationships and interactions between objects within a system.

Currently I tend to concentrate primarily on ActionScript 3.0, however I am language agnostic in the sense that I am not driven by a particular language or simply by the solution in which a language provides, but rather by the gratification I receive from working with a language that adheres to Object Oriented Principles and the results of this practice.

I brought to my teams attention the other day at work that this year marks the 40th anniversary of the first Object Oriented language. I also mentioned this to a few former co-workers of mine whom are also fellow OO enthusiasts. They said I should blog about this milestone, and so I am as I feel many of you will find the origins of Object Oriented Programming interesting.

In the late 1960s two Norwegian programmers, Kristen Nygaard and Ole-Johan Dahl were developing a new language which would be able to naturally describe complex systems at a higher level using concepts that were much easier to grasp. This new language was called Simula 1 and was derived from an existing language Algol. Algol was a block structured language which was comprised of functions containing variables and sub functions. The owning function amounts to a data structure on the stack. The sub functions can access the variables defined within the data structure. It has been said that they experimented with moving this data structure from the stack to the heap, this way the variables and sub functions would outlive the owning function once it had returned.

Now if you read the last paragraph again you will notice that something sounds very familiar; the owning function is a constructor, the variables defined within the owning function are instance variables and the sub functions are methods.

Simula-67 – the very first Object Oriented Programming language was born!

And so I thought I would take a moment to reflect on the origins of the OO concepts which we work with on a daily basis and have come to enjoy so much.

Resource Writer API for Apollo

The ability to create files to a local filesystem via ActionScript is one of the main attractions of Adobe Apollo.

For years developers have been restricted by the Flash Player security model and for good reason. It was quite common to delegate the responsibility of creating files to a middle tier service. However middle-tier services only enabled files and directories to be created on the server, and not the client machine, unless the application server was running on the client machine, which for the most part is never the case.

As many of you are probably aware of by now Apollo provides Flex Developers with the ability to create files to a local file system purely in ActionScript via flash.filesystem.File. This new functionality creates endless possibilities.

Taking advantage of this, I have developed a ResourceWriter API for Apollo which allows developers to easily create .properties files to a local file system. This is useful creating localized content which needs to be modified frequently as well as many other uses.

You can view the source: ResourceWriter, IResourceWriter, IInspectableFileClient as well as download the example Apollo Application.

Query String Inspector for Flex

It is common for Flex applications which are deployed to an application server to require specific parameters be provided via the applications query string.

The Flex Framework Application class provides a parameters property which contains the query string provided to the application as well as the FlashVars HTML parameters provided to the application. This is very useful as developers are no longer required to facilitate interoperability between ActionScript and other languages, typically JavaScript, just to get an swf applications query String.

The QueryString inspector is an all static class which takes advantage of this by providing an API which allows developers to perform detailed inspection of an applications Query String.

Below is a description of each method:

  • rawQueryString: Retrieves the raw query string provided to the application
  • isProvided: Determines if parameters have been provided to the application
  • nameValuePairs: Creates an Array of objects comprised of each name / value pair provided to the application
  • parameters: Retrieves the parameter names provided to the application
  • values: Retrieves the parameter values provided to the application
  • containsParameter: Determines if the specified parameter has been provided
  • containsValue: Determines if the specified value has been provided
  • getValue: Returns the value of the specified parameter
  • length: Returns the length of the query string

FileWriter API for Apollo

I have published a simple FileWriter API for Adobe Apollo which is essentially an all static class providing methods for synchronous and asynchronous File creation.

FileWriter encapsulates file creation in an all static class which can be used to easily and intuitively create files to a local file system simply by specifying the name of the file to create as well as the path in which to the file is to be created.

FileWriter will create a new file if the file does not currently exist and return an open FileStream referencing the file object via FileMode.WRITE, otherwise FileWriter will open a previously created file and return an open FileStream referencing the File via FileMode.UPDATE.

You can view the source as well as download the basic sample application which allows you to create a File to your desktop utilizing the FileWriter API.

FileStream namespace bug in Apollo

One thing that you may encounter when attempting to use the FileStream Class in Apollo is that it does not resolve to the correct package.

For instance, FileStream is mistakenly located in the flash.events namespace but is actually defined in the flash.filesystem namespace. This creates a problem when you try to import FileStream in the Eclipse IDE as intellisense will not locate the class. However, FileStream does not resolve to flash.events. FileStream and you will get a compiler error if you attempt to import flash.events. FileStream, even though intellisense will find it.

So the solution is to simply import flash.filesystem.FileStream as it is intended to resolve to this package even though you will not see it using intellisense. This is a weird bug that can leave you scratching your head for awhile so I thought I should mention it here.

Remember that this is just the initial Apollo Alpha and I am sure that this bug will be addressed in the next release.