My little software store

Random thoughts about my experience as moonlight software developer.

It's Been a While

.. since my last blogpost.

I’ve done a few things in the meanwhile, I wrote a game with LibGdx, I tinkered with various frameworks, but on top of all these things I’ve been taking care of my one (and a half) year old daughter.

I do certainly have less time to devote to side projects, but I still like to learn new things and Android is exciting from that point of view.

While trying to catch up with all the new things that keep happening in the Android World, I hope I’ll be able to post more often here.

PS: I used this post to reacquatain myself with octopress

Dragging With ViewDragHelper

While working on my last side gig, a patch to Firefox for Android to allow the urlbar to be dragged in order to show content hidden behind the main view, I had to deal with ViewDragHelper and understand how it works.

The final result (please note that the patch is still under review) is something like this:

It caused me more than one headache, and for this reason I am writing this post hoping it might be helpful to anybody wanting to tinker with it.

ViewDragHelper’s usage is not well documented, but this post by Flavien Laurent is the best place you could start from.

In order to provide a simpler example for this post, I’ll introduce a simplified version of what I have done on Firefox, without all the extra code needed to interact with the rest of the app.

Let’s start with..

How touch events are handled

A good source of information is the official documentation. However, I’ll write a short introduction here.

Whenever a touch event happens, the parent view is being asked if it wants to handle that event in place of its children. This is done by calling its onInterceptTouchEvent() method, which should return true if the parent view wants to handle the event.

In case the event is trapped by the parent, its onTouchEvent() method gets called and it must return true if the event is handled.

Children view can also rebel against their parent tiranny, and disable this mechanism by calling requestDisallowInterceptTouchEvent(). By doing that, they ensure that the touch event wont be passed to the parent view.


How ViewDragHelper works

The idea behind it is pretty simple. You register a draghelper on a container view

mDragHelper = ViewDragHelper.create(this, 1.0f, new DragHelperCallback());

and then you set a couple of entry points, one to listen if a drag is being started (or is in progress), the other to handle the motion events and perform the dragging when the event is being passed to the view it registered against:

public boolean onInterceptTouchEvent(MotionEvent event) {
    if (mDragHelper.shouldInterceptTouchEvent(event)) {
            return true;
    return super.onInterceptTouchEvent(event);

public boolean onTouchEvent(MotionEvent event) {
    return true;

ViewDragHelper will be asked to check if a motion event is part of a dragging process. The behaviour of the whole dragging process is ruled by a DragHelperCallback instance passed on creation. DragHelperCallback has method that need to be implemented to be notified of particular evens, such as:

  • a change in the dragging state
  • a change in the dragged view location
  • when and where the dragged view was released

It also has methods used to influence the dragging behaviour:

  • clamp the position of the view / the range it can be dragged within
  • check whether a particular subview can be dragged

A whole drag process is intended a sequence of Down / Move / Up events over a particular target view. Whenever a drag process starts, ViewDragHelper finds the topmost child that contains the location of the motion event, and asks us if that particular view can be dragged or not in tryToCaptureView() method.
This is more or less the theory involved in the dragging process. On top of that, ViewDragHelper offers also settleAt methods to let the views settle to their rest location gracefully.

Since explaining in words it’s not the easiest thing (nor I am particularly good to explain), I’ll introduce the simplified app I used to understand (a bit) how ViewDragHelper works.

Enters DragQueen

images Licensed under commons creative

(Just kidding). DragQueen is a (ultra) simplified version of what I implemented on fennec with a button named queen that you can drag.

It consists of:

  • OuterLayout (the root element of our activity, the one that contains the views we want to drag)
  • a front panel which can be dragged


To make the things a bit more complex we want to enable the dragging only from a particular subview, Queen. To make the things even more complex, we want to be also able to interact with Queen button while the dragging is not happening.

We also allow only two rest locations, so if the view is released mid-way it will settle to its open / close location depending on the speed and the location of when the view is released. Finally, note that OuterLayout contains also a button that is hidden when main layout is in its closed state.


Outerlayout is a ViewGroup that extends a RelativeLayout.
As I wrote before, the two methods ViewDragHelper needs to hook into are

public boolean onInterceptTouchEvent(MotionEvent event) {
    if (isQueenTarget(event) && mDragHelper.shouldInterceptTouchEvent(event)) {
            return true;
    } else {
        return false;

public boolean onTouchEvent(MotionEvent event) {
    if (isQueenTarget(event) || isMoving()) {
        return true;
    } else {
        return super.onTouchEvent(event);

You may notice that onInterceptTouchEvent if has another condition. This is because we want to drag mainlayout only if the touch targets the Queen (it would not be drag-queen otherwise). This is a simplified version of what happens in Fennec, where we want to intercept the drag only if it starts from the toolbar to avoid to interfere with the web content.

In any case, checking if Queen is targeted is quite easy:

private boolean isQueenTarget(MotionEvent event) {
    int[] queenLocation = new int[2];
    int upperLimit = queenLocation[1] + mQueenButton.getMeasuredHeight();
    int lowerLimit = queenLocation[1];
    int y = (int) event.getRawY();
    return (y > lowerLimit && y < upperLimit);

Other methods that influence the behaviour of the dragging are:


    public boolean tryCaptureView(View view, int i) {
        return (view.getId() ==;

which gives draghelper the permission to drag main layout). You must return true up there for the view you want to be dragged.

getViewVerticalDragRange && clampViewPositionVertical (there are Horizontal flavours too)

    public int getViewVerticalDragRange(View child) {
        return mVerticalRange;

    public int clampViewPositionVertical(View child, int top, int dy) {
        final int topBound = getPaddingTop();
        final int bottomBound = mVerticalRange;
        return Math.min(Math.max(top, topBound), bottomBound);

which do what you expect them to do, setting limit for the dragging. In this particular case, vertical range is set to half the size of screen.


Note also how mMainLayout is set as clickable with android:clickable="true". This prevents touch events to be passed down to the view below when it is closed..


There are several callbacks you will want to implement in order to react to the events related to the dragging:


    public void onViewDragStateChanged(int state) {
        if (state == mDraggingState) { // no change
        if ((mDraggingState == ViewDragHelper.STATE_DRAGGING || mDraggingState == ViewDragHelper.STATE_SETTLING) &&
             state == ViewDragHelper.STATE_IDLE) {
            // the view stopped from moving.

            if (mDraggingBorder == 0) {
            } else if (mDraggingBorder == mVerticalRange) {
                mIsOpen = true;
        if (state == ViewDragHelper.STATE_DRAGGING) {
        mDraggingState = state;

notifies the state transitions of DragHelper between DRAGGING, IDLE or SETTLING state.


public void onViewPositionChanged(View changedView, int left, int top, int dx, int dy) {

whose purpouse is pretty clear.


    public void onViewReleased(View releasedChild, float xvel, float yvel) {
        final float rangeToCheck = mVerticalRange;
        if (mDraggingBorder == 0) {
            mIsOpen = false;
        if (mDraggingBorder == rangeToCheck) {
            mIsOpen = true;
        boolean settleToOpen = false;
        if (yvel > AUTO_OPEN_SPEED_LIMIT) { // speed has priority over position
            settleToOpen = true;
        } else if (yvel < -AUTO_OPEN_SPEED_LIMIT) {
            settleToOpen = false;
        } else if (mDraggingBorder > rangeToCheck / 2) {
            settleToOpen = true;
        } else if (mDraggingBorder < rangeToCheck / 2) {
            settleToOpen = false;

        final int settleDestY = settleToOpen ? mVerticalRange : 0;

        if(mDragHelper.settleCapturedViewAt(0, settleDestY)) {

is where you (might) want to let the view go into its rest place. I made it behave in such way that dragging speed (and direction) is more important than the place you are releasing the view.

Bonus methods

mDragHelper.settleCapturedViewAt(0, settleDestY))

is a helper method that will make your view smoothly settle at the given destination.

Quirks and reasons for headaches

ViewDragHelper sets the offset of the target view ..

.. by calling offsetTopAndBottom, which is ok but you have to remember that a layout round called by any of the children of outerLayout (or the parent view you are passing to the draghelper) will reset that offset. What you are going to see in that case is your dragged view getting back at its rest position.

A possibile solution to this is to force back the parent where it was before:

mMainLayout.addOnLayoutChangeListener(new View.OnLayoutChangeListener() {
        public void onLayoutChange(View v, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom) {
            if (mOuterLayout.isMoving()) {

ViewDragHelper always want to intercept the top most child in z order

If you have some view in between, but you want to be able to drag a lower one, you have to let ViewDragHelper think that your view is the topmost one.

    public int getOrderedChildIndex(int index) {
        int mainLayoutIndex = indexOfChild(mMainLayout);
        if (index > mainLayoutIndex) {
            return mainLayoutIndex;
        } else {
            return index;

What’s more

ViewDragHelper offers a lot more features than those I just presented. DragQueen implements only vertical dragging, but you can drag your views horizontally too. Again, refer to the excellent post by Flavien for more details.

Moreover, ViewDragHelper allows you to intercept drag events that start from the edge of the screen, which is the way its used in the NavigationDrawer.

All it needs to enable it is to call


and to implement

public void onEdgeDragStarted(int edgeFlags, int pointerId) {
  mDragHelper.captureChildView(mMainLayout, pointerId);


ViewDragHelper is a bit complex and as I said before not well documented. However it allows you to drag views around with very little code, and it can be used to implement nice effects. In any case you can unrestrainedly copy take inspiration from DragQueen source code on GitHub (it seems to work). I really hope this post does not contain too many errors and that you enjoyed reading it as much as I did writing.

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

Migrating From Blogger to Octopress (Done!)

It feels a bit like this Light bulb

but when I had to write a new blogpost and had to embed some code snippets into my blogger hosted blog, I got so pissed of that I chose to migrate my existing blog to a github hosted instance of octopress.

Jason Jarrett made a pretty nice tutorial about the whole process here. However, I had to change a couple of things and I thought those might be helpful to anybody who faces the same problems.

The overall process is something like:

  • setup octopress
  • import an exported dump of blogger
  • fix internal links
  • setup redirects from blogger to your new blog

Setting octopress up

Nothing to say here. Just go to octopress website and follow the instructions.

Importing posts from blogger

This is pretty straightforward too. Export your blogger content as xml, and use this ruby script that generates a posts folder containing all the posts exported from blogger. Anyway, refer to Jason’s blog, everything is described accurately there.

Fix internal links

You’ll have to play a bit with sed in order to fix internal links, otherwise they will keep pointing to blogspot.

Setup redirects

Here is where things get interesting, because you will want to make visitors of the old url be redirected to the new blog (possibily with 301). The whole process is a bit tricky due to blogger limitation (for more details check here).

There are a couple of other obstacles too: the script available is powershell only. Moreover, Jason suggets to use the alias plugin which seems to be broken at the moment.

However, jekyll-redirect seems to work fine, so I chose to use it in my solution.

And finally, since powershell is not an option, here is my python version of the script. It binds the post id with the title of the posts, loop all the html files in your post folder, injects the redirection in the yaml header.

Using it is as easy as calling:

python -p octopress/source/_posts/ -b ./blog-08-22-2014.xml

where p is the path of your posts folder, b is the xml file produced by blogspot.

Here is the script:


  • Read Jason’s blog
  • When setting up redirection, install jekyll-redirect
  • Use my script to inject redirection in the header of exported blogposts
  • Setup blogger template as described in Jason’s blog

PS: I still need to write the blogpost that made me switch to octopress.

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.