Annotating Android

2013-03-24 12:48

Coding for Android typically means writing Java, for all the good and bad it entails. The language itself is known of its verbosity, but the Android itself does not really encourage conciseness either.

To illustrate, look at this trivial activity that simply displays its application name and version, complete with a button that allows to close the app:

  1. public class VersionActivity extends Activity {
  2.     private TextView txtAppName;
  3.     private TextView txtAppVersion;
  4.     private Button btnExit;
  5.  
  6.     @Override
  7.     public void onCreate(Bundle savedInstanceState) {
  8.         super.onCreate(savedInstanceState);
  9.         setContentView(R.layout.version);
  10.  
  11.         txtAppName = (TextView) findViewById(R.id.app_name_text);
  12.         txtAppVersion = (TextView) findViewById(R.id.app_version_text);
  13.         btnExit = (Button) findViewById(R.id.exit_button);
  14.  
  15.         btnExit.setOnClickListener(exitButtonListener);
  16.  
  17.         PackageManager pm = getPackageManager();
  18.         try {
  19.             PackageInfo pi = pm.getPackageInfo(getPackageName(), 0);
  20.             txtAppName.setText(pi.applicationInfo.name);
  21.             txtAppVersion.setText(pi.versionName + " (" + pi.versionCode + ")");
  22.         } catch (NameNotFoundException wontHappen) {}
  23.     }
  24.  
  25.     private OnClickListener exitButtonListener = new OnClickListener() {
  26.         @Override
  27.         public void onClick(View view) {
  28.             finish();
  29.         }
  30.     };
  31. }

Phew, that’s a lot of work! While the IDE will help you substantially in crafting this code, it won’t help that much when it comes to reading it. You can easily see how a lot of stuff here is repeated over and over, most notably fields holding View objects. Should you need to change something about them or add a new one, you have to go through all these places.

Not to mention that it simply looks cluttered.

Android Annotations project logoWhat to do about it, though?… As it turns out there is a way to structure your Android code in a more succinct and readable way. Like a few other approaches to modern Java, it employs a palette of annotations. There is namely a project called Android Annotations that offers few dozens of them and aims to speed up Android development, making the code easier and more maintainable.

And it’s pretty damn good at that, I must say. Rewriting the previous snippet to use those annotations results in a class which looks roughly like this:

  1. @EActivity(R.layout.version)
  2. public class VersionActivity extends Activity {
  3.     @ViewById(R.id.app_name_text) TextView txtAppName;
  4.     @ViewById(R.id.app_version_text) TextView txtAppVersion;
  5.  
  6.     @AfterViews
  7.     void showApplicationInfo() {
  8.         PackageManager pm = getPackageManager();
  9.         try {
  10.             PackageInfo pi = pm.getPackageInfo(getPackageName(), 0);
  11.             txtAppName.setText(pi.applicationInfo.name);
  12.             txtAppVersion.setText(pi.versionName + " (" + pi.versionCode + ")");
  13.         } catch (NameNotFoundException wontHappen) {}
  14.     }
  15.  
  16.     @Click(R.id.exit_button)
  17.     void exitButtonClick() {
  18.         finish();
  19.     }
  20. }

Not only we have eliminated all the boilerplate, leaving only the actual logic, but also made the code more declarative and explicit. Some of the irrelevant entities has been completely removed, too, like the btnExit field which was only used to bind an event listener. Overall, it’s much more elegant and understandable code.

How about a bigger example? There is one on the project’s official page which looks pretty impressive. I can also weigh in my own anecdotal evidence of going through the Android game I wrote long ago and molding its code (a few KLOC) to work with AA. The result has been rather impressive, partially thanks to very light dependency injection facilities that the project provides, allowing me to replace many occurrences of Game.get().getGfx().draw(...); silliness with just gfx.draw(...);.

So in closing, I can recommend AA to all Android devs out there. It will certainly make your lives easier!

Be Sociable, Share!
Be Sociable, Share!
Tags: , ,
Author: Xion, posted under Computer Science & IT »


6 comments for post “Annotating Android”.
  1. Piotr:
    March 24th, 2013 o 13:17

    What’s your opinion about RoboGuice? It does similar work to Android Annotations, but I see that Android Annotations probably has more features. I am only curious whether Android Annotations would work properly with other libraries I use in some projects.

  2. Xion:
    March 24th, 2013 o 15:06

    AA will work with RoboGuice through AA’s @RoboGuice annotation . Both frameworks are a bit tangential to each other but RoboGuice might be just a natural step up from AA, especially if you end up using @EBean and @Bean annotations extensively.

    I haven’t used RoboGuice specifically, but I use the original Guice and I quite like the idea. As long as you can afford not to care that much about your objects lifetime (or are willing to spend some time defining custom scopes), it’s a nice framework at least for two things: (1) decoupling for the purpose of writing tests and (2) separating dev/staging/production configuration. (If you don’t care about either, the benefits of DI may not be apparent until the codebase grows large).

    It has some learning curve though, as well as few dos and don’ts that you need to follow (like not putting extensive logic into modules) in order to be effective. But all in all, it’s a good trade off.

  3. Maciej Czekański:
    March 24th, 2013 o 23:51

    I have been using AA for a few months, and I wouldn’t recommend it. The problem is, if you change anything in an @Enchanced class, you have to rebuild the whole project (at least in IntelliJ). Otherwise very strange crashes occurs at runtime. Sometimes I think I spend more time rebuilding project, than I would have spent writing that boilerplate code.

    For the next project I’ll go for RoboGuice. Or Scala ;)

  4. Xion:
    March 26th, 2013 o 1:14

    For a project so large that build time becomes so severe an issue, a proper DI framework like Guice is probably necessary. That doesn’t preclude using AA in smaller ones, I suppose.

    Plus, I haven’t heard about this strange crashes in Eclipse so it might be an IDE or Android plugin/toolchain issue.

  5. Piotr:
    March 26th, 2013 o 19:20

    I’ve read more about Android Annotations and I see one specific thing I don’t like.

    Quote from project wiki:
    “[…]
    You should always register your activity with an _ suffix in the Android Manifest.

    This is because AndroidAnnotations generates a subclass for each annotated activity. It has the same package and name, plus an _ suffix.
    […]”

    This requirement creates some mess in the application.

  6. Xion:
    March 27th, 2013 o 18:36

    The only change this mandates is in AndroidManifest.xml. I don’t see a big deal here.

Comments are disabled.
 


© 2023 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.