AndroidAnnotations — semantics, stupid!

The pace of today’s mobile world is tremendous; new devices and technologies come and go, and developers are constantly under pressure to learn new things. Despite what most hard-core Unix users will tell you, real skills are not hundreds of commands memorized along with their syntax; your professionalism is measured by the ability to creatively solve problems. AndroidAnnotations is a step in the right direction.

How it started

Semantics (from Ancient Greek: σημαντικός sēmantikós; important) is the study of meaning.

In the beginning of time, there was this:

Machine code. Well, yeah, you’re right, nobody was really writing programs using machine code, but even I recall „coding” short snippets for 8-bit Atari using raw numbers, and I still remember some of them. This is probably where the term coder comes from. Secret knowledge. Magic numbers. Profession for the chosen ones.

Then, there was this:

From that point, it has never been so easy anymore. Hello World for Windows in C was roughly 100 lines of code. But semantically, it goes like this:

display window;
print "Hello world!"

Two lines. We all used to watch cheap SF movies from the 80’s where a blond chick tells the machine what she wants and the machine does that. It’s not dumb or childish. It’s smart. And today we finally get to see people telling their i-machines what they want them to do. It’s called Siri. It’s semantics and usability. 

But why software developers, who strive to make their users’ lives easier, still have to delve into the bloated code? It’s called boilerplate. And it’s all wrong again. Welcome to the XXI century.

Apage, boilerplate code!

Look at the following snippet:

public class SeeminglySimpleActivity extends Activity {
    
    TextView textField;

    Button button1;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        getWindow().setFlags(FLAG_FULLSCREEN, FLAG_FULLSCREEN);
        setContentView(R.layout.activityLayout);
        textField = (TextView) findViewById(R.id.textField);
        textField.setText("Hello world!");
        button1 = (Button) findViewById(R.id.button1);
        button1.setOnClickListener(new OnClickListener() {

            @Override
            public void onClick(View v) {
                doSomethingWicked();
            }
        });
    }
}

I’m not trying to be rude, but why all this crap, Mr Google? It would be educational to see how many thousands of hours developers around the world have wasted typing in all these anonymous listener classes, findByWhatever’s, casts and instance states. And yes, I mean wasted, and these are not cheap hours. There’s no business code above, just creating an app window, showing a welcome text and catching button clicks.

Now, take a look at this:

@NoTitle
@Fullscreen
@EActivity(R.layout.activityLayout)
public class ReallySimpleActivity extends Activity {
    
    @ViewById
    TextView textField;

    @ViewById
    Button button1;

    @AfterViews
    void init() {
        textField.setText("Hello world!");
    }
  
    @Click(R.id.button1)
    void button1Clicked() {
        doSomethingWicked();
    }

}

Neat, huh?

Statistics show that the time spent reading the code is ten times the time required to write it. If you’re familiar with Android programming, bring someone who’s not and let them read the latter piece of code. Not only will they find out quickly what it does, but they’re likely to say „Hey, it looks so clean, I wanna learn this!”. And it’s not really about the number of lines of code — it’s about readability, neatness and separation of concerns. A little step towards declarative programming. 

AndroidAnnotations is an open-source framework that speeds up Android development. It takes care of most of the boilerplate code and lets you focus on your creative tasks. It leverages the power of Java annotations and fills the void that should have been filled by Google engineers a long time ago (RoboGuice is not a good alibi, guys!).

In pure Java Android, if you want to refer to a resource, like a field on the screen, you need the following code:

EditText userName;
userName = (EditText) findViewById(R.id.userName);

So, first you create a view definition file with your userName field (not shown here for brevity), then you define a corresponding variable in the code, then find that element by its id, cast it to the appropriate type, and voila — you’re done. You just had to repeat the field name three times, repeat the field type twice, and separate the variable definition from initialization if you wanted to use it in more than one method. First they tell us „do not repeat yourself”, and then we’re forced to do just that: repeat. Here’s the equivalent written using AndroidAnnotations:

@ViewById
EditText userName;

It’s design by contract: by default the framework assumes that the name of your variable matches the name of the resource. Smart. In 95% of cases it does. And if you really want or have to give it a different name, just point the annotation to the correct resource, passing its identifier in brackets.

But AndroidAnnotations can do much more than that! Things like reacting to device orientation changes have always been a nightmare of Android programmers, especially when there are things going on in the background. With AA, you just use @Background, @NonConfigurationInstance, and @UiThread if you want to publish task progress and result. Want to use REST? Create an interface and invoke its methods when needed:

@Rest("http://www.bookmarks.com")
public interface BookmarkClient {
  
  @Get("/bookmarks/{userId}?search={search}")
  Bookmarks getBookmarks(String search, String userId);
 
}

@RestService
BookmarkClient restClient;
 
@Background
void searchAsync(String searchString, String userId) {
    Bookmarks bookmarks = restClient.getBookmarks(searchString, userId);
    updateBookmarks(bookmarks);
}

What about speed?

When we get to hear about things that speed up development, there’s this one question hovering around: but what about run-time performance? Here comes another advantage of AA — it works at compile time using Java annotations preprocessing, so there’s basically no performance impact at run-time. This comes at a price and some RoboGuice fans will raise their hands and say „our framework is more potent as it provides real decoupling and dependency injection”. But as the AA creator states, AndroidAnnotations is not meant to replace RoboGuice, but rather to be used complementarily, and you can have them both in the same project. Just be aware that the reflection engine employed by RoboGuice to inject stuff is not a strong point of Android, so be moderate.

The recipe for success

The pace of today’s mobile world is tremendous; new devices and technologies come and go, and developers are constantly under pressure to learn new things. Despite what most hard-core Unix users will tell you, real skills are not hundreds of commands memorized along with their syntax; your professionalism is measured by the ability to creatively solve problems. Steep learning curve is an obstacle and we should make implementation details as easy to grasp as possible. AndroidAnnotations is a step in the right direction. If you want to become an Android developer, I suggest you choose AndroidAnnotations and focus on those great projects that keep bubbling in your mind.

Tags: Java