Archive for the 'Adobe AIR' Category

Cairngen Project moved to Google Code!

Monday, March 31st, 2008

Since the initial release of Cairngen 1.0 there has been an amazing amount of interest in the project and your feedback has been very encouraging. In addition I have received a number of extremely valuable customizations from community members, many of which have made it into subsequent releases.

In order to provide a solid foundation to help facilitate a collaborative Open Source initiative for the Cairngen Project I have decided to move the project to Google Code.

Moving Cairngen to Google Code allows for a number of significant development benefits for the Cairngorm Community. This includes regular development updates, access to all releases, availability of all source code revisions, better documentation, defect lists, feature requests and much more.

I am currently accepting requests for new contributors so if you feel you have added new functionality which would provide benefit to the project visit the Become a Contributor page. All comments on the project are welcome and encouraged. In addition I strongly recommend the if you have any issues with Cairngen, especially environmental issues you should log them to the Issues Page.

Along with the new Cairngen Google Code Project I have also released Cairngen 2.1.1 which aligns the source project with the new SVN repository.

So go check out all of the new information on Cairngen at the new Cairngen Project Home.

Using multiline values in properties files

Monday, March 24th, 2008

When building localized Flex applications with ResourceBundle there are a few tricks you may not be aware of which can come in handy should you need them.

I have had quite a few people ask how multiline values can be specified in a properties file. This is a pretty common question and luckily the answer is very simple: backslash (\).

For example, suppose you have a properties file which contains a string resource with a really long value, like a paragraph. Typically the property value will just be one really long String on one line. However you can use the backslash (\) character to continue the value on multiple lines in order to make the properties file more legible, such as in the following example:

title   = Welcome
message = Lorem ipsum dolor sit amet, consectetur elit, \
sed do eiusmod tempor incididunt ut labore et dolore magna \
aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
ullamco laboris nisi ut aliquip ex ea commodo consequat. \
Duis aute irure dolor in reprehenderit in voluptate velit \
esse cillum dolore eu fugiat nulla pariatur. Excepteur sint\
occaecat cupidatat non proident, sunt in culpa qui officia \
deserunt mollit anim id est laborum.
 

So if you have properties with very long values remember to use backslash (\) to help clean up your resources.

example

Accessing private class members in AS3

Tuesday, March 11th, 2008

Reflective programming is a very common, powerful, yet expensive software development practice. In most modern programming languages reflection can not be utilized to modify private members of an object, which is to be expected. However in certain circumstances, such as when developing very high level frameworks and automation APIs it may be beneficial at times to be have the ability to access private members of an object from outside of the public API of the class.

For instance, consider the following class definition:

// User class does not define setter functions for
// the private members _username and _password
package com.ericfeminella.example
{
    public class User
    {
        private var _username:String;
        private var _password:String;
       
        public function User(username:String, password:String)
        {
            this._username = username;
            this._password = password;
        }      
        public function get username() : String
        {
            return this._username;
        }
       
        public function get password() : String
        {
            return this._username;
        }
    }
}

The above class defines two private members: _username and _password. The public API of this class exposes these properties via the read-only accessors get username and get password. Per design assignments to these properties can only be made via the instance constructor.

So how can these values be modified once the object has been instantiated? More importantly, should this be allowed as the properties have not been publicly exposed? Theoretically they can not, philosophically they shouldn’t. All of this is debatable; however as a dynamic programming language ActionScript can easily accomplish accessing and modifying private members of an object which have not been exposed.

To do so is simple: define a method which provides an interface into the private members of the class instance, as in the following example:

// static method which provides a mechanism allowing
// private properties to be modified
public static function modifyMember(instance:User,
                                    property:String,
                                    value:*) : void
{
    try {
     instance[property] = value;
    }
    catch(error:ReferenceError)
    {
        throw new ArgumentError(property+not defined by+User);
    }
}

The above example is pretty straightforward. It is simply a static method which requires 3 arguments. The first being the instance of the class, the second is the property in which to assign a new value, and the third is the value to assign to the property. This static method can be defined in any class and will work fine - you only need to change the type of the instance argument and error message to match the type of the class in which the method is defined. All methods in a class definition have access to any member of the class therefore assignments can be made to an instance of the class via a static method. This is possible in most object oriented languages such as C# and Java, however ActionScript takes this approach into the dynamic realm thus making it much more robust as the actual properties which are to be modified can be specified at runtime.

This approach can just as easily be accomplished on the instance level as well via an instance method, as in the following:

// instance method which provides a mechanism allowing
// private properties to be modified
public function modifyMember(property:String, value:*) : void
{
    try {
       this[property] = value;
    }
    catch(error:ReferenceError)
    {
       throw new ArgumentError(property + not defined by+this);
    }
}

A client implementation for each would be as follows:

var vo:User = new User("foo", "bar");

trace( vo.username ); // foo
trace( vo.password ); // bar

// static implementation
User.modifyMember( vo, "_username ", "efeminella" );
trace( vo.username ); // efeminella

// instance implementation
vo.modifyMember( "_username ", "admin" );
trace( vo.username ); // admin
 

This approach is best suited for assigning values to simple types, or for pointing reference types to other object instances. This does not allow nested properties of a member to be accessed or modified (although it could easily be refactored to do so). Most importantly, (as you may be thinking) this breaks encapsulation and violates information hiding; therefore I do not recommend utilizing this approach for general use, however it is a convenient and efficient way to modify objects when developing complex APIs which use reflection and also for implementing Unit Tests directly against private members.

Initially I was introduced to the static implementation of this technique by a .Net developer on my team, and admittedly I was somewhat skeptical at first, however given the dynamic nature of ActionScript I realized this could open up some interesting possibilities under unique circumstances, similar to how mixins open up many possibilities - when used with discretion in a good design they both provide powerful advantages over other languages.

Food for thought. Enjoy.

LocalPersistenceMap

Sunday, March 9th, 2008

When developing browser based Flex application SharedObject provides just about everything one needs to facilitate local persistence of application data. SharedObject is restricted by certain rules governed by the Flash Player Security Model, however it is very efficient for general use.

The data property of a SharedObject provides read/write access to the underlying data which is persisted to the SharedObject. Personally, I prefer to have a consistent API available when working with dynamic objects, thus I developed the IMap interface.

LocalPersistenceMap provides an IMap implementation into the data property of a SharedObject instance. It allows clients to work with the underlying data of a SharedObject just as one would with a HashMap, ResourceMap, etc.

Below is a basic example which demonstrates how LocalPersistenceMap can be utilized to provide an IMap implementation into a SharedObject:

var map:IMap = new LocalPersistenceMap("test", "/");
map.put("username", "efeminella");
map.put("password", "43kj5k4nr43r934hcr34hr8h3");
map.put("admin", true);

The LocalPersistenceMap constructor creates a reference to a local SharedObject based on the specified identifier and optional local path. A reference to the underlying SharedObject can also be retrieved via the sharedObjectInstance accessor.

In addition to the new LocalPersistenceMap, I have also packaged the Collections API which can be downloaded here. Complete documentation and code examples for the Collections API are also available here.