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.

January 20, 2007 News
2 Comments

WebORB for PHP v1.3.2

I have been hearing a lot about Weborb for PHP so I decided to check it out for myself. If you are not familiar with Weborb, it is a server based technology that provides a Flex RPC service implementation which exposes remote PHP objects to a Flex client via remoting utilizing AMF3.

WebORB for PHP can be installed in your server root on any web server which supports PHP 5. Weborb for PHP is very easy to use and the documentation is good. I had it installed and got the sample application up and running in about 5 minutes.

Weborb for PHP is similar to AMFPHP in many respects. Both Weborb for PHP and AMFPHP alpha 1.9 provide AMF3 support. Neither requires FDS. All in all they both provide similar solutions, just in different ways.

If you are a Flex developer who builds backends in PHP, or if you are a PHP developer who is interested in developing rich client applications in Flex then Weborb for PHP is definitely worth a try.

You can check out the simple start up tutorial at the Weborb site. You can also check out WebORBPHPRemoteGateway, which is a generic base class I wrote that developers can extend for use in a Weborb for PHP Flex application.

January 18, 2007 News
Comments Off on WebORB for PHP v1.3.2

Pseudo-abstract classes in AS3

I was developing an API which required specific abstract base classes to be developed in order to provide a default implementation for derived concrete classes, and, as you may know ActionScript 3.0 doesn’t support Abstract Classes (classes which can not be instantiated) so I had to develop my own solution that I thought I would share.

Abstract classes in general are classes which can not be instantiated directly, but rather would be used as a base class in which sub classes would provide a specific implementation. For example, a “Mammal” could be considered an abstract class as there are no concrete examples of a generic “Mammal” per say, but there are instances of it’s decedents; People, Dogs, Cats etc., which would more than likely also be abstract types themselves, however, eventually in the inheritance chain there would be concrete classes which would override the methods defined in the base class. The base class would provide a default implementation for it’s decedents but would also require that derived classes override methods which it can not provide a default implementation.

In ActionScript 3.0 you can not use the private access modifier in a constructor definition and ActionScript does not provide an actual abstract keyword, therefore you can not create a true abstract class.

So how do you create a “pseudo abstract class” in ActionScript 3? My solution is very simple:

In the above example all I am doing is creating an inner class: Private, which is only accessible from within the defined class Abstract. This enforces that only an object of type Private can be passed as an argument to the constructor.

Now were on to something. As you can clearly see from the example above, only a sub class of Abstract has access to an instance of Private via the protected static function getAccess(). Therefore only a sub class can instantiate an instance of Abstract, and why would it ever need to if it is a sub class? The sub class would then call super in the constructor and pass the instance of Private via getAccess(); as follows:

This is a pretty elegant solution in my book. Yes, it is obviously not an abstract class in the true sense of the word but it does the trick if you want to enforce that a class is never directly instantiated.

I would suggest restricting all Abstract classes access to internal if possible in order to help further avoid potential misuse by limiting access to package level classes only.

01.04.08 – I have since implemented a utility class for enforcing Abstract types which I recommend using over the implementation in this example. The AbstractEnforcer and examples can be found here

January 16, 2007 Code Review / Design Patterns / Object Oriented Design
2 Comments

Referencing “this” in AS3

Someone recently asked me why should they use the “this” keyword? My response was that you can use a reference to “this” as an easy way to disambiguate instance members from method parameters, local variables and so forth. In certain cases such as dynamic classes, the use of the “this” keyword is required.

After giving a little more thought as to why I originally began utilizing references to “this”, I quickly realized that it began back when AS2 first came out. At the time, I was a Flash engineer who specialized in Object Oriented design in Flash / ActionScript. There were a lot of Flash developers who would use references to _root as a way of dealing with scoping issues specific to Flash. This was definitely a bad idea as application requirements would demand scalability and if ever anything needed to change things would begin to break throughout the application. I began advocating the use of the “this” keyword to my team as a way of enforcing best practices and standards within our organization, but most of all, to eliminate convoluted scope references which would lead to applications failing to scale as needed.

When I moved over to the Flex world during the Flex 1.5 days, I would see the same kinds convoluted references to _root… so again, I quickly began enforcing the use of the “this” keyword to other team members.

So why do I still use the this keyword you might ask? Is there any real benefit? Not really. In reality the “this” keyword is the exact same construct as the “this” pointer in C++, as it is implied by the compiler if not explicitly specified. “this” simply points to the calling object’s pointer variable underneath the covers so to speak.

In the following, both examples are quite literally identical as far as the compiler is concerned:

However, in certain situations using a reference to “this” is required, such as dynamic classes as I had mentioned earlier.

The actual AS3 definition of the “this” keyword as defined by Adobe is:

“A reference to a method’s containing object. When a script executes, the "this" keyword references the object that contains the script. Inside a method body, the "this" keyword references the class instance that contains the called method.”

This is exactly my point. If ever you see a reference to this, you automatically know that the object being referenced is a property or method of the class instance in which you are working. You don’t have to figure anything out.

So it is a matter of personal preference. Again, I mainly use references to this out of habit, but also as a quick way to disambiguate instance properties from method parameters and so forth. Some people prefer to name all instance properties with an under score, and parameters without an underscore, and vise-versa. I personally don’t. Using references to this works for me and it may also work for you, or it might not.

So again, it is a matter of personal preference, and in the end it is simply a matter of whatever works best for you.

January 10, 2007 News
2 Comments

AMFPHPRemoteGateway API update

I have modified my AMFPHPRemoteGateway API to only support ActionScript implementations.

The AMFPHPRemoteGateway class is now to be considered a base class, not necessarily a pseudo-abstract class, but rather a base class in which sub-classes can build on to implement specific remote method invocation. You can still use AMFPHPRemoteGateway directly as well for general purposes.
Sub classes of AMFPHPRemoteGateway should now implement mx.rpc.IResponder and pass a reference of themselves to the new addResponder(); method.

I have also added a generic DAO interface which implementors can utilize to perform typical create, read, update and delete (CRUD) operations on a persisted object. The new interface, IDAO, provides a default contract which can be implemented by AMFPHPRemoteGateway sub-classes for specific remote DAO invocation.

I suggest that users create individual sub-classes of AMFPHPRemoteGateway for each domain object in which to perform CRUD operations on.

You can view the docs as well as download the swc. There is also a project folder in the download which contains a basic usage example.

January 6, 2007 News
1 Comment

2007 Golf Digest Hot List

I have just completed development of Golf Digest’s 2007 Hotlist, which was developed entirely in Adobe Flex 2 and Cairngorm 2.0.

The 2007 Hot List is a good example of organizations beginning to utilize the power of Flex to improve the user experience, and for us Flex developers this is exactly what we have been working to achieve.

http://www.golfdigest.com/flash/hotlist/

January 4, 2007 News
6 Comments
← Older Articles
Newer Articles →