As you may know, the Support Library 24 included a new really handy class called DiffUtil, which will let you get rid of the boring and error prone of detecting which cells changed and update them

If you haven’t heard about it, you can take a look at this nice article from Nicola Despotoski, which explains quite easily how to deal with it.

As usual, Java language introduces a lot of boilerplate, and I decided to investigate what we can get when implementing this using Kotlin.

The example

For the example, I’m creating a small App (which you can download from Github) that randomly selects the set of items that will be next included in the RecyclerView from a list of 10.


So, from one iteration to the next one, some of them will be repeated, some of them will have disappeared, and some other will enter as new.

If you know how RecyclerView works, you may know that to notify those changes to its adapter, you have these three methods:

  • notifyItemChanged
  • notifyItemInserted
  • notifyItemRemoved

And their corresponding Range variations.

Join my free 2-hour training!

  • Learn how to start and use a more idiomatic Kotlin in a breeze
  • Find out what's the current situation of Kotlin in the market
  • Get 2 free ebooks just for attending!

The DiffUtil class will do all the calculations for us, and will call the required notify methods.

The raw implementation

For a first iteration, we could just get the items from a provider, and let the adapter notify the difference (not the best code ever, but you’ll understand soon why it’s done like that):

Easy: I save the previous items, generate the new ones, and say the adapter to notifyChanges, which is a method that uses DiffUtil:

This is really annoying, because most part of the code is basically boilerplate, but we’ll get back to it later.

Now, you saw that I’m calling notifyChanges just after setting the new set of items.

So why don’t we delegate that behaviour?

Using delegation to make notifications simpler

If we know that we are notifying every time the set of items change, let’s just use, which leaves an awesome code:

The activity is much simpler:

And the observer looks quite nice:

Awesome! But this can be better.

Using extension functions to improve adapter capabilities

Most of the code in notifyChanges is boilerplate. If we use data clases, we just need to implement a way to detect that two items are the same, even when their content isn’t.

In the example, the way to identify this is the id.

So I’ll create an extension function for the adapter that will do most of the hard work for us:

The function receives the two sets of items, and another function. This last parameter will be used in areItemsTheSame to decide whether two items are the same or not.

And now to the call:

Using composition

I can understand that you don’t like the previous solution very much. It’s rather specific to a particular case, and you don’t want that all adapters can use it.

But there’s an alternative: an interface.

Sadly, interfaces can’t extend classes as they did at some point of Kotlin preview (I really hope it’s re-added in the future). This let you use the methods of the extended class, and forced classes that implement the interface to be of that type.

But we can get a similar result by moving the extension function into an interface:

And the adapter just needs to implement this interface:

And that’s all! The rest of the code remains unchanged.


There are several ways to use DiffUtils that make code look great and simpler than in Java. You can choose any of them.

If you want to try any particular solution, go to the repository and move to the specific commit.


%d bloggers like this: