06/30/2012 § 1 Comment
I am still covering the basis, but I can tell that Adapters are cool stuff.
An Adapter object acts as a bridge between a view and the underlying data for it. For example, the ListAdapter is specialized in handling data for a ListView (it corresponds to the implementation of UITableViewDelegate on iOS).
What is so cool about Adapters?
They allow high level of code reuse and easy customization.
How did I get to this conclusion? Well, let me tell you my story.
I started with a ListView backed by a custom ArrayAdapter that I called PlacesListAdapter. All that it did was receive a list of items as argument, inflate and populate a specific view for each item in the list.
To reduce the time for initial view loading and be as parsimonious with memory usage as possible, I considered to lazily load data as the user scrolls.
Why? Because it is a gorgeous solution. He came up with an adapter – he called it EndlessAdapter – that wraps a ListAdapter and provides the means for loading more items once the user gets to the end of the list. Basically it sums 1 to the number of items in the wrapped list adapter and returns a pending view for this last item. Once this pending view is inflated, the Endless Adapter calls cacheInBackground() in a worker thread for you to load data in background. Once its done, appendCachedData() is called in the main thread and you are able to add that data to your wrapped adapter and notifyDataSetChanged() so that more data is shown on the list. The stop criteria is the amount of items you fetched.
Once this was made past, I changed just a little bit my custom list adapter to fetch data from a ContentProvider. Basically I inherited from CursorAdapter instead of ListAdapter and provided a Cursor object as argument.
It happens a Cursor object represents the results of a query, so in order to load the next set of items, I needed to do a new query and retrieve a new cursor – so everytime cacheInBackground() is called, the query limit is increased by limit, grabbing more data each time. Besides that a CursorAdapter requires the current cursor to be swapped to the new one so that it can reflect the data set change in the list.
But this is not optimal. I looked the documentation and found the MergeCursor, a convience class that lets you present an array of Cursors as a single linear Cursor. Although this approach was very interesting it did’t quite meet my requirements because I needed to fetch the next set of items from the local cache – so the users sees right away the data he wants – and then from a web service – so I get to update the data I have in the cache. Therefore I would have to query the ContentProvider for all the items again.
So I thought of doing as Mark did and create a MergeAdapter class that would present an array of adapters as a single linear adapter. This way I could read only new data of page limit size from the local cache (by increasing the offset instead of the limit), provide the cursor to a brand new PlacesListAdapter and append it to the MergeAdapter. Once the data for that page is fetched from the web service, I could just grab the list adapter for that page and swap the cursors. Beauty!
Fortunately I found a convience class for this as well, and guess who wrote it? Mark Murphy.
In the end the architecture is very simple: an EndlessAdapter wraps a MergeAdapter that wraps a list of PlaceListAdapters.
To get this working on iOS is not that easy. Mostly because of its architecture. In first instance, UITableViewDelegate methods are implemented by the controller, so the developer needs to create the concept of ListAdapter and implement its lifecycle in the controller. Then inherit from this custom controller every time a table view is required. Once this is done, the Android approach can be taken.
But this is not the most important part. The highlight here is that Android helps the developer to write better code than iOS does in this case.
06/27/2012 § 3 Comments
Previously on Android Saga..
“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.”
It happens I was wrong. Yesterday I tested the app on the device – precisely a Samsung Galaxy i5500 running API Level 8 – and I was surprised when it didn’t work since all this time I was testing on an emulator running the very same API Level. I know the emulator is different from the device. This is true for the iOS simulator as well. But not THAT different.
Anyways, Johan’s implementation doesn’t work either on Samsung Galaxy i5500 running API Level 8 nor Samsung Galaxy S2 running 4.0.3 (Yes I tried a newer version to see if I was pushing to hard by using an old API version).
I got to a point where I started to think that maybe pull to refresh wasn’t the answer for Android. Actually my girlfriend asked me if I was not trying to put an iOS app into Android. And she had a good point: Android doesn’t support bouncing in the list view, so Android users are not used to pull the list hence they don’t easily discover how to pull to refresh.
Discussing this matter with some co-workers, I was presented with a list of well known Android apps (Twitter, Facebook, LinkedIn…) that actually do a very good pull to refresh. This convinced me that Android apps can be as good as iOS apps.
So I kept looking for other pull to refresh implementations. In the end, I got to Chris Banes’s library.
This time as soon as it worked on the emulator, I tried on both devices I have here and it worked pretty well. In fact, it is as good as Twitter’s pull to refresh.
Now, the interesting fact is: Chris Bane’s implementation needed 6 Java classes (and they are not tiny), 8 XML files and 2 images. His implementation is very interesting and truly had outstanding results. BUT this is TOO MUCH WORK FOR SUCH A SIMPLE FEATURE!
Knowing there are developers and developers (although this guy deserves respect since he is the only one that got a – open source – pull to refresh to properly work on Android), I tried not to think: “On iOS it would take a class for the header view and another to use it. Really.”.
Instead I googled for the Twitter APK file, downloaded it and decompiled it (a pretty painful process – by the way – that requires decompressing the APK, converting smil files to dex, from dex to jar and finally to Java source files). Of course, I wasn’t able to just grab and use their implementation, but that was enough readable code to see that they use just about the same number of files that Chris Bane’s does.
I am sure every file has its meaning and need, but still too much work for this feature. And just to be sure we are in the same page, I am not counting any i18n files neither assets for supporting multiple screen densities whatsoever.
Anyways, I learned two things on all of this:
1. Android apps can be as good as iOS apps
2. #1 requires a lot more work than it takes on iOS (and I am not talking about device fragmentation)
For those that like references, here are the best pull to refresh libraries I tried on Android:
And the tools I used for decompiling Twitter:
06/25/2012 § Leave a comment
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 😉
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.
<?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.
<?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>
<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:
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.