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

It has been awhile since I initially posted the pre-alpha release of Cairngen in early January. As I had mentioned in the original post, Cairngen was simply a tool which I created to help speed up my own personal development process when building Flex applications with Adobe Cairngorm. My intentions were to share the project “as is”, as I had assumed other developers would certainly benefit from using Cairngen to quickly generate Cairngorm classes and project directories. I have since received numerous E-mails from many developers who are using Cairngen and the feedback has been very positive.

In part, I released Cairngen to demonstrate just how easy it was to build a simple tool to generate Cairngorm projects and templates. From start to finish the pre-release version of Cairngen took around 6 hours or so. Another reason I released Cairngen was in the hopes that other developers with the required time available would take an initiative and build a proper Eclipse based plug in version of Cairngen.

Since Cairngen’s pre-release, there has been many developers building their own versions of Cairngen in other technologies, and I see this is as a very good thing for the community. Originally, I was contemplating releasing Cairngen to the community as an open source project in order to allow developers the ability to extend the APIs to suit their particular needs. This would alleviate much of the need for my continued maintenance and support of the project.

So what is the future of Cairngen moving forward? Ultimately, I have decided to re-develop Cairngen from the ground up as an Apollo application. Building Cairngen in Apollo will give me maximum flexibility and allows Cairngen to run as a stand alone application. I still have some additional research to complete before I can officially confirm, however, it will definitely be possible, and it will also help build interest in the Apollo community as well.

So if you are developing applications with Cairngen you can expect the version 1.0 release to be available as an Apollo application shortly after the alpha release of Apollo is available. If you have any requests for the 1.0 release feel free to comment.

There are a number of different ways in which a Flex application can persist data. Typically, in most real-world situations data is persisted on the server, but for specific situations where it is logical to persist data locally on the client in order to reduce unnecessary overhead, flash.net.SharedObject is the preferred solution.

SharedObject is easy to use and provides a relatively simple base API from which developers can utilize in order to persist data locally. However, in order to enforce that local persistence is maintained consistently across applications, a more robust API is needed.

Local Persistence API allows developers to consistently work with session specific data. The data is persisted locally on the clients file-system via SharedObject. Data can be saved and accessed intuitively in accordance with rules governed by the Flash Player Security Model.

Local Persistence API provides a solution which allows developers to create session specific timestamps and genuine unique identifiers (GUID), consistently get / set and delete persisted properties without knowledge of the underlying implementation, specify specific object encoding for persisted SharedObjects as well as SharedObject name validation and invalid charachter substitution.

Local Persistence API is protected under the MIT license. You can download the LocalPersistenceAPI bundled compiled source, asdoc and uml documentation.

Today I re-built my ActionScript Debugger from the ground up for ActionScript 3.0 / Flex 2.0. If you are not familiar with the ActionScript debugger it is a simple Local Debugger which recursively traces out various complex types such as Objects, Arrays etc to a seperate .swf file.

I will continue to build on the current functionality to take advantage of the various new type-checking features in ActionScript 3.0.

To see an example of the Debugger in Action click here