Why I Ditched ButterKnife

Am I the first person to ever diss Jake Wharton's Butter Knife?

UPDATE (22nd June 2016)

I have just found an Android Studio plugin to remove ButterKnife – details at the end of this post.


I was recently working on an Android development project where one of the engineers introduced Butter Knife. I didn’t see much benefit in using the library, apart from slightly cleaner code, but went along with the idea anyway. But the more I worked with the library the more frustrated I got with its shortcomings, and eventually I took the library out of the app and went back to normal Android code.

The idea of Butter Knife is to give you cleaner code in your activities and fragments. For example, to bind Activity fields to their views, instead of this

You can write this

And to bind view listeners to methods, instead of this

You write this

I’m sure you’ll agree this is a lot neater than writing all that boilerplate code, especially when you have a lot of views to bind to fields and listeners. And the really clever thing about ButterKnife is that it does this at compile time, not at runtime using reflection, so there is no performance hit.

So all good yes? Certainly if you read most blogs about it they have nothing but praise. Check this one out by Trey Robinson, especially number five in his reasons for using ButterKnife. Seriously? Don’t get me wrong, Jake Wharton and the guys at Square do some good shit, and are probably better Android developers than I’ll ever be, but ActionBarSherlock is not one of their finest endeavors.

The first thing I disliked about the library was the access modifier requirement on fields. Take a look again at my example of binding a TextView to a field, notice the lack of access modifier. This is because fields bound with ButterKnife have to be either public or package private, as this one is. I know this isn’t a big deal, but access modifiers are specified for a reason, and making a field package private (or even worse, public) when it is not intended for that purpose is plain sloppy in my view.

Another thing is that you can only bind class level fields, so if you only want to reference a view once in your class, for example in the initialisation of your activity you might have a line like

But with ButterKnife you would be forced to create a class level field for this, even if that variable was only used once. Again, to me, this seems sloppy and makes the code less readable.

But then came the real deal breaker.

In Android Studio there is a lint inspection called  WrongViewCast. So if you do something like

And in the xml layout file the view with an id of text_name  is defined as a Button , the error will be highlighted in your code:

It doesn’t work 100% of the time as you could have more than one view with the same id in various layout files, but it is still a really useful feature to help pick out errors as you code.

But of course with ButterKnife, you lose this inspection. So errors like that will lead to a crash, and if that piece of code is only executed in specific conditions, it might not be you who gets the crash.

Each of these issues I have with ButterKnife are fairly minor, and are more inconvenient niggles than anything more serious. But when you add them all together I think it destroys enough of the Android development paradigm to make ButterKnife a library spawned by the devil. Which is why we don’t use it in our project anymore.

I’m interested to hear your thoughts and experiences with this, so please leave a comment below.

Must dash, Great British Bake Off is on, who’ll be leaving the tent tonight?


 

UPDATE (22nd June 2016)

I just found this Android Studio plugin on Android Arsenal that says it will remove all ButterKnife code from your project. Wish I’d known about it at the time I wrote this article, as it was a real pain taking all that code out and replacing it with findViewById . I haven’t tried the plugin myself (as I don’t have ButterKnife in any of my projects anymore, natch), so if you do try it please leave a comment here and let us know how it is.

Leave a Reply

Your email address will not be published. Required fields are marked *