{"id":5837,"date":"2013-06-17T10:00:31","date_gmt":"2013-06-17T14:00:31","guid":{"rendered":"http:\/\/blog.xamarin.com\/?p=5837"},"modified":"2013-06-17T10:00:31","modified_gmt":"2013-06-17T14:00:31","slug":"android-the-swipe-down-to-refresh-pattern","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/xamarin\/android-the-swipe-down-to-refresh-pattern\/","title":{"rendered":"Android: The Swipe-Down-to-Refresh Pattern"},"content":{"rendered":"

\t\t\t\tThe pull-to-refresh pattern, popularized by applications like Twitter and finally integrated as a native component in iOS 6, has long been frowned upon in Android land. Because the feature is generally considered an iOS pattern, apps utilizing it on Android are sometimes regarded as “bad ports” of their iPhone counterparts.<\/p>\n

Instead of supporting pull-to-refresh, Android applications typically include a refresh button: either in the main UI or (more recently) in an app’s Action Bar. The latest version of the Gmail app, however, has started using another interesting method—one that is closer to pull-to-refresh, but integrated with Android’s Action Bar:<\/p>\n

\"device-swipe-down-refresh\"<\/p>\n

When the ListView<\/code> is positioned at the beginning, starting an overscroll will—in addition to displaying the normal edge effect—change the ActionBar to display an action message and a horizontally-centered progress bar defining when the movement results in a refresh. You can reproduce that user interface element in only a few steps.<\/p>\n

Hijacking the Action Bar<\/h3>\n

By default, the Action bar API doesn\u2019t allow you to supply a custom view. Thus, we have to somehow find a way to supply our own custom layout while interoperating with the default Action bar. For that purpose, we will exploit two things: first, the fact that Action bar’s style (appearance) is readily available through the normal Android style\/theming API and, second, a special mode which allows the action bar to be overlaid on top of normal content (as in the Google Maps app).<\/p>\n

Thanks to these two facilities, we can virtually recreate the ActionBar<\/code> look and feel by hand in a custom view and then let the system action bar draw over it with a transparent background (so that the animations applied to it are not noticeable). When we hide the action bar, we can re-purpose our \u201cfake\u201d action bar layout to display any custom view we want.<\/p>\n

Following XML is the layout that recreates the action bar background:<\/p>\n

\n<FrameLayout\n\tandroid:layout_width="fill_parent"\n\tandroid:layout_height="?android:attr\/actionBarSize"\n\tstyle="?android:attr\/actionBarStyle"\n\tandroid:id="@+id\/fakeActionBar">\n\t<TextView\n\t\tandroid:text="Swipe down to refresh"\n\t\tandroid:layout_width="wrap_content"\n \t\tandroid:layout_height="wrap_content"\n\t\tandroid:id="@+id\/swipeToRefreshText"\n\t\tandroid:layout_gravity="center"\n\t\tandroid:visibility="invisible"\n\t\tandroid:textColor="#0099cc"\n\t\tandroid:textSize="18sp" \/>\n<\/FrameLayout>\n<\/pre>\n
And then in our main Activity OnCreate<\/code> method, we can setup the Action bar like this:<\/p>\n
\nprotected override void OnCreate (Bundle bundle)\n{\n\tbase.OnCreate (bundle);\n\n\tRequestWindowFeature (WindowFeatures.ActionBarOverlay);\n\tActionBar.SetBackgroundDrawable (new ColorDrawable (Color.Transparent));\n\tSetContentView (Resource.Layout.Main);\n}\n<\/pre>\n
The advantage of having the ActionBar in this special overlay mode is also that it doesn\u2019t impact the main content layout. Indeed, if the bar hadn\u2019t been in that mode, each show\/hide call would result in a full layout pass of the visual tree, which is not what you want.<\/p>\n
A Tale of Progress Bars<\/h3>\n
When the overscroll movement is detected, we are supposed to show a horizontally-aligned progress bar to give feedback to the user. In the spirit of reusing what\u2019s already in the framework, we want to go with the standard ProgressBar<\/code> widget.<\/p>\n
It turns out that using only one progress bar is a bit awkward. Having it expand on both sides means that we would have to re-layout\/offset it all the time and monitor the progress value in order to be even in all cases.<\/p>\n
We will use two ProgressBar<\/code> controls instead and sync them on the same value. Obviously, we need to somehow find a way to flip one of them since it needs to fill up in the other direction.<\/p>\n
Again, this is very easy to do in Android by using static transformations. In our case, we will use the android:scaleX<\/code> attribute to flip the X coordinates so that the left ProgressBar<\/code> appears reversed.<\/p>\n
Following is the layout of that part:<\/p>\n
\n<FrameLayout\n\tandroid:layout_width="fill_parent"\n\tandroid:layout_height="fill_parent">\n\t<!-- Main content view -->\n\t<ListView\n\t\tandroid:layout_width="fill_parent"\n\t\tandroid:layout_height="fill_parent"\n\t\tandroid:id="@+id\/listView1"\n\t\tandroid:entries="@array\/planets_array" \/>\n\t<!-- Overlayed progress bars-->\n\t<LinearLayout\n\t\tandroid:orientation="horizontal"\n\t\tandroid:layout_width="fill_parent"\n\t\tandroid:layout_height="wrap_content"\n\t\tandroid:visibility="invisible"\n\t\tandroid:id="@+id\/loadingBars">\n\t\t<ProgressBar\n\t\t\tstyle="?android:attr\/progressBarStyleHorizontal"\n\t\t\tandroid:layout_width="wrap_content"\n\t\t\tandroid:layout_height="wrap_content"\n\t\t\tandroid:id="@+id\/loadingBar1"\n\t\t\tandroid:layout_weight="1"\n\t\t\tandroid:progress="50"\n\t\t\tandroid:layout_marginTop="-7dp"\n\t\t\tandroid:scaleX="-1.0"\n\t\t\tandroid:scaleY="1.0" \/>\n\t\t<ProgressBar\n\t\t\tstyle="?android:attr\/progressBarStyleHorizontal"\n\t\t\tandroid:layout_width="wrap_content"\n\t\t\tandroid:layout_height="wrap_content"\n\t\t\tandroid:id="@+id\/loadingBar2"\n\t\t\tandroid:layout_weight="1"\n\t\t\tandroid:progress="50"\n\t\t\tandroid:minHeight="0dp"\n\t\t\tandroid:layout_marginTop="-7dp" \/>\n\t<\/LinearLayout>\n<\/FrameLayout>\n<\/pre>\n
For exactly the same reason as with the Action bar, we use a FrameLayout<\/code> to overlay the two progress bars on top of the main content so that making them appear and disappear doesn\u2019t cause an unnecessary relayout.<\/p>\n
Using normal ProgressBar<\/code> controls introduces a slight visual defect—by default, they have a background color that makes them look like this:<\/p>\n
\"progress-bar-with-bg\"<\/p>\n
It is a little bit too intrusive and harder to tweak with animations since, visually, they still occupy the same screen space. However, thanks to the fact that on Android progress bars are implemented with Drawable<\/code> rather than custon drawing, we can easily work around that issue. More precisely, the default Holo styled progress bar uses a layer drawable which, as the name implies, is a special kind of drawable that layers other drawables on top of each other.<\/p>\n
Here is the definition of this layer drawable in the framework for the default progress bar:<\/p>\n
\n<layer-list xmlns:android="http:\/\/schemas.android.com\/apk\/res\/android">\n    <item android:id="@android:id\/background"\n          android:drawable="@android:drawable\/progress_bg_holo_dark" \/>\n    <item android:id="@android:id\/secondaryProgress">\n        <scale android:scaleWidth="100%"\n               android:drawable="@android:drawable\/progress_secondary_holo_dark" \/>\n    <\/item>\n    <item android:id="@android:id\/progress">\n        <scale android:scaleWidth="100%"\n               android:drawable="@android:drawable\/progress_primary_holo_dark" \/>\n    <\/item>\n<\/layer-list>\n<\/pre>\n
The layer we want to hide is the one identified with android:id\/background<\/code>. It\u2019s not that straightforward, however, since LayerDrawable<\/code> objects don\u2019t allow layers to be removed at runtime.<\/p>\n
What we can do is swap the drawable referenced by one of the layers to something else. Thanks to that approach, we can hide the background by changing its original 9-patch drawable to be a transparent color drawable like so:<\/p>\n
\nforeach (var p in new ProgressBar[] { bar1, bar2 }) {\n\tvar layer = p.ProgressDrawable as LayerDrawable;\n\tif (layer != null)\n\t\tlayer.SetDrawableByLayerId (Android.Resource.Id.Background,\n\t\t                            new ColorDrawable (Color.Transparent));\n}\n<\/pre>\n
The Result<\/h3>\n
I haven\u2019t covered some of the last points of the implementation like animations and event subscription, but those should be mostly straightfoward once you read the code.<\/p>\n
Here is a video of the pattern implemented by us:<\/p>\n
And you can grab the code from GitHub:<\/p>\n
\n
\n         garuma\/SwipeDownToRefresh<\/a>\n    <\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
The pull-to-refresh pattern, popularized by applications like Twitter and finally integrated as a native component in iOS 6, has long been frowned upon in Android land. Because the feature is generally considered an iOS pattern, apps utilizing it on Android are sometimes regarded as “bad ports” of their iPhone counterparts. Instead of supporting pull-to-refresh, Android […]<\/p>\n","protected":false},"author":1925,"featured_media":39167,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[4],"class_list":["post-5837","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-developers","tag-xamarin-platform"],"acf":[],"blog_post_summary":"
The pull-to-refresh pattern, popularized by applications like Twitter and finally integrated as a native component in iOS 6, has long been frowned upon in Android land. Because the feature is generally considered an iOS pattern, apps utilizing it on Android are sometimes regarded as “bad ports” of their iPhone counterparts. Instead of supporting pull-to-refresh, Android […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/posts\/5837","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/users\/1925"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/comments?post=5837"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/posts\/5837\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/media\/39167"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/media?parent=5837"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/categories?post=5837"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/xamarin\/wp-json\/wp\/v2\/tags?post=5837"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}