While being at Google I/O last week, I finally found an application using the ActionBar animation technique. Let’s be honest, it literally blew my mind the first time I saw it. I felt in love with the nice, subtle and yet extremely useful animated effect probably more than the entire app itself! I am pretty sure you know the application I am talking about as it has been presented during the Google I/O keynote. You have also probably recently received an update of it: Play Music!

The latest update of Play Music (v5.0) has been completely redesign and features a brand new artist/album detail screen. If you open such a detail screen, you’ll notice the ActionBar is initially invisible and overlaps a large image describing the artist/album. Once you start scrolling down (if possible), the ActionBar fades in gradually. The ActionBar turns completely opaque when the large image has been scrolled out of the screen.

Here are two main advantages of this ActionBar animation:

• Polish the UI: animations synchronized on an element you’re interacting with are generally appreciated by users because it makes them feel the UI is natural and reacts to their actions. The fading animation is a direct consequence of the per-pixel scrolling state and not a launched-once animation.

• Take advantage of the screen real estate: while still preserving the UX of the platform, this pattern let the user primarily focus on the content rather than the controls. Used in addition to a nicely designed screen, it can be a game changer for your app’s interface.

In this article, I will deep dive into the details of implementing the technique described in ”ActionBar on the Move” to create an effect similar to the one used in the Play Music app.

In order to better understand the goal we are targeting, you can have a look at the screenshots below or alternatively download the sample application.

Download the sample APK

Application theming/styling

As you can easily notice, in order to reproduce such an effect, the ActionBar must overlap the content of the screen. This can be easily done using the android:windowActionBarOverlay XML attributes. The code below describes the definition of the themes we’ll use:

1
2
3
4
5
6
7
8
9
10
11
12
13

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="Theme.TranslucentActionBar" parent="@android:style/Theme.Holo.Light.DarkActionBar">
        <item name="android:actionBarStyle">@style/Widget.ActionBar</item>
    </style>

    <style name="Theme.TranslucentActionBar.ActionBar" />

    <style name="Theme.TranslucentActionBar.ActionBar.Overlay">
        <item name="android:actionBarStyle">@style/Widget.ActionBar.Transparent</item>
        <item name="android:windowActionBarOverlay">true</item>
    </style>
</resources>

Pretty logically, the style of the ActionBar is defined in values/styles.xml as follows:

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="Widget.ActionBar" parent="@android:style/Widget.Holo.Light.ActionBar.Solid.Inverse">
        <item name="android:background">@drawable/ab_background</item>
    </style>

    <style name="Widget.ActionBar.Transparent">
        <item name="android:background">@android:color/transparent</item>
    </style>
</resources>

Finally, we can use these themes in order to style our Activity.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.cyrilmottier.android.translucentactionbar"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="14"
        android:targetSdkVersion="17" />

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/Theme.TranslucentActionBar">

        <activity
                android:name=".HomeActivity"
                android:theme="@style/Theme.TranslucentActionBar.ActionBar.Overlay">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

    </application>

</manifest>

Note that by using themes/styles we remove all potential flickering issues at startup (see Android App Launching Made Gorgeous for more information).

Getting the content ready

As explained previously, the ActionBar fading is synchronized on the per-pixel state scrolling of the scrolling container. In this example, we’ll simply use a ScrollView as a scrolling container. One of the major drawback of this container is you can’t register a listener in order to be notified when the scroll has changed. This can be easily done be creating a NotifyingScrollView extending the original ScrollView:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

package com.cyrilmottier.android.translucentactionbar;

import android.content.Context;
import android.util.AttributeSet;
import android.widget.ScrollView;

/**
 * @author Cyril Mottier
 */
public class NotifyingScrollView extends ScrollView {

    /**
     * @author Cyril Mottier
     */
    public interface OnScrollChangedListener {
        void onScrollChanged(ScrollView who, int l, int t, int oldl, int oldt);
    }

    private OnScrollChangedListener mOnScrollChangedListener;

    public NotifyingScrollView(Context context) {
        super(context);
    }

    public NotifyingScrollView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public NotifyingScrollView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    @Override
    protected void onScrollChanged(int l, int t, int oldl, int oldt) {
        super.onScrollChanged(l, t, oldl, oldt);
        if (mOnScrollChangedListener != null) {
            mOnScrollChangedListener.onScrollChanged(this, l, t, oldl, oldt);
        }
    }

    public void setOnScrollChangedListener(OnScrollChangedListener listener) {
        mOnScrollChangedListener = listener;
    }

}

Then, we can use this new scrolling container in an XML layout:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?xml version="1.0" encoding="utf-8"?>
<com.cyrilmottier.android.translucentactionbar.NotifyingScrollView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/scroll_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="vertical">

        <ImageView
            android:id="@+id/image_header"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:scaleType="centerCrop"
            android:src="@drawable/daft_punk"/>

      <! -- Some long content -->

    </LinearLayout>

</com.cyrilmottier.android.translucentactionbar.NotifyingScrollView>

Fading in/out the ActionBar

Now most of the boilerplate is ready, we can plug all of these components together. The ActionBar algorithm is rather simple and only consists on computing the alpha depending on the current per-pixel scrolling state of the NotifyingScrollView. Note that the effective scrolled distance must be clamped to [0, image_height - actionbar_height] in order to avoid weird values that may occur mainly because of the default over scroll behavior of scrolling containers on Android:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

package com.cyrilmottier.android.translucentactionbar;

import android.app.Activity;
import android.graphics.drawable.Drawable;
import android.os.Build;
import android.os.Bundle;
import android.support.v4.view.GravityCompat;
import android.support.v4.widget.DrawerLayout;
import android.util.Log;
import android.view.Menu;
import android.widget.ScrollView;

public class HomeActivity extends Activity {

    private Drawable mActionBarBackgroundDrawable;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_home);

        mActionBarBackgroundDrawable = getResources().getDrawable(R.drawable.ab_background);
        mActionBarBackgroundDrawable.setAlpha(0);

        getActionBar().setBackgroundDrawable(mActionBarBackgroundDrawable);

        ((NotifyingScrollView) findViewById(R.id.scroll_view)).setOnScrollChangedListener(mOnScrollChangedListener);
    }

    private NotifyingScrollView.OnScrollChangedListener mOnScrollChangedListener = new NotifyingScrollView.OnScrollChangedListener() {
        public void onScrollChanged(ScrollView who, int l, int t, int oldl, int oldt) {
            final int headerHeight = findViewById(R.id.image_header).getHeight() - getActionBar().getHeight();
            final float ratio = (float) Math.min(Math.max(t, 0), headerHeight) / headerHeight;
            final int newAlpha = (int) (ratio * 255);
            mActionBarBackgroundDrawable.setAlpha(newAlpha);
        }
    };
}

As described in ”ActionBar on the Move”, this snippet of code above doesn’t work for pre-JELLY_BEAN_MR1 devices. Indeed, the ActionBar isn’t invalidating itself when required because it isn’t registering itself as the Drawable’s callback. You can workaround this issue simply be attaching the following Callback in the onCreate(Bundle) method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private Drawable.Callback mDrawableCallback = new Drawable.Callback() {
    @Override
    public void invalidateDrawable(Drawable who) {
        getActionBar().setBackgroundDrawable(who);
    }

    @Override
    public void scheduleDrawable(Drawable who, Runnable what, long when) {
    }

    @Override
    public void unscheduleDrawable(Drawable who, Runnable what) {
    }
};

1
2
3

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
    mActionBarBackgroundDrawable.setCallback(mDrawableCallback);
}

You can already run the code “as it”. Although the result looks alike the animation used in Play Music we can still continue to tweak it to make it better.

A final brush stroke

Enforcing ActionBar contrast

Having an transparent ActionBar may lead to design issues because you generally don’t know about the background you’ll be displayed on top of. For instance you may end up with a transparent ActionBar displaying a white text on top of a white description image. No need to say it makes the ActionBar invisible and useless.

The easiest way to avoid such a problem consists on modifying the image to make it a little bit darker at the top. Thus, in a worse case scenario (i.e. white image) we would have a grey area on top of the image making the ActionBar content (title, icons, buttons, etc.) visible.

A simple way to do that is to overlay a translucent dark to transparent gradient on top of the image. This can be done in XML only with the Drawable described below:

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
       android:shape="rectangle">

    <size android:height="100dp"/>

    <gradient
        android:angle="270"
        android:startColor="#8000"
        android:endColor="#0000"/>

</shape>

The gradient is overlaid using a wrapping FrameLayout:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <ImageView
        android:id="@+id/image_header"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:scaleType="centerCrop"
        android:src="@drawable/daft_punk"/>

    <View
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@drawable/gradient"/>

</FrameLayout>

Avoid over-scroll

In Gingerbread (API 9), Android introduced a brand new way to notify the user a scrollable container is being scrolled beyond the content bounds. First it introduced the notion of EdgeEffect (available in the API starting API 14) and enabled over-scroll. While this is not a problem in general, it can be pretty annoying when one of the edge of your scrollable content is different from the background color.

You can reproduce it be simply flinging the ScrollView rapidly to the top and you’ll notice some white color (the background color) appears on top of the screen because the image is scrolling beyond the bounds. I personally consider this a a UI glitch and usually prefer disabling it in this rare cases.

One could imagine the best way to avoid over-scroll is to use View#setOverScrollMode(int) to change the mode to View#OVER_SCROLL_NEVER. Although it works, it also remove the edge effect which can be visually disturbing¹. A simple way to do that is to modify the NotifyingScrollView to force the maximum over scroll values to zero when necessary:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

private boolean mIsOverScrollEnabled = true;

public void setOverScrollEnabled(boolean enabled) {
    mIsOverScrollEnabled = enabled;
}

public boolean isOverScrollEnabled() {
    return mIsOverScrollEnabled;
}

@Override
protected boolean overScrollBy(int deltaX, int deltaY, int scrollX, int scrollY, int scrollRangeX, int scrollRangeY,
                               int maxOverScrollX, int maxOverScrollY, boolean isTouchEvent) {
    return super.overScrollBy(
            deltaX,
            deltaY,
            scrollX,
            scrollY,
            scrollRangeX,
            scrollRangeY,
            mIsOverScrollEnabled ? maxOverScrollX : 0,
            mIsOverScrollEnabled ? maxOverScrollY : 0,
            isTouchEvent);
}

Conclusion

I seriously don’t know if the team behind the Play Music application decided to implement the behavior based on my article. But it appears they brilliantly used the technique to both polish and emphasize the UI. It is clearly an awesome pattern to use whenever you need to design a screen which content is self-explanatory and is more important than the ActionBar content itself.

1. Do not ask me why the naming of the constants/method is so ambiguous…

• Polaris GitHub page
• “Meet Polaris, a Map Library for Android” blog post
• “Polaris, simple mapping library for Android” slides

(Un)fortunately - the addition/removal of the ‘un’ obviously depends on the point of view - Google released a radically different and new version of the library in December 2012. In addition to this release they announced the deprecation of the first version of the API as of March 2013¹. Let’s be honest, at first I was pretty annoyed by this new release because it turned almost all of my work to a waste of time. On the other hand, I was quite happy to notice the new API were really close - functionaly and API-ly speaking - to what I did on my own with Polaris.

Back in December I gave my point of view about the new Google Maps Android API v2. After almost 6 months, the library has been updated only once (as part of the Google Play Service, it was supposed to be updated very often…) and is not a great starting base for building libraries on top of it (all of the classes are final and hence cannot be extended).

With the release of AVélov 1.2, a lot of people were interested in the animated clustering algorithm I developed. Several companies asked me for the app source code and I was quite frustrated not being able to deliver a true library but only a sample code. That was true until I decided to find a way around the Google’s locked down library. I finally managed to by-pass the ‘final’ limitation fairly easily. I entirely wrapped the original Google’s library into my own library: Polaris v2.

Introducing Polaris v2

The main purpose of Polaris v2 is to act as the root component for creating library projects around the Google Maps Android API v2. Although I originally developed it for creating commercial library providing animated clustering, I extracted the essence of it and kept some basic features. As a consequence, Polaris v2 aims to fix some of the most frustrating bugs of the original library and provide additional features.

For now, the code is mostly a wrapper but I’m releasing and open-sourcing the code so that the community can contribute to it and enhance it with some awesome new features and fixes. The current release includes just a few improvements (see the README file on GitHub for more information). Hopefully, some of the changes introduced in Polaris v2 will be backported into Google Maps Android API v2…

Go to Polaris v2 GitHub page

Using Polaris v2 in your projects

Using Polaris v2 in your projects is quite simple. The API exposed by Polaris v2 is a super-set of what the original Google Maps Android API v2 exposes. As a result, you only need to switch all of the imports from the Google Maps Android API v2 (com.google.android.gms.maps.*) to Polaris v2 (com.cyrilmottier.polaris2.maps.*)

Finally you can start interacting with the underlying GoogleMap by calling getPolarisMap() (instead of getMap()) on your SupportMapFragment, MapFragment or MapView.

Conclusion

While the original project at the root of Polaris was more featureful, this release is the perfect way for developers to start adding some missing features to the original Google-provided mapping library. Today, Polaris v2 is just a wrapper around the Google Maps Android API v2 but could easily become a must-use library in the future. The project is just waiting for the community to help it grow.

1. Having a deprecated API doesn’t mean it is not working anymore for all existing applications. Google only decided to prevent people from generating new API keys. As a consequence, it is now impossible to create new applications using the Google Maps external library except if you are signing your application with a certificate you already have assigned a map API key to.

3 or 4 months ago I received an email from my host telling me they were dropping support of my old version of PHP (5.2). The version of Wordpress used for my android.cyrilmottier.com blog was so old it wasn’t supporting the PHP 5.4 and can’t even upgrade itself to a PHP 5.4 compliant version… Not being a server/backend guy, I decided to go for a complete redesign of both the guts and the look of cyrilmottier.com.

No more PHP or MySQL

The new version of the website is now using Octopress. Put simply, Octopress is a static website generator. Some of the main advantages of Otopress over Wordpress is it requires no SQL and no PHP, is responsive by default, deals perfectly with code snippets and relieve me from the pain of updating stuff I don’t know well. The only required piece of software Octopress needs is … Apache.

Bringing simplicity

The cyrilmottier.com domain was previously redirecting to a landing page made of tons of redirections to subdomains. Whilst it keeps clear sections in your website, it is hard to maintain and require time I don’t have (nor don’t want to spend on). As a result, I decided to go for something way more simple:

android.cyrilmottier.com is now cyrilmottier.com

In the process, I removed several subdomains and redirections I considered outdated and useless :

• My professional website
• A prehistoric web page of my TI calculators apps
• A old blog about my experience as an Erasmus student in Helsinki, Finland
• A file manager I never ever used in 5 years

Holo-like theme

Aside from removing a bunch of subdomains, I also created a theme from scratch. Once again, the idea behing the ‘Carrot’ theme (don’t ask me why I decided to name it that way) is to make things simple, remove all distractful and useless info just like the Android Holo style does. I really think I managed to focus on the content by getting rid or minimalizing of all secondary information.

As a mobile UI/UX engineer and designer, I wanted to finally have a website that looked like what I would have done if my website was an Android app. You can now notice the new website is layout and density¹ responsive. As a result, it renders like magic on phones as well as tablets and desktop

Do not hesitate to delegate

Static websites don’t let you create dynamic algorithms… After all that’s what “static” means :). In order to keep features such as comments or search I used a plain old design pattern in computer science: delegation. Starting from now, comments are managed by Disqus², and search is done by the best search-engine in the world: Google.

Miscellaneous

Meaningless URLs are now over. When creating android.cyrilmottier.com I wanted to have short URLs to blog posts. The only purpose of this was to avoid the use of URL shorteners in social networks such as Twitter. However, using short URLs is far from being a great search engine optimization (SEO). Now that Twitter automatically shorten URLs, I’ve decided to switch to a more standard URL model:

http://cyrilmottier.com/<year>/<month>/<day>/<post-slug>.html

The previous version of android.cyrilmottier.com was great for accessing new content but it wasn’t easy to browse the entire content of the blog. The new version now includes an ”Archives” page you can use to easily browse old posts.

Conclusion

I have spent quite a lot of time redesigning this domain but it was worth it. I learned tons of new stuff and I loved it. From a user point of view, everything should work fine seamlessly. However, as I said, I’m not a server administrator nor a backend guy so please contact me if you think something is wrong.

One of the redirection that scares me the most is the RSS feed (R.I.P. Google Reader …). The URL (from http://android.cyrilmottier.com/?feed=rss2 to http://cyrilmottier.com/atom.xml) as well as the format (from RSS2 to ATOM) has changed so please make sure you RSS reader now points to http://cyrilmottier.com/atom.xml.

1. I’m only talking about the theme. Indeed, images from posts are not density-responsive for one single reason: Octopress nor HTML correctly handles it.

2. Disqus comments are not activated nor migrated for now but I plan to do it as soon as possible.

This is only after the user has downloaded and launched the app you can start thinking of gradually engaging her/him, presenting an awesome user interface, displaying a minimalist setup, etc. A recent study measured the importance of the first impression and determined 26% of all apps downloaded are opened only once and then never used again. Only 26% were used 11 times or more. Of the remaining 48% of apps: 13% are opened only twice, 9% are opened only three times, and so on. Regarding such figures, there is no need to tell how crucial the polishing of the first impression is if you want your app to survive in the “apps jungle”.

In this post, I wanted to talk about the exact point in time at which the user taps on an app icon and opens it: the app launching animation. It happens I have recently played with tons of apps completely screwing this part of the user flow. In order to help developers polishing their applications, I thought about introducing the issue, explaining in details how Android deals with app launching and finally fixing all of the potential glitches.

Introduction to the issue

Let’s take a very simple example to understand what I am talking about here: the built-in Calculator application. This app is rather simple and made of a single screen letting users write formulas and get the result of it. From a feature point of view, the Calculator application does what it is intended to. Unfortunately it doesn’t respect the previously described “first impression is all” rule. You can have a closer look into the application startup looking at the screencast below.

Have you seen something visually disturbing and/or jarring? I guess most of you haven’t noticed anything. Okay, I’ll be honest with you: the screencast example was intentionally hard. Here are some easier examples that respectively illustrate the launch of GigBeat and Facebook (the screen on the left is displayed prior the one on the right):

I guess you now clearly understand the issue. GigBeat and especially Facebook display an intermediate screen that is completely at the opposite of the final screen on the right. When I’m saying “opposite” I thinking in terms of appearance and contrast. From a user standpoint, it looks like the application is launching a useless screen to initialize something prior actually launching the main screen.

On the other side, some applications like the built-in Contacts or Messages applications do the launching the right way. Here are the screen flow I have when starting the Contacts app on my dwarf-dedicated mobile phone…

As you can see, the launching is perfect and gives the impression the app starts instantly by preloading a subset of the UI: the background color and the color of the ActionBar. Once the Activity is ready, the system fades out the temporary screen revealing the actual content of the screen. This technique makes app launching natural, continuous and smooth.

Understanding Android app launching

To fix this annoying issue we must first understand how Android deals with application launching. I believe giving all of the details would take a huge amount of time and I don’t think you need to understand every single detail of it so I will be as short as possible.

Starting a new application on Android basically consists on spawning a new process running an instance of a Dalvik VM. Once started, the Dalvik VM will, in turn, initialize a thread in which most of your code will be executed: the famous UI thread aka the main thread. Because initializing a process with a Dalvik VM from scratch may require a lot of time, Android relies on a trick called Zygote.

Curious people can go to the Wikipedia page of “Zygote” and will read the following abstract:

A zygote is the initial cell formed when two gamete cells are joined by means of sexual reproduction. In multicellular organisms, it is the earliest developmental stage of the embryo. In single-celled organisms, the zygote divides to produce offspring, usually through meiosis.

It may looks like this definition has nothing to do this Android but it actually do! Android’s zygote has been named after the term defined above. The Zygote technique used in Android consists on creating an initial process at boot time with a Dalvik VM. This instance preloads a bunch of classes, Drawables and ColorStateLists from the SDK and is used as the seed process from which all instances will be derived. Thanks to this technique, spawning a new ready-to-use process in Android simply requires forking the Zygote process which is way more efficient than creating a new process from scratch.

Zygote is an important optimization in Android because it minimizes the memory usage (on a copy-on-write basis) and reduces the amount of time required to start a new process. Although, application launching is blazingly fast, Android still require some time to load some data from your application (classes, resources, etc). In order to avoid hiccups and visually respond as soon as possible to the user interaction, the system displays a temporary window: the “starting window” also known as the “preview window”.

Pretty logically, starting windows are very basic windows that do almost nothing but displaying a minimalist UI. Starting windows are of type TYPE_APPLICATION_STARTING, are not focusable nor touchable and only displayed when the started Activity belongs to an application whose process is not started yet. As a result, starting windows are usually shown before actually displaying the Activity whose category is android.intent.category.LAUNCHER. However, due to the Android multitasking model, starting windows can also be displayed when restoring an Activity. In other words, do not consider starting windows as splash screens (you can read a previous post of mine to understand my point of view on splash screens).

As described previously, the purpose of preview windows is to give the user immediate feedback that the app launched, but it also gives your app time to initialize itself. When your app is ready to run, the system removes the window and displays your app’s windows and views. As a result, none of your Java code is executed when the starting window is displayed. So how does Android know what my application will look like? In order to infer the design of the Activity, the framework uses the current Activity theme i.e. the theme of the Activity or the theme of the parent Application if no theme has been set to the Activity. Android inflates an empty but themed decor view (the base view hierarchy of an Activity), attaches it to a starting window and displays the latter on screen.

The perfect preview window

Now you have a clear overview of how Android deals with application launching, you can easily imagine what’s wrong this the Calculator, Gigbeat and Facebook apps. They are not correctly setting the theme. Even worse, all of these applications rely on the default theme @android:style/Theme or @android:style/Theme.Holo.Light and use their layout as the UI styling component. This is the reason why we see an intermediate design of the application (inferred from the theme) that is completely different from the second screen (the actual Activity).

So how can we fix the preview window issue? The first thing to do is obviously to create your own custom theme. As an example, we will investigate the built-in Calculator app because the code source is completely open source and available on GitHub. The Calculator app’s AndroidManifest.xml is given below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.calculator2">

    <original-package android:name="com.android.calculator2" />

    <application android:label="@string/app_name" android:icon="@mipmap/ic_launcher_calculator">
        <activity
            android:name="Calculator"
            android:theme="@android:style/Theme.Holo.NoActionBar"
            android:windowSoftInputMode="stateAlwaysHidden">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.LAUNCHER" />
                <category android:name="android.intent.category.APP_CALCULATOR" />
            </intent-filter>
        </activity>
    </application>
</manifest>

As you can see, the Calculator app is made of a single Activity using the @android:style/Theme.Holo.NoActionBar theme. In order to modify some theme attributes, we will simply create a custom theme using the theme currently used by the Calculator app as the parent:

1
2
3

<style name="Theme.Calculator" parent="@android:style/Theme.Holo.NoActionBar">
    <!-- -->
</style>

and use it in the AndroidManifest.xml:

1
2
3
4
5
6

<activity
    android:name="Calculator"
    android:theme="@style/Theme.Calculator"
    android:windowSoftInputMode="stateAlwaysHidden">
    <!-- -->
</activity>

The first way to avoid the preview window artifacts is to completely disable the feature. Indeed, although starting windows are enable by default on Android, the SDK allows you to disable them simply by setting the android:windowDisablePreview attribute to true in your theme. Unfortunately, disabling preview windows also removes their main advantage: simulate an instant application launching. As a result, I highly suggest you not to disable starting windows unless really necessary (this is mostly only necessary in games based on Open GL ES).

The correct way to style a preview window is to make sure it best matches your Activity. In the case of the Calculator app, we will simply modify the background of the window to switch from the default gradient to a solid black color:

1
2
3

<style name="Theme.Calculator" parent="@android:style/Theme.Holo.NoActionBar">
    <item name="android:windowBackground">@android:color/black</item>
</style>

You can now kill and restart the Calculator app and notice that the preview animation is now in accordance with the Activity. The job was pretty simple, wasn’t it? To help Google improving the Calculator app, I have already submitted this patch to the Android review system.

Thanks, to this tiny change in the code we now have a Calculator application with a nice preview animation. However, even if the result is visually correct, you can still enhance the rendering performance of the app. Indeed, let’s look for some potential overdraw. Enabling “Show GPU overdraw” in the developer options gives us the following screenshot:

As a reminder, blue means an overdraw of 1x, green 2x, light red 3x, etc. If you don’t know what overdraw is or how to measure and minimize it, please read the excellent documentation/reference on Romain Guy’s blog. Most of the screen being blue or green it basically means we are rendering too much layers on some parts of the UI. A rapid investigation on the layouts explains the issue. Indeed, all of the main.xml layout variants used a the content view of our main Activity are as follow:

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="#ff000000">

    <!-- -->

</LinearLayout>

It is now clear that the overdraw comes from the fully opaque black color drawn by the root LinearLayout as the background. While it was previously used to inefficiently hide the default gradient window background, it is now useless and can be removed. Here again, I have submitted a patch.

Moving the background of your screens from the root of your layout to the background of your window is generally a good fix. Nevertheless, in some cases, the background of your window cannot be used as the general background and styling at the “layout level” is still required. In such as case, the trick consists on keeping a theme so that the system can infer the preview window of your app and change the background of the final window back to null in your Activity’s onCreate():

1
2
3
4
5
6

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    getWindow().setBackgroundDrawable(null);
    setContentView(R.layout.main);
}

To conclude, you may still want to understand how the Contacts app displays a preview of the ActionBar. The answer to this question has been given above: the preview window is made of a themed empty decor view. The decor view is the hierarchy where lies the ActionBar. As a consequence, always style the ActionBar directly in your theme (see the documentation for more information) to have a nice and smooth application launching.

Conclusion

Starting windows may not be visible for a huge amount of time, they are shown at a crucial moment in the lifetime of your application. Hence, ensuring they correctly display a subset of your Activity UIs is vital. Polishing preview windows make your app fancier and smoother by removing all of the un-needed extra layers.

To finish, starting windows are great but must not be considered or used as splash screens. Do not consider preview windows as an excuse for publishing slow applications. They are clearly not intended to do that. They’re here to fake a fast launching while the system loads up your application process and make your app launch as graphically pleasant as possible to your users.

The purpose of this article is to give you a clear explanation about the control offered by Android over scroll containers. I have intentionally used iOS to do the comparison because the philosophy behind scroll containers in iOS is relatively different than Android.

Once upon a time, there was iOS

Just like every mobile OS, iOS runs on devices with a rather limited display surface. In order to display as much content as possible, applications can use scroll containers such as UIScrollView (ScrollView-equivalent), UITableView (ListView-equivalent), UIWebView (WebView-equivalent), etc. These containers let you scroll the content using gestures now considered elementary: the swipe gestures. When looking at your content, you may want to be brought back to the top of that content. While this is not something obvious on Android, the feature is available via a consistent and nice gesture on iOS: you simply have to tap the status bar. When doing so, the system will basically look for a UIScrollView in your app’s view hierarchy and scroll it back to the top if allowed to (i.e. if the UIScrollView has the scrollToTop property set to YES and the delegate allows it)).

Some might criticize the lack of discoverability of this feature and I totally agree. This is clearly something that is not natural to the user. It will generally be discovered by mistake. Once spotted, this is a power-feature reserved to power-users. However, always keep in mind that it is important to satisfy these guys : they generally push feedbacks and review your application way more rapidly than “regular” users.

So what about Android? I guess you are not aware of such a gesture on your devices. The reason is pretty obvious: Android doesn’t offer such a system-wide/global gesture! I don’t know the exact reason of this “lack”. Google considering it as not required? Apple having patented the gesture? The only thing I’m sure of is implementing scroll-to-top is almost impossible on Android because scroll containers in the SDK are a complete mess.

The Android scroll issue

This is not a mystery to anyone, globally speaking, I do love Android. However, I’m also pragmatic enough to notice some parts of the platform are not well designed or badly implemented. The scrollable containers APIs belong in this category. You don’t need to be an API designer to notice they are extremely confusing regarding scroll-related capabilities.

By default, the framework provides basic support for Views that wish to internally scroll their content and draw scrollbars. For instance, you can scrollTo(int, int)). While this works perfectly with ScrollView it doesn’t with ListView nor WebView nor my beloved MapView. Another example of this confusion is the ViewTreeObserver.OnScrollListener that works perfectly on all kinds of scrollable content but doesn’t provide you with the container that scrolled. Once again, Google Maps Android API v2 MapView is an exception and won’t fire the callback when being scrolled or zoomed. Finally, there are some inconsistencies. For instance, AbsListView.OnScrollListener lets you listen to AbsListView scrolls but there is no View.OnScrollListener counterpart. If you want to listen to scrolls at the View level, you’ll need to override the onScrollChanged(int, int, int, int) method.

Put simply, Android offers several scroll containers, but no consistent way to formalize scrolling and notify the developer. Even if you can determine if a View is a scroll container by using View.setScrollContainer(boolean)¹, there is absolutely no way to develop a unified algorithm that would scroll your container to its top with a single call to View.scrollTo(0, 0).

On the other side, iOS simplified the problem by making sure all scrollable containers are unified via a UIScrollView - the base class containing the “scrolling” and “scroll-to-top” implementation. The framework offers a bunch of scrollable containers: UITextView, UITableView, UIWebView, MKMapView, etc. that all inherit or encapsulate a UIScrollView. By factorizing the scrolling behavior, iOS ensure that the scrolling physics (velocity, friction, bouncing, etc.) are consistent throughout iOS apps and guarantee all scrollable content can be scrolled back to the top.

So, is Android a crappy framework? Well I don’t think so. The API mess is probably difficult to apprehend - especially for new developers - but this is also what makes Android’s ListView so powerful compared to iOS UITableView when displaying items with variable heights for instance. UITableView relying on UIScrollView, it has to know all of the list’s items. On the other hand, Android’s ListView only requires the height of the visible items.

To sum up, iOS’ UIScrollView-based API simplifies development and enforces UIs consistency. On the other hand Android’s messy API requires more attention from the developer, but can kick iOS’ ass in some special cases.

It appears that not being able to implement a global scroll-to-top gesture is not really a problem. Indeed, most issues can be solved at the application level using components that are generally way more specific to the data displayed by your app. It obviously requires more work than relying on the default system’s behavior and doesn’t provide a consistent and coherent gesture throughout the platform. But, why would I need a scroll-to-top gesture in the Contacts iOS app if it also offers an index on the right?

Back to top on Android: the ethereal problem

Ultimately, the scroll content issue Android suffers from at the API level has no impact on the UI. If you are complaining about the feature missing, you should probably notify the developer his/her app needs some enhancements. The framework includes out-of-the-box workarounds and components that prevent the user from flinging for eternity trying to reach the top of your scrollable container:

• Avoid long scrollable content at all cost: The best way to avoid scrolling pains is to avoid large scroll containers. In general, avoid long ListViews at all costs. Failing to do so will drown the important information in the middle of an almost un-findable/searchable list.

• Enable fly-wheel: Since API 11, Android offers a fly-wheel mode in Scroller and OverScroller (the base components used to implement scrolling behaviors). When activated, successive fling motions will keep on increasing scroll speed. As a result, the user can rapidly increase the speed of the scroll containers to go back to an edge. Prior API 11, the velocity was generally topped by ViewConfiguration.getScaledMaximumFlingVelocity().

• Enable fast scroll whenever possible: AbsListView can be scrolled extremely rapidly with a call to setFastScrollEnabled(true). Used in addition to SectionIndexer this makes navigation though an ordered list of grouped items extremely pleasant and powerful. While fast scroll can be used with all kind of data, it is generally only appropriate with ordered and grouped data. The Contacts app for instance uses it brilliantly.

Contrary to iOS, you generally don’t need to implement a tap-on-something-to-scroll-to-top behavior on Android. However, there is one case where the previously described techniques don’t fit: the timeline. Most of the time, a timeline is a vertically scrolling area displaying events sorted by creation date. The closer you are to the top, the more recent the data are.

The best - or should I say the worst - example of this is Google+. Google+ for Android displays a timeline with all of the posts from your circles’ members. Reading posts is usually done from top to bottom which basically means from the most recent to the oldest ones. Sometimes you want to scroll way back to the top to see if there is a new post. That sounds easy, right? Well good luck with that :s. Here are the two options I found:

• Start flinging like crazy back to top. Unfortunately, it looks like they completely disabled the fly-wheel mode which makes scrolling a pain in the ass.

• Exit the timeline and reopens it I don’t think I need to describe this technique. You’ll all have understood it is purely non-logical and hence not user-friendly.

In this rare case I think, the tap-on-something-to-scroll-to-top is the correct option.

Tweaking the Quick Return pattern

Android not letting us listen to taps on the status bar, the only option is to use a clickable area in your application: a tab, a regular TextView, etc. A few months ago, Roman Nurik and Nick Butcher described and formalized a pattern they called “Quick Return”. I highly suggest you take a look at Roman’s G+ post or at Juhani Lehtimäki’s blog article to learn more about this emerging UI pattern.

While this pattern is great to make some important controls of your UI reappear, it doesn’t exactly fit the scroll-to-top gesture. Indeed, using the Quick Return pattern in this case would involve having a button appearing once the user starts scrolling up. This could be really annoying or frustrating.

In order to fix the issue, I’ve decided to tweak the pattern. Because users usually scroll up rapidly when going back to top, I thought it was only necessary to display the button when the velocity is higher than a given threshold. The rest of the article will focus on implementing such a widget but you can download an APK of the project (API 12 min) here:

Download sample APK

Note: The code given below is a proof of concept. I have never used it in production and I already know it may behave weirdly (crash ?) when the underlying Adapter’s data is modified. Please make sure to understand what you are doing when using/modifying the snippet of code below.

Scrolling to the top

Going back to the top in a ListView is rather complicated. Here are some of the methods you can use:

• setSelection(int): This method works like a charm by selecting the given position. As a result setSelection(0)can bring us back to the top. Unfortunately it has two mains disadvantages: the transition is not animated at all which is visually jarring and modifying the selected position in the middle of a fling animation doesn’t stop the animation.

• smoothScrollToPosition(int): Available since API 8, this methods sounds like a good match. Unfortunately, I have never made it work in my projects. I’ve found a lot of complains about it on the web and stopped using it.

• smoothScrollToPositionFromTop(int, int): Available since API 11, this method is a low-level counterpart of the previous method. The only different is it seems to work. Put simply, Android does not offer per-pixel scrolling in ListView prior API 11.

As you may have noticed, scrolling a ListView to its top in an animated way is rather difficult. Fortunately, some people in the Android team already did the job of creating an extension of ListView: the AutoScrollListView. Available in the Contacts app, the AutoScrollListView can be asked to scroll (smoothly or otherwise) to a position.

Measuring the velocity of a ListView

ListView doesn’t provide a method to get its current velocity. As a consequence, the only thing we can do is computing it. Measuring the velocity of a ListView is rather difficult. Indeed, measuring a velocity is usually done using the simple formula: v = Δd/Δt. Getting Δt is pretty elementary but that’s not the case for Δd on Android.

Contrary to iOS’s UITableView, ListView doesn’t give you a “current scroll Y”. The “measure items on demand” strategy used by ListView makes it hard to scroll at the pixel level and to measure its physical property (such as the velocity). However, even if you can’t determine the exact velocity of a ListView, you can approximate the value using an approximation of the travelled distance. Here is the approach I created:

• At each scroll step n, keep the values of the View top d_n and the position p_n of the underlying data in the Adapter of the ListView’s child at index 0

• If the item’s at position p_n+1 is still visible then Δd is equal to the difference between the new top and the previous top: d_n+1 - d_n.

• If the position is not visible anymore, then we can approximate the distance by computing the average height of the visible items in the ListView and multiply this value by the difference between the current position and the old position.

The schema shows a list being scrolled up (i.e. the user is swiping from top to bottom). As explained previously, Δd = d₂ - d₁.

While the technique works great and scrolling up, you may easily fall into a case where d₂ is not measurable because the view at index 0 in the previous measurement has been recycled. The trick consists of using the exact same technique twice: once for the child at index 0 (mostly used when scrolling up) and also for the child at index getChildCount() - 1 (mostly used when scrolling down).

Finally, if you are scrolling up or down extremely rapidly you may have none of the children on screen from one step to another. In this case we will use the “position is not visible anymore” approximation. This case can also occur if your application freezes the UI thread.

The code is provided below and consists on extending AutoScrollListView to approximate the velocity of the ListView and notifying an optional client:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188

package com.cyrilmottier.android.scrolltotop.widget;

import android.content.Context;
import android.util.AttributeSet;
import android.view.animation.AnimationUtils;
import android.widget.AbsListView;
import android.widget.ListView;

/**
 * An extension of the framework's {@link ListView} that can determine an
 * approximate value of its current velocity on the Y-axis.
 * 
 * @author Cyril Mottier
 */
public class VelocityListView extends AutoScrollListView {

    /**
     * A callback to be notified the velocity has changed.
     * 
     * @author Cyril Mottier
     */
    public interface OnVelocityListViewListener {
        void onVelocityChanged(int velocity);
    }

    private static final long INVALID_TIME = -1;

    /**
     * This value is really necessary to avoid weird velocity values. Indeed, in
     * fly-wheel mode, onScroll is called twice per-frame which results in
     * having a delta divided by a value close to zero. onScroll is usually
     * being called 60 times per seconds (i.e. every 16ms) so 10ms is a good
     * threshold.
     */
    private static final long MINIMUM_TIME_DELTA = 10L;

    private final ForwardingOnScrollListener mForwardingOnScrollListener = new ForwardingOnScrollListener();

    private OnVelocityListViewListener mOnVelocityListViewListener;

    private long mTime = INVALID_TIME;
    private int mVelocity;

    private int mFirstVisiblePosition;
    private int mFirstVisibleViewTop;
    private int mLastVisiblePosition;
    private int mLastVisibleViewTop;

    public VelocityListView(Context context) {
        super(context);
        init();
    }

    public VelocityListView(Context context, AttributeSet attrs) {
        super(context, attrs);
        init();
    }

    public VelocityListView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
        init();
    }

    private void init() {
        super.setOnScrollListener(mForwardingOnScrollListener);
        mForwardingOnScrollListener.selfListener = mOnScrollListener;
    }

    @Override
    public void setOnScrollListener(OnScrollListener l) {
        mForwardingOnScrollListener.clientListener = l;
    }

    public void setOnVelocityListener(OnVelocityListViewListener l) {
        mOnVelocityListViewListener = l;
    }

    /**
     * Return an approximative value of the ListView's current velocity on the
     * Y-axis. A negative value indicates the ListView is currently being
     * scrolled towards the bottom (i.e items are moving from bottom to top)
     * while a positive value indicates it is currently being scrolled towards
     * the top (i.e. items are moving from top to bottom).
     * 
     * @return An approximative value of the ListView's velocity on the Y-axis
     */
    public int getVelocity() {
        return mVelocity;
    }

    private void setVelocity(int velocity) {
        if (mVelocity != velocity) {
            mVelocity = velocity;
            if (mOnVelocityListViewListener != null) {
                mOnVelocityListViewListener.onVelocityChanged(velocity);
            }
        }
    }

    /**
     * @author Cyril Mottier
     */
    private static class ForwardingOnScrollListener implements OnScrollListener {

        private OnScrollListener selfListener;
        private OnScrollListener clientListener;

        @Override
        public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount) {
            if (selfListener != null) {
                selfListener.onScroll(view, firstVisibleItem, visibleItemCount, totalItemCount);
            }
            if (clientListener != null) {
                clientListener.onScroll(view, firstVisibleItem, visibleItemCount, totalItemCount);
            }
        }

        @Override
        public void onScrollStateChanged(AbsListView view, int scrollState) {
            if (selfListener != null) {
                selfListener.onScrollStateChanged(view, scrollState);
            }
            if (clientListener != null) {
                clientListener.onScrollStateChanged(view, scrollState);
            }
        }
    }

    private OnScrollListener mOnScrollListener = new OnScrollListener() {
        @Override
        public void onScrollStateChanged(AbsListView view, int scrollState) {
            switch (scrollState) {
                case SCROLL_STATE_IDLE:
                    mTime = INVALID_TIME;
                    setVelocity(0);
                    break;

                default:
                    break;
            }
        }

        @Override
        public void onScroll(AbsListView view, int firstVisiblePosition, int visibleItemCount, int totalItemCount) {

            final long now = AnimationUtils.currentAnimationTimeMillis();
            final int lastVisiblePosition = firstVisiblePosition + visibleItemCount - 1;

            if (mTime != INVALID_TIME) {

                final long delta = now - mTime;
                if (now - mTime > MINIMUM_TIME_DELTA) {
                    int distance = 0;
                    //@formatter:off
                    if (mFirstVisiblePosition >= firstVisiblePosition
                            && mFirstVisiblePosition <= lastVisiblePosition) {
                        distance = getChildAt(mFirstVisiblePosition - firstVisiblePosition).getTop() - mFirstVisibleViewTop;

                    } else if (mLastVisiblePosition >= firstVisiblePosition
                            && mLastVisiblePosition <= lastVisiblePosition) {
                        distance = getChildAt(mLastVisiblePosition - firstVisiblePosition).getTop() - mLastVisibleViewTop;
                    //@formatter:on
                    } else {
                        // We're in a case were the item we were previously
                        // referencing has moved out of the visible window.
                        // Let's compute an approximative distance
                        int heightSum = 0;
                        for (int i = 0; i < visibleItemCount; i++) {
                            heightSum += getChildAt(i).getHeight();
                        }

                        distance = heightSum / visibleItemCount * (mFirstVisiblePosition - firstVisiblePosition);
                    }

                    setVelocity((int) (1000d * distance / delta));
                }
            }

            mFirstVisiblePosition = firstVisiblePosition;
            mFirstVisibleViewTop = getChildAt(0).getTop();
            mLastVisiblePosition = lastVisiblePosition;
            mLastVisibleViewTop = getChildAt(visibleItemCount - 1).getTop();

            mTime = now;
        }
    };

}

The final code

Now we can be notified of a change in the velocity of our ListView, so we can animate in a scroll-to-top button only when going beyond a certain threshold. First of all, let’s create the layout of our Activity:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >

    <com.cyrilmottier.android.scrolltotop.widget.VelocityListView
        android:id="@android:id/list"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />

    <Button
        android:id="@+id/btn_scroll_to_top"
        android:layout_width="match_parent"
        android:layout_height="32dp"
        android:layout_gravity="top"
        android:background="@drawable/list_selector"
        android:gravity="center"
        android:text="@string/tap_to_scroll_to_top"
        android:textColor="@android:color/white"
        android:textSize="12sp"
        android:textStyle="bold"
        android:translationY="-32dp" />

</merge>

The Activity’s code is now crystal clear:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

package com.cyrilmottier.android.scrolltotop;

import android.animation.Animator;
import android.animation.Animator.AnimatorListener;
import android.animation.AnimatorListenerAdapter;
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.ViewGroup;
import android.view.ViewPropertyAnimator;
import android.widget.BaseAdapter;
import android.widget.Button;
import android.widget.TextView;

import com.cyrilmottier.android.scrolltotop.widget.VelocityListView;
import com.cyrilmottier.android.scrolltotop.widget.VelocityListView.OnVelocityListViewListener;

public class MainActivity extends Activity {

    private static final int VELOCITY_ABSOLUTE_THRESHOLD = 5500;

    private static final int BIT_VISIBILITY = 0x01;
    private static final int BIT_ANIMATION = 0x02;

    private static final int SCROLL_TO_TOP_HIDDEN = 0;
    private static final int SCROLL_TO_TOP_HIDING = BIT_ANIMATION;
    private static final int SCROLL_TO_TOP_SHOWN = BIT_VISIBILITY;
    private static final int SCROLL_TO_TOP_SHOWING = BIT_ANIMATION | BIT_VISIBILITY;

    private VelocityListView mListView;
    private Button mScrollToTopButton;

    private ViewPropertyAnimator mAnimator;

    private int mVelocityAbsoluteThreshold;
    private int mScrollToTopState = SCROLL_TO_TOP_HIDDEN;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mVelocityAbsoluteThreshold = (int) (VELOCITY_ABSOLUTE_THRESHOLD * getResources().getDisplayMetrics().density + 0.5f);

        setContentView(R.layout.main_activity);

        mScrollToTopButton = (Button) findViewById(R.id.btn_scroll_to_top);
        mScrollToTopButton.setOnClickListener(mOnClickListener);

        mAnimator = mScrollToTopButton.animate();

        mListView = (VelocityListView) findViewById(android.R.id.list);
        mListView.setAdapter(new CheesesAdapter());
        mListView.setOnVelocityListener(mOnVelocityListener);
    }

    private OnClickListener mOnClickListener = new OnClickListener() {
        @Override
        public void onClick(View v) {
            mListView.requestPositionToScreen(0, true);
        }
    };

    private OnVelocityListViewListener mOnVelocityListener = new OnVelocityListViewListener() {
        @Override
        public void onVelocityChanged(int velocity) {
            if (velocity > 0) {
                if (Math.abs(velocity) > mVelocityAbsoluteThreshold) {
                    if ((mScrollToTopState && BIT_VISIBILITY) == 0) {
                        mAnimator.translationY(0).setListener(mOnShownListener);
                        mScrollToTopState = SCROLL_TO_TOP_SHOWING;
                    }
                }
            } else {
                if ((mScrollToTopState && BIT_VISIBILITY) == BIT_VISIBILITY) {
                    mAnimator.translationY(-mScrollToTopButton.getHeight()).setListener(mOnHiddenListener);
                    mScrollToTopState = SCROLL_TO_TOP_HIDING;
                }
            }
        }
    };

    private final AnimatorListener mOnHiddenListener = new AnimatorListenerAdapter() {
        public void onAnimationEnd(Animator animation) {
            mScrollToTopState = SCROLL_TO_TOP_HIDDEN;
        };
    };

    private final AnimatorListener mOnShownListener = new AnimatorListenerAdapter() {
        public void onAnimationEnd(Animator animation) {
            mScrollToTopState = SCROLL_TO_TOP_SHOWN;
        };
    };

    public class CheesesAdapter extends BaseAdapter {

        @Override
        public int getCount() {
            return CHEESES.length;
        }

        @Override
        public String getItem(int position) {
            return CHEESES[position];
        }

        @Override
        public long getItemId(int position) {
            return position;
        }

        @Override
        public View getView(int position, View convertView, ViewGroup parent) {

            if (convertView == null) {
                convertView = getLayoutInflater().inflate(R.layout.text_item, parent, false);
            }

            ((TextView) convertView).setText(getItem(position));

            return convertView;
        }
    }

    public static final String CHEESES[] = {
            "Abbaye de Belloc", "Abbaye du Mont des Cats",
            // ...
            "Zanetti Grana Padano", "Zanetti Parmigiano Reggiano"
    };

}

As described previously, the code above should be considered as a proof of concept rather than a ready-to-use widget. Because of this I have decided not to push it on GitHub but share it “as it” here. Please note the license attached to it is the Apache v2.

Download source

Conclusion

Android’s scroll containers are probably more difficult to understand than their iOS counterparts, but they also offer a larger set of features. While scrolling to the top is extremely easy to implement on iOS, it requires more work from developers on Android. However, always keep in mind that implementing an iOS-like scroll-to-top gesture is not necessary 95% of the time. The other 5% can freely tweak or reuse the code I shared here.

Thanks to @franklinharper and @moystard for reading drafts of this

1. This flag is currently used by Android to determine whether the window can resize or must pan when a soft IME is open.

As the creator and developer of Polaris - a library greatly enhancing the features of Google Maps API v1 with effortless map annotating, gesture support, map callout support, built-in “user tracking” mode, etc. - and the developer of AVélov - a map-based application to determine the availability of city bikes/slots in Lyon, France - I really wanted to have a look at the new version of the framework. So did I and here is a feedback after 5 days playing with it.

At first sight, Google Maps Android API v2 is clearly an insanely great improvement to the first version of the framework. First of all, it is providing the developer with all of the features I developed on top of Google Maps Android API v1 with Polaris: it gets rid of the annoying ItemizedOverlay, it provides a “user-tracking” mode, it recognizes all gestures, it contains several default resources (markers, info windows), etc. Moreover, all of this is based on a new vector-based rendering engine supporting scrolling, zooming, tilting and bearing for continous levels. Thanks to that you can now have a non-discrete zoom-level of 6.1234 which basically means you can create awesome smooth animations.

In addition, the framework brings some cool new features such as support for third-party tile provider, ground overlays, polylines, polygones, etc.

Pretty logically, the engineers behing the framework threw away the API from v1 and re-wrote the v2 from scratch. I’m pretty happy with that because the new API are more Android-compliant and future proof. API v2 are finally in accordance with what we could expect from a company like Google that is supposed to excel at doing maps.

One of the major drawback though is that everything is final. In other words, they decided to put some concrete in the set of API to prevent developers from using them :s. While I understand the final keyword can be useful sometimes, I really don’t understand why they used it as proficiently and - as it looks to me - as stupidly. I’m strongly convinced developing a solid but yet extensible framework is possible - the Android SDK is a great example of it - and that’s not the approach Google took here.

Finally, there are some strong lacks such as the un-ability to be notified of user location change when using the default LocationSource or to be notified precisely of a CameraPosition change.

Okay so now we are done with the API, I will continue with the implementation. In order to efficiently test the new Google Maps API v2 framework, I decided to make the switch in AVélov. Put simply, the app consists on displaying a map with a bunch of markers. When you click on it you have an info window that pops out and shows the name/address of the station and starts an asynchronous request to query the current number of bikes/slots for this station. Once the query is done, the popup is updated with the availabilty data.

Let’s be honest this application is pretty simple. Well I guess it was too simple because I ended up with a lot of bugs and limitations. Indeed, while it bring some amazingly great improvements, it cruely lacks of polish and pixel-perfect-ness. This article is not intended to be a bug-tracker but here are the main issues I had/have:

• Issue #4639: Black screen when instantiating a SupportMapFragment
• Issue #4645: Info windows are not refreshed when updated
• Issue #4666: Info window displayed in two parts with a 1px wide transparent gap
• Issue #4667: Blurry markers

In a nutshell, I really consider this new Google Maps Android API v2 as a beta version. I spent a lot of time and energy working with it and finally realized I had done all of this for nothing. I am now waiting for all of these bugs to be fixed. From my point of view, I seriously consider this new Google Maps Android API v2 shouldn’t have been released at all or alternatively, should have been released as the Google Maps Android API v2 beta. It clearly doesn’t respect my motto: Do less but do it great.

I spent the last 5 days being both joyful and unbelievably mad at the same time. I couldn’t resign myself publishing a version of my app which quality was lower than the current available version. While Google Maps API v2 brings several major improvements, it also carries a lot of issues, bugs and limitations. Always keep that in mind when starting using it or you’ll end up as disappointed as I was.

Over the past year, the ActionBar paradigm has become an essential component in the process of designing and developing an Android application. Indeed, the ActionBar has many advantages that help developers in future-proofing their apps. It contains contextual actions, can be customized fairly easily, is highly scalable, etc. Because of this, one should ALWAYS consider using the ActionBar UI pattern in one’s design process when creating a new Android app.

ActionBar features a lot of interesting styling APIs. These APIs let you brand your application so that it fits your design, while still being recognizable among other applications. Put simply, there are almost no limits to what you can do with an ActionBar. Until you try doing something more advanced …

Back in March 2012, I was in the process of designing AVélov, I really wanted to have an ActionBar that differentiated it from the other apps. So I came up with the idea of having an animated ActionBar background. AVélov being about bikes, I logically wanted the animation to be in relation with bikes (a bike riding from the left edge of the screen to the right screen, a spinning wheel, etc.).

In order to make sure this was possible I created a tiny app with an ActionBar. I rapidly built an AnimationDrawable, started it with a simple call to the start() method and used it as the ActionBar’s background. The result was pretty disappointing because it wasn’t animating at all. Exploring ActionBarContainer (a non-public View backing the ActionBar) source code I noticed it wasn’t registering a callback¹ to my Drawable:

1
2
3
4

public void setPrimaryBackground(Drawable bg) {
    mBackground = bg;
    invalidate();
}

As a result, the Drawable had no way to notify the enclosing View to redraw itself at fixed time intervals. From my point of view this was a wanted behavior to avoid these web-of-the-90’s-red-to-yellow-blinking ActionBars. I finally decided to postpone the animation to a future release.

Recently I came back to this feature/enhancement and started developing a new Animatable Drawable for testing purposes. This very basic Drawable changes its color and animates the changes in a smooth fashion:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

public class ColorAnimationDrawable extends Drawable implements Animatable {

    private static final long FRAME_DURATION = 1000 / 60;
    private static final long ANIMATION_DURATION = 1500;

    private static final int ACCCENT_COLOR = 0x33FFFFFF;
    private static final int DIM_COLOR = 0x33000000;

    private static final Random mRandom = new Random();

    private final Paint mPaint = new Paint();

    private boolean mIsRunning;

    private int mStartColor;
    private int mEndColor;
    private int mCurrentColor;

    private long mStartTime;

    @Override
    public void draw(Canvas canvas) {
        final Rect bounds = getBounds();

        mPaint.setColor(mCurrentColor);
        canvas.drawRect(bounds, mPaint);

        mPaint.setColor(ACCCENT_COLOR);
        canvas.drawRect(bounds.left, bounds.top, bounds.right, bounds.top + 1, mPaint);

        mPaint.setColor(DIM_COLOR);
        canvas.drawRect(bounds.left, bounds.bottom - 2, bounds.right, bounds.bottom, mPaint);
    }

    @Override
    public void setAlpha(int alpha) {
        oops("setAlpha(int)");
    }

    @Override
    public void setColorFilter(ColorFilter cf) {
        oops("setColorFilter(ColorFilter)");
    }

    @Override
    public int getOpacity() {
        return PixelFormat.TRANSPARENT;
    }

    @Override
    public void start() {
        if (!isRunning()) {
            mIsRunning = true;

            mStartTime = AnimationUtils.currentAnimationTimeMillis();
            mStartColor = randomColor();
            mEndColor = randomColor();

            scheduleSelf(mUpdater, SystemClock.uptimeMillis() + FRAME_DURATION);
            invalidateSelf();
        }
    }

    @Override
    public void stop() {
        if (isRunning()) {
            unscheduleSelf(mUpdater);
            mIsRunning = false;
        }
    }

    @Override
    public boolean isRunning() {
        return mIsRunning;
    }

    private void oops(String message) {
        throw new UnsupportedOperationException("ColorAnimationDrawable doesn't support " + message);
    }

    private static int randomColor() {
        return mRandom.nextInt() & 0x00FFFFFF;
    }

    private static int evaluate(float fraction, int startValue, int endValue) {
        return (int) (startValue + fraction * (endValue - startValue));
    }

    private final Runnable mUpdater = new Runnable() {
        @Override
        public void run() {
            long now = AnimationUtils.currentAnimationTimeMillis();
            long duration = now - mStartTime;
            if (duration >= ANIMATION_DURATION) {
                mStartColor = mEndColor;
                mEndColor = randomColor();
                mStartTime = now;
                mCurrentColor = mStartColor;
            } else {
                float fraction = duration / (float) ANIMATION_DURATION;
                //@formatter:off
                mCurrentColor = Color.rgb(
                        evaluate(fraction, Color.red(mStartColor), Color.red(mEndColor)),     // red
                        evaluate(fraction, Color.green(mStartColor), Color.green(mEndColor)), // green
                        evaluate(fraction, Color.blue(mStartColor), Color.blue(mEndColor)));  // blue
                //@formatter:on
            }
            scheduleSelf(mUpdater, SystemClock.uptimeMillis() + FRAME_DURATION);
            invalidateSelf();
        }
    };
}

I think the only interesting thing in this code is the method used to animate a color change. It consists of extracting each color component and animating these values and not the entire color.

I applied this Drawable to my ActionBar and boooom it was working! I was quite surprised and starting to investigate. After looking at the AOSP source code for the Jelly Bean MR1 release, I noticed the issue had been fixed by Adam Powell (an engineer at Google working on the UI toolkit) with a7cc06d. The code is now as described below:

1
2
3
4
5
6
7
8
9
10
11
12
13

public void setPrimaryBackground(Drawable bg) {
    if (mBackground != null) {
        mBackground.setCallback(null);
        unscheduleDrawable(mBackground);
    }
    mBackground = bg;
    if (bg != null) {
        bg.setCallback(this);
    }
    setWillNotDraw(mIsSplit ? mSplitBackground == null :
            mBackground == null && mStackedBackground == null);
    invalidate();
}

The problem with this fix is it wasn’t available for pre-API 17 builds. So I came up with a pretty simple solution for pre-API 17: registering a custom Drawable.Callback and invalidating the ActionBarContainer repeatedly setting the same Drawable with the ActionBar’s setBackgroundDrawable(Drawable) method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

public class MainActivity extends Activity {

    private final Handler mHandler = new Handler();
    private ColorAnimationDrawable mActionBarBackground;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main_activity);

        mActionBarBackground = new ColorAnimationDrawable();
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
            mActionBarBackground.setCallback(mDrawableCallback);
        } else {
            getActionBar().setBackgroundDrawable(mActionBarBackground);
        }
        mActionBarBackground.start();
    }

    @Override
    protected void onResume() {
        super.onResume();
        mActionBarBackground.start();
    }

    @Override
    protected void onPause() {
        super.onPause();
        mActionBarBackground.stop();
    }

    private Drawable.Callback mDrawableCallback = new Drawable.Callback() {
        @Override
        public void invalidateDrawable(Drawable who) {
            getActionBar().setBackgroundDrawable(who);
        }

        @Override
        public void scheduleDrawable(Drawable who, Runnable what, long when) {
            mHandler.postAtTime(what, when);
        }

        @Override
        public void unscheduleDrawable(Drawable who, Runnable what) {
            mHandler.removeCallbacks(what);
        }
    };

}

Thanks to this trick, you can now animate your ActionBar’s background back to API 11 but please keep in mind this may have several and sometimes serious consequences on your application:

• It can make your application look different and more polished by featuring tiny, subtle and nice details

• When setting an animated background to an ActionBar, always make sure it is as subtle as possible. Animations should not distract or interrupt the user in his/her interactions with your app. For instance you could run the animation only when the user is not touching your Activity.

• Using the technique described in this article forces the system to invalidate the whole ActionBarContainer for each animation frame. Reduce the duration of your animation as much as possible as it can be CPU & GPU consuming

• The animated background Drawable should not be something essential to your app. Drawable should only be considered as styling component and not interaction components.

1. I could write an entire book chapter about the Drawable notion. Put simple, when setting a Drawable as a View background, the View registers itself as the Drawable’s callback. This let the Drawable invalidate the View it is attached to. In other words, it lets you create Drawables that can refresh/redraw themselves. Android experts will also say it lets you easily leak Contexts when keeping a static reference to a Drawable.

I am pleased to announce Polaris: a brand new map library that completely rethinks the way you use MapView in your application. Polaris’ philosophy is based on 3 main rules:

• Make the user’s life easier
• Make the developer’s life easier
• Make the resulting map look polished and natural

Prior to giving you some details about the library and what it can do, here are all of the resources you can use to download and test the library:

• Library: github.com/cyrilmottier/Polaris
• Sample app: PolarisSample on Google Play

In practice, the Polaris library is an extension of the Google Maps External Library that fills some important gaps. For instance, it provides a lot of amazingly useful and powerful additions to the regular MapView. Here is a short (but still incomplete) list of some of the features supported by the Polaris library:

Gesture support

One of the major drawbacks of MapView is the lack of support for basic gestures such as the well-known double tap to zoom. Not providing developers with a gestures-enabled map reduces consistency among map-based application. Users usually expect all MapView to supply at least the exact same set of gestures regardless of the application being used. As a consequence, having MapViews not recognizing the gestures supported by the built-in Maps application can greatly frustrate users.

Polaris automatically handles essential gestures. The list below gives you an exhaustive catalogue of the available gestures as of version 1.0:

• Single tap on map: opens, if necessary, the callout associated to the tapped marker
• Double tap on map: zooms in focusing on the tapped location
• Long press on map: does nothing by default. Clients may assign a OnMapViewLongClickListener to the PolarisMapView to be notified of long presses
• Double tap on map callout: zooms in and pans to the maximum level of detail available

Effortless map annotating

PolarisMapView drastically simplifies addition of markers to a MapView by getting rid of the ItemizedOverlay (at least from a developer point of view) and introducing Annotations. Annotation is an extension of OverlayItem containing map-related information such as coordinates of a point, a title, a snippet and an optional marker Drawable. Annotating a PolarisMapView consists on building a list of Annotations and adding it to the map with the setAnnotations(List, int) or setAnnotations(List, Drawable) method. To sum up it only requires a few lines of code to annotate your map:

1
2
3
4
5
6

// Create a new list of Annotations
List<annotation> annotations = new ArrayList<annotation>();
annotations.add(new Annotation(new GeoPoint(), "Paris", "The city of love"));

// Set the Annotations to the PolarisMapView
mPolarisMapView.setAnnotations(annotations, R.drawable.default_marker);

One of the main advantage of using Annotations over OverlayItem is map callouts are automatically managed for you. Indeed, out of the box, the OverlayItem contains two Strings: a title and a snippet. Unfortunately, no matter how hard you search into the documentation, you will notice these Strings are never ever used! PolarisMapView automatically displays a map callout when the underlying annotation is tapped which makes map annotating insanely easy.

Map callout variable anchor positioning

Most (or should I say all) map-based applications uses 9-patches as map callout backgrounds. While 9-patches are great in most cases, they don’t allow variable stretching of the stretchable areas. As a consequence, it is not possible to make a map callout which positions an arrow depending on the position of the point of interest. Polaris includes a MapCalloutDrawable which allows variable positioning of the anchor.

This improvement is largely used by the Polaris library to get a more polished map. Indeed, while third-party applications usually center the map on the tapped OverlayItem, and the Maps app scrolls to make the callout entirely visible, PolarisMapView shows map callouts trying to reduce map scrolls as much as possible.

Built-in “user tracking” mode

In order to track the user location, The Google Maps external library provides a dedicated Overlay call MyLocationOverlay. This overlay displays a tiny blinking blue dot surrounding by a translucent blue disc describing the accuracy of the fix. Unfortunately, this Overlay is just an indication of the user location. There absolutely is no way to interact with it. PolarisMapView greatly enhances, while still simplifing, user tracking. With only one call to setUserTrackingEnabled(true), the Polaris library starts tracking the user location and displays a button similar to the one in the Maps application. When clicked this button centers the map on the user’s location.

Automatic built-in zoom controls

Android can run on a large diversity of devices. Nowadays, the vast majority of these devices support multi-touch gestures. However, there are still some others that don’t (especially lower-end devices). PolarisMapView seamlessly displays zoom controls only when required. It relieves the developer of the burden of checking the hardware capabilities of the device while maximizing the visible portion of the map on modern devices by hiding useless controls.

Natural map callouts transitions

PolarisMapView animates all transitions when showing and/or dismissing map callouts. Making a demonstration of the animation in a blog post is obviously not possible so I highly suggest to you to look at the PolarisSample app. Animated transitions results in a more natural and more polished map callout rendering.

Additional listeners

The default Google Maps External Library is cruelly lacking of listeners notifying the developer when the current state of the map has changed. For instance, there is no way to listen to changes on the visible region of the map (i.e. when the map has been zoomed and/or panned). Polaris includes additional listeners such as the OnRegionChangedListener. It can be particularly useful in order to lazy load annotations depending on the currently visible region.

As you can easily imagine, PolarisMapView relies on MapView while trying to be as transparent as possible. As a consequence, PolarisMapView offers the exact same features MapView offers and also suffers from some bugs related to the Google Maps external library. However there is a limitation when adding Overlays to the PolarisMapView. You must not use the getOverlays() method in MapView¹ and use the addOverlay(Overlay), removeOverlay(Overlay) and similar methods instead. Moreover, you need to bind the onStart() and onStop() to your MapActivity equivalents. These methods are necessary to notify the PolarisMapView of the MapActivity lifecycle.

I really hope you will love the features and principles introduced in this first version of the Polaris library. Please keep in mind, you can obvisouly use it in your projects but you can also help the project submitting pull requests on GitHub. If you release an app that uses Polaris I would love to hear about it. Please contact me via Twitter, Google+, or email.

Thanks to @franklinharper for reading drafts of this and Marie Schweiz for designing the Polaris icon

1. There is no way to by-pass this limitation due to the fact MapView makes the getOverlays() final.

As you can imagine, AVélov heavily rely on the Google Maps External Library. This library lets you easily add mapping capabilities to your application. Unfortunately it is far from being perfect. It doesn’t support vector graphics, you can’t use the new animation framework to create custom map animations, you can’t have several MapActivity per process, MapActivity can contain one and only one MapView, MapView instantiation outside of a MapActivity is impossible, MapView doesn’t support some fundamental gestures such as “double tap to zoom”, MapView zooming gestures are completely buggy sometimes, etc. In other terms, the current Google Maps Android framework is far from what we could expect from a world-class mapping actor like Google.

Google not releasing a new version of the Google Maps framework was the biggest disappointment I had at Google I/O this year. This framework hasn’t been updated for years and is now pretty outdated. But there is a good news. Lots of developers at Google I/O asked what Google was doing to solve that issue. The answer was pretty simple and straightforward but also so vague at the same time: “We are working on it!”.

Another annoying flaw of the Google Maps External Library is the lack of default resources. Let’s imagine you want to add pins and bubbles to your map - which is what you want to do 99% of the time - you’ll have to create graphics resources from scratch. Providing default resources helps developers with no particular design-skills to create nice-looking maps and improve design consistency through applications.

As a consequence, while working on AVélov, I recreated the latest1 official Google Maps main screen. I made it using the xhdpi density so that you can easily downscale it to the appropriate density.

I also spent some time ensuring the resulting PSD contains only vector-based elements and is sensibly layered, named and grouped. In other words, the PSDs provided in this post respects a certain hygiene, all of your mobile-design-dedicated PSDs should respect.

The PSD below have been created with Photoshop CS6 but should work properly with all recent versions of CS. Also note the following resources are licensed under the CC BY 3.0:

Google Maps Assets PSD

I really hope you’ll find this PSD useful in your MapView-based applications.

1The latest release of Google Maps have tweaked bubbles. Previous releases were based on rounded corners while they have now been squared. AVélov 1.0.1 contains the old version of the bubbles but will soon take advantage of the resources provided in this article as well as a MapView-related framework I’ve been working on. And yep, you can consider this spoiler as a teaser to an incoming new library.

In a previous article of mine I explained how important it is to create stunning and pixel-perfect screenshots. I gave several Photoshop resources you can use to create professional looking screenshots. Unfortunately, the pack had a lack of landscape resources. I am proud to tell you I have fixed this mistake and I am sharing the new resources to you. Here is the new zip file containing all of the PSDs:

Android Screenshots Assets

The zip above contains four PSDs you can use to create professional looking Android screenshots:

• Device framed screenshot

  • Landscape: android_device_frame_land.psd
  • Portrait: android_device_frame_port.psd

• Basic screenshot

  • Landscape: android_screenshot_land.psd
  • Portrait: android_screenshot_port.psd

In order to follow the adage “A picture is worth a thousand words”, you will find below some sample screenshots generated using the resources:

All of the resources given in this post are available under the Creative Commons BY 3.0 license. Feel free to use these PSD wherever and whenever you want to demonstrate and promote your applications in blogs, social networks, newsletters and conferences!

• The making of Prixing #1: Fly-in app menu
• The making of Prixing #2: Swiping the fly-in app menu
• The making of Prixing #3: Polishing the sliding app menu

This time, I would like to talk about the way we’ve managed notifications in Prixing 3.0. Indeed, Prixing for Android is a rather complex application containing tons of screens. Each of these screens can notify the user about something important: an error occurred while connecting to the server, you earned a new badge, the query you typed is too short, etc. By default, Android provides two great ways to notify the user without blocking: status bar notifications and Toasts. The first is dedicated to notifications happening outside of the application while the latter is for in-app notifications. Simply put, a Toast is a non intrusive and non touchable notification that is always displayed on top of your application’s screens.

From my point of view, this class is amazing. I really love it and that’s probably one of the reason why I am getting so frustrated when developing on iOS. Indeed, the platform made by Apple has no equivalent by default. Developers generally use a UIAlertView (iOS AlertDialog equivalent) which is extremely annoying to the user as it completely blocks the user flow as long as one of the “Cancel” or “OK” buttons hasn’t been pressed. As a consequence, iOS developers tend to notify the user via in-layout notifications. It is not consistent throughout iOS apps but the usability gain definitely worth it. Toast makes unobstrusive notifications amazingly easy as you can create new instances from everywhere as long as you have a reference to a Context (Service, Activity, BroadcastReceiver’s onReceive method, etc.).

Unfortunately, Toast is far from being perfect and I am not entirely satisfied with it. Toast can be un-accurate in some cases. Indeed, Toast has one major drawback: it completely breaks contexts. This issue can be reproduced effortless. Let’s say a user is currently in an app firing a Toast and wants to switch to another application using the dedicated “multitask” button. The Toast will remain on screen even if the brought-to-front application has nothing do to with the previously shown app as described on the following figure:

Sample of a user flow in which Toast fails

As you can easily notice, the problem with Toasts is they are persistent1. Once a Toast has been fired, it is displayed on top of any screen and remains visible for the duration specified at its creation.

Information is always context-related

When designing and developing an app, you always have to spend a lot of time thinking about contexts. Contexts are insanely important as they define the space/time frame an information can live in. Exposing information in the wrong context will make your UI incomprehensive and will radically degrade your users’ experience. Can you imagine Google announcing a new Android version in the middle of the annual world dental congress? I guess and hope your anwser is no. This example clearly demonstrates information and context are close and depend on each other.

As of this logic, Prixing currently features 3 main contexts:

• The application context is where images and network data live in. All of this information is not tied to a particular screen or widget and are shared among all Prixing’s screens.
• The Activity context contains the information belonging to a screen (profile, nearby stores, products list, etc.).
• The application menu context: Introduced by the fly-in app menu, the application menu context describes the entire app navigation. It is completely independent from the two previous contexts.2

In order to bypass the Toast persistence problem and ensure information is displayed in the correct context, we decided to create a new notification system in Prixing: Activity-bound notifications. In reference to the Toast class and to my French culture I decided to name it a Crouton (if you don’t know what a Crouton is go to this Wikipedia page). This is what it looks like in the current version of Prixing:

Crouton overcomes the main issue of having a Toast being shown while the menu is open. It sticks to the current screen sliding with it and leaving the menu completely free of any information that would have not been related to it.

Introducing the Crouton API

The Android framework lets you interact with the Toast class via a very simple API. You usually only need a single line of code to create and show a notification. We wanted Crouton to be at least as easy to use as the Toast class so we engineered an insanely simple API:

• Public Constants
  • int STYLE_ALERT: Show the text notification for a long period of time with a negative style.
  • int STYLE_CONFIRM: Show the text notification for a short period of time with a positive style.
  • int STYLE_INFO: Show the text notification for a short period of time with a neutral style.
• Public Methods
  • static Crouton makeText(PrixingActivity prixingActivity, CharSequence text, int style): Make a Crouton with the given text and style.
  • static Crouton makeText(PrixingActivity prixingActivity, int resId, int style): Make a Crouton with the given text (extracted from the resource identifier) and style.
  • void show(): Show the view with the specified style.

Yes, you’re right! No visible constructors, just 2 static factory methods, a public method and 3 constants. The two main differences with Toast are you always need a PrixingActivity instead of a Context and the third parameter isn’t the duration but the style of the notification.

Contrary to the Toast class, Crouton automatically computes the duration of the notification depending on the style. Pretty logically, we decided an alert notification had to be visible for a larger amount of time than a confirmation or neutral information. People usually spend more time on understanding an issue than a validation message. As a result, we decided to use 3000 milliseconds instead of 1300 milliseconds.

Crouton handles multiple notifications fired at the same time just like Toast does. In order to do so, it stacks Croutons in a queue if another instance is currently being displayed. This makes sure no notification is lost as long as the user remains on the emitting Activity

Implementing in-layout notifications

The Android framework contains several classes inheriting from Activity. Each of this Activity-subclasses can be used to manage particular components. For instance, ListActivity manages a ListView, FragmentActivity manages Fragments and Loaders, MapActivity manages MapView, etc. All of these subclasses may look helpful for developers but they can also be a pain in the ass when engineering a rather large project. Java not allowing multiple inheritance and not supporting categories/extension methods (yet?) makes it pretty boring and tedious to add features to Activity-subclasses. As a direct consequence, trying to have a consistent layout in your Activity is hard. So here is a tiny advice to you: always favor composition over inheritance in your projects.

To overcome this issue, all Prixing Activity implements an interface called PrixingActivity. Roughly speaking, PrixingActivity manages several Activity-based behaviors and ensures the Activity root layout is as follows:

As described on the previous figure, a PrixingActivity always contains a TextView which is laid out by our custom TitleBarHost in a way it is above the TitleBar (custom implementation of the ActionBar) and slides down when the notification needs to be shown.

To have consistent and smooth animations, we used the same interpolator introduced in the first part of this serie when showing/hiding a Crouton: the SmoothInterpolator.

Finally, some of you may wonder why the notification is not lazily created/inflated thanks to a ViewStub. Crouton currently relies on a single TextView. Using a ViewStub is clearly not a performance boost in this case as the final View hierarchy is small. Keep in mind a ViewStub remains a View. As a result, using a ViewStub would have resulted in inflating 1-min or 2-max View. The method used in Prixing ensures only a single TextView is inflated. If you really care about not creating a TextView that is often never used, you can lazy-create it the first time it is requested.

In-layout notifications may not be perfect but they can solve lots of UI/UX problems. Implementing such a mechanism in Prixing made the application easier to use and more logical. The fly-in app menu clearly outlined some of the major drawbacks of the Toast, Crouton solved. Don’t use Toast blindly, think about your application’s context and the information you need to display. In other words: leave the engineering mindset aside and start thinking like a real user.

Thanks to @franklinharper for reading drafts of this.

1. A Toast is actually theoritacally persistent if and only if you don’t call Toast#cancel(). In practice, nobody keeps a reference on the fired Toast, the Toast#cancel() documentation clearly states it shouldn’t be used and, last but not least, the current Toast#cancel() implementation contains a magnificent // TODO annotation informing the method is not complete:

    // TODO this still needs to cancel the inflight notification if any
   

2. Contexts are everything! This is I why I believe an ActionBar has to slide with the content when using a fly-in app menu. An ActionBar should only be used to describe the current screen/Activity context. As a result it has nothing to do with the application menu. The current version of Prixing, Google+, Spotify, etc. have it right while some others such as Youtube have it wrong in my opinion.

Let’s start this article with a quote I love from John Wooden, a former basketball player and coach. Reading the following lines, you will easily notice this quote perfectly fits this article’s subject:

It’s the little details that are vital.
Little things make big things happen.

Last week, I spent three amazing days at the Moscone Center in San Francisco, CA for the Google IO. Let’s be honest, this conference is clearly one of the best I have participated in so far. I saw insanely great sessions about various subjects and met very interesting people from Google or other well-known international companies. This year, Google IO focused on mobile and especially Android. As a result, keynotes and sessions was using a lot of images from mobile devices. Unfortunately, as a perfectionist, I was pretty disappointed about some of the graphics. Indeed, a lot of them were untidy, non professional, draft-looking, etc. The worst examples of this happened during the Google+ keynote. It featured some screenshots in which the screen glare was only visible on the device and not on the screenshot itself. I also saw an iPhone in which the screenshot of the application had been applied directly on top of the launcher app. This resulted in a translucent status bar with the background of the launcher which is obviously impossible in real life.

I recently decided to visit the new Nexus website and discovered some similar issues that could have been easily solved. Here are some of them:

• The time displayed on screen is different from the one in the status bar. I guess this is because the designer reused graphics from the ICS release and only changed the status bar. Unfortunately, this huge mistake transforms Android to a crappy platform that can’t even display the current time correctly

• The disrupted/missing screen glare is probably one of the biggest mistakes I am used to seeing out there. Compared to the previous picture, this screenshot is far from looking professional. It gives the impression the screenshot has been glued to the device frame. There’s is also a more-difficult-to-notice issue on the status bar as it is smaller than it should. I seriously believe the designer used a screenshot from a Nexus 7 tablet and applied it to the Galaxy Nexus thinking nobody would notice the difference between 800x1280 and 720x1280.

• Blurry screenshots waste your product. Be careful when resizing an image and ensure the resize algorithm you use makes the final graphics crisp and sharp. Moreover, the background they used indicate a Jelly Bean release while the displayed time is at 4:00 (ICS). Try to remain logical: if you decided to change the displayed time then follow your own rules and stick to them.

Lots of people think of me as a mobile developer but I am also a huge fan of pixel perfect graphics and applications. As a result I spend at least 15% of my time working on software like Photoshop or Illustrator. I am strongly convinced being a developer doesn’t mean you can’t like great things. As a developer you are not supposed to do your designer’s work but should be multi-skilled enough to handle situations where some design tasks are required. For example, it may be quite handy sometimes to know how to create resources to create a Button or style the background of your ActionBar.

Taking care of the resources you make public is extremely important as it reflects you and your product. When managing a product you always have to have a fine-grained control over the information you release. Screenshots are particularly important as they can carry tons of information. As a developer, you can think of releasing graphic resources as releasing a new API: everything that has been made public is visible and usable by everybody. You will have no opportunity to change it in the future without breaking what has been built on top. Moreover, using inappropriate graphic resources may completely make your product presentation pointless. One of the best recent example I have in mind is the announcement of the existence of the Higgs boson. The CERN team decided to use the Comic Sans MS font on web-from-the-90s-looking slides (cf The Verge). From my point of view, the poor quality of the presentation (obviously I am not talking about the content of the presentation itself) totally ruined the actual revelation of the announcement. People almost talked more about how crappy the slides were instead of the amazing announcement of the Higgs boson existence:

Here is some advice I gathered to create professional-looking graphic assets:

• Always ensure your screenshots are consistent: Just like you love to have a cohesive environment on your desktop, at home or at work, people appreciate consistency in marketing pictures. As a result, taking screenshots with the same version of your app and Android platform in the best guarantee your users won’t be jostled.

• Create physically accurate screenshots: When modifying the content of your screenshots always make sure the resulting image is physically “doable”. For instance, if you modify the time in the status bar, make sure the alarm widget is also modified. The other common issue occurs when using a screen glare as I described earlier. The image you show must be something the user can see in the real world.

• Apply the exact same status bar on all of your screenshots: Android status bars have changed quite a lot over time. It was grey with black information on Android 1.6, switched to black with green and gray information on Gingerbread and finally switched to black with blue/grey information on Honeycomb. When releasing screenshots always try to reuse the same status bar, preferably the latest version of it.

• Have clear and clean status bar icons: You generally don’t want your users to be distracted by a large set of status bar icons. Make them focus on the actual content of your application by removing all un-necessary icons (notification icons, alarm, silent mode, etc.). Also use completely filled up icons for fillable icons: battery, reception, etc.

• Override the current time: Releasing a graphic indicating a screenshot was taken at 2AM in clearly not professional. It may indicate you rushed to finalize the application. Use a smart and ingenious time and stick to it! For instance Google, with the Galaxy Nexus uses the version of latest platform: 4:00 for Ice Cream Sandwich and 4:10 for Jelly Bean. Apple generally uses 9:41, the time at which products such as the iPhone or the iPad are likely to be introduced.

• Always use the same device frame: If you have decided to base your graphics on the latest Google Android devices then stick to it. Using different device frames may make people think they are looking at different apps running on different hardware. It is usually a good idea to increase consistency by associating your app to a single Android device.

• Enforce branding if needed: You may add icons to ensure your screenshots are personalized but if you do so, make sure the result is Android compliant. For instance, you may add a notification icon in the status bar. When doing so, always ensure your icons follow the guidelines as described on the Android website.

• Use screen glare cleverly: Keep in mind, screen glares are not appropriate on screen-only screenshots. They are usually used in addition to a device frame.

That’s a lot of rules, isn’t it? Fortunately, some tools and resources do exist to help you. Roman Nurik’s Android device frame generator lets you easily create device-framed screenshots with a simple drag and drop gesture. Roman’s generator is awesome. However, the simplicity of this tool makes it also less powerful than Photoshop. Personally I don’t use the Android device frame generator for various reasons: drop shadow too strong - especially on white background, missing device reflection, un-optimized exported PNG, no status bar standardization, etc.

Below are the PSDs I made and use for my own screenshots. These files have been created in Photoshop CS6 but should work properly with all recent versions of CS. Also note the following resources are licensed under the CC BY 3.0:

Android Screenshots Assets

The PSDs above are very simple to use and will help you to generate graphic resources in a few steps:

1. Open the appropriate PSD and the screenshot in Photoshop
2. Copy the entire source screenshot (⌘A and ⌘V)
3. Open the “Smart Object” (double click) and paste the source image (⌘V)
4. Save and close the “Smart Object” (⌘S and ⌘W)
5. Export the result for the web using the Photoshop optimizer (⌥⇧⌘S)

I know Photoshop may be quite difficult to apprehend so I made a small demonstration video in which the few steps are explained in details.

Carefully spreading your work on the Internet is extremely important. It shows how great your product is and the amount of attention you gave while designing it. The more care you give to the screenshots, the more you’ll say to your audience you brought care to your application, its features, its design, etc. I’m not a marketing guy but I can say that consumers are very impacted by the way things are presented. Be consistent, look carefully at the details, control what you are spreading in the outside world.

API 16 is clearly a minor update. If you look attentively to the API diff documentation, you will notice there has been just a few packages, classes and methods added. However, being a minor update doesn’t mean it is useless. Indeed, what I particularly appreciate about this release is it makes the API more consistent and clearer. Google obviously spent some time making the API more logical and hence easier to understand and use. The list below gives you a set of changes that brings uniformity and clearness to the framework.

• From non-final to final: Prior API 16, View Property such as ALPHA, or ROTATION_X were not final. This was obviously a huge mistake because these properties was not intended to be modified (see my Google+ post). When I noticed it, I warned some of the framework engineers and I’m glad to see they fixed it even if it may break some applications.

• Methods renaming: In order to always have consistency between getters and setters, some methods have been renamed. For instance, setAlpha(int) on ImageView is now setImageAlpha(int).

• Added getter and setter: Prior API 16, it was sometimes impossible to do things in Java while it was completely possible from XML. For example, the size of a scrollbar wasn’t modifiable from Java but it was from XML. Some getters/setters have also been added to ensure all View attributes have a setter and its getter counterpart. In general, you can now set and get all attributes from a widget (ie object that extends View)

• Deprecation of some classes: There has been a lot of criticism on the fact Renderscript rendering pipeline is now deprecated. I actually think Google made a mistake not informing developers that the graphic part of Renderscript was experimental at the first release. However, some widgets such as the Gallery are now deprecated and I think that’s a really good point. I really believe advanced widgets like the Gallery are not supposed to exist in the framework. For my point of view, a framework is not supposed to provide everything a developer need. It has to provide very simple but powerful APIs that let you, developers, create whatever you want whenever you want. A simple framework is easier to apprehend and understand and relieves Google of maintaining a too large/complex API. This deprecation (deprecation doesn’t mean it has been removed) is a good start and I hope Google will continue to remove/depreciate classes that should never has been there.¹

While reading the entire API differences, I’ve also discovered several interesting changes:

• A new display density has been introduced: DENSITY_XXHIGH which corresponds to 480 pixels per inch. It clearly demonstrates Google is thinking about Android in a long-term manner and starts to prepare the system to future screen densities. Personally I think this will be the last added density (no need to have a higher density on any device) but I can’t wait to see a Nexus device using it!

• LongSparseArray has been made public or more specifically unhidden (it has always been in the Android source code). SparseArray<E>s, SparseBooleanArray and SparseIntArray are really great to avoid auto-boxing/auto-unboxing problems in maps. Prior API 16, the LongSparseArray was hidden. As a result, it is now possible to have maps in which keys are longs. This make me believe, the pool API (PoolManager, Poolable, etc.) that lets you easily create a pool object mechanism may be unhidden some day…

• You can now synchronize your custom animations with the display vertical synchronization (vsync). This can be done using the Choreographer class directly or one of the new View methods (also available in the support library through the ViewCompat class): postOnAnimation(Runnable) and postInvalidateOnAnimation(). I applied it to my implementation of the fly-in app menu and I got to admit I love the result!

• ViewPropertyAnimator now includes 3 more methods making the animation framework crystal clear and easier to use. Indeed, you can know define a start and/or action directly from it via with[End|Start]Action(Runnable). The API also includes a new withLayer() method. Thanks to this method chaining feature, creating, applying properties and starting an animation has never been so simple.

• The WebView framework has also been updated because a new WebView.FindListener has been added. it lets you be notified as find-on-page operations progress. The outdated getZoomControls() method has also been completely removed. Here again, it brings clearness to the framework and remove redundancy (zoom controls can be disabled/enabled using WebSettings.setBuiltInZoomControls (boolean))

The minor Jelly Bean release clearly moves Android forward. I sincerely love the work Google has made on this release and hope they’ll continue to follow the path they’ve taken. Lots of developers may complain at first about the introduced changes and deprecations but this is for the good of Android. Google is preparing Android for the future. You, as a developer should stop complaining, get use to it and adapt yourself. Do not forget Android is now a 6 years-old system. Legacy is not something we can ignore.

1. My personal point of view about what a framework should be is also the explanation of why the fly-in app menu shouldn’t be part of the SDK. The Android SDK contains everything you need to create a stunning fly-in app menu. Stop asking Google integrating it in the SDK. That’s something that should be clearly done by Android developers and optionally by third-party libraries. From time to time I really believe Android developers are pretty lazy. They prefer spending time on begging Google to help them rather than actually developing. Look at the permissive and powerful framework, read the documentation, etc. You have the power of Android in your hands: you just have to use it!

• The making of Prixing #1: Fly-in app menu
• The making of Prixing #2: Swiping the fly-in app menu

This post will concentrate on making the UI widget more polished and will give the answer to the puzzle I gave in the conclusion of the previous post: “How to use the sliding menu between Activities by-passing the default transition”. Of course, I highly suggest you read the previous articles of the series as they were both dedicated to the fly-in app menu.

Note: As usual, all figures in this article are available in high definition by simply clicking on it.

Enforcing perspective with drop shadows

As shown in the figure below, the fly-in app menu draws a drop shadow on the left of the host - ie the content of the screen - when being dragged or opened. The drop shadow enforces the perspective giving the user the impression the host slides on top of the menu. It is also a way to indicate the content is primary while the menu is secondary.

Drawing a drop shadow can be done in a number of ways. For instance you can add an ImageView with a “shadow” image as background that will always be laid out on the left of the host. This is obviously possible but it is pretty heavy in term of memory-consumption and layout/drawing performance. The current implementation of the Prixing’s ribbon menu uses a GradientDrawable drawn manually in dispatchDraw(Canvas). This latter method can be used in your custom Views whenever you want to draw something manually before or after the children were drawn. In our case this is obviously done after. You may also add a tiny optimization that prevents the shadow from being drawn when it is not visible ie when the drawer is closed. Here is what the RootView’s dispatchDraw(Canvas) looks like.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Override
protected void dispatchDraw(Canvas canvas) {
    // Draw the children
    super.dispatchDraw(canvas);

    if (mState != MENU_CLOSED) {
        // The menu is not closed. That means we can potentially see the host
        // overlapping it. Let's add a tiny gradient to indicate the host is
        // sliding over the menu.
        canvas.save();
        canvas.translate(mHost.getLeft(), 0);
        mShadowDrawable.draw(canvas);
        canvas.restore();

        final int menuWidth = mMenu.getWidth();
        if (menuWidth != 0) {
            final float opennessRatio = (menuWidth - mHost.getLeft()) / (float) menuWidth;

            // We also draw an overlay over the menu indicating the menu is
            // in the process of being visible or invisible.
            onDrawMenuOverlay(canvas, opennessRatio);

            // Finally we draw an arrow indicating the feature we are
            // currently in
            onDrawMenuArrow(canvas, opennessRatio);
        }
    }
}

The interesting things happen on top of the menuWidth computation/caching line (we will focus on the rest of the source code afterwards). When overriding the dispatchDraw(Canvas) just call super.dispatchDraw(Canvas) to draw the children Views and put your extra code after this call. As shown, the GradientDrawable is drawn manually on the Canvas which is translated to the appropriate position using Canvas#translate(int, int). Do not forget to initialize the bounds of your Drawable using Drawable#setBounds(int, int, int, int) or Drawable#setBounds(Rect) prior to using it or you will end up pulling your hair out, or even crying, because nothing happens. And believe me, I know that it hurts a lot!

“Abracadabra” or how to make the menu dis(appear)

In order to emphasize the fact the menu is appearing or disappearing it is usually a good idea to add some nice effects. The stock launcher app on my Galaxy Nexus for instance uses a nice zooming and fading animation to indicate the next page is being visible/invisible. When designing the RootView, I wanted the effect to be subtle and more in a two-dimensional space (I am not a huge fan of 3D effects). Pretty naturally we decided to make the menu appear/disappear using a dimming and parallax effect as shown below:

The dimming effect is done pretty basically using the previously introduced dispatchDraw(Canvas) method. It consists of drawing a translucent black rectangle entirely covering the menu. The transparency of the rectangle is computed on the fly with a fairly straightforward linear formula. Please note that the MAXIMUM_MENU_ALPHA_OVERLAY constant is not 255 but 170. Indeed, using a fully opaque rectangle when starting to open the menu would likely result in having users seeing a black background. This obviously doesn’t help knowing a menu is lying down there. Always having a translucent rectangle is way better from a user perspective.

1
2
3
4
5
6
7
8
9
10

private static final int MAXIMUM_MENU_ALPHA_OVERLAY = 170;

private void onDrawMenuOverlay(Canvas canvas, float opennessRatio) {
    final Paint menuOverlayPaint = mMenuOverlayPaint;
    final int alpha = (int) (MAXIMUM_MENU_ALPHA_OVERLAY * opennessRatio);
    if (alpha > 0) {
        menuOverlayPaint.setColor(Color.argb(alpha, 0, 0, 0));
        canvas.drawRect(0, 0, mHost.getLeft(), getHeight(), mMenuOverlayPaint);
    }
}

If you have carefully read the first article of the series, you probably know how to implement the parallax effect. Indeed, in the first article of this series we talked about a method used to quickly offset a View: offsetLeftAndRight(int). Thanks to this method, it is possible to offset the menu from a value depending on the current openness ratio:

1
2
3
4
5
6
7
8
9

private static final float PARALLAX_SPEED_RATIO = 0.25f;

private void offsetMenu(int hostLeft) {
    final int menuWidth = mMenu.getWidth();
    if (menuWidth != 0) {
        final float opennessRatio = (menuWidth - hostLeft) / (float) menuWidth;
        mMenu.offsetLeftAndRight((int) (-opennessRatio * menuWidth * PARALLAX_SPEED_RATIO) - mMenu.getLeft());
    }
}

Indicating the selected application menu item

The Prixing application includes a lot of application features. Each of these features are normally represented by a single item in the application menu. In order to help the user understand where she is in the workflow, we decided to add an indicator on the current feature. In the application, the indicator is represented by a tiny arrow that keeps pointing to the feature as long as it is visible on screen. In the beginning, I thought about adding it to all of the itemviews composing the app menu and displaying it whenever necessary. Unfortunately, this would have caused several problems. First the drop shadow would have been drawn on top of the arrow, so we would have had some cases where the arrow is drawn next to the ActionBar which would be really ugly and it would have been impossible to make the arrow strech out/retract depending on the current openness of the menu. We really wanted to have a precise control over the arrow so we used a radically different approch: drawing the arrow manually in dispatchDraw(Canvas).

As attentive people may have noticed, the heavy work is done with the onDrawMenuArrow(Canvas, float) method. It first retrieves the bounds of the active View with getDrawing(Rect). At first, this method may look quite weird as its return type is void. getDrawing(Rect) is one of the rare methods in the Android framework returning the result directly in the passed argument. This is a trick that prevents creating several Rect instances for nothing. As a result, only a single instance can be created and reused over time. The main problem with the bounds returned by getDrawing(Rect) is that they are given in the active View’s parent coordinates space. Since we need to draw the arrow in the RootView’s dispatchDraw(Canvas) method, we need them in our coordinates space. Fortunately, the Android framework provides a utility method to offset the rectangle appropriately: offsetDescendantRectToMyCoords(View, Rect). The name of this method is rather long and mysterious, but it does the job! The resulting Rect lets us compute the position of the arrow on the Y-axis. The exact position of the arrow on the X-axis is determined depending on the given openness ratio - Prixing uses an AccelerateInterpolator to make the stretching out/retract effect less linear. Drawing the arrow on the Canvas is done pretty basically with a combination of Canvas#clipRect(int, int, int, int) and Canvas#drawBitmap(Bitmap, int, int, Paint)

Fly-in app menu usage 101

The RootView includes a nice feature that helps users to discover the hidden menu as well as the swipe capability. This feature called “menu hint” consists of animating the drawer as if it were bouncing the first time the user sees it. From my point of view, this is not the best option to teach the user the menu can be found below the host. Displaying the first Activity with an opened application menu which closes automatically after a given delay is probably better. We finally decided to go for the bouncing animation because we wanted the user to see the content of the application first. Now that you are familiar with Interpolators you can easily understand the PageHintInterpolator used by the RootView when the “menu hint” is enabled:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package fr.epicdream.android.prixing.view.animation;

import android.view.animation.BounceInterpolator;
import android.view.animation.DecelerateInterpolator;
import android.view.animation.Interpolator;

/**
 * A custom {@link Interpolator} reproducing the effect of an object thrown in
 * the air, starting to fall and bouncing at the end
 * 
 * @author Cyril Mottier
 */
public class PageHintInterpolator implements Interpolator {

    private Interpolator mDecelerateInterpolator = new DecelerateInterpolator();
    private Interpolator mBounceInterpolator = new BounceInterpolator();

    @Override
    public float getInterpolation(float t) {
        // The purpose of this is pretty simple :
        // - mDecelerateInterpolator for t < 0.33
        // - mBounceInterpolator for t >= 0.33
        if (t < 0.33) {
            return mDecelerateInterpolator.getInterpolation(t / 0.33f);
        } else {
            return 1f - mBounceInterpolator.getInterpolation((t - 0.33f) / 0.67f);
        }
    }

}

Using the fly-in app menu between Activities

Let’s conclude this article with the answer to a puzzle I gave at the end of the preceeding one: How to seemlessly open/close the RootView between Activitys. Indeed, when I started working at Prixing, I discovered an enormous existing code base mainly based on tons of Activitys. We wanted to release a radically different version quite rapidly so we had to deal with all the existing Activitys, rather than switching them to Fragments. As a result, we started thinking about a way to make the transition between Activitys as natural as possible, and rapidly came up with a simple idea: Faking that the current Activity hasn’t changed simply by applying the same state to the opened Activity.

The Activity transition in the Prixing application relies on the exact same technique the Android framework uses to restore an Activity after it has been destroyed in low memory conditions. As a result, everytime a new Activity needs to be opened, we save the the interesting part of the current UI state using View#onSaveInstanceState()/View#saveHierarchyState(SparseArray<Parcelable>) and re-apply it to the newly created Activity thanks to View#onRestoreInstanceState(Parcelable)/View#restoreHierarchyState(SparseArray<Parcelable>)

I have to admit this is a pretty advanced technique but it works pretty great. Of course I haven’t given all the details here to make it work perfectly, but I hope you understand the main idea. Behind the scene we had to develop a custom ScrollView that saves its current scrolling state for the menu. Indeed, it is impossible to save the ListView state at a pixel level in Android 2.1, and the framework’s ScrollView doesn’t save its scrolling position¹. Moreover, we implemented an OnLayoutListener-equivalent on our RootView to indicate that the menu close animation should be performed after the Activity has opened. Finally, since it is used on all Activitys, we worked hard on making the menu as light-weight as possible, flattening the View hierarchy and creating custom Views. For instance each feature in the menu is a made of a single AppMenuItemView which directly extends View and manages an icon, a title, a subtitle, an annotation and a divider.

Conclusion

That’s it! You now have all of the technical details to create stunning fly-in app menus. Some may say all of the tricks given in this post are just details but keep in mind details are what makes the difference. Details matter, so do not be afraid about spending a lot of time working on them. It will make your application better, more polished, more appreciated and hence more downloaded and used. I sincerely hope I have given all the tips and tricks required to reproduce all of the features that Prixing’s sliding menu has. If not, feel free to post a comment below and I will be pleased to answer your questions. I will surely continue revealing some Android UI development tricks we used while developing the third version of Prixing in future articles, so stay tuned!

Thanks to @franklinharper for reading drafts of this

1. Some of you may wonder “Why the hell is this not already managed by the Android ScrollView?”. That’s completely normal and here is the reason of it. Android is based on the idea that on a configuration change the content of a screen may change dramatically (for example the layout may be completely different). As a result, having a ScrollView in the portrait orientation doesn’t mean its height/content will be the same in the landscape orientation. Because of this it is not accurate to save and restore the current scrolling value by default.

In the first article we ended up creating a very basic fly-in app menu. Indeed, the widget we created was closable/openable only programmatically or using a simple click gesture. The latter obviously works like a charm but it has a cruel lack of naturalness and intuitiveness. Having a closing/opening animation of the host makes the user want to interact with the object as he/she would in the real world using a well known gesture: the swipe gesture.

Having a drawer the user can move precisely is the best way to make your UI feel like it is an extension of the real world. Have you ever played video games in which it is impossible to shoot a tree or move a basic object like a book? Pretty frustrating, isn’t it? Users usually hate being artificially blocked or unable to do something he/she wants to. UI development in general follows the exact same rule: Do not block your users, let them do whatever they want. The figure below shows some of the available gestures:

The purpose of this second article is to give you all the requirements you need to add the swipe gesture capability to your fly-in app menu. To be honest, the swipe gesture is far from being new. It is pretty natural to mobile (iOS, Android, Windows mobile, etc.) users. It has been spread so much it is now now available in lots of mobile applications nowadays. In Prixing, the main problem we had was to imbricate horizontally scrollable components (ViewPager, MapView, etc.) in another swipable component (the RootView). This obviously leads to a simple question: Which component has the right to intercept the gesture?1. The Android documentation gives a partial answer to this fundamental question: “You should never use a ScrollView with a ListView, since ListView takes care of its own scrolling.”. This is actually true but several ways to overcome the issue exist:

• No swiping: The easiest way to implement tricky things is not to implement them! As I like to say: if you don’t want to have trouble, stay at home and do nothing. The problem with this method is it makes your life boring. I am not this kind of guy.

• Smart swiping: This technique consists of first looking at the top-most (in the drawing order)View which wants to deal with the gesture. In this case, if the component can scroll horizontally in the direction of the swipe gesture, then let it scroll. If it has already reached its maximum position, let the scrollable container intercepts the gesture. This pattern is used in the latest version of GMail. Indeed, when browsing your emails, the ViewPager won’t scroll to the next page until the WebView has not scrolled to the edge. The main problem with this technique is it requires the canScrollHorizontally(int) method which is only available starting from API 14. Moreover you need to be able to determine the View that consumed the gesture (aka TouchTarget in the Android source code). I couldn’t find a public method allowing us to determine this View¹ and Prixing had to run on devices with Android 2.1+ so we decided to use another technique.

• Bezel swiping: This technique consists of intercepting a swipe gesture if and only if it starts near from the edge of the View. Bezel swiping is usually implemented looking at the position of the first gesture’s TouchEvent: the ACTION_DOWN. This is how Chrome for Android lets you navigate between your tabs. I don’t consider it as perfect because you may end up with some gesture mismatch but it makes your menu always accessible. In Prixing, we decided to go for it!

Handling touch events

The Android framework provides everything you need to handle touch events. The most important method is onTouchEvent(MotionEvent). It is called by the system when a MotionEvent (the class representing a touch event) occurred in your View. This is where you put the code that will make the host follow the user’s finger. Unfortunately, implementing onTouchEvent(MotionEvent) will not be enough as it may never be called by the system in case another View - deeper in the View hierarchy - consumes the touch event first. In order to be able to intercept the touch you will simply have to override onInterceptTouchEvent(MotionEvent) in your RootView. I strongly suggest you read the documentation of this method) as it has a fairly complicated interaction with onTouchEvent(MotionEvent)) If you are not familiar with the event dispatching system in Android you can have a look at the great “Mastering the Android Touch System” presentation Dave Smith - @devunwired - gave at AnDevCon III. I didn’t attend the talk, but looking at the slides and the source code clearly suggested to me that the talk was great.

Using platform-provided constants

If you look closely to the source code of some UI widgets included in the framework, you will see they use various constants. The vast majority of these constants can be easily retrieved thanks to the ViewConfiguration class. You should always use this class whenever you need to create your own UI widgets. In fact, the provided values have been widely tested by the Android team. For instance, we will later use the “touch slop” constant which describes the distance a touch can wander before we think the user is scrolling. This value is expressed in pixels and can be accessed via a call to getScaledTouchSlop(). Please note the static unscaled counter part method getTouchSlop() is deprecated and should never be used anymore as it doesn’t scale the constant to match the screen density.

If you really want to use your own dimensions, always remember to scale them appropriately to the current device. This will ensure your widgets will always behave the same regardless of the device they are running on. Dimension scaling can be done pretty easily relying on the resource system or manually using the code provided below:

1
2

final float density = getResources().getDisplayMetrics().density;
mScaledValue = (int) (UNSCALED_VALUE * density + 0.5f);

Note: The information given in this article never mentions multitouch capabilities. This may seem irrevelevant when dealing with a one-finger-only-gesture but this is not the case. Try sliding the host drawer and touching the screen with another finger and you will see it “jumps” from one finger to another. This strange behavior happens because the current implementation of the RootView in the Prixing application doesn’t take into account actions such as MotionEvent#ACTION_POINTER_[DOWN|UP]. That’s definitely something we have on our ToDo list. It just has a low priority compared to the thousands of other tasks.

When can a gesture be considered as a swipe?

The Prixing application uses two separate algorithms to determine if a swipe gesture has been started. Indeed, the swipe-to-open algorithm is a little bit more complicated than the swipe-to-close one. In order to get a complete understanding of how to implement such a gesture, we will mainly focus on the most technical one: the swipe-to-open gesture. The implementation involves several constants and techniques that may be difficult to explain textually only. As a consequence, I created a figure (it also gave me a chance to play around with the new amazing Photoshop CS6!) laying everything down. Please note the figure is available in high definition by simply clicking on it:

A gesture always starts with a MotionEvent whose action is ACTION_DOWN (the red surrounded arrow). In order to consider this touch event as valid to start a swipe gesture, it must happen on a thin area on the left of the View. In the preceding figure, this area is represented by the translucent green rectangle on the left of the screen. The width of this area is very important. Having a narrow bezel area may make your sliding menu difficult to open. On the contrary, a too large bezel area results in gesture mismatches. Android has no support for bezel swiping by default, as a result, we spent a lot of time at Prixing looking for the perfect dimension. We finally ended up with 30dp.

Having an ACTION_DOWN next to the left edge of the View is far from being enough to consider it as the starting point of a swipe gesture. Indeed, some noisy ACTION_MOVEs may be generated by the system as the user’s finger is on screen. This is perfectly normal and you have to deal with this. Fortunately, Android includes a method to determine the distance beyond which a gesture is considered as a drag: ViewConfiguration#getScaledTouchEvent(). On every Android build I have seen, the returned value is equal to 8dp scaled to the current display density. As a consequence, the fly-in app menu considers a gesture as accurate and intercepts it when the travelled distance is greater than the touch slop threshold. Technically, it means:

1

Math.hypot((mCurrX - mStartX), (mCurrY - mStartY)) > mTouchSlop

In order to minimize gesture mismatches, we also added a few other conditions to our RootView. All of them are only applied to the swipe-to-open gesture:

• The direction of the gesture must be left-to-right. From a technical point of view, it requires all MotionEvents to have increasing values on the X-axis.

• The gesture is valid only when the distance made by the traveled distance is greater than ViewConfiguration#getScaledPagingTouchSlop() (16dp) on the X-axis. This method has been introduced with API 8 so you may need to use the ViewConfigurationCompat class or copy its implementation into your code (getScaledPagingTouchSlop() is twice the value returned by getScaledTouchSlop()).

The algorithm described previously could be summed up pretty simply using the graphic above. In order to consider a gesture as a bezel swiping gesture, we need to ensure all MotionEvents occur in the striped area, respect the left-to-right direction, and go out of the stripped area via its right edge.

Dragging the host

Now it’s action time! The swipe gesture has been intercepted and we have to drag the host according to user actions. The trick here is to reuse what we have already discovered in the first article of this series: offsetLeftAndRight(int). As long as the onTouchEvent(MotionEvent) receives MotionEvent#ACTION_MOVEs, the RootView reads the position of the MotionEvent on the X axis and translates the host accordingly. Remember that after being intercepted, the rest of the gesture’s MotionEvents are passed to our onTouchEvent(MotionEvent) method.

Ending a swipe gesture?

This is where the magic happens! As a UI developer, managing the end of a gesture is awesome. This is where you have to study the gesture as precisely as possible to graphically reflect what the user wants. So we are at the exact moment the user removed his/her finger from the screen. We need to make sure the RootView animates to one of its stable state (opened or closed). This is done in a few steps described on the diagram below. As usual, clicking on it opens the high definition version.

Velocity is very important

This diagram explains almost everything except how to handle velocity. Indeed, RootView actually looks at the velocity of the gesture using the VelocityTracker helper class. This may be used in some cases to determine whether the host has been thrown rapidly enough to close or open the RootView. The best example of this is when you do a pretty “short” (let’s say 32dp) swipe gesture. Tracking the velocity will let the sliding menu be closed/opened whenever the velocity has gone beyond a certain threshold (ViewConfiguration#getScaledMinimumFlingVelocity()). One may also need to normalize the velocity using the ViewConfiguration#getScaledMaximumFlingVelocity() method. When crafting your own UI widgets, always take velocity into account. Velocity is a well known notion and managing it will make your component even more realistic and usable.

Conclusion

That’s it for now. I think we have been through a lot in this second part. It gave you all the elements to create stunning actionable UI widgets. In the third part of this series I will concentrate on some other details such as parallax translation, menu fading, selection arrows and menu hints. We will also cover a point lots of developers have been asking me to reveal: Activity transitions. Indeed, Prixing is made up of tens of Activity. Having animated transitions like we do is “normally” impossible on Android … Shake up your brain cells about it and feel free to leave a comment below if you have an idea of how I managed to do it on Prixing. Stay tuned for more!

Thanks to @franklinharper for reading drafts of this

1. Some of you may ask how GMail succeed to do it. I have not reverse-engineered the application but I am pretty sure they did it very easily. Each page of the ViewPager being a WebView, the touch target is always the WebView. Knowing that, you simply have to call canScrollHorizontally(int) on the WebView of the currently selected page.

We, at Prixing, released a brand new version of our Android application in the middle of April. To sum up, Prixing is a startup created by the French entrepreneur Eric Larchevêque. It aims to help people find product information and the best prices in a localized manner. The company currently only targets the French market but the application can be downloaded regardless of your location. Go to the Prixing’s Google Play page to download it on your Android device (the current version is only dedicated to handsets) and play with it!

I started working at Prixing as the lead mobile software engineer in January of this year. As a huge fan of the Android platform, I mainly worked on making the Android application easier to use and fancier. As a result, tons of changes and improvements were made. After the release of the application, I received several questions regarding the implementation of the UI. I sincerely appreciate having curious developers asking me how I implemented this or that. This series is an attempt to answer all of the questions I received. Instead of sharing great tips to a very restricted set of developers I thought it was way better to share them globally via some blog posts.

Note: Everything I will talk about in this series will probably never feature source code. It is absolutely intentional. Prixing’s source code is obviously not open-source and chances are high it will remain closed-source in the future. The purpose of these articles is to describe the techniques and methods to use to make astonishing UIs rather than giving ready-to-use snippets of code. Nevertheless, I may open source some interesting and reusable snippets of code in the future. Feel free to leave a comment below so I can anticipate the average number of motivated developers.

In this first post we will start with one of the most important UI widgets in Prixing: the fly-in app menu. The figure below gives you a screenshot of the UI widget on a Galaxy Nexus. You can also click on the picture to access a high resolution screenshot and look at the details but I strongly suggest you download the application to fully see how the Prixing fly-in app menu works and what it looks like.

I can already hear some of you saying “That’s a Facebook-like menu!”, “It looks like Path on iOS!”¹ etc. Indeed, in addition to technical questions, I also received some messages from people who don’t consider the fly-in app menu as an Android UI pattern. I think I talked a lot lately about what I consider Androidy or not (cf my thoughts dealing with splash screens and the pull-to-refresh UI patterns). I am not going to talk about it in this series mainly dedicated to development techniques. I am sure some people will soon talk about it and describe whether it is good or not. However, I would like to outline my point and make it clear. Personally, I don’t think the fly-in app menu is a straight Android UI pattern. I actually believe it is a UI pattern not related to any platform at all. Applied to Android, this pattern works pretty well and doesn’t go fundamentally against Android principles. The only problem I have with it is the back stack is totally messed up. When looking closer at the pattern you can notice it is pretty much like a classical two-panes screen (in Google Talk or GMail for tablets) mixed with a plain old SlidingDrawer. We decided to use the fly-in app menu pattern in Prixing for three main reasons:

• It is directly accessible from everywhere, regardless of how deep you are in the screen hierarchy, using a simple click and/or swipe gesture

• It presents items in list-manner rather than a paged-manner. This is a pretty big advantage when dealing with a large amount of items as a list-based menu is more understandable than paged-dashboards

• It is not dedicated to Android nor iOS. Consequently, we can have overall application usage consistency among our mobile applications

I recently found a lot of fly-in app menu implementations (Facebook, 8tracks, Evernote, Spotify, etc.) but found none as polished as the Prixing one. Of course, most implementations are running great but they lack naturalness, easiness, smoothness, etc. or a combination of it. I am not saying the implementation included in Prixing is perfect as we still have some improvements to make but I think it contains a lot of interesting concepts you may need if you want to implement your fly-in app menu or simply enhance it.

Introduction

Implementing a fly-in menu requires building a custom layout. Creating a class inheriting from ViewGroup helps you to precisely control how components are being laid out and drawn. Being the root View in Prixing’s View hierarchy, we named it RootView. The RootView basically contains two child Views: the menu that has to be laid out on the left of the screen and the content view we called the host (mainly because it is always a TitleBarHost², a custom implementation of the ActionBar holder paradigm)). The purpose of the RootView’s onLayout is to lay out the menu and the host in a stacked fashion as a FrameLayout would do. The only difference remains in the width taken by the menu which is currently the entire available width minus the app menu button width (44dp).

RootView == SlidingDrawer?

As we discussed earlier, the RootView is pretty much like a SlidingDrawer. As a consequence, APIs are very similar and include methods to action the RootView in animated fashion - animate[Close|Open|Toggle]() - or not - [close|open|toggle]() - and some methods to retrieve the current RootView’s state - is[Opened|Moving|Animating](). The first natural feature to implement is the “open-by-clicking” the app-menu button. In order to do so, we simply applied an OnClickListener to the app-menu button that does nothing more than calling RootView#animateToggle().

Scrolling content using Scroller

Implementing open/close animations can be pretty simple starting from Android 3.0, thanks to the new animation framework. Unfortunately, Prixing had to be compatible with devices running on Android down to the version 2.1. As a consequence, we decided to implement the open/close animation manually. To be honest, it can be done fairly easily using classes from the Android framework. Animating a value can be done manually or using a Scroller/OverScroller. Scroller is a helper class that can be used to compute position values of objects scrolling or flinging in a 2 dimensional space. Once you want to start animating the menu simply call Scroller#startScroll and keep calling Scroller#computeOffset every 16ms (60 frames per second) using a Handler and the Handler#postDelayed(Runnable, long) method. In the Runnable that gets executed every 16ms, reading the current position of the Scroller gives you the position at which your object should be translated to.

Actually translating the host using offsetLeftAndRight

Translating the host value is done by adding, in the onLayout an integer containing the value to add to the original X position of the host. We will call this variable mHostOffsetX. Updating mHostOffsetX in the previously described Runnable and calling the well known requestLayout() would get the job done. Using this method would run perfectly but your application may suffer from severe lags. Indeed, using requestLayout() repeatedly is usually a bad idea as it forces the system to measure and layout all Views in the hierarchy. Translating the host view (in other words, your entire content) doesn’t require it to be laid out again as nothing but the position of the host has changed. Fortunately, the system provides a great method called offsetLeftAndRight(int) that will translate the host by the given amount of pixels from its current position. Do not forget to call invalidate() to force the RootView to redraw itself and reflect the translation on screen.

Optimized rendering

Since Android 2.1, the system avoids rendering a View when it is not visible. A View is considered as “not visible” when its bounds are outside screen bounds or if it is entirely covered by a View which returns true to a call to View#isOpaque(). To ensure the rendering pipeline does not try to uselessly draw the menu when it is completely hidden (closed state), just set its visibility to View.GONE. It won’t help in many cases (API level greater to 2.1) but using this trick is pretty straightforward and easy to include in your code. In other words, setting the menu visibility to View#GONE will ensure your application runs the same as it would have without the menu.

Smoother closing/opening animations

If you look attentively to the opening/closing animation you will probably notice it is pretty “brutal”. Indeed, the drawer opens/closes in a linear fashion. Because of this, the user has a strange and negative feeling the menu “crashes” abruptly when it has arrived at its final position. This “crash” is actually due to the default behavior of the Scroller class. By default, the Scroller computes the current position of an object using a LinearInterpolator. This means the current position is determined by the following formula (simplified to a single axis):

x_cur(t_cur) = x_start + distance * ((t_cur - t_start) / duration)

In this formula the position (xcurrent) is a function of the current time. distance indicates the overall distance of the animation and duration the total duration of the animation. The main problem with this formula is it doesn’t include an interpolation function. This is actually a simplified version of the complete formula based of the hypothesis interpolator(t) = t. The complete formula is given below:

x_cur(t_cur) = x_start + distance * interpolator((t_cur - t_start) / duration)

interpolator(t) is a function defined on [0, 1]. It usually returns values in the [0, 1] range but this is not mandatory as having returned values outside of this range will indicate overshooting animations. By modifying the Interpolator, you can easily change the way the animation performs. In Prixing, we started by using some of the framework-provided Interpolators but weren’t satisfied so we created a SmoothInterpolator which is basically a polynomial function:

interpolator(t) = (t-1)⁵ + 1

The difference between the two interpolators is given on the figure below. The green curve describes the Interpolator used in the current build of Prixing. The red curve is the Scroller’s default Interpolator:

As you can easily see, passing a SmoothInterpolator when creating your Scroller will make the animation way smoother. The drawer will open/close very rapidly at the beginning but will slow down at the end to reach quietly and smoothly its final position. Do not hesitate to play around with Interpolators as it helps you create stunning animation curves and may make your UI way more polished from a user point of view.

Some interesting additional features

This first article concentrates on having a basic RootView that can be opened/closed programmatically or via a simple click on the app-menu button. In the manner of Angry Birds, Prixing uses the system menu button to easily toggle the RootView. It is implemented at the Activity level by calling RootView#animateToggle() in Activity#onKeyUp(int, KeyEvent) but it could also be implemented at the View level using View#onKeyUp(int, KeyEvent)

Note: Eagle eyed people may have noticed the current implementation of Prixing is based on Activity#onKeyDown(int, KeyEvent) rather than Activity#onKeyUp(int, KeyEvent). This is definitely a bug of mine that has been fixed in a recent release.

To prevent the user from finishing the current screen when the menu is open, it could be smart to first ensure the menu is closed. You can do it by simply calling RootView#animateClose() in Activity#onBackPressed() when the menu is fully opened.

Being an actively used control, we need to ensure the app menu button is very easily accessible. The best way to do so is to virtually enlarge the touchable area of the button. I seriously don’t know why but this is not something that is done by default on the ActionBar. The UINavigationBar - iOS ActionBar equivalent has a built-in similar mechanism which makes all buttons impressively accessible. Prixing is based on a custom implementation of the ActionBar so we have simply set a TouchDelegate to the app menu button. It enlarges the touchable area with a 30dp wide frame. If you want to do it I strongly suggest you read a previous article of mine dealing with enlarged touchable areas.

Conclusion

That’s it, at least for now! We have covered everything you need to create a panel that can slide from a closed state to an open state or vice versa. In future articles we will continue enhancing our RootView by managing state of the art features such as bezel swiping, parallax translation, menu fading, selection arrow, menu hint, etc. I have tried to cover everything in this article but I may have forgot some interesting techniques. Do not hesitate to tell me if you want more explanations on a particular feature. Stay tuned for more.

Thanks to @foxykeep and @franklinharper for reading drafts of this

1. When I wrote the article dealing with the scrolling info panel, I criticized how poor, in term of functionalities, the Android version of the application was compared to the iOS one. I explained how to implement a scrolling info panel and I recently received an update of the Path application that includes the UI widget. I really don’t know if Path used my article to implement it. This fly-in app menu is something the Android Path app is also missing. If you are a developer at Path, feel free to use these tricks and post a comment to thank me in return!

2. Implementing a fly-in app menu with the built-in Android ActionBar requires using several awful hacks one of which consists of considering the View returned by Window#getDecorView() as a FrameLayout. As a bitter enemy of hacks I couldn’t resolve myself to do it and decided to write my own implementation of the ActionBar paradigm. Let’s be honest: this is far from being ideal…

I have recently seen many Android applications starting with what I call a splash screen. A splash screen is an image that takes the entire screen space and usually shows branding information about the application (logo of the company, logo of the application, etc.). This screen is generally visible for a small amount of time while the application is starting or loading some resources in the background. I am pretty sure you have already seen some of the popular Android applications below featuring a splash screen on startup:

Once again, from my point of view, the splash screen paradigm is a port of the iOS equivalent. Some of you may start thinking I hate iOS because it influences Android in a really bad way. I often consider lots of mistakes in Android applications are due to stupid ports of iOS apps to Android. However I don’t consider iOS as a crappy mobile platform. I honestly believe iOS is an awesome mobile OS. Issues are not related to OSes themselves but to how people incorrectly understand them and use them. The splash screen is one of the best example of how people are misleading OSes in general. Being widely used on iOS, the UI pattern is also actively discouraged by Apple! Indeed, if you look closely to the iOS documentation you will notice Apple encourages developers to use launch images. Launch images are very different from splash screens as they are images used to pretend an application launched rapidly. On iOS, the system displays the launch image instantly when the user starts your application and until the app is fully ready to use. As soon as your app is ready for use, it displays its first screen, replacing the launch placeholder image. As a result, supplying a launch image is the best way to improve user experience. The graphic below shows you the launch image on the right that is used in the built-in “Stock” iOS apps:

The iOS documentation clearly specifies launch images should not be used as an opportunity to display branding information. Unfortunately, rules are made to be by-passed and iOS folks understood that. I honestly can’t blame them! They have simply used a functionality offered by the framework and slightly modified launch images to use them as splash screens. What is very disappointing to my mind is the same pattern is currently happening on Android. I am strongly convinced splash screens are not appropriate on Android for several reasons I would like to share with you:

• A splash screen prevents the user from using the application. As far as I know, it is not explicitly written in Android guidelines but Android has been primarily designed to help the user achieving and completing tasks rather than offering features. In order to do so, the entire system focuses on what users want to do and letting them do it as quickly as possible. This fastness is achieved by rendering the overall UI in a insanely fast fashion and never blocking the user. Some of the best examples of this are the notification area (I guess iOS users will always remember the so annoying and blocking popups - UIAlertViews - when receiving a text message pre iOS5), the advanced multitasking mechanism, the launcher widgets, the fast transition animations (I don’t have the exact numbers but the default transition between two Activity is twice as fast as the transition between two UIViewControllers put in a UINavigationController), etc. In a nutshell, being blocked is not something an Android user is used to nor wants to be confronted with.

• Most of the time, it is not necessary A splash screen can be used to make resources available before an application starts. Personally I think it is not necessary in 98% of the cases. It may be useful for applications actively relying on heavy resources such as Google Earth, Sky Map, or games but this is not applicable to simple utility applications such as feed readers, social network apps, news readers, etc. You should not require a network connection at startup nor do heavy computations. Always keep in mind, Activity launching is blazingly fast on Android. The Android team at Google spent a lot of time - and I am sure they are still spending a lot of time working on it - ensuring applications and the Activity class launches very rapidly. As a result it is quite easy to have an application and its first Activity up and ready in less than 400ms. Also always keep in mind that an application displaying a splash screen is also completely up and running from a system perspective.

• Displaying a launch image or splash screen in not part of the framework¹. I don’t know the exact percentage of the Android documentation I have read at least once but I assure you the number is pretty high! I have never seen a method, class or xml resource explicitly dealing with launch images or splash screens. This obviously proves the Android team never considered the launch image trick as necessary or easy to implement.

• Adding once-viewed resources increase the size of your APKs. In order to make a great splash screen, one may usually need to add several resources to the APK (bitmaps, layouts, 9-patchs, etc.). This may uselessly and drastically increase the size of your APK making it more difficult to download/install. It may also drive several of your users mad if they have a pretty memory-constrained device. I think the best way to demonstrate the horrible consequences of launch images is to give the example of a universal iOS app (a universal app is an app running both on iPad and iPhone). As I previously explained, iOS fakes fast application startup rapidly displaying a launch image. If you look closely at the iOS documentation, you will notice the iPhone requires two default images (only in portrait, one for each density - 320x480 and 640x960) while the iPad requires 4 images (one for each orientation and density - 768x1004, 1536x2008, 1024x748 and 2048x1496). Knowing iOS requires launch images encoded using the PNG compression algorithm, you will likely create an application that is almost 5Mo-sized (depending on how much your launch images are compressed) and only displays a splash screen!

• Implementing a great splash screen is very difficult and tedious Developing on Android requires dealing with a lot of resolutions, densities, orientations, etc. In general, the built-in resource switching mechanism is enough. In the context of splash screen development in which absolute layouts are usually required, it is generally not sufficient. Moreover, you also have to deal with Android’s Activity lifecycle. I have seen many application falsely redisplaying a splash screen in low memory conditions, because the developers forgot to save the splash-screen-has-been-displayed flag in onSaveInstance(Bundle). The worst bug I am used to see is an app auto-magically restarting itself after the user got out of it. This is mostly because splash screen are implemented using a Runnable posted with a certain delay in a given Handler. Not removing it from the Handler’s queue in onPause() will let the application restart itself. Developers should rather focus on making their app launch time as short as possible rather than designing a well-working splash screen. Equally, designers should spend more time on making Android apps Androidy…

• Users don’t care about branding at launch time. When a user is starting an application, he/she is expecting it to fully fulfill what it is intended for. Making your applications responsive and fast is part of that job. Having a splash screen or a long startup time is the best option to do the complete opposite of what the user wants. If you really need to brand your application (and I encourage you to do so to create visually unique looking apps), I strongly suggest you to style the ActionBar, add an ‘About’ screen, use the background as a display area, etc. Doing in-app branding is the best opportunity to spread your message to your users as it will remain visible on all application’s screens. Believe me, as a user, when I open the Facebook app, I already know I am using the Facebook app. There is no need to display a huge Facebook logo in the middle of my screen.

• A splash screen indicates a single-entry point application. Just a few application use this technique but Android applications may have several entry points. The best examples of that are Maps, Google+, Contacts/Phone or, more recently, Facebook. This can be done very easily using the appropriate <intent-filter />s on your entry point activities in the Android manifest. I’m not saying this is something that is easy to apprehend for a user but it’s available from a framework perspective. This feature is not supported by iOS. Because of this, lots of people falsely consider an app has a single entry point and use it to add a splashscreen.

• In a multitasking context, launch images have no meaning. In an ideal multitasked environment (ideal means en environment with access to unlimited resources), a splash screen is diplayed only once: the first and only time an application is started. Indeed, once an application is started, there is no need to display the splash screen again as the application will always remain in memory. Android has been primarily designed as a massively multitasked OS and therefore doesn’t stick to the splash screen paradigm at all.

Conclusion

When Apple launched the first iOS SDK, it may have made a great decision by enabling developers to fake a fast application startup via a launch image. Unfortunately, iOS evolution - iOS now runs on several densities and devices and supports multitaking - and the fact that developers completely hacked the way launch images are used made it a big mistake. Spending time on ensuring applications are opened rapidly would have been a better option. On the other hand, Android has been built to deal with an insanely large amount of devices. Please start taking this into account and continue fighting against the iOS enthousiasts who think the iOS way is the only way. iOS and Android are both awesome mobile OSes. They both have some particularities that need to be taken into account when developing applications. Understanding an iOS app is appropriate on iOS, and an Android app is appropriate on Android, etc. is the path to making awesome multiplatform applications.

1. Android has actually always had a built-in mechanism similar to launch images. I won’t talk about it as it could be the topic of an entire article. Moreover, writing about it in an article severely criticizing the splash screen paradigm would be the best way to make this blog post pointless.

• 25 May 2012: ‪‪Null your ViewStub references after being inflated (mViewStub = null). It lets the GC garbage it and saves memory. #androidtip #androiddev‬

• 9 May 2012: ‪‪#androidtip‬ (for experts): Create custom Views with some texts in it using Layout (http://developer.android.com/reference/android/text/Layout.html) and its subclasses. ‪#androiddev‬

• 4 May 2012: ‪#androidtip‬: When working with ContentProviders you often have to play with Uris. ContentUris is here to help you (http://developer.android.com/reference/android/content/ContentUris.html)

• 2 May 2012: #androidtip: Need a “triplean” in your code (a boolean with 3 possible values : unknown, true and false)? Use a Boolean (null, true, false)

• 30 Apr 2012: #androidtip: Starting API 11, you can draw dividers between your Views in a LinearLayout (http://developer.android.com/reference/android/widget/LinearLayout.html#setShowDividers(int))) #androiddev #android

• 25 Apr 2012: #androidtip: If you want to know if an URL is valid, HTTP, HTTPS, etc. use the android.webkit.URLUtil (http://developer.android.com/reference/android/webkit/URLUtil.html) class

• 25 Apr 2012: #androidtip: Starting from API 11 you can reuse Bitmap (using BitmapFactory#Options#inBitmap) in order to avoid memory allocations.

• 24 Apr 2012: #androidtip When displaying web content in a Fragment you can use the WebViewFragment: a Fragment managing a WebView. #androiddev

• 19 Apr 2012: Use android:foreground on your FrameLayout to overlay a Drawable on opaque images in itemviews

• 18 Apr 2012: Check whether a View is actually visible using View#isShown(). It will check your View visibility AND all of its ancestors

• 17 Apr 2012: Remember you can start the Settings app from yours on a given screen using the actions described in http://developer.android.com/reference/android/provider/Settings.html

• 16 Apr 2012: Pre-populate Intent chooser using LabeledIntents (Intent with a name/icon) and the Intent#EXTRA_INITIAL_INTENTS extra

• 13 Apr 2012: When creating your own custom view with scrollable content, don’t forget to use EdgeEffect (http://developer.android.com/reference/android/widget/EdgeEffect.html)

• 12 Apr 2012: Need View#onConfigurationChanged on API < 8? Use a BroadcastReceiver or forward your Activity’s onConfigurationChanged. Here’s a sample of using a BroadcastReceiver: http://gist.github.com/2367432

• 11 Apr 2012: Stop uselessly fetching resources when your WebViews aren’t visible anymore with WebView#onPause|onResume (API >= 11)

• 11 Apr 2012: With split content (ListView + content), call setActivated(true) on the appropriate item view to indicate the current section

• 10 Apr 2012: Don’t forget to use android:textIsSelectable=”true” (API >= 11) on your TextView to let users copy your TextView content

• 6 Apr 2012: Java 5 accepts return type refinement. Return your object type instead of Object in Adapter#getItem(int). It saves you a cast

• 4 Apr 2012: Do not forget to call HandlerThread.quit() (or HandlerThread.getLooper().quit() if API < 5) when you no longer need it

• 3 Apr 2012: Stop developing countdown algorithms, use the built-in CountDownTimer (http://developer.android.com/reference/android/os/CountDownTimer.html) #android #androiddev

• 2 Apr 2012: Add margins to your ListView selection areas using a SelectionBoundsAdjuster (http://developer.android.com/reference/android/widget/AbsListView.SelectionBoundsAdjuster.html) #android #androiddev

As an iOS & Android developer/user I spend a lot of time looking at and playing with mobile applications. Since 2007 (the year mobile really had a leap forward thanks to the iPhone), mobile UI patterns have been introduced, enhanced and reused by applications. The Android platform has always been a very productive environment for UI designers and recently has become even more so. This rapid growth and evolution is probably a direct consequence of the increasing number of Android developers and applications. Recently, I have noticed some emerging UI patterns. Among them is the well known “pull-to-refresh” pattern.

As far as I know, “pull-to-refresh” has been primarily developed on iOS. It consists of adding an additional cell at the top of your ListView that remains hidden most of the time. As suggested by its name, you can pull down your ListView to make the widget appear. When you pull enough, a smooth animation indicates you can release the ListView in order to launch the refresh process. The cell contents switches to an activity indicator for the duration of the refresh. When the refreshing has been completed, the list scrolls in order to hide the additional cell. The screenshots below show you the complete interaction model. Please note I have used the official Twitter application. However, it doesn’t mean I appreciate this application. To be honest, I think it is in my top 10 of the least Androidy or should I say the most iOSy on Android … From my point of view, Twitter on Android is exactly the kind of app you shouldn’t do (grouped UITableView, UINavigationBar, UITabBar, UISegmentedControl, iOS look ‘n feel, etc.).

To be honest, I love this UI pattern on iOS. I think it is extremely “natural”: most recent items are usually on top of the list so it’s natural to scroll further to the top to access to the most recent items. It totally fits iOS platform philosophy. When it comes to Android, lots of developers and companies have a tendency to reproduce this pattern on the Android version of their application. I consider it a huge mistake and here is my point of view:

• The ‘pull-to-refresh’ UI pattern is mainly dedicated to power users. I honestly don’t think it is as intuitive as a simple but clear “Refresh” button. Lots of developers use this UI pattern without thinking about their actual audience and how technophile they are. Most of the time a “Refresh” button would have been way easier to implement from a developer perspective and to use from a user point of view. I believe this is one of the main reasons Apple never used it in any of their stock iOS applications.

• A lot of people primarily consider ‘pull-to-refresh’ as a way to save space on screen. I can’t disagree with this argument! It obviously saves space as nothing is visible on screen at all! Hiding the essential refresh button from normal users will probably just leave room for another useless button. On iOS, the framework forces the developer to have a single button on the right of the UINavigationBar (ActionBar equivalent on iOS)¹. Saving as much space as possible on iOS may be a good practice, it is not a big issue on Android. On Android, the system will automatically adapt the ActionBar appearance to ensure the maximum amount of actions is visible. You often have enough room to add two or three actions (regardless of the device you are running on) which is enough to maintain the main features on screen. For instance, in the Twitter application, it would have been possible to have a “Refresh” button next to the “New tweet” button.

• The pull-to-refresh pattern is not easily visible to the user. The Android UI philosophy is to make the UI as clean and sober as possible. Unfortunately developers have a tendency to misunderstand this UI rule. They often over-engineer the UI by putting buttons everywhere, making their applications look like a cockpit! The actual rule is to make the UI as clear as possible by prioritizing and ensuring it remains accessible. Keep in mind that a mobile application is not intended to give the same level of functionality as its desktop/web equivalent. A mobile app has to be concise and has to provide an extremely well designed small subset of all of the product’s features. On iOS, people may see “pull-to-refresh” quite easily when the screen is displayed or when they are rapidly flinging the UITableView to its top. In that case, the list will bounce when reaching the top edge, letting the user see the “pull-to-refresh” widget. As far as I know, there is no equivalent on Android as all implementations are only visible from the very top of the ListView.

• You have to be at the top of the ListView to refresh it. This may be easy on iOS as a click on the status bar automatically scrolls all UIScrollViews on screen to their top. Unfortunately this is not a default behavior on Android. As a result, a user who has reached the bottom of a ListView will have to scroll all the way up to the first item and then ask for a ‘Refresh’. Pretty boring, isn’t it?

• It is not compliant with how Android represents scrollable contents. To my mind, this is the biggest issue when using “pull-to-refresh” in Android apps. On iOS, most scrollable containers inherit from UIScrollView which nicely ‘bounces’ when at least one of the edges is reached. As a result, creating a UI widget on top of a UIScrollView will let you benefit from the amazingly great bouncing mechanic that Apple implemented. It improves consistency and enforces its adoption by the users. Because of this, enhancing the ‘edge bouncing’ property with a “pull-to-refresh” widget is pretty natural to iOS users. Android users are not familiar with bouncing scrollable containers². I am not saying Google didn’t make a mistake when they released the first version of Android not including such a nice behavior. It’s probably because the early Android devices had screens with lots of afterglow: having a bouncing animation would have resulted in having a blurry screen while the ListView would be springing back to its final position. I’m not happy with this either but I consider we now have to deal with it and stop misleading the user by changing how scrollable containers scroll at every new release. Google recently introduced the edge effect (see EdgeEffect for more information) so we have to stick to it. The pull-to-refresh is clearly not compatible with the edge effect (see screenshot below).

• Most of the time the ‘pull-to-refresh’ is not necessary: I have seen many applications using the ‘pull-to-refresh’ pattern for items having a low “update rate”. As a consequence, implementing the “pull-to-refresh” pattern in those cases is almost useless. There is a little chance the list will need to be updated while the user is looking at it. Android has several mechanisms and callbacks you may use to refresh the contents when appropriate. Always prefer considering a smart and automatic refreshing mechanism. There is nothing better than simplifying the UI by anticipating what the user wants and doing it for him. For instance, you can look for new contents at every onResume calls, every X minutes, etc. You may also use components such as Service to refresh your contents in the background at fixed intervals of time (that has no equivalent on iOS) or the Cloud 2 Device Messaging (C2DM) service to push the new contents only when strictly necessary.

• When visible, the “pull-to-refresh” widget is pretty intrusive compared to a regular “Refresh” button. The best example of this is probably the latest GMail application. When tapping on the “Refresh” button, it turns into an indeterminate ProgressBar while refreshing. You can continue reading your contents while still knowing whether or not the refresh is in progress.

Conclusion

I know some of you totally disagree with what I said in this article. As a huge fan of the ‘pull-to-refresh’ UI pattern on iOS I can’t blame you. I just wanted to show you that stupidly porting UI widgets from one platform to another is never a good practice. Please always consider platform differences when developing an application on different OSes. If you are like me, a developer using an Android device a daily basis and surrounded by iOS users (designer, boss, etc.) then you will have to fight everyday to explain that Android is different. It may sound weird to say that to people who “think different” but I actually do it everyday. It’s an ongoing fight. When I develop an application on several platforms I always ensure they all have the same set of functionalities but I always redesign the UI where necessary. That’s the price to pay to get an Android app on Android, an iOS app on iOS, etc. and have non-disoriented users.

1. Technically speaking you can add several buttons to a UINavigationBar. For instance you may add a button on the left but this area is often reserved by the “back” button. You may also add a control in the center of the UINavigationBar but you will lose the UINavigationBar’s title. If you really want to add several buttons on the right of your UINavigationBar, you will often end up with tricks such as using a custom view (a UISegmentedControl for instance) in your UIBarButtonItem.

2. I know some of you may mention some manufacturers implementations. Personally, I love how the UIScrollView (and of course its UITableView descendant) bounces on iOS but most of the implementations I have seen on Android so far are not great. They either don’t feel natural or are not consistent with the rest of the system. For instance, Samsung implemented it, and the movement is quite OK. But is not consistent with the rest of the framework: neither View (which has a basic scrolling support) nor ScrollView (even worse!) bounce.

Some of you may wonder why I have decided to publish a new article in the ListView Tips & Tricks series. Indeed, in the last article, I mentioned the fourth post was the latest of the series. Actually, at the time of the writing it was true but I recently came up with a new topic! As a result, I will stop saying such and such an article is the final of the series and I will never be wrong again!

I also would like to give you a quick recap of the topics we have already covered (please note it is not necessary - but highly encouraged - to read the previous tips in order to fully understand the article below):

• ListView Tips & Tricks #1: Handling emptiness
• ListView Tips & Tricks #2: Sectioning your ListView
• ListView Tips & Tricks #3: Create fancy ListViews
• ListView Tips & Tricks #4: Add several clickable areas

Moreover, all of those articles are based on some snippets of code that have been all gathered in a single Android application. You can download/clone the source code of this application on GitHub using the following link:

http://github.com/cyrilmottier/ListViewTipsAndTricks

Note: This article is mainly dedicated to ListViews. The main reason behind this is enlarging touchable areas if often necessary in itemviews containing lots of controls (Button, CheckBox, etc.). Please remember the trick explained in this article doesn’t only apply to ListViews. It can be used everywhere in the system as long as you use Views … which, I guess, is often the case when developing an application.

In the previous article of this ListView Tips & Tricks series, we have discovered several way to enlarge touchables areas. The main purpose of those techniques is to ensure the user correctly and easily access to secondary actions (star an item, select an item, etc.). Ensuring your users don’t get frustrated because of their actions are not being recognized is very important. Chances are high that an angry user will rate your application with a bad comment or worse uninstall the application.

A great example of a easy-to-interact-with application is the new GMail application. Personally, I love using it because you can navigate through the sections seamlessly and flawlessly. The UI is clean and responds precisely, which has not always been the case… Even if the select and star controls are pretty tiny (graphically speaking), they are easy to check/uncheck. To sum up, the general design remains clean and simple while the size of the controls does not influence the correctness of user interactions. The screenshot below shows an itemview from the new GMail application:

More than being a reference to me, the GMail application is also highly featured on the new Android Design website - which, by the way, I highly recommend you to read. For instance, the Android design team decided to use the GMail application to give an explanation of how to create contextual icons on Android. Go to the ‘Small / Contextual Icons’ of the Iconography section to read the recommendations. The actual problem of this guideline is it only describes iconography. Knowing a touchable area has to be at least as big as a 30x30dp square and Google requires a 16x16dp icon brings us to a big question: How to reconciliate designers with ergonomists ?

My previous ListView Tips & Tricks article gave us some advices:

• Adding padding to controllable Views
• Adding a transparent safe-frame to all images used in controls
• Enlarging view bounds using fill_parent or manually setting a dimension

All these techniques are working perfectly and are pretty familiar to developers. Unfortunately they also bring you several issues as these methods don’t let you have a precise control over the touchable areas. For instance, the first technique involves modifying the general layout of your itemviews (padding has an effect on how Views are laid out) and may not let you entirely fill vertically the parent. The second technique makes reusing the image fairly difficult. There’s a good chance the safe-frame won’t be necessary if the image is reused somewhere else. In other words, those techniques can be pretty hazardous to use and may not be your best option.

Fortunately, Android gives you an amazing way to enlarge touchable areas. The principle consists on forwarding MotionEvents (an object describing a touch) from a View’s rectangle area to another View. This can be done natively creating a TouchDelegate and attaching it to a View, the touches of which needing to be forwarded to another View (the delegate View). This class gives you a finer control over how MotionEvents are consumed. You can obviously have a look at the TouchDelegate documentation on the Android developer website. As usual, I will follow the “show me the code” path instead of procrastinating. We will simply develop a tiny application emulating GMail behavior. It will display a list of cheeses that can be independantly (un)selected and/or (un)starred. The screenshot below gives you an overview of the result we are targeting. The red rectangles define touchable areas that will (un)select the itemview. Blue rectangles describes the area allowing the user to (un)star the itemview:

On the screenshot below you can easily notice (especially on the left of the itemview) the touchable area overlaps the actual TextView bounds.

A custom View as itemview

Most of the time, UIs are based on XML layouts. This type of declaration if usually enough to create a UI. However, sometimes you may require a finer control over the View hierarchy: be notified the size of a View has changed, be notified a layout pass has been performed (starting from API 11, this is now possible from outside of a View using the OnLayoutChangeListener), etc. This is the main reason why I have decided to develop my own custom View for the purpose of this sample. The XML View hierarchy of our custom itemview is given below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android" >

    <ImageButton
        android:id="@+id/btn_select"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:background="@null"
        android:src="@drawable/btn_check_off_normal" />

    <TextView
        android:id="@+id/content"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:layout_weight="1"
        android:ellipsize="end"
        android:paddingLeft="6dp"
        android:paddingRight="6dp"
        android:singleLine="true"
        android:textAppearance="?android:attr/textAppearanceLarge" />

    <ImageButton
        android:id="@+id/btn_star"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:background="@null"
        android:src="@drawable/btn_star_off_normal" />

</merge>

The Java counterpart of our itemview is where all the magic happens as this is where TouchDelegates are set. The trick consists on listening to onLayout(boolean, int, int, int, int) calls and re-apply the correct TouchDelegate if the size of the itemview has changed (we suppose child Views cannot change their position/size if the parent keeps the same size)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181

package com.cyrilmottier.android.listviewtipsandtricks.widget;

import java.util.ArrayList;

import android.content.Context;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.graphics.Paint.Style;
import android.graphics.Rect;
import android.util.AttributeSet;
import android.view.LayoutInflater;
import android.view.TouchDelegate;
import android.view.View;
import android.view.ViewGroup;
import android.widget.ImageButton;
import android.widget.LinearLayout;
import android.widget.TextView;

import com.cyrilmottier.android.listviewtipsandtricks.R;
import com.cyrilmottier.android.listviewtipsandtricks.view.TouchDelegateGroup;

public class LargeTouchableAreasView extends LinearLayout {

    private static final int TOUCH_ADDITION = 20;
    private static final int COLOR_SELECT_AREA = Color.argb(50, 255, 0, 0);
    private static final int COLOR_STAR_AREA = Color.argb(50, 0, 0, 255);

    public interface OnLargeTouchableAreasListener {
        void onSelected(LargeTouchableAreasView view, boolean selected);

        void onStarred(LargeTouchableAreasView view, boolean starred);
    }

    private static class TouchDelegateRecord {
        public Rect rect;
        public int color;

        public TouchDelegateRecord(Rect _rect, int _color) {
            rect = _rect;
            color = _color;
        }
    }

    private final ArrayList<touchdelegaterecord> mTouchDelegateRecords = new ArrayList<largetouchableareasview.touchdelegaterecord>();
    private final Paint mPaint = new Paint();

    private ImageButton mSelectButton;
    private ImageButton mStarButton;
    private TextView mTextView;

    private TouchDelegateGroup mTouchDelegateGroup;
    private OnLargeTouchableAreasListener mOnLargeTouchableAreasListener;

    private int mTouchAddition;

    private boolean mIsStarred;
    private boolean mIsSelected;

    private int mPreviousWidth = -1;
    private int mPreviousHeight = -1;

    public LargeTouchableAreasView(Context context) {
        super(context);
        init(context);
    }

    public LargeTouchableAreasView(Context context, AttributeSet attrs) {
        super(context, attrs);
        init(context);
    }

    private void init(Context context) {

        setOrientation(LinearLayout.HORIZONTAL);
        setDescendantFocusability(ViewGroup.FOCUS_BLOCK_DESCENDANTS);

        mTouchDelegateGroup = new TouchDelegateGroup(this);
        mPaint.setStyle(Style.FILL);

        final float density = context.getResources().getDisplayMetrics().density;
        mTouchAddition = (int) (density * TOUCH_ADDITION + 0.5f);

        LayoutInflater.from(context).inflate(R.layout.large_touchable_areas_view, this);
    }

    @Override
    protected void onFinishInflate() {
        super.onFinishInflate();

        mSelectButton = (ImageButton) findViewById(R.id.btn_select);
        mSelectButton.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                setItemViewSelected(!mIsSelected);
                if (mOnLargeTouchableAreasListener != null) {
                    mOnLargeTouchableAreasListener.onSelected(LargeTouchableAreasView.this, mIsSelected);
                }
            }
        });

        mStarButton = (ImageButton) findViewById(R.id.btn_star);
        mStarButton.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                setItemViewStarred(!mIsStarred);
                if (mOnLargeTouchableAreasListener != null) {
                    mOnLargeTouchableAreasListener.onStarred(LargeTouchableAreasView.this, mIsStarred);
                }
            }
        });

        mTextView = (TextView) findViewById(R.id.content);
    }

    @Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        super.onLayout(changed, l, t, r, b);

        final int width = r - l;
        final int height = b - t;

        if (width != mPreviousWidth || height != mPreviousHeight) {

            mPreviousWidth = width;
            mPreviousHeight = height;

            mTouchDelegateGroup.clearTouchDelegates();

            //@formatter:off
            addTouchDelegate(
                    new Rect(0, 0, mSelectButton.getWidth() + mTouchAddition, height),
                    COLOR_SELECT_AREA,
                    mSelectButton);

            addTouchDelegate(
                    new Rect(width - mStarButton.getWidth() - mTouchAddition, 0, width, height),
                    COLOR_STAR_AREA,
                    mStarButton);
            //@formatter:on

            setTouchDelegate(mTouchDelegateGroup);
        }
    }

    private void addTouchDelegate(Rect rect, int color, View delegateView) {
        mTouchDelegateGroup.addTouchDelegate(new TouchDelegate(rect, delegateView));
        mTouchDelegateRecords.add(new TouchDelegateRecord(rect, color));
    }

    @Override
    protected void dispatchDraw(Canvas canvas) {
        for (TouchDelegateRecord record : mTouchDelegateRecords) {
            mPaint.setColor(record.color);
            canvas.drawRect(record.rect, mPaint);
        }
        super.dispatchDraw(canvas);
    }

    public void setOnLargeTouchableAreasListener(OnLargeTouchableAreasListener listener) {
        mOnLargeTouchableAreasListener = listener;
    }

    public TextView getTextView() {
        return mTextView;
    }

    public void setItemViewSelected(boolean selected) {
        if (mIsSelected != selected) {
            mIsSelected = selected;
            mSelectButton.setImageResource(mIsSelected ? R.drawable.btn_check_on_normal : R.drawable.btn_check_off_normal);
        }
    }

    public void setItemViewStarred(boolean starred) {
        if (mIsStarred != starred) {
            mIsStarred = starred;
            mStarButton.setImageResource(mIsStarred ? R.drawable.btn_star_on_normal : R.drawable.btn_star_off_normal);
        }
    }
}