My little Android warehouse

Random thoughts about my experience as moonlight android developer.

Generating Preloaded Sqlite Data

Preloading data in Sqlite is a common problem during android development.
The most common solutions are:
  • hardcode the insert statements and execute them (possibly inside a transaction) the first time the db is opened
  • place the data inside a csv file, load it the first time the db gets opened, parse the rows and populate the db
  • prepare a pre-built sqlite file, ship it along with your app and load it the first time the db is opened

    I’ll focus on the third approach, because it allows us to check our db outside the app without extracting it from our device, and because it allows us to prepare the data in a more “human friendly way”.

    It’s worth to mention the excellent sqlite asset helper library by Jeff Gifelt, that allows us to embed a prebuilt (compressed) sqlite file without having to reinvent the wheel. For this reason, this post will be about how to handle data entry process (and something more), and you won’t find a (yet another) way to preload a sqlite file.

    Let’s start with a problem: you want to build a pretty simple Seasonal Fruit and Vegetables app, and the amount of data you have to deal with is big enough to discourage you to prepare the inserts manually.
    You’ll have:
    • the list of products
    • the description of each product (possibly localized in different languages)
    • the data related to the seasonality of each product
    So, here’s the approach:

    Step 1: data entry

    Use a spreadsheet to fill the data in a human friendly way, export it as csv (or tsv, so you won’t have to deal with any random comma inside the descriptions), parse it and produce the sqlite file together with localized string res files to be embedded inside the application.
    In my case I had a file  having the genre (fruit or veg), the calories count, the name and the description in italian and in english:

     asparagus     0     25     Asparagi     Descrizione asparagi in italiano.      Asparagus     English asparagus description  
    chard 0 12 Bietola Descrizione bietola in italiano. Chard English chard description

    I also have files that describe the seasonality of each products in different areas, but I will not describe them since they are not relevant to the approach I am describing here.

    Step 2: Parse!

    Choose your favorite scripting language. I went for python since it’s super slick and it comes with batteries included, such as xml writing and sqllite support.

    Creating the db is straightforward:
     CREATE_ITEMS = 'create table Item (_id integer primary key, Name text, kind integer, calories integer);'  
    CREATE_ITEM_PER_MONTHS = 'create table ItemPerMonth (ItemId integer, Month integer, Freshness integer, Area integer);'
    CREATE_ITEM_PREFERRED = 'create table PreferredItem (PreferredItemId integer);'
    conn = sqlite3.connect('fruit')
    c = conn.cursor()

    Then we need to use the data we have to fullfill two purpouses:
    • fill the database
    • fill the localized string resources 
    Again, filling the database consists of parsing each line of the csv file and calling the appropriate insert.

    In python is as easy as calling


    on a cursor object, where statement is the insert statement.

    Together with that, we do have a lot of data that needs to be rendered in the proper language.
    In order to take advantage of the resource framework, I chose to generate the resource files instead of relying on a “locale” field in the db to filter in my queries.
    Again, filling an xml node is pretty straightforward in python:

       name = ET.SubElement(root, "string")  
    name.set("name", item_name)
    if lang_name.find('%') != -1:
    name.set("formatted", "false")
    name.text = lang_name

    At this point, we can generate an it_descriptions.xml file and an eng_descriptions.xml file (and even let our script place them in the proper folders).

    When we want to use our descriptions in Android (i.e. in  our cursor adapter’s bindView), we  need to bind the product name (i.e. “asparagus”) with the corresponding resource. That’s easy and it can be done in this way:

      int nameResID = context.getResources().getIdentifier(name,   
    "string", context.getPackageName());

    By doing that, we can retrieve the resource id of the string related to the name that was generated by our script. If we are worried about the cost of the lookup, we can even add a lru cache to absorb that cost.

    • Write your data in a human readable format
    • Parse that data with your favourite language
    • Write the data that does not depends on the language in sqllite
    • Write the language-dependent data in resource files
    • Use getIdentifier for retrieving the resource id of the strings automatically generated
    Bonus point: again, you can use this convention for pictures as well, so you can throw an “asparagus.png” image in your assets to be loaded afterwards.

    The biggest advantage of this approach is that you have only one master source of your data (the spreadsheet) that you can modify and rerun the generator over every time you modify it.

    If you are interested in the whole loader python script you can check it here

    Rest Interaction in Android

    In last December (‘13) I was asked to submit a talk proposal for the first Italian Droidcon, which I did. It got accepted, so in Febraury I gave my first public speech speaking of “(O)Authenticated Rest Interaction in Android” in front of real people.

    This post is meant to be a follow up with the information that can’t be found in the slides

    I hoped to sum all the talk up in a post, but it got too long so I am going to split it in several pieces. This one will cover the asynchronous interaction with a remote webservice. 

    Disclaimer: I am not inventing anything new here, most of the content can be found on the internet. A great source of inspiration is this talk, from where I took the inspiration for the approach I am going to explain, probably in a worse way.

    Rule #1: decouple the interaction with the web service from UI components (activities / fragment)

    This means that cut and pasting that AsyncTask that contains an HttpUrlConnection code you found on google directly inside your activity is a bad idea (I don’t even want to remind you that you should NOT host the HttpUrlConnection directly inside your activity, if you are doing that you probably won’t understand the rest of this post and you should restart your android journey here).

    There are several reasons for that. 
    You should start thinking that any network operation has a cost, in terms of bandwith and cpu power. Every time you turn the radio on involves consuming (a lot of) battery power, performing the request and parsing the result involves cpu (and therefore) battery power, so any network operation is precious and you do not want to waste any performed request result.

    Said that, you should (must?) be aware that your activity might be killed at any time.. well, not at any time but as soon as it’s not foregrounded anymore, which is something that is likely to happen if your beloved user chooses to leave your application in favour of candy crush, or if he receives an incoming phone call.
    BUT, the result of a request started inside that activity might still be useful for a latter use, so you do not want your request to be killed together with the activity that hosted it.

    Moreover, you should be aware that every time a “configuration change” occurs, which is what commonly happens when the device gets rotated, the current activity gets killed and recreated. 
    Well, guess what? That ongoing request that costed you a lot of power / cpu is lost, and its result with that. Even worse, it’s not completely lost, but it might be notified to a leaked activity that nobody will look at anymore because the current one is the one which was recreated. There are ways to circumvent this, like hosting the components that you want to survive to a configuration change inside a headless fragment, but again, you should be very careful.

    Finally, given that you want to host the interaction with the service inside the activity, and because the activity is guaranteed to be active only as long as it is in foreground, it is obvious that in this way is impossible to schedule requests to be performed while the application is not being used.

    Malus point: if you have a god activity that handles the UI interaction, a component like a AsyncTask or a Thread that is in charge of performing the request, the real interaction with the service AND the interaction with the activity in order to update the UI, well, you are likely to have a poor encapsulation of your code and you might have some issues while testing your code.

    So where am I supposed to perform the calls?


    The answer is pretty simple. Use a Service, which is “is an application component that can perform long-running operations in the background and does not provide a user interface”, so it’s just right for our purpouse. The idea here is to host that rest call inside a service, so it can survive to any activity lifecycle event.
    There are a couple of ways to interact with a service, you can throw intents at it, or you can bind your activities to it. In the latter case, you’ll get back a reference to the whole service object, and so you are able to implement a rich api your activity can interact with.
    On the other hand, you should be careful and stop your service when you do not need it anymore (ie when all the requests are satisfied), and you should also remember that you (still) need to host your asynchronous interaction inside of some kind of threaded component. 


    Are my favourite flavour of services when speaking of rest interaction. Why is that?
    • IntentService(s) provide only a onHandleIntent method, which is performed inside a different thread. No need to spawn an asynctask
    • IntentService(s) get destroyed as soon as onHandleIntent returns. No need to understand (or risk to forget) when the service needs to be shut down.
    Have you ever heard of Command Pattern ? You can just embed your requests parameter inside the intent, parse them in onHandleIntent and let the intentservice execute the request for you. Isn’t that cool?

    Cool! Now I have the data I retrieved from the service, what should I do with that?

    Store it! The two most common alternatives are plain sqllite or using a content provider. The first benefit of using some kind of persistant storage is that you don’t want to perform the same costly request twice in order to retrieve the same data.
    Moreover, storing the data enforces the decoupling of your service with the activity, since the activity will fetch the data from the storage, regarless of when the storage was filled. This is also better in terms of user experience, because it’s better to find some kind of data instead of an empty listview if the device is offline.

    Bonus point! If you want to perform the inserts a bit faster, check if you can fetch only new data, if the apis you are consuming are offering any kind of timestamp parameter. Plus, remember to use transactions and bulkinserts in order to speed up your inserts.

    Anything missing?

    Ok, your activity asked to the service to perform the request, the request was performed, the result parsed and stored in your content provider. You should now notify the activity that the storage contains something new. 
    You have some options:
    Or if you are using a content provider, you could take advantage of CursorLoader / Observers , which I think are the less error prone way to feed a listview out of a content provider’s data.

    You just need to remember to add a couple of lines of code:

    Final result:

    The final picture of this kind of architecture is the following (please forgive my extremely bad design skills):

    Please note how the the activity asks the Service to perform the request with the webservice and then forgets about it. Any time the data needs to be displayed, it’s always fetched from the storage.
    The only other interaction happens when the service tells the activity it needs to reload the data.
    In this way, any ongoing request will survive even if the activity gets killed. When the user will return to your application, the newly created activity will load the latest fetched data from the storage.

    This was the first post related to the Rest Interaction in Android. I really hope I did not say too many wrong things…

    If you liked this post, consider following me on twitter @fedepaol.


    Nice article.
    I got a question about one of the common situations, when you get some data from server, that is already sorted on the server, and we don't have enough fields to sort it on the client. Should we persist this data? And what should we do on another request? Clear table?
    Federico Paolinelli
    Let's distinguish between notifying the activity and then having it update itself. ContentProviders plus loaders offer a full solution via observers, so you don't have to worry about anything.

    On the other hand, if you want to notify the activity in some other way, you can:
    - use a messagebus
    - use (local) broadcasts

    Once the activity knows that the underlying storage has new content, again, you have a lot of ways depending on how you stored the data.
    Again, you can use custom loaders (my favourite one is . Alternatively, you can use asynctask, native threads or any async way to interact with your storage.
    Federico Paolinelli
    Gave a quick look at your groundy lib, it looks like it's a slick way to perform async interaction inside a service. My only concern is about passing a callback object instead of registering / unregistering a listener. By doing that, you can only return the result to the calling activity. Worse than that, it looks like (if I understood correctly, sorry it's a bit late here) you are not using weak references, so you might leak the activity in case the reference is being held but the activity is not active anymore.
    Michal Kejzlar
    Thank you for your post, good points there. What would you recommend for observing changes in storage without having Content Provider and loaders? E.g. storing data via dao objects telling to activity via EventBus and then what? Having ugly AsyncTask for querying the database?
    Cristian C
    Hi Federico.

    Have you taken a look at ?

    It makes interaction between Service and Activity easier.

    Disclamer: I wrote the library.
    Federico Paolinelli
    @Andy Res:

    I don't think you can "natively" stop an intentservice once you launched it. However, what you can do is letting it discover that you are not interested in it anymore. This sounds like a reasonable solution. However, despite being a big fan of them, I admit that this is a big limit of IntentService. Another limitation is that you cannot prioritize requests. This is because you are implicitly relying on the Intent queue instead of explicitly using one (or a library that use a queue). In any case, I would also say that in most common use cases, once you start a request you are unlikely to want to delete it. Still, think about updating your twitter feed. If you launch an update, you want the request to be completed even if the user leaves the application.
    Hope my reply makes sense :-)
    Federico Paolinelli

    I assume you are talking about how to handle the endless data, not how to display it by using some kind of endless listview. In any case, I'd say that how you want to handle it depends on the data you want to display and on the kind of your application. If you really have an "endless" == almost infinite amount of content, what you can do is just provide a "window" on the data that is held on the server, the same way any twitter client does by showing only the latest tweets and by performing a new get whenever you approach the end of the list. If, on the other hand, you have a HUGE amount of content you always want to be synched on your device, this is a more complex topic to discuss. The "easiest" way would be letting the remote server be the master of your data, and perform a full delete before you download all the new data. From that, several optimizations can be implemented. One can be having a timestamp related to the whole resource, and not performing the sync if your device already has the latest version. More complex optimizations are harder to implement by using a restful interface, because you can't tell it "just send me the data changed since xxx or even the data deleted since xxx" in order to allow you to apply those differences (at least, not that I am aware of). Sorry for the delay in the reply, but I have been a bit busy in the latest couple of days.

    Andy Res
    Thank you for the very useful info.

    What could you tell in regards to requests cancelation while using IntentService?

    Hello, Federico. Could you explain how can we handle a case with endless list of content? As i understand we should download all content and find changes to persist. In general the main question is: How to maintain consistency beetween remote and local database? Thank you.

    Contributing to Firefox for Android

    In the past two / three years I have been (mostly) developing Android code, even before it was cool(tm), as a way to do something different from what I do during my day time job.

    I wrote some apps, a couple of libraries, and some 80% finished projects I really hope I will finish some day.

    Recently I thought that joining some big android related open source project could have been interesting, and I went for them.

    That’s when I found Firefox for Android (code name fennec). There are several reasons why I choose it. It’s one of the most complex / active open source projects, I spotted these slides on my g+ stream and I decided to give it a spin.

    (Some rights reserved, cc licenze by “Tambako the Jaguar”)

    I must admit that I was not using fennec as my primary browser on android.

    This is my first experience in a (quite) big open source software project, and now I spend on fennec all of the free time I devote to developing (and I really like it).

    What was *totally* a surprise,

      is the fact that fennec is very far from a “plain android” project. When I first started, I (wrongly) expected to find an android project where I could reuse the stuff I knew from before, and I ended up working on a lot of javascript (which I never used before). The project is various and I like the mixture of js, c++ and regular android, and I find this challenging, even if the code read / written ratio has become really huge. Hope this will get better with time.

    Working on it is harder than a regular android project.

      Forget intellij, eclipse or android studio. Forget debugging, or at least expect attaching a command line debugger to your code to be tricky. Slow build time (a full build takes something like 2 hour and half on my laptop).
    Incremental builds time and upload to the device may take up to 2-3 minutes. I got back to the really old times when I wrote most of my code using vim and figuring out what was happening through logs.

    You can get a lot of help from the mobile team,

      but you need to ask. A lot. Think of your average day. A lot of work to be done. Bugs coming, code to be written. Now think about some guy, who never wrote a line of code on the project you are working on, coming and asking some dumb or obvious questions. You are that guy.
    That’s what must be their point of view (hope I am making less dumb questions). But they are helpful, even on monday mornings. You just have to ping them on irc.

    Did I say it is hard at first?

      The bugs ahoy page makes it quite easy to find a bug to start with, and the build instructions are dumb proof. But then, it feels like being thrown in the middle of the jungle with a pocket knife. A huge codebase, xul interfaces, javascript, C++ code, Xpcom interfaces, no idea of which function is calling what.
    The documentation is there, but it’s hard to figure out where to start from.
    But if you are not worried about pinging and pinging people on irc, you will be given all the answers you need in order to get better and go ahead, and you will learn about all the tools at your disposal that help a distributed team to work better, such as mxr, pastebin and mopad, or how to submit a patch using hg queues.

    Is it worth it?

      Definetely. As I wrote before, I am currently spending all the spare time I devote to side projects writing code for Fennec. Or I should say, reading a lot of code and writing some code. The “aha” moment when you realize that you understand how things work after grepping and digging into interfaces and callbacks has no price and it’s something I haven’t experienced for a long time.
    Moreover, it’s exciting to interact with the mobile team, they all are passionate about what they are doing and very capable, not to mention that you will be forced to produce high quality code in order to pass the reviews.
      Finally, the fact that you are contributing something bigger than that pasta cooking timer app , and that your code will run in the hands of a lot of users is huge. I am not an opensource software integralist, despite having written a decent amount of it, but the freedom message shared by the mozilla foundation is something it feels nice to be part of.

    Not to mention the tshirt I received and the ”friend of mobile team” badge I was awarded :-)


    Federico Paolinelli
    Thanks mrlachatte. Did not realize that my first contribution was getting live until now!
    It's FF 23 release day, and I saw your name in the list on Congratulations on having your first contribution be released to our many users!

    PostMan (RingsTwice) Reloaded - Android Rest and Oauth Make Easy(er)

    Android and Rest

    My PostManLib android library had a quite troubled genesis. Some infos can be found in this old post , but bear in mind that I only kept the skeleton of what I wrote at that time (which, by the way, was inspired by this talk).

    The api was (to be kind) a bit clunky, and I recently chose to rewrite / finish it. Apart from its clunkyness, one thing was missing:

    OAuth Authentication

    OAuth authentication is quite common for android apps, since it is a widely supported authentication system. Looking for “inspiration” I came across which not only provides oauth out of the box, but already provides a good and well tested abstraction for http rest interactions. I then chose not to reinvent the wheel and to delegate oauth and http interaction entirely to scribe.

    Why asynchronous rest calls in android are important:

    In android, performing time consuming work in the ui thread may result in ANR errors, and obviously rest calls belong to this category. What postmanlib does is to decouple the requests and execute them inside intent services, providing a way to get notified of calls results.

    What postmanlib offers:

    • OAuth login using a webview hosted inside a fragment dialog. Every interaction is performed asynchronously. Just call registerOAuthService and the registration will happen
    • Asynchronous rest calls (oauth-ed or not) performed inside an intent service
    • Multiple api handling - token storage

    Given that the interaction is performed inside an intent service, all the well known problems related to asynctasks are avoided. 

    What postmanlib does not offer:

    • Storage: the data received in background can be stored in the user’s favorite storage. I strongly suggest to use a content provider, using my automatic content provider generator
    • Parsing: the plain text received must be interpreted. There is plenty of json / xml parsing library, just pick one

    Library Architecture

    A singleton object collects the requests to perform the rest calls in background. 
    The requests are parcelable objects that are passed inside an intent to the intent services. Using the command pattern along with the strategy pattern to implement the interaction resulted in a much cleaner api (more details about the structure can be found in the git repository).

    All the client application has to do is to perform oauth requests is to create and register a oauthservice builder. 
    I had to wrap the original scribe oauth service builder because I had to store all the tokens in order to restore them whenever the singleton is garbage collected.

    After performing the registration (which is done using a OAuthHelper class), a registered api can be used to sign any request sent. The only difference between oauth-ed and plain requests is that in the first case we specify a signer.


    I really like the way the library grew up (not just because I wrote it :-) ). Scribe performs an excellent job in abstracting oauth registration and http interaction, so I could focus on asynchronous interaction with it.
    The registration process is more than trivial, and rest requests are strongly decoupled from the activities.

    I think this library might be of some help to anybody who wants to interact with webservices and want to go beyond the too often badly used async tasks.
    A real world sample (with no oauth, sorry) can be found in my AndAppennino application


    Federico Paolinelli
    Grazie mille :-), cerco di darmi da fare come riesco, troppo buono a mettermi sullo stesso piano di Gabriele..
    Ho visto la pull request, appena ho un attimo ci faccio un giro e la mergio, adesso sono un po' preso dall'arrivo di una figlia :-)

    Grazie ancora per le (troppo) buone parole.
    Alessandro Bellesia
    Ciao Federico! Innanzitutto ti faccio i miei complimenti per l'ottimo progetto. Si tratta di una soluzione davvero molto completa e comoda perché già pronta out-of-the-box.

    Grazie a te ed a Gabriele Mariotti praticamente l'Android Weekly è tutta italiana! Sono davvero molto contento.

    Giocando un po con la libreria mi sono accorto che la funzione isServiceEnabled nel ServerInteractionHelper non funziona nel modo corretto. I numero di Services infatti risulta sempre 4 a prescindere dai servizi effettivamente impostati nel manifest dell'app.

    Mi sono permesso di fare una piccola pull request su GitHub con la mia proposta di correzione!

    Grazie mille ed ancora complimenti!


    DroidAlone - Reloaded

    Whenever I speak with another android developer, the occasional chat goes to “what did you develop?” question.
    Last time it happened at droidcon uk, and for the first time I felt something wasn’t completely right when I showed my DroidAlone app.

    DroidAlone is a useful app (so they say) that comes into play whenever you forget your phone at home. With a simple sms protected by a password choosen by the user, it can be activated. From that moment, it will start notifying you of any missed calls and sms. It also ships a lot of other nice features, such as phone location retrieval and auto reply via sms (if you want to inform the caller that he can reach you to another number).
    The full description of DroidAlone can be found at Missed Calls for Android .

    Everything seems to work well, it has a lot of good reviews and the few users are happy.
    Except one thing. It looks (looked) like this:

    It also had another view with the list of events. The other developer’s reaction was “ugh”. And then I realized that I can’t keep producing new stuff ignoring what I have around, especially if this is the case of the only app I manage to sell a bit.

    So, when I got home I decided to change the ui “just to make it more pleasant”.  Then I opened the code, and I realized that my two year’s old code needed a bit more than a refresh.

    Here what was wrong:

    • it used tabactivity, which is very old fashioned. I decided to add the actionbar.
    • from the event list view, you had to click on the item to see the details of the event. The details where shown into a dialog. Ugh (again). In the new version I wanted all the details to be visible since they are not so long.
    • All the properties of the views in the layouts where explicit. No styles anywhere. The color resources where “background_color”, or “title_color” instead of some name that remind you the color. I had to put a heavy hand on that.
    • I tried to use gridlayout a lot since it seem to be the more efficient way to dispose a layout.
    • There was no empty list information.
    • A lot of calls where deprecated. I switched to the most modern versions.
    • All the data was contained in a sqllite storage without using a content provider. I switched to using a content provider and a cursorloader, which ended up in a more compact code. I didn’t need anymore to use a broadcast to notify the ui that the data was changed.
    • DroidAlone uses broadcast receivers to be notified of incoming calls / sms. Even tough the sms receiver must be enabled because an activation sms can be received at anytime, the call receiver is needed only when the app is active. I then used the package manager to disable it when not needed.
    • I wanted to refactor a lot of code. A lot of brackets where on the new line instead of the same line of the method (a la C), and it bothered me a lot. I also trusted lint and changed a lot here and there. 

    Other than these things, I redraw (by my self) a lot of the assets using inkscape. Because I soon got bored to export the resources in 4 different resolutions folders, I wrote a simple python script to do that for me. You can find it here .

    More than that, I got REALLY REALLY bored while writing the content provider, so I ended up writing another python script to automatically generate the content provider for me, as described in my previous post. You can find the android content provider generator here

    Finally, I switched the project to maven because I am getting used to that solution, especially in case I want to add robolectric tests and keep working with intellij.

    The new version of the app hasn’t been released yet (I want to have it running for a while on my phone before releasing it, just to be sure that I didn’t break anything).

    This is how the new version will look like 

    So, this is how a “little ui polishing” ended lasting more than two weeks (of my spare time). I am also glad that I think my old code is not that good. I like to think that I am better than two years ago.

    Android Content Providers Generator

    During the refactoring of my two years old app DroidAlone, I decided to try to access to the storage through a ContentProvider.

    Even if the official documentation warns that there is no need to use content providers if your app does not want to export it’s data against other apps, there are a bunch of advantages in using a content provider in your app.

    The main and more obvious advantage is that you can use a Loader with your data. Using loaders relieve you from managing the cursor, forgetting open cursors here and there and most of all, makes a lot easier for your ui to react to changes in your model. Well, more than easier, you don’t have to do anything.

    However, I am not writing this post to describe how to interact with an android content provider, nor how to implement a content provider. There are a lot of content provider tutorials out there that probably can explain how them work better than I could possibly ever do (and in a better English).

    I am writing this post because while writing the content provider, I got bored.
    It’s a lot of code, always the same, that cannot be avoided, and you don’t have to add any value to it. The best thing you can do is not getting distracted and write it with no errors. And it’s loong (ok, not that long).

    Given the “boilerplateness” of this problem, I thought I could take off some dust from my old SqliteHelper builder script and maybe make it able to generate the content provider class for me. And that’s what I did.

    Android Content Provider Generator

    I added a couple of options to it, and now it can generate automatically for you (no more cut/paste, no more forgotten columns) the content provider class AND a client class with a bunch of methods you can use to add / update / delete / query your data.
    A sample of the generated code is already included in the beta of my app and it seems to work properly.

    I won’t write any instructions or examples here, they are already in the github repo.
    All you need to know is that with a 10 rows text file that describes your data, you can generate the whole content provider.

    As I wrote on G+, it’s certainly not the most elegant piece of python I wrote, but it makes it’s job.

    If you liked this post (or my script), consider following me on twitter @fedepaol

    DroidconUk 2012

    Here I am, back again from my third DroidconUk experience.

    I can still remember explaining to my non tech friends what Android was the evening of the 1st droidcon, and since then it became a sort of ritual, a couple of days when I can take some rest from my day time job and take part to the community of some of the best android developers coming from all over the Europe.

    It’s an (almost) cheap to flight from Pisa (IT) where I live to London, and I can always count on my architect friends from Marcel Mauer for accommodation.

    My overall impression is that droidcon is getting better and better. It’s growing as much as the Android  platform itself, and despite all the interesting talks the better part is still the people you can meet there BETWEEN the talks. Even if you are as shy and sociopath as I am.

    Most of the talks where very instructive and I heard about a lot of new stuff I can reuse on my side projects.

    Here I will put a short list of what are the things I liked most (as a kind reminder for me but also for any occasional reader that lands on this page by chance).

    The talks:

    I am not following a proper order if not the chronological one. I really enjoyed all the talks.

    The keynotes:

    It’s official. They are putting Android everywhere. Three keynotes for three Android related product which where not phones nor tablets.
    - Ouya, the famous kickstarter funded android gaming console
    - Vendscreen, an android based vending machine (!)
    - Parrot android based car stereos.

    Building songkick for Android (slides):

    Askay and Jamie from Novoda show their professional approach to build the songkick app. A lot of interesting tips and best practices from them. Really liked the “writing good code is always faster than writing bad code” approach.

    Overcoming device fragmentation:

    Jan and Jon from SoundCloud had a bad time dealing with sound infrastructure in Android, especially from a multi device perspective.
    It’s not an aspect of the platform I have never addressed that much, but I really enjoyed their story about going from the simple system call up to get the hands dirty with bringing on board ogg library through ndk. I also liked the fact that at first they tried to deal with java version, because it’s something I would do as well.

    The fly in app menu for designers and developers (slides):

    Cyril Mottier ( we may remember him for Greendroid) made a gorgeous presentation on this navigation pattern which is getting more and more popular (but don’t use it just because it’s à la mode).
    The presentation was a proper walkthrough on why and when one should use the new pattern (and when one shouldn’t). During the talk he gave a lot of tips on how the correct user experience should be. Very inspiring.
    If you want to bring this pattern in your app and you can’t affort to develop it “in house” as Cyril did, there are a couple of libraries that implement it for us:

    Beaming data to devices with nfc (slides):

    Mark Murphy from CommonsWare introduced what (and how) can be done with an nfc enabled phone through a royalty free spy story. Interesting and funny as always, the talk of Mark is worth the ticket by itself (well, his talk and the free beers I had).
    It’s a good starting point when I will look into nfc, which might be very soon.

    Fast, user friendly and power efficient network communication with android (slides): 

    Another series of super tips from Erik Hellman on how you should perform networking in a proper manner.
    Still, stuff I read here and there but still useful.
    He also mentioned library, which is something I should definitely check, since my current project involves plain socket operation and I implemented it my self (the android way).

    Introduction to Google Tv (slides):

    Google Tv looks to be the next big thing. I have never dig into the docs but it really looks like a new whole world. Apart from the different challenges that we can have developing a tv ui, I really like the idea of having it interact with our personal devices.

    The libraries:

    Polaris (link):

    Cyril Mottier (yes, still him) delighted us with Polaris, his map library to enhance the poor experience available from standard map apis.

    RoboSpice (link):

    The french guys from Octo (sorry I can’t remember the name of the speaker) presented their awesome RoboSpice library, a library to perform asynchronous jobs (and a lot more) on steroids. 
    I was really interested in this talk because of my previous attempt to build something (barely) similar with Postman Lib . Unfortunately I never had time to polish it and it’s still an unfinished product. Moreover, the guys from Octo made a better job under every aspect of object reusing and performance, dealing with issues I would have never fix even if I took the library to a decent state. I am quite curious to dig into their code just for the fun of it :-)


    Erik Hellman from Sony introduced how opencv library for computer vision can be (almost) easily integrated into an android app. Still, something I would always loved to play with, maybe I will if I get some extra spare time.

    NetMera (link):

    Well, this is not a real library, but it’s a brand new concept (at least, new to me) for a platform as an sdk.  It was introduced by Friedger Muffke during his talk “Serverless Android Applications”. They provide a full remote backend without having you bother at all for it. Sounds like the holy grail for developers with no time(tm) but I don’t like the idea of having my code bound to a specific service.

    Talks I missed:

    I was told that this talks were excellent:
    - The fragment transition by Corey Latislaw
    - Proguard by Eric Lafortune
    - Dynamic animations with custom views by Anders Ericsson


    I had a great time at droidcon, I really enjoyed it under every aspect (even though I suspect I still have to digest an hotdog of two from the dinner of Thursday). It really boosted my hunger for learning new things. As an immediate effect I decided to polish my old apps, those I developed three years ago which now look ugly and old (the code as well).

    See you next year, DroidConUk!

    (This picture was taken at Liverpool Street while waiting for the bus to Stanstead Airport). Way too early for a Saturday morning.

    Gridlayout Support Library With Maven

    EDIT 17/10/2012:
    Gridlayout support is now working natively with maven android deployer. I strongly suggest to use it instead of my method.


    Gridlayout has been introduced since api level 14, and is being suggested layout as a more efficient alternative over nested linear layouts and relative layout.

    It has also been recently added as part of the android support library, in order to have it available on older devices.

    Trying to use it in a maven setup is a bit tricky.
    At the time of writing, the version added by maven android deployer won’t work because of this issue .
    The problem is, you can’t just add the jar because the library is intended to be an android project library, which means that brings with itself a couple of resources.

    The error you might get is

    java.lang.NoClassDefFoundError: android/support/v7/gridlayout/R$dimen

    I don’t know if the following is the best “mavenic” way to solve the problem, however it worked for me and I am sharing it here.

    What you need to do is to build your own apk lib to add to your maven repo to link against.

    Step 1: building an apk lib

    The information you can find on android maven plugin website wasn’t very clear to me. However they ship a couple of examples you can take inspiration from.

    Assuming that you have a proper ANDROID_HOME variable set up, and you already used maven android deployer to have a working setup, the first thing you have to do is to download the support library. 
    You will find it under $ANDROID_HOME/extras/android/support/v7/gridlayout

    Make your own copy somewhere else in your hard disk.

    Now copy my pom.xml file:

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="" xmlns:xsi=""

    <name>Gridlayout compatibility library</name>





    You will have another thing to do. Since you cannot include jar files directly but you have to specify them as depedencies, you can:
    • refer to the jar provided by maven android deployer
    • have a dependency pointing a local repo, as described here

    I chose the second approach.

    As you can see in the lower part of the pom file, I add a local repository.
    You need to put the jar file in that repository. As suggested by the stackoverflow answer, you can let maven build it for you with

    mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=libs/android-support-v7-gridlayout.jar -DgroupId=com.grid -DartifactId=gridlayout -Dversion=1.0

    Step 2: Including the apklib to your project

    Now you have your apklib ready to use. You can add it as a dependency in the pom.xml of your app


    This costed me a couple of sleepless nights figuring out why it was not working…


    As markus pointed out in his comment, I forgot the last trivial step which is to run
    mvn install 


    Please read the README file included in the gridlayout support library BEFORE trying to use it. It will save you a bit of extra headache.

    If you liked this post, you might be interested in following me on twitter @fedepaol


    Last Step is mvn install.

    Intellij, Robolectric and Android

    I have been curious about intellij since droicon uk 2011, where I noticed that some of the speakers were using IntelliJ instead of eclipse.

    A post from Richard Hyndman, who is a developer advocate from Google, was the final straw that pushed me to download IntelliJ and give it a try.

    The first thing an eclipse user will notice in intellij is how slick and fast compares to the behemoth which is eclipse. On the other hand, an you can feel a bit disoriented at first.

    Setting up a new android project using IntelliJ is pretty straightforward. You can follow the nice tutorial from jetbrains website
    For this reason, I will not write about how to set up an Android project in intellij here.

    What I am going to write about is how to setup an android project with intellij and integrate robolectric with it.

    I really like robolectric. It makes unit testing for android a lot faster as it would be on the emulator. What’s more, you can use mockito with it.
    Mockito is a mocking framework that makes a lot easier to mock your java objects.
    Mockito does not work with dalvik jvm, but robolectric makes your tests run on your pc’s jvm.

    Despite robolectric provides instruction on how to setup an intellij project manually, I have tried that process a lot of times, carefully checking if I was missing a step.
    However, I did not manage to get it working. The guys from Pivotal provide also an intellij starter project, which you can configure to point a git repository

    However, I was not either satisfied with this solution and, inspired by this post , I tried to setup a maven solution and to import it in intellij afterwards.

    This provides another great benefit, which is the fact that I can import the same project in my linux netbook without bothering for relative paths in eclipse projects.

    So, here are the steps I had to follow in order to get it working:

    - Install the android sdk. This is trivial, I assume you are comfortable with that
    - Let the ANDROID_HOME environment variable point the path where you uncompressed the android sdk
    - You need to have at least one version of the sdk installed, so if you haven’t yet, you should launch the sdk manager that is the “android” executable on ANDROID_HOME/tools/android. Install also the extras, such as the compatibility library, admob stuff and all the libraries you find at the bottom

    - install the maven android sdk deployer you can find at and then install it.

    I read somewhere that you can get android jar without relying on it, but in any case, if you need google maps or other private apis like that you still need to use this tool.
     I use the latest (almost) version which is 4.0.3, so I run mvn install -P 4.0.3

    - Install maven android plugin. The easiest way is to use android archetypes from here:

    Finally, you are now ready to generate your first maven android project:

    mvn archetype:generate \
      -DarchetypeArtifactId=android-quickstart \ \
      -DarchetypeVersion=1.0.8 \ \

    You could find an issue.  Recently the tree of the android sdk folders has been slightly changed. Maven android plugin expects them to be in the updated version (I don’t remember what the differences where). However, if maven complains it cannot find android related stuff, and your sdk has been installed for some time, a good option would be to remove the sdk and reinstall it from scratch (at least the part you download with the sdk manager).

    At this point, you have a working maven project, which you could already open with intellij. What is still missing is the robolectric dependencies.
    Nothing more easy, all you have to do is to add

    right below android dependencies. You should also create the test folder, under src/test/your/package/

    Now, a problem I had was that I had to change the pointer of the repository in order to have robolectric 1.2 working.

    At this point, you should be able to open the pom.xml with intellij.

    Now, to have robolectric working from intellij, you still need to make a couple of changes:
    - the order of include of jars does not respect the one you specified. What’s more, you will likely to get the STUB! error because android jar is included before junit and robolectric.
    All you need to do is to move the android jar below junit and robolectric

    - you need to manually specify the javadocs for android. You do this by highlighting android jar, pressing the little edit in the lower left corner.

    and pressing the plus sign. Then you choose “Attach files or directories”, point the path related to your android docs,
    which is /docs/references under your ANDROID_HOME. Finally, you declare that it’s related to javadoc.

    Now you are _almost_ ready to start. You made all this mess because you want to have robolectric working with intellij.

    You need to create, right under src/ folder, the following path:
    src/test/java/ YOUR_PACKAGE 

    where you are going to include your unit tests, and you are done!

    If you liked this post, please consider following me @fedepaol .


    Federico Paolinelli
    I added here a working pom.xml I am currently using. I just tried to mvn clean install from a clean checkout and it looks to be finding robolectric. I hope you are missing something which you can correct using this example. Ping me if you can't
    Christopher Perry
    I added the sonatype repository stuff, and it's not finding robolectric. Not sure why.
    Christopher Perry
    This comment has been removed by the author.

    Tcp Connections in Android

    Or how to keep your app connected and stop worrying. 

    This is not another place where you can find java code snippet to open a socket and read and write to some server.
    If you need that, go back to your favorite search engine and look for another result. But be careful: while looking for “inspiration” I found a lot of examples where the connection was held inside the UI thread. Please, don’t do that. At least use an asynctask.

    Short version of this post (spolier warning):

    • If you need to interact with a tcp server, use a singleton object that contains the socket 
    • You can access it from all the activities of your app
    • If you want to be connected only while in foreground, have a counter that gets incremented on onStart() and gets decremented on onStop() of any client activity. Connect when the counter is > 0, disconnect when the counter is < 0

    As a side project, I am developing a simple turn based multiplayer game, with a tcp server as backend (python twisted).

    In order to make my life easier, I wanted the interaction with the server to work as follows:

    • if the player gets disconnected while playing, it can’t reconnect and he is out of the current game
    • if the app goes background for any reason, it will disconnect from the server

    The way the app interacts with the server is not the subject of the current post (hint: a thread for sending, one for receiving AND google protobuf for serialization), but it will probably be the subject for some code on github and another blogpost.

    What I am writing about is how to share a tcp connection between several android activities.

    Using a service to share the socket between android activities:

    • if you think about something that needs to survive between activities transition, a service is the first thing you think about
    • the code to interact with the server was self contained, so in every activity I had to bind to the service, wait for the bind to be done, call the service that called my code
    • because of the constraint I imposed to make the tcp server easier, I had to stop the service and restart it whenever my app went background
    • I was risking to keep the service around, consuming resources with no reason
    So, use a service ONLY if you really need to keep the connection even if your app is no longer visible.
    If you need to do periodical tasks, or if you need to perform one shot operations, please consider using intent services. 
    Be kind and let your users know that you are draining their battery, using a notification icon when the service is alive and your app gets backgrounded.

    Using a singleton to share the tcp socket:
    • A singleton object resides in your process, and so once started it’s accessible from all the activities
    • You can even run one or more threads inside of it, and they will be running no matter which activity is visible
    • Not using a service, you authorize the os to suspend your application (or even to kill it) when it runs out of resources.
    • There is no need to have the service layer to bind from the activity, you can access directly your singleton object
    So, this is the BEST WAY to share a tcp connection between activities.

    But what if you want to connect only when the application is foregrounded?

    How to check when your application is active:
    Have a global counter (a good place might be the singleton itself) that gets incremented every time an onStart() is called from one of your activities, and decremented when onStop() gets called. 

    If that counter is > 0, that means the (at least) one activity is active and then the socket must be connected.
    On the other hand, if the counter gets to 0, no activity is visible and so you need to disconnect.

    If you are afraid that the counter might go to 0 only because an activity is starting another one and so its onStop() gets called before onStart of the next one, please note that the official android documentation assures us that when starting one activity from another,  onStop gets called AFTER onStart() of the started activity

    With that in mind, we are sure that the only time the counter will get to 0 is when the ALL the activities are stopped.

    If you liked this post, please consider following me on twitter @fedepaol .