Beginning RecyclerView - Part 7: Challenge: | Ray Wenderlich Videos

🎓 Courses & Articles
1

Take all the basics of RecyclerView that you've learned so far to build a Favorites screen for the sample app.

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/4568-beginning-recyclerview/lessons/7
2

When updating the data set for the adapter with new favorites:

Is there an advantage to using this.creatures.clear() and then this.creatures.addList(creatures) instead of making the creatures property mutable and re-assigning it?

3

Generally I prefer immutable values over mutable ones, unless performance becomes a concern, in which case a performance analysis could be done to see which approach is more performant.

5

Generally I prefer immutable values over mutable ones

Definitely. So in this case is there a preference for immutable property assignment over immutable data?

For example, the solution for this video stores a private mutable list that is reset with new data:

class CreatureAdapter(private val creatures: MutableList<Creature>) 
    : RecyclerView.Adapter<CreatureAdapter.ViewHolder>() {

    fun updateCreatures(creatures: List<Creature>) {
        this.creatures.clear()
        this.creatures.addAll(creatures)
        notifyDataSetChanged()
    }

    // ...
}

As opposed to a mutable private creatures assignment of an immutable list:

class CreatureAdapter(private var creatures: List<Creature>) 
    : RecyclerView.Adapter<CreatureAdapter.ViewHolder>() {

    fun updateCreatures(creatures: List<Creature>) {
        this.creatures = creatures
        notifyDataSetChanged()
    }

    // ...
}

I was really curious if their was an advantage to the first approach as it pertained to RecyclerView usage. The latter is more concise, but I wasn’t sure if that was the only benefit. If this just comes down to preference, that’s fine.

Either way, thanks for making a great series of videos. I learned a ton!

6

@macsimus Can you please help with this when you get a chance? Thank you - much appreciated! :]

7

Although it may not be relevant in this app, I think there is a general tendency to make a list that is central to an app be a constant property and a mutable list, rather than replacing the list. If any other class object has a reference to the list, such as a helper utility, it will always be accessing the current data. If you replace the main list, you would also need to reset any references to it, else those references will still be to the original list.

So if you make this.creatures, and then set a reference to it, i.e. helper.creatures = this.creatures, changes you make to this.creatures will also show up in helper.creatures. If you replaced this.creatures, on the other hand, helper.creatures would still reference the old list, until you set it again. It is that kind of maintenance in a larger app that makes the mutable list content appealing.