Functional Reactive Programming has been adopted in many programming communities, and for good reason. Trying to manage multiple asynchronous calls usually results in a mess of code that is not only tricky to debug, but difficult to maintain and build upon — not to mention the many “gotchas” surrounding the use of AsyncTasks on various different versions of the Android SDK. This kind of code usually ends up being the bane of an Android developer’s existence.

Enter the Android module for RxJava.

By using a souped up version of the Observer pattern, we gain the ability to create incredibly powerful chains of logic that can be specifically run against various threads (UI, background, etc) and that can be further modified by users of these observables to tune them exactly for the UI they are trying to populate.

When we enabled Social Sign In for our mobile users in the HootSuite Android app, we wanted to keep the flow simple and light with as few screens and dialogs as possible. This meant that we needed to defer collecting the user’s email address in certain cases until after sign-up.

As such, we wanted to surface an inline notification asking users to enter their email. The design was pretty straightforward: put a dialog inline with the main tab view content where the user can insert the information or dismiss the dialog.

I had done this a few times before, and the cleanest way to implement this in my opinion is to create the inline element as a view and add it as a header to the ListView object. What I never really had to do before was dismiss it away with a collapsing animation. When implementing that animation, I ran into an issue with ListView that I did not expect to find.

While playing around with a pretty simple list view item layout, I had just perfected my margins and positioning for all the components and it was time to update the background with a custom nine patch image. For implementation specific reasons, I had to do this in code and after pushing the APK to the device I noticed that all my padding was gone.

What gives?

Well, since the nine patches define their own padding, Android correctly stomped out my XML padding and used the nine patchs' own settings. In this case, I didn't want to create a custom nine patch just for this one view so I simply stored the padding values before setting the drawable and reapplied them afterwards.

private void setBackgroundResourceAndKeepPadding(View view, int resourceId) {
    int left = view.getPaddingLeft();
    int right = view.getPaddingRight();
    int top = view.getPaddingTop();
    int bottom = view.getPaddingBottom();

    view.setBackgroundResource(resourceId);
    view.setPadding(left, top, right, bottom);
}

Another developer blog is born...

First off, I'm not Romain Guy or Jake Wharton, so don't expect brilliant insight into Android's view rendering or magical libraries developed overnight that reduce boilerplate code by 90%.

That said, everyone can learn from each other and I seem to stumble upon things that might help others now and then.

Let's see how this goes...