Android stuff you probably want to know about

About once a month I interview potential employees at Base CRM. The nice thing about this is that I usually learn a thing or two. The not-so-nice thing about it is that sometimes you have to tell someone that there is much they have to learn.

At this point most of the candidates ask "OK, so what else should I know?". I used to give some ad-hoc answer for this question, but it's not the best idea, because I tend to forget to mention about some stuff; and even if I don't miss anything, the candidate probably won't remember half of what I said because of the stress accompanying the job interview.

Anyways, I decided to write down the list of Android learning materials, blogs, libraries, etc. I recommend reading about.

Android basics

Some people's Android knowledge can be summed up as "Activities + AsyncTasks". That's not enough to write anything more complex than Yet Another Twitter Feed app, so if you seriously think of being the Android developer, go to http://developer.android.com/guide/components/index.html and fill the gaps in your education.

At the very least you should also know about Fragments and Loaders. If you want to persist the data, I recommend using the ContentProvider. It looks like a hassle to implement at first, but it solves all the issues with communication between Services and UI. While we're at the Services: you should know the difference between the bound Service and started Service, and you should know that most likely all you need is the IntentService. You should also know about BroadcastReceivers, and what is the ordered broadcast and sticky broadcast. Pay attention on what thread the different components operate.

Libraries

Support library
Guava
ActionBarSherlock
JodaTime
Commons IO
Dagger
Otto
Gson
HoloEverywhere

Blogs

Mark Murphy
Cyril Mottier
Romain Guy
Roman Nurik

Github

Jake Wharton
Square

Design / UI

Android Views
Android UI Patterns blog

Android UI / UX

Android Asset Studio
Android cheatsheet for graphic designers

Miscellaneous

Google I/O app sources
Grepcode
AndroidXRef

I probably forgot about something very important, so please leave the comment if you thing anything is missing.

Weekend hack: MicroOrm library

Last week I had to write some fromCursor() and getContentValues() boilerplate. Again. I finally got fed up and decided to write a library to replace all the hand rolled crap.

You may ask, why not use some existing ORM solution? There are plenty, five minutes with Google yielded these results:

• http://www.mobeelizer.com/
• http://ormlite.com/
• http://greendao-orm.com/
• https://github.com/ahmetalpbalkan/orman
• http://hadi.sourceforge.net/
• https://www.activeandroid.com/
• https://github.com/roscopeco/ormdroid
• http://droidparts.org/
• http://robotoworks.com/mechanoid-plugin/

The problem is, all those solutions are all-or-nothing, full blown ORMs, and all I need is the sane way to convert the Cursor to POJO and POJO to ContentValues.

And thus, the MicroOrm project was born. The public API was inspired by google-gson project and is dead simple:

public class MicroOrm {
  public <T> T fromCursor(Cursor c, Class<T> klass);
  public <T> T fromCursor(Cursor c, T object);
  public <T> ContentValues toContentValues(T object);
  public <T> Collection<T> collectionFromCursor(Cursor c, Class<T> klass);
}

I'd like to keep this library as simple as possible, so this is more or less the final API. I intend to add the MircroOrm.Builder which would allow registering adapters for custom types, but I haven't decided yet to what extent the conversion process should be customisable.

The elephant in the room is obviously the performance. Current implementation is reflection-based, which incurs the significant overhead. I did some quick benchmarking and it seems that the MicroOrm is about 250% slower than the typical boilerplate code. Sounds appaling, but it's not that bad if you consider that a) the elapsed time of a single fromCursor call is still measured in 100s of microseconds and b) if you really need to process a lot of data you can fall back to manual Cursor iteration. I'm also considering changing the implementation to use code generation instead of reflection, similarly to Jake Wharton's butterknife, which should solve the performance problems.

In the following weeks I'll try to adapt the Base CRM code I'm working on to use the MicroOrm, and I expect this project to evolve as I face the real-life issues and requirements. All feedback, comments, ideas and pull requests are more than welcome. You can also show the support by starring the project on Github.

Upgrading to Android SDK Tools revision 22

The Google I/O 2013 has come and gone and one of the many things left in its wake is the new revision of Android SDK Tools and ADT plugin for Eclipse. If you haven't let Eclipse go in favor of new hot Android Studio (which is what Mark Murphy, a.k.a. commons guy, recommends BTW) and you upgraded to the latest Android SDK Tools, you'll probably have some issues with building your old projects.

After installing all the updates from Android SDK Manager and updating the ADT Eclipse plugin your projects will simply fail to build, with the errors pointing to the R class in gen folder. If you try to build the project with ant you'll get more meaningful "no build tools installed" message. After re-running the Android SDK Manager, you should see an additional item in Tools section called Build-tools. Go ahead and install it.

Now your project will build (you might have to restart the Eclipse), but if you use any external libraries from your projects libs directory, your app will crash on the first call using this libs. To fix this you have to go to the project Properties, Java Build Path, Order and Export tab and check the "Android Private Libraries" item. The previous name for this item was "Android Dependencies" and apparently the build rules for those two are not updated correctly.

Of course new projects created with revision 22 of Android tools doesn't require jumping through all those hoops.