Rany Albeg Wein

Creating a custom CoordinatorLayout Behavior

Wed, 27 Sep 2017 01:14:26 +0300

1. Intro

Trust me, it's not as complicated as it might first look like. You either drink too much coffee, or need to take your face off of the screen for a while.

A CoordinatorLayout is this thing:

public class CoordinatorLayout extends ViewGroup implements NestedScrollingParent {
    ... 
}

from the support library ( compile 'com.android.support:design:25.3.1' ), which seems at first like an innocent old FrameLayout, until you discover its real powers - Behaviors!

A Behavior is an object attached to a child of a CoordinatorLayout, which defines its interaction with another View, ( a dependency) within the same layout.

So, a CoordinatorLayout monitors every movement of its children, and notifies the ones with attached Behaviors for a dependency change.

Something like this:

The SnackBar here is called a dependency - which makes sense, because the child depends on its movement in order to behave in a certain way specified by its attached Behavior.

Following Material Design guidelines, this behavior is the correct interaction between a SnackBar and a FloatingActionButton.

2. Let's get started!

Everything should run in a context or under the supervision of a CoordinatorLayout, so let's create a fresh Activity with a CoordinatorLayout as its content-view root element.

Create a new project, and add a new Activity by selecting the "Basic Activity" template:

Take a look at activity_main.xml, it should contain the following:



    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.rany.albeg.wein.behaviors.MainActivity">

    
        android:layout_height="wrap_content"
        android:layout_width="match_parent"
        android:theme="@style/AppTheme.AppBarOverlay">

        
            android:id="@+id/toolbar"
            android:layout_width="match_parent"
            android:layout_height="?attr/actionBarSize"
            android:background="?attr/colorPrimary"
            app:popupTheme="@style/AppTheme.PopupOverlay" />

    

     layout="@layout/content_main"/>

    
        android:id="@+id/fab"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        android:layout_margin="@dimen/fab_margin"
        app:srcCompat="@android:drawable/ic_dialog_email" />

Since the default behavior of FloatingActionButton is to run away from the SnackBar like we wish to implement ourselves, take it off of the XML tree and insert something like an AppCompatButton:




     ...

    
        android:id="@+id/bt_click_me"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        android:layout_margin="16dp"
        android:text="Click me"/>

Edit MainActivity accordingly, and modify onCreate():

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        AppCompatButton btn = (AppCompatButton) findViewById(R.id.bt_click_me);
        btn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                Snackbar.make(view, "Yeah buddy!", Snackbar.LENGTH_LONG)
                        .setAction("Action", null).show();
            }
        });
    }

3. Implementation

To create a Behavior we'll need to create a class that extends CoordinatorLayout.Behavior where V is a type of a class which extends View and represents the type of the child - in our case it'll be AppCompatButton:

public class CustomMoveUpBehavior extends 
                                  CoordinatorLayout.Behavior<AppCompatButton> {
    ...
}

We're almost done! To complete programming our custom behavior and define the unique interaction between a child and a dependency, we'll need to:

Override layoutDependsOn(...)

This method gets called ( at least once in response to a layout request ) by the parent CoordinatorLayout to determine whether the supplied child view has another specific sibling view as a layout dependency.
In other words, CoordinatorLayout sees the SnackBar and asks us :

"Hey, is this AppCompatButton depends on this SnackBar ?" and we should answer "Yes!" in order to further react in accordance to SnackBar's movement:

    @Override
    public boolean layoutDependsOn(CoordinatorLayout parent,
                                   AppCompatButton child,
                                   View dependency) {

        return dependency instanceof Snackbar.SnackbarLayout;
    }

Override onDependentViewChanged(...)

This method gets called by the parent CoordinatorLayout after the relevant layoutDependsOn(...) returns true, in which we need to actually move stuff!

In our case, for the button to run away from the SnackBar, we'll want to translate its Y position to be the difference between SnackBar's current Y translation and its height!

    @Override
    public boolean onDependentViewChanged(CoordinatorLayout parent,
                                          AppCompatButton child,
                                          View dependency) {

        float tY = dependency.getTranslationY() - dependency.getHeight();
        child.setTranslationY(tY);
        return true;
    }

We return true to say: "Hey CoordinatorLayout! Our Behavior changed AppCompatButton's position"

CustomMoveUpBehavior is done and ready to be attached!

There are several ways to attach a Behavior to View, and I'll choose to go with the common way - via XML.

In order to attach CustomMoveUpBehavior to AppCompatButton via XML, add the following constructor first:

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

and now jump into activity_main.xml and just add the following attribute to AppCompatButton's XML tag:

    
    ...
        app:layout_behavior="your.package.name.CustomMoveUpBehavior"
    ...
    />

replacing your.package.name as necessary.

Play it!

Want to support this kind of content ? Buy Rany a Coffee

Writing a basic RecyclerView.Adapter

Fri, 02 Dec 2016 16:07:00 +0200

In my previous article, ListView and ViewHolder, I discussed about the ViewHolder pattern and how it should be combined to be a part of an adapter for a ListView, or more specifically - a part of an adapter's getView() method.
We had a simple model named Profile, which describes some basic information of a person. It has an image, a name and a short bio:

public class Profile {
    /**
     * Name of person.
     */
    private String mName;
    /**
     * Bio.
     */
    private String mBio;
    /**
     * Profile image resource.
     */
    private int mProfileImageResource;

    public Profile(String name, String bio, int profileImageResource) {
        mName = name;
        mBio = bio;
        mProfileImageResource = profileImageResource;
    }

    /* "Get" methods... */
}

Our adapter, MyArrayAdapter, mapped Profile's three members ( name, bio and image ) to matching Views in our layout (R.layout.list_item): two TextViews for name and bio and an ImageView for the image. Let's remember that instead of using findViewById() multiple times ( to find these three Views as getView() is being called ), we created a ViewHolder and used it to map a Profile to a visual layout.

This mapping process is called binding. We can say that we bind ViewHolder's members ( Our layout's Views ) to a Profile.
If we first create a ViewHolder and then bind a ViewHolder, wouldn't it make sense to split these two tasks into two methods onCreateViewHolder() and onBindViewHolder() ?
This is exactly what RecyclerView.Adapter does!

RecyclerView.Adapter declares two abstract methods which we obviously must implement when we extend it:

public abstract VH onCreateViewHolder(ViewGroup parent, int viewType);

public abstract void onBindViewHolder(VH holder, int position);

RecyclerView.Adapter is responsible for invoking these two methods whenever there's a need to create or bind a ViewHolder.
You can see that onCreateViewHolder() returns a VH type, and I can tell you that onBindViewHolder() receives this exact returned value as an argument. VH stands for View Holder and it's a generic type which needs to extend RecyclerView.ViewHolder and which we need to implement. Let's call it MyViewHolder :

    class MyViewHolder extends RecyclerView.ViewHolder {
        TextView name;
        TextView bio;
        ImageView img;

        MyViewHolder(View itemView) {
            super(itemView);
            name = (TextView) itemView.findViewById(R.id.tv_name);
            bio = (TextView) itemView.findViewById(R.id.tv_bio);
            img = (ImageView) itemView.findViewById(R.id.iv_profile_image);
        }
    }

In its constructor, MyViewHolder receives the itemView argument, which is the inflated layout (R.layout.list_item) in which and by which we find all other child views: name, bio and img.
MyViewHolder's constructor executes a series of calls to findViewById(), one for each View in our layout and keeps references to each one of the Views.

To get a better idea on how to implement onCreateViewHolder() and onBindViewHolder() having MyViewHolder implementation, let's look at their similarity with our already implemented getView() in the previous article - ListView and ViewHolder

OK, things are getting more clear now.onBindViewHolder()'s implementation is just a copy-paste task:

    @Override
    public void onBindViewHolder(MyViewHolder holder, int position) {
        final Profile profile = mProfiles.get(position);
        holder.name.setText(profile.getName());
        holder.bio.setText(profile.getBio());
        holder.img.setImageResource(profile.getProfileImageResource());
    }

Finally, we can write onCreateViewHolder() to create a MyViewHolder and return it, so that onBindViewHolder() will receive it as an argument later and continue with the binding process:

    @Override
    public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        final View itemView = View.inflate(mContext, R.layout.list_item, null);
        return new MyViewHolder(itemView);
    }

Connecting all the pieces, we can now write our adapter - MyProfilesAdapter :

class MyProfilesAdapter extends RecyclerView.Adapter<MyProfilesAdapter.MyViewHolder> {
    private Context mContext;
    private List<Profile> mProfiles = Collections.emptyList();

    MyProfilesAdapter(Context context, List<Profile> profiles) {
        mContext = context;
        mProfiles = profiles;
    }

    @Override
    public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        final View itemView = View.inflate(mContext, R.layout.list_item, null);
        return new MyViewHolder(itemView);
    }

    @Override
    public void onBindViewHolder(MyViewHolder holder, int position) {
        final Profile profile = mProfiles.get(position);
        holder.name.setText(profile.getName());
        holder.bio.setText(profile.getBio());
        holder.img.setImageResource(profile.getProfileImageResource());
    }

    @Override
    public int getItemCount() {
        return mProfiles.size();
    }

    class MyViewHolder extends RecyclerView.ViewHolder {
        TextView name;
        TextView bio;
        ImageView img;

        MyViewHolder(View itemView) {
            super(itemView);
            name = (TextView) itemView.findViewById(R.id.tv_name);
            bio = (TextView) itemView.findViewById(R.id.tv_bio);
            img = (ImageView) itemView.findViewById(R.id.iv_profile_image);
        }
    }
}

Want to support this kind of content ? Buy Rany a Coffee

ListView and ViewHolder

Fri, 25 Nov 2016 01:08:00 +0200

One of the main concerns an Android developer should have is reducing strain from the main thread, also known as the UI thread.

ListView is one of the most common views in Android and it is important to know how to write a fast adapter for it. One of the ways to enahnce your ListView performance is by using a ViewHolder pattern.

Assume we have an object named Profile which describes some basic information of a person. It has an image, a name and a short bio.

public class Profile {
    /**
     * Name of person.
     */
    private String mName;
    /**
     * Bio.
     */
    private String mBio;
    /**
     * Profile image resource.
     */
    private int mProfileImageResource;

    public Profile(String name, String bio, int profileImageResource) {
        mName = name;
        mBio = bio;
        mProfileImageResource = profileImageResource;
    }

    /* "Get" methods... */
}

We would also want to create a ListView of Profiles, in which every row looks like this:

and can be described in XML ( R.layout.list_item ) like this:

 xmlns:android="http://schemas.android.com/apk/res/android"
                android:layout_width="match_parent"
                android:layout_height="match_parent">

    
        android:id="@+id/iv_profile_image"
        android:layout_width="50dp"
        android:layout_height="50dp"
        android:layout_alignParentStart="true"
        android:layout_alignParentTop="true"/>

    
        android:id="@+id/tv_name"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_above="@+id/tv_bio"
        android:layout_alignParentEnd="true"
        android:layout_alignParentTop="true"
        android:layout_toEndOf="@+id/iv_profile_image"
        android:padding="@dimen/padding_profile_text"/>

    
        android:id="@+id/tv_bio"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignBottom="@+id/iv_profile_image"
        android:layout_toEndOf="@+id/iv_profile_image"
        android:paddingLeft="@dimen/padding_profile_text"/>

To start, we should write an adapter ( ArrayAdapter<Profile> for the sake of an example ) which should look something like this:

public class MyArrayAdapter extends ArrayAdapter<Profile> {

    private Context mContext;
    /**
     * A layout inflater to create Views from XML.
     */
    private LayoutInflater mInflater;
    /**
     * Row View resource.
     */
    private int mResource;
    /**
     * List of profiles.
     */
    private ArrayList<Profile> mProfiles;

    public MyArrayAdapter(Context context, int resource, ArrayList<Profile> list) {
        super(context, resource, list);

        mContext = context;
        mResource = resource;
        mProfiles = list;

        mInflater = LayoutInflater.from(mContext);
    }

    @NonNull
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        /**
         * Missing implementation.
         */
    }
}

getView() is the main method we should focus on here, as it's the method which gets called by the system every time a new View needs to be inflated, updated and returned - to display the data ( a Profile ) at the specified position in the data set ( Profiles list in our case ).

Let's consider the following getView():

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

        /**
         * 1. Inflating layout from resource.
         */
        final View rowView = mInflater.inflate(mResource, parent, false);

        /**
         * 2. Finding views by id.
         */
        TextView name = (TextView) rowView.findViewById(R.id.tv_name);
        TextView bio = (TextView) rowView.findViewById(R.id.tv_bio);
        ImageView img = (ImageView) rowView.findViewById(R.id.iv_profile_image);

        Profile profile = mProfiles.get(position);

        /**
         * Setting information.
         */
        name.setText(profile.getName());
        bio.setText(profile.getBio());
        img.setImageResource(profile.getProfileImageResource());

        return rowView;
    }

Very slow!

As the ListView is being scrolled and getView() is called, two tasks happen:

R.layout.list_item is inflated into a new View.
A series of findViewById() calls are executed, one call for each inner View in our layout.

Getting called frequently, these two tasks are very performance-expensive, especially if R.layout.list_item is large and more complex.

1. Using ListView's recycling mechanism

To take care of the first task and avoid inflating the same View over and over again, we can take advantage of ListView's inner recycling mechanism. ListView works with a RecycleBin object ; a data set used to store unused views that should be reused during the next layout to avoid creating new ones.

Sounds great! How do we know when a View is being recycled ? By the value of convertView argument we get in getView(int position, View convertView, ViewGroup parent)'s second parameter.

When convertView is not null, the system actually tells us : "There you go, an already inflated View which is currently not visible to the user and which you can use to update its contents according to your data set and position, instead of inflating a new one."

Therefore, we can update our getView() code to effectively use this recycling behavior:

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

        /**
         * 1. Inflating layout from resource.
         */
        if (convertView == null) {
            convertView = mInflater.inflate(mResource, parent, false);
        }

        /**
         * 2. Finding views by id.
         */
        TextView name = (TextView) convertView.findViewById(R.id.tv_name);
        TextView bio = (TextView) convertView.findViewById(R.id.tv_bio);
        ImageView img = (ImageView) convertView.findViewById(R.id.iv_profile_image);

        Profile profile = mProfiles.get(position);

        /**
         * Setting information.
         */
        name.setText(profile.getName());
        bio.setText(profile.getBio());
        img.setImageResource(profile.getProfileImageResource());

        return convertView;
    }

Faster! But not enough.

2. The ViewHolder pattern

To take care of the second task, and reduce the amount of findViewById() calls, a ViewHolder pattern takes place.
As you can quite easily guess, A ViewHolder is an object whose only purpose is to hold references and give access to our layout's inner Views.

The ViewHolder will hold the returning Views from findViewById() calls and will be kept as a tag object inside convertView for later retrieval and usage.

Our ViewHolder looks like this:

    private static class ViewHolder {
        TextView name;
        TextView bio;
        ImageView img;
    }

Let's use it to update getView() and enhance our ListView performance even further:

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

        ViewHolder vh;
        /**
         * 1. Inflating layout from resource.
         */
        if (convertView == null) {
            convertView =  mInflater.inflate(mResource, parent, false);

            vh = new ViewHolder();
            /**
             * 2. Finding views by id.
             */
            vh.name = (TextView) convertView.findViewById(R.id.tv_name);
            vh.bio = (TextView) convertView.findViewById(R.id.tv_bio);
            vh.img = (ImageView) convertView.findViewById(R.id.iv_profile_image);

            /**
             * Keep the ViewHolder as a tag for later retrieval and usage.
             */
            convertView.setTag(vh);
        } else {
            /**
             * Grab the already stored ViewHolder to save findViewById() calls.
             */
            vh = (ViewHolder) convertView.getTag();
        }

        Profile profile = mProfiles.get(position);

        /**
         * Setting information.
         * This time - using our already set ViewHolder.
         */
        vh.name.setText(profile.getName());
        vh.bio.setText(profile.getBio());
        vh.img.setImageResource(profile.getProfileImageResource());

        return convertView;
    }

    private static class ViewHolder {
        TextView name;
        TextView bio;
        ImageView img;
    }

Extremely faster!

As you can see, when convertView is null, we do not only inflate a new View but also create a new ViewHolder. This ViewHolder holds references to Views returned from the calls to findViewById(). We use the function View#setTag(Object) to save the populated ViewHolder inside convertView, so that when we get a not null convertView in one of the next calls to getView(), we'll be able to retrieve it back via View#getTag(), skip the calls to findViewById() and save time !

Want to support this kind of content ? Buy Rany a Coffee