I’m just in the process of finishing the development of an Android application at work. This reminds me that since I’ve been a dedicated Flash developer for more than a decade, switching to a different platform was an interesting challenge, and one worth sharing.

Luckily, I saved a lot of notes in the process, and I thought I’d share my impressions here, so other developers – of any platform, but Flash/ActionScript especially – could read them and know what to expect when doing development for the Android platform. My posts will focus on specific topics and while they won’t cover the whole range of features or capabilities of the Android platform (there are many other places and better articles for that), they’ll cover what surprised me the most.

My first note is: Java has no getters and setters to work as mutators and accessors in the same way that ActionScript (or C#, or others) support them.

Consider the following code:

protected var _position:int;

public function get position():int {
    return _position:int;
}

public function set position(__position:int):void {
    _position = __position;
}

What this code does is create a position pseudo-variable. When you read its value, it simply returns the value of the protected variable _position, which wouldn’t normally be accessible to other objects. Likewise, when you set that property to a value, it simply sets the value of position. This means those methods could then be used as if they were a normal variable, like so:

someObject.position = 0;
trace (someObject.position); // 0

Using a getter/setter combination like that is, of course, fairly useless, since it’s just passing values along, without providing any additional benefit. The real advantage is when you need to have additional code bound to either method. Consider, for instance, that a getter method doesn’t need to be bound to the value of an existing variable, but instead generate its own return value as needed:

public function get numBrokenItems():int {
    // Calculate the number of broken items on a list
    var brokenItems:int = 0;
    for (int i = 0; i < items.length; i++) {
        if (items[i].isBroken) brokenItems++;
    }

    return brokenItems;
}

// Traces the number of "broken items" in this instance
trace(someObject.numBrokenItems);

In the same way, a setter can be used to run additional code after a variable is changed:

public function set x(__x:int):void {
    // Simple implementation of a redrawing method for illustration purposes only
    // This is not very efficient; for a real implementation of position getter/setters
    // it'd be better to have display invalidation and a deferred redraw()

    // Sets the new value
    _x = __x;

    // Redraws the item
    redraw();

    // Dispatches an event
    dispatchEvent(new MyObjectEvents(MyObjectEvents.MOVED));
}

// Changes myObject's 'x' variable, redraws it, and dispatches an event that it has moved
myObject.x = 10;

It should be obvious by now that I’m particularly fond of using getters and setters – I believe they give developers a lot of control, especially for fluid, animated interfaces; getters and setters are a requirement if you need easy tweening with any generic tweening library out there, for example.

Alas, it is not so in the Java world, where Android developers finds themselves in.

In Java, you can still have accessors and mutators (even though some people hate them), but they are normal functions and methods. It’d look like this:

protected int _position;

public int getPosition() {
    return _position;
}

public void setPosition(int __position) {
    _position = __position;
}

This means you access them as you would normally access functions:

someObject.setPosition(0);
Log.v("", someObject.getPosition()); // 0

It works well; I’m yet to see a real disadvantage (you can’t do the typical ActionScript-style tween syntax on Java anyway, so the main advantage of having a pseudo-variable like in ActionScript is moot). But the result is a situation where you’ll always dealing with a bunch of different functions for every class, and, in my opinion, a polluted interface where every variable access is duplicated and actual variables are pretty much never used. There’s probably an argument to be made here in favor of simplicity and encapsulation (whether the value is generated or comes from a hidden variable), but not sure whether that’s enough; right now I’m keeping an open mind and accepting the language for what it is (my love for getter/setters notwithstanding) since it’s a new platform and assumptions can be risky.