You are viewing the Articles published in

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.

    Configurable ContextMenu API

    The ContextMenu classes in ActionScript 3: ContextMenu, ContextMenuItem, ContextMenuBuiltInItems, provide a good base for working with context menus in Flex 2, however, they do not provide an intuitive API for developing and working with custom context menus.

    Such is the case whereas an application requires the flexibility to dynamically add, remove, enable and disable ContextMenuItems at runtime. To meet the requirements for an application which needs to meet any of the criteria I just mentioned, developers have 2 options; either work with the ContextMenu classes directly or develop a more intuitive API to provide the required functionality. I prefer to roll my own APIs in these situations.

    The ConfigurableContextMenu API allows developers to dynamically create custom context menus in which items can be added, removed, enabled, disabled and cloned dynamically at runtime. This opens up numerous possibilities such as adding individual context menus for each item in a DataGrid, or each node in a Tree, etc.

    The ConfigurableContextMenu API addresses certain issues which fail silently in the ContextMenu class such as ContextMenuItem collision and so forth. Developers can add caption items that do not require a listener or command items which contain both a caption and a listener to handle the item when selected. Items can be removed, added, cloned, enabled and disabled dynamically at runtime. ContextMenus can be created with a listener which is invoked when the contextmenu is selected (right-click). ConfigurableContextMenus can be added to any InteractiveObject or sub-class of InteractiveObject.

    The ConfigurableContextMenu API is published under the MIT license.

    Release version API

    I have published a software release version API which allows developers to set valid software release versions for a Flex 2 application. Release versions can be utilized for specifying additional meta data within a Flex application.

    The release version API contains a main entry point, ReleaseManager; a Singleton containing a reference to the ResourceBundle instance which comprises each valid release code.

    A release is set by specifying a valid release code which is defined as a constant in the ReleaseCodes class as follows:

    Each release code is mapped to a corresponding value in release.properties as follows:

    • SR00PA=Pre-Alpha: {0}.{1}.{2}
    • SR00AV=Alpha Version: {0}.{1}.{2}
    • SR00BR=Beta Release: {0}.{1}.{2}
    • SR00RC=Release Candidate: {0}.{1}.{2}
    • SR00GA=General Availability Release: {0}.{1}.{2}
    • SR00UR=Unstable Release: {0}.{1}.{2}
    • SR00SR=Stable Release: {0}.{1}.{2}

    The tokens in each release code are substituted by the developer according to a projects current release version; major, minor, revision/build.

    You can download source as well as view the ASDocs

    Label statement in AS3

    In ActionScript 3 a label statement is used to associate a statement with an identifier which can be referenced by both the break and continue statements to exit a block of code. Basically, a label statement is the equivalent of goto in C – yes, I know what you’re thinking!

    For instance, in a nested loop, a break or continue statement will only break out of the immediate loop and will not skip the entire series of loops (the end of the outer most loop) as one might expect. Labels are used as identifiers for an entire block of code from which a break or continue statement can reference in order to skip the entire series of loops or a specific loop from within a series of nested loops.

    An example of how a label statement can be used to break out of an outer loop is as follows:

    A label may also be referenced by a break statement to exit a block statement as follows:

    Typically, it is rare that you would need to use the label statement, however, in certain situations if it is necessary and can be justified, the label statement provides a convenient way to exit code.

    Update to Flex 2 Local / Object Debugger

    One recommendation I would make to the Engineers at Adobe is that the global trace(); method in Flex 2 become a bit more robust. Just as in previous versions of Flex and Flash the trace method only handles simple types; String, Boolean, Number, int, unit etc.

    Flex 1.5 had a really good object debugger available but I have yet to find something similar for Flex 2. So I decided to build my own debugger to handle recursively tracing objects of complex type; Array, Collections, Object etc.

    The Flex2LocalDebugger is a simple Object debugger API which uses LocalConnection for tracing objects of both simple and complex types to a debugger console. Flex2LocalDebugger does not provide a logging API, however users could easily extend FlexLocalDebugger to add logging capabilities.

    The LocalDebugger console runs in a browser so you can easily switch between your application and the debugger from within the same browser, without the need to to run the debug player. This is useful for when you simply want to trace an object of complex type without running the Debug version of Flash Player.

    The main entry point into the FlexLocalDebugger API is the LocalDebugger class. The LocalDebugger class provides methods which allow objects to be sent to the debugger console as well as displayed in an Alert window:

    • trace();
      Checks to see if the object specified is of simple or complex type. If the object is of simple type LocalDebugger will send the object to the debugger console. If the object is of complex type, LocalDebugger will recursively trace the object and all elements of the object to the debugger console.
    • send();
      Allows users to bypass recursive tracing and send an object directly to the console.
    • show();
      Traces an object to an mx.controls.Alert window. Similar to trace, mx.controls.Alert will only trace a String in an Alert window. For ease of use, FlexLocalDebugger handles casting an object to String and displaying the object in an Alert window within the application.
    • allowConnection();
      Terminates / allows all connections to LocalDebugger

    The debugger will recursively trace an object of complex type. Each call to LocalDebugger.trace(); prints a [trace-object-root] when tracing a new object. This is the root of the top level object which has been specified as the parameter in a call LocalDebugger.trace();.

    To use the Flex2LocalDebugger API in your application, simply right-click on your project and select: properties > Flex Build Path > Library Path > Add SWC. Browse to the location of FlexLocalDebuggerAPI.swc and click ok.

    You can download the swc as well as view the documentation for the Flex Local Debugger API.

    Flex2LocalDebugger is protected under the MIT Licence.