Pros and Cons of some Android frameworks

This post is a summary of first impressions of a few android related frameworks that we (the Android team at Jayway) tried out during a competences session recently.

Spring for Android

“Spring for Android is an extension of the Spring Framework that aims to simplify the development of native Android applications.”
Spring give you a easy to use toolbox for talking to a server over the internet. The setup of spring was quite easy, you only need to add one dependency and one maven repo to your gradle file. Once we got it running it was very easy to use as-well, all in all it took less than 15 minutes to setup and write the first working piece of code using it. There is support for URI- and Rest-templates, but there seams to be some problem with this. We could not get it to work unless we rewrote the urls our selfs. It seams that Spring for Android does not follow the uri template standard.
Read more:


“Volley is an HTTP library that makes networking for Android apps easier and most importantly, faster.”
Volley is similar to Spring in that it gives you a toolbox for talking to online servers. It does differ quite a bit in packaging, Volley does not have any official package/jar or similar, just a git repo. The recommendation from the maintainer of Volley is to download a copy and put in your project. This might be done using git submodules or git subtree. I have not tried either so I can not give any further advice on pros/cons. You can also build your own jar and use that (this is the approach I have used).
Once you are past the hassle of making a jar och cloning the Volley git repo you have to spend some time to familiarize yourself with volley. One thing you will have to do right away is to implement a cache class since this is missing. When the initial obstacles are overcome your good to go and working with Volley is a treat. One thing that Volley has that Spring doesn’t is a separate way of handling images and ImageViews. The NetworkImageView can download and populate itself with images and is quite handy if you are ok with overloading the native ImageView. Over all Volley is good for making loads of smaler requests but might struggle a bit if you try requests with very large response data.
Read more:


“A powerful image downloading and caching library for Android”
Picaso handles images, both downloading, caching and scaling/cropping and placeholders/error/missing image handling. To get started is as easy as it can get, copy one dependency to your gradle file and you are set to start using Picaso. With a one-liner you can download scale and put a image into a imageview, you can even add a placeholder while downloading the real image. In my book it does not get any better than this. But if you are already using a networking lib that can handle images for you the overhead of having another lib added to you apk should be considered.
Read more:


“Dagger constructs instances of your application classes and satisfies their dependencies. ”
Dagger is a dependency injection framework, unfortunately most of us did not manage to setup dagger or failed to get dagger running once setup. So I can not give a proper overview of dagger2.
Read more:


“AndroidAnnotations is an Open Source framework that speeds up Android development. It takes care of the plumbing, and lets you concentrate on what’s really important. By simplifying your code, it facilitates its maintenance.”
AndroidAnnotation removes boilerplate code and provides similar networking capabilities as spring and Volley. Setup was easy and usage is reasonably easy to. A massive (in my mind) drawback is the generation for sub-classes of EVERY class you annotate. This quickly becomes a bit messy and is not the nicest way to go about things, but the way chosen by the AndroidAnnotation devs.
Read more:


“Annotate fields with @InjectView and a view ID for Butter Knife to find and automatically cast the corresponding view in your layout.”
Butterkife is a view injection lib for android. As such it only handles injection of view components and does this using a InjectView annotation. So some boilerplate is removed and less code has to be written. Some of us found the result a bit harder to read and in some cases the reduction of code was not noticeably, but this is most likely true for the other injection frameworks to and not something specific for Butterknife. Setup was easy with just one dependency. Stack-traces was reportedly difficult to read when Butterknife was used.
Read more:

RoboGuice 3

“RoboGuice 3 takes the guesswork out of development. Inject your View, Resource, System Service, or any other object, and let RoboGuice 3 take care of the details.”
RoboGuice 3 is similar to AndroidAnnotations and Butterknife, easy to setup, two dependency’s needs to be added to the build file. This framework seems like it should be easy to use if you are already familiar with Guice, and even if you don’t its not that hard to understand and use. It is similar to the other dependency injection frameworks that you don’t get all that much for your money, but it’s easy to use and removes some boilerplate. The documentation could use a touch-up.
Read more:

Android universal Image Loader

“Powerful and flexible library for loading, caching and displaying images on Android.”
Very similar to Picaso but looks like it has greater flexibility/more options to tweak the actual download/caching and behavior of the image loader object than Picaso.
Read more:


“Retrofit turns your REST API into a Java interface.”
The name is fitting, this is a framework for networking and more specifically for old style rest. So the support for url manipulation is there but might not be of much use for modern rest interfaces that tends to not use constructs like {id} in the urls anymore. Setup was easy and usage seems pretty straight forward, looks a bit dated and there are other frameworks that does the same and more.
Read more:

The views on the frameworks above is the result of a 3 hour session where we tried them out and had a short discussion about each of them to sum up the experiences. Given the limited time we spent on each of the frameworks we might have missed some important things, if you find and mistakes or are missing some important information please post a comment below.

This Post Has 3 Comments

  1. Vishnu

    What’s the status of Dagger now? Is the team still using it?

    1. Carl-Emil Kjellstrand

      Sorry for the exceptionally late reply, dagger 2 works very well and I would recommend using it.

  2. vishal Juneja

    what was the limitation in dagger1 overcome we are use dagger2 ?

Leave a Reply