Android Saga: Pull to Refresh
06/25/2012 § Leave a comment
Pull to refresh is an extremely popular UI gesture (that Loren Brichter pioneered in Tweetie) used in a lot of iOS apps. Basically it makes refreshing part of the scroll gesture itself.
The iOS community have had library support for this for a long time – I think that Three20, back in 2010, was the first library to offer this feature out of the box.
This very feature has come to the Android world later on and today many apps use it.
Since I don’t have much experience with Android, the first thing I did was to search for an open source implementation. I found plenty of them in a couple seconds.
(I also found a lot of Android developers thanking the Android open source eco-system for making libraries available as if that wasn’t true for other platforms. iOS as many other mobile platforms counts with a strong open source community too ^^)
The best implementation I found out there was a contribution from Johan Nilsson. Besides the sluggish scrolling and lack of animations, it works pretty well (correct me if I am wrong, but we can’t blame Johan for half the issues here since Android makes it really difficult to have smooth scrolling and bounce animations on ListViews).
I didn’t have any problems to import his library and use his implementation. Specially because he provides a very straightforward demo. The only thing that was really upsetting me though, was that pull to refresh header is supposed to be hidden all the time when the user isn’t scrolling or refreshing the list. And the header was standing there presenting a “Tap to Refresh” message.
That was when I decided to look the code and fix it. To be honest, the idea behind Johan’s implementation is very similar to the iOS approach. But not quite.
Let me tell you why.
On iOS, Pull To Refresh is implemented by the following steps:
1) Create the header view which displays the arrow, the spinner and the text messages
2) Add it to the UIScrollView with a negavite y value
3) Implement the UIScrollView’s delegate to set the contentInset as the header height (therefore making it visible) and ask the controller to refresh the content
4) Once the controller is done, it sets the contentInset to zero (therefore hiding the header view)
On Android, all the implementations I found follow the steps below:
1) Create the header view which displays the arrow, the spinner and the text messages
2) Extend the ListView and implement onAttachedToWindow, setAdapter, onTouchEvent to select the first row (WTF!?)
3) Implement the onScrollListener (equivalent to the UIScrollView’s delegate)
4) Once the controller is done, select the first row so the list scrolls to the top and hides the header if the content is higher then the list view
Although the approaches are very similar, Android’s version is essentially a hack that exploits the optional header in standard ListViews. When the list is displayed, it scrolls to the first item on the list, effectively hiding the header. When the list is short enough to be displayed entirely on screen, no scrolling is necessary, hence the “Tap to Refresh” button is always visible!
After an hour, I didn’t find a way to fix the issue of keeping the header hidden since hiding it would not make it disappear. That is when I came to a StackOverflow post that basically told me to put the header in a LinearLayout that wraps it’s content, and hide the content so the wrapping LinearLayout collapses when its content is hidden, resulting in the header view being 0dip high and therefore invisible.
I find the solution very bizarre, but it worked out and that is what I am using right now. The only thing that still upsets me, is that the feature is not polished enough. It is still sluggish to pull, flicks once in a while, and lacks animation.
I will get back to this post once I figure out a better solution, if any. I am counting on you – Android devs – to help me out 😉
EDIT:
Found a library that provides a very good user experience. Full story here.
Android Saga: Applying an image as the background pattern of a ListView
06/23/2012 § 2 Comments
This is the first (I hope) of many episodes of an epic saga where an iOS developer (me) adventures himself in the (so far painful) Android developers world.
Before we get started, let’s get synced. Long before mankind (back in 2007), when Android was on a very early stage, I got all fired up and started one (if not THE) first Android community in Brazil. It turns out I ended up working with iOS on the next year (which won my heart) and since then I have not write a single line of Android code. So, today I am nothing but an iOS developer struggling to build an Android application that actually feels as good as an iOS app.
We all know iOS has such appealing features that Android still lacks, like smooth scrolling apps, list views that are able to nicely bounce, a simulator that is a piece of cake and system upgrades ;P
But I am not going to write bad stuff about Android trying to make iOS shine. I am actually following an advice of a friend of mine (idevzilla). After hearing me mumbling for a couple days, he got tired and told me to go share the experience of coming out from the iOS platform and diving into the Android SDK.
Personally I hope Android experts will come to me and show me better ways of writing Android code so that I can get the user experience I want for my Android app.
Since every awesome app is made of tiny little details, let’s get started with one: apply an image as the background pattern of a ListView (equivalent to UITableView).
Let’s start with Android.
After an hour researching on how to do this, I found out that Android requires the creation of a XML file that describes a bitmap which the source is the image I want to use as the pattern and the tile mode is repeat. This file must be placed under a drawable folder.
res/drawable/app_background.xml
<?xml version="1.0" encoding="utf-8"?> <bitmap xmlns:android="http://schemas.android.com/apk/res/android" android:src="@drawable/background_pattern" android:tileMode="repeat" />
Then we need to create a set of styles for the ListView that use this bitmap and tell the app it should use those styles.
Running the app I saw that nice background. Then I scrolled down the list and it became black. I lifted my finger and then the background was there again (WTF!?).
It happens by default an Android View has a transparent background and transparency involves a lot of calculation when rendering your application on screen. In order to avoid blending and make the rendering faster while scrolling, the ListView widget uses a cache mechanism. This mechanism consists on “turning opaque the view hierarchy”. So I researched a little more until I found out that I needed to set the cache color hint to “transparent”. This solves the issue but also disables the optimization we just discussed.
res/values/styles.xml
<?xml version="1.0" encoding="utf-8"?> <resources> <style name="app_theme" parent="android:Theme"> <item name="android:windowBackground">@drawable/app_background</item> <item name="android:listViewStyle">@style/TransparentListView</item> <item name="android:expandableListViewStyle">@style/TransparentExpandableListView</item> </style> <style name="TransparentListView" parent="@android:style/Widget.ListView"> <item name="android:cacheColorHint">@android:color/transparent</item> </style> <style name="TransparentExpandableListView" parent="@android:style/Widget.ExpandableListView"> <item name="android:cacheColorHint">@android:color/transparent</item> </style> </resources>
AndroidManifest.xml
<application android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/app_theme">
Okay. This works out. BUT…I want the background to scroll together with the ListView so the user feels he is actually moving the list down or up.
Unfortunately the only way I found to achieve this goal is to forget about that styles.xml file and undo the changes to the AndroidManifest.xml file. Instead, we need to create a layout file for the list item (equivalent to UITableViewCell) and add the following to the root Layout element:
android:cacheColorHint="@android:color/transparent" android:background="@drawable/app_background"
This however will not disable any highlights caused by the list selectors…but this post already got too long.
Let’s ignore this issue for a moment and see how iOS handles this.
self.tableView.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background-pattern.png"]];
That is all for today.