The 'Farata' way or the highway

A recent response to my post on Flex Shortcomings by some guys from Farata Systems attracted my interest. The basic sentiment is let's bash the guy who said something bad about Flex. In this post I'm going to briefly make some remarks about the aforementioned reply. Lets not waste any time...

Generics is one of the most confusing Java elements. The lack of generics in AS is a plus. - Yakov

Perhaps I got lucky because I really didn't find generics all that confusing... but then again I actually made an effort to learn how to use them.

No dependency injection. This is just wrong. Flex is an event driven environment that allow lose coupling design of components. - Yakov

If that's how you like to manage your dependencies then good for you. I can't even see how the two are comparable so I'll stick with DI.

The code for model view controller you are basing your generics case upon is really bad way to do client side software. Not using generics actually allows for more generic code and better reuse of controls and libraries. That allows smaller libraries to be streamed to the client. It is common to take large Flex application ( >20,000 lines of code) built by Java shops, then re-build them using dynamic coding techniques and more generic code - ending up with less then 25% of the original size. - Anatole

If you like coding using dynamic typing that's great. To say that static typing is 'really bad' when the majority of Flex itself is written using static typing is ridiculous.

Multithreading is great thing - when it works - and that still require some skills in almost every environment. If you are up to multithreading, it is not hard to provide solution that instantiate and synchronize multiple Flash VMs. - Anatole

Do I look like a masochist? The bottom line is that for high response applications the lack of native threading in Flex can be a MASSIVE downside, you can butter it up all you like but the fact is we don't live in a single processor world anymore.

Every language and framework has it's strong and week points. I would not use Flex for a few things - but there is no comparable portable environment for building RIA at this point. - Anatole

Agreed, that was what I was trying to get across in my original article. Although Flex is top dog now, I won't assume that technologies like Silverlight aren't capable of stealing the show.

To end this post I must say that despite my discussion of the negative sides of Flex, it is a language that I love developing with. Unlike a lot of people out there I won't pretend it's perfect or assume everyone only intends to write a simple single threaded RIA client using it.

Like anything there is room for improvement in Flex but unless we have a development community that has the capacity to be self critical and identify those areas we may get left behind.

Optional Typing

My recent introduction to Flex programming language has given me my first encounter with dynamic typing. Flex is built on top of the ActionScript language and supports both static and dynamic typing. For a brief introduction to dynamic typing and type systems, please see this wiki page.

I have been vaguely aware of the difference between static and dynamic typing for a while but didn't see what the fuss was all about. Without any first hand experience I assumed it was just matter of personal preference.

So here I am, in an interesting situation. I can happily continue coding away my Flex classes using static types in ignorant bliss. Or, I can take the time learn how dynamic typing might be another tool I can pull out of my hat when the situation demands. I naturally chose the latter.

The path to enlightenment

My first port of call was to query Thomas Lee, a local programming language guru.

"If you are working in a language that has static and dynamic typing, how do you decide when to use one over the other?"

He gave me this advice:

"Be pragmatic, use what works"
"If you're fighting the type system, you're probably doing it wrong."

After thinking on this I came to the conclusion that some tasks must be inherently dynamic and better suited to dynamic typing. The juicy question for me is, which tasks are they? I can think of one...

Dynamic Proxies

The best example of this is the ObjectProxy class in Flex. You can dynamically add property change support to any object by wrapping it in an Object proxy.

var cust:Customer = new Customer(); 
cust.name = "Thomas Lee" 

var proxy:ObjectProxy = new ObjectProxy(cust); 
proxy.addEventListener(propertyChangeLogger); 
proxy.name = "Shanon"; 

A proxy like this would be well suited to transparently providing security, logging, lazy loading etc.

More examples?

I wasted a good hour trying to find other pragmatic advantages of dynamic typing. I read plenty of articles that were really just complaints about specific languages. An interesting paper from Microsoft (don't freak out it, it does happen) alluded to dynamic languages being well suited to data centric programming, but failed to provide any examples.

I am interested to hear what others think about optional typing and when dynamic typing is appropriate.

Flex Shortcomings

In my last post I looked at a few of the features of Flex that I found particularly refreshing after having spent a lot of time writing Java code. For all those people out there considering using flex for an upcoming project, are you aware of its shortcomings? In not then I'd suggest you continue reading.

IDE Choices

The only professional quality Flex IDE currently available is Flex Builder from Adobe. Flex Builder is an eclipse plugin that has a short learning curve and a very nice GUI editor. If you plan to do any serious development you will need to get out your wallet and purchase a copy. Overall its a very sufficient tool to develop Flex applications but it's still a way behind Eclipse JDT and IntelliJ IDEA in terms of refactoring, code analysis and code generation.

No generics

I think generics were a great addition to Java 1.5, they made working with collections a whole lot easier and safer. I started to use them in my everyday coding and then after a while I started creating my own generic classes. It wasn't long before I couldn't imagine why any modern language wouldn't have them.

interface EditModel<E> {
  public E getEditedObject();
}

EditModel<Customer> customerEditModel = ...

With generics I can create a nicely defined interface for editing any object, yet be sure that my customer edit model is editing customers and not 'Objects'.

Unfortunately Flex does not have generics. R.I.P.

No concurrency

Flex has no language support for concurrency so background processing is basically out of the equation. There are asynchronous events being used in some of the data access libraries I have used but seems like a bit of black magic to me.

No dependency injection

There are no commercial ready dependency injection frameworks available for Flex that I am aware of. If you have spent any time developing Java applications using a framework such as Spring or Google Guice, its going to be something you will sorely miss.
This means people out there are using a lot more singletons and testing a lot less than they should.

Minor things

• No abstract classes


• No method overloading


• No constants in interfaces

Im summary I would like to say that in my opinion Flex is a great language for developing UIs and related logic. If you are developing a rich client application (desktop or web) then Flex may be right up your alley. If not then you may well be better of using another language, or at least writing non UI code in another language.

From Java to Flex

I have recently made the switch from a pure Java environment to a Java/Adobe Flex hybrid. The front end is written in Flex, while the back end remains in J2EE. I decided to share a couple of things I have really enjoyed about working with Flex to create rich client applications.

Built in 'JavaBeans'

Remember the days of spending countless hours writing JavaBeans with observable properties? Well you can do that in Flex with one simple [Bindable] meta data tag (annotation):

[Bindable]
public class Customer {
    public var name:String;
    public var age:int;
    public var shoeSize:int;
}

This customer will now fire property change events when any of its properties change.

Implicit Getter and Setter

Ok so observable public variables are all well and good but what do you do when you need to write a custom setter? Check out these Java style get and set functions (methods).

public class Customer {
    ....
    private var _name:String;

    public function get name():String {
        return _name:
    }

    public function set name(newName:String): void {
        if(newName == null) {
            throw new Error("no null values please.");
        }
        _name = newName;
    }
    ....
}

The great thing is you can still treat the property just like you did before...

var c:Customer = new Customer();
c.name = "fred"; 

Built in Data Binding

Flex uses human friendly XML documents to create user interfaces, the following snippet creates a text field and binds the customer name to the text.

<domain:Customer id="model" />
<mx:TextInput id="nameText" text="{model.name}" />

Look out for the curly braces that do the binding, you might have missed them!

You've gotta be quick!

In my last post I discussed the concept of object properties in Java. Well the guys over at https://bean-properties.dev.java.net/ have taken that concept one step further. While I was only beginning to think about the idea, they were already hard at work turning the idea into a reality.

I think their project looks very promising, my only concern is that they may be biting off more than they can chew. Bean Binding, Spring Integration, Swing X Integration, Validation and an ORM solution to name a few. In any case good luck to them, I will be watching closely.

JavaBean properties, I Object!

The JavaBeans specification was published way back in 1997. Its authors wanted a way to create “reusable software component(s) that can be manipulated visually in a builder tool.”

The JavaBeans specification needed “a way for tools to identify properties, events, and exported methods”. A convention for defining property names was the method chosen to achieve this.

For Properties:

public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);

For observing property events:

public void add<EventListenerType>(<EventListenerType> a)
public void remove<EventListenerType>(<EventListenerType> a)

By creating these conventions the specification defined a standard interface that could be used to dynamically obtain information about properties. What I find interesting is the fact that the specification defines an interface for properties but does not do so using a java interface. A property is not an object in its own right, its just a bunch of fields and methods grouped together using a convention. A java interface for properties might have looked something like this.

public interface Property {
        public <PropertyType> get();
        public void set(<PropertyType> a);
        public void add<ListenerType>(<ListenerType> a);
        public void remove<ListenerType>(<ListenerType> a);
}

So what are the differences between the two approaches? Well a java typed interface allows us to represent a property as a java object and leverage the full power of object-orientation. The best way to explain this is through example.

A JavaBeans Example

public static final String PROP_NAME = "name";
private String name;
public String getName() {
        return name;
}
public void setName(String name) {
        String oldVal = this.name;
        this.name = name;
        pcs.firePropertyChange(PROP_NAME, oldVal, name);
}

An object property example

// It’s final so we can maintain encapsulation.
public final StringProperty name = new StringProperty ();

Refactor a object property

public final StringProperty firstName = new StringProperty ();

And add a second object property

public final StringProperty firstName = new StringProperty ();
public final IntegerProperty age = new IntegerProperty ();

As you can see an object property requires a lot less code to use. This is because using objects allows us to re-use standard implementations for common properties. Not only that but it allows us to create more modular code.

// Decorate any property with advanced synchronization support.
new ThreadSafeProperty(StringProperty());

This example is very trivial and certainly not an in depth look at the pros and cons of JavaBean properties and object properties. It is merely an example to identify that an object property is a plausible concept.