Wrap it and build faster with ButterKnife and Abstraction — Android

Remove Redundancy and let the new come in.

In Android Application Development, one thing which a developer get to introduced in the very beginning and then almost every day, is this statement

findViewById(R.id.viewId);

Well, it has a very important role in development because a view should be binded before accessing it in an Activity or Fragment. But, what if you have multiple views for which you keep on writing findViewById statement multiple times? It is irritating and doesn’t looks good. It’s Redundant.

It can’t be completely omitted but can be written in a structured and decent manner. ButterKnife which is a Field and method binding for Android views solves this problem in a nice and effective manner. Let’s take a look at it.

Regular way of binding

FloatingActionButton addButton = (FloatingActionButton)findViewById(R.id.add_button);

Using ButterKnife

@BindView(R.id.add_button)FloatingActionButton addButton;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    ButterKnife.bind(this);
}

Looks Better. Isn’t it!

We first bind the views using the annotation @BindView and then let ButterKnife know about it by just writing ButterKnife.bind(this) in onCreate() of our Activity or ButterKnife.bind(this, inflatedView) in onCreateView() of our Fragments.

Not just Views but we can even bind our resources using ButterKnife.

Regular way of using resource

String name = getResources().getString(R.string.name);
int color = ContextCompat.getColor(this, R.color.black);

Using ButterKnife

@BindString(R.string.name)String name;
@BindColor(R.color.black) int color;

See how easy it is. You can bind any type of resource like int, float, array, drawable, color and many more. This somehow also protect you from worrying about the deprecated methods. Check out the ButterKnife page and you’ll get more out of it.

Wait! Using ButterKnife was a good upgradation but everything has a cost. Because we bind views and so we have to unbind them. Doing it in every Activity/Fragment is again a different pain altogether. So what do we do now?

Yes, Abstraction comes in here. We can abstract all what is important but need not to be repeated every time.

So, we’ll now create an abstract class called as BaseActivity, which will handle the binding and unbinding of views. All our Activities will just extend it. Here’s how.

BaseActivity.java

And now we can extend it as

public class TestActivity extends BaseActivity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }
    
    @Override
    protected int getActivityLayout() {
       return R.layout.activity_test;
    }
}

As you can see in BaseActivity, there is one abstract method getActivityLayout(). This is one add on to our BaseActivity because now we don’t have to write setContentView(int) as well in our child Activities. We can even create BaseFragment and BaseDialogFragment for our Fragments and DialogFragments. Check out my gist.

Also, as the architecture components are out there, we can even make our BaseActivity as LifeCycle aware.

BaseActivity as LifeCycle Owner

So less struggle, less redundancy, more of Abstraction and faster execution.

That’s it! You can check my gist for complete code.

Happy Abstraction:)

Cheers!