You are viewing the Articles in the Software Engineering Category

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.

Local Persistence API

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.

    Managed ResourceBundle API

    The most common methods used to externalize or internationalize an application in Flex 2 are typically either an XML implementation or a ResourceBundle implementation. Both provide their own unique advantages and disadvantages.

    XML requires additional structural data which needs to be parsed in order to retrieve specific values, and, more often than not, results in larger files sizes. ResourceBundles must load each associated .properties file at compile time. Additionally, Flex Builder also contains a bug which causes a random compiler error to occur while attempting to resolve a reference to a .properties file for a specific ResourceBundle. However this error typically can be resolved by cleaning your project.

    IMHO, internationalizing and externalizing an application is much easier to do when working with ResourceBundles. Partially because they are ideal for working with locales and configurations, and also because ResourceBundles open up numerous possibilities in regards to externalizing an application, runtime class loading and so forth.

    The ResourceBundleManager provides an easy to use API which allows access to multiple ResourceBundle instances from a single, centralized location. All ResourceBundle instances for an application can be added, deleted and accessed by ResourceBundleManager. ResourceBundleManager provides methods for working with a typical ResourceBundle which allows all ResourceBundle properties to be accessed as a single, virtual ResourceBundle.

    The ResourceBundle API is published under the MIT License. You can download the ASDoc and swc which contains an example Managed ResourceBundle API Flex Project.