Archive for January, 2008

SQLite Administrator

Thursday, January 24th, 2008

When developing application in Adobe AIR which utilize the SQLite API it is often useful to have a quality SQLite editor available, especially during development and testing.

I have tried many different SQLite editors, most of which were quite good, however the best of the bunch you have to pay for.

Personally I recommend SQLite Administrator. SQLite Administrator is a powerful tool which allows for the design, creation and modification of local SQLite databases. The code editor is very intuitive and provides a simple UI which allows you to write SQL queries with little effort. In addition, there are many useful features which you would expect from a quality editor such as code completion and highlighting.

SQLite Administrator

So if you are looking for an high quality free SQLite Editor when working with Adobe AIR and SQLite check out SQLite Administrator

InsideRIA.com

Wednesday, January 23rd, 2008

InsideRIA.com

O’Reilly and Adobe have teamed up to create an invaluable online community for RIA developers. This new project will provide up-to-date information on the ever-changing state of design and development in the Rich Internet Applications (RIAs) space.

Rich Tretola will be championing the effort for InsideRIA as the Community Manager.

Show your support so we can make InsideRIA the number one place on the Internet for Rich Internet Application resources and information.

Flex Unit TestSuiteHelper

Friday, January 18th, 2008

Test Driven Development is an essential part of any software project. Leveraging Flex Unit in your Flex and AIR projects is a well known best practice and will inevitably result in less unknowns and provide a much more reliable codebase, however like most things in life that provide value, unit testing comes at a cost: Time.

In general, writing Unit tests is often an overlooked process as it ultimately equates to an additional level of effort (time) in a project plan. However, writing unit tests should not be over looked for a number of reasons, and in my opinion most importantly because it forces developers to understand what problems the code they write are intended to solve, thus resulting in a better understanding of the problem domain.

Now without getting into a lengthy discussion about the benefits of Test Driven Development, as there is plenty of information available on the subject, I am going to focus on how to make it easier in Flex.

Typically when I write a unit test I stub it out and then run the test runner to make sure it fails. I pretty much do this immediately after I write the test and then I see that my test did not come up and realize I never added it to the test suite. Obviously something like adding tests to a test suite can be an automated process which would allow unit tests to be developed a little faster as all that would be needed was to write the test.

So in an effort to simplify the process of adding tests to a test suite I have developed a TestSuiteHelper which is a simple utility class that automates the process of adding unit tests to a test suite. Rather than manually adding each test the TestSuiteHelper will automate the process simply by invoking a static method and passing in the test class from which you need to extract all of the tests.

So if you would like to simplify your team’s unit testing workflow feel free to utilize the TestSuiteHelper.

API Design: Method parameter objects

Saturday, January 12th, 2008

When defining a constructor or method with more than three parameters it is considered a best practice to create a parameters object for holding the values which are required. This especially holds true when some of the parameters are optional (as they will contain default values) and also when two or more consecutive parameters are of the same type (as developers may accidentally transpose these parameters - which will not result in compile time or runtime errors, making debugging a nightmare!)

The most appropriate solution for such cases is to break up the method into separate methods, however when this is not feasible creating a parameters object will improve both code readability and provide a cleaner design which leaves less room for unexpected errors.

Consider the following method:

public function someMethod(a:String,
                           b:Object,
                           c:int = 1,
                           x:int = 2,
                           y:int = 3,
                           z:Boolean = true):SomeType
{

The parameters defined in this method are typical of what you will often see, however it is much cleaner and reliable to create a parameters object for holding these parameters. In addition, a parameters object allows for a much easier client implementation as default values need not be reassigned for all parameters which proceed a parameter which you need to specify a value other than the default value. For instance, if a method accepts 5 parameters and the first two parameters are required but the last three are optional, if you you need to specify a value for the last parameter you will need to re-assign the default values for the proceeding parameters, when in fact you really only need to specify three parameters.

The following example demonstrates creating a parameter object which can be passed to “someMethod”:

package
{
    public final class SomeMethodParams
    {
      public var a:String;
      public var b:Object;
      public var c:int = 1;
      public var x:int = 2;
      public var y:int = 3;
      public var z:Boolean = true;
       
      //only specify required parameters in constructor
      //optional parameters are simply public properties
      //which have default values assigned
      public function SomeMethodParams(a:String, b:Object)
      {
          this.a = a;
          this.b = b;
      }  
   }
}

When invoking “someMethod” clients can now simply instantiate an instance of the parameter object, set values only for what is needed and pass it in as follows:

var params:SomeMethodParams= new SomeMethodParams("a",{}) ;
params.z = false;

instance.someMethod( params );

So if you would like to improved code readability and provide proactive exception precautions, consider utilizing parameter objects for methods which require more than three parameters.