Introduce a generic data-binding-enabled RecyclerView adapter

[BenHenning]

This introduces a data-binding-enabled RecyclerView adapter that can be used to both data-bind a list to a RecyclerView, but also continue data-binding for RecyclerView-owned Views. It also simplifies RecyclerView construction immensely. See #106 for a working example. Snippets from that CL include:

Data-binding a list of items to the RecyclerView adapter

  <androidx.recyclerview.widget.RecyclerView
    android:id="@+id/recyclerView"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
    app:data="@{viewModel.topicListSummaryLiveData}"/>

Data-binding each topic list summary to a constituent view contained in RecyclerView

<?xml version="1.0" encoding="utf-8"?>
<layout
  xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:app="http://schemas.android.com/apk/res-auto">

  <data>
    <variable
      name="topicSummary"
      type="org.oppia.app.model.TopicSummary"/>
  </data>
...
    <TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="@{@plurals/lesson_count(topicSummary.canonicalStoryCount)}"
      android:textColor="@android:color/white"
      android:fontFamily="sans-serif-light"
      android:textStyle="italic"
      android:textSize="14sp"
      android:layout_margin="8dp"
      app:layout_constraintStart_toStartOf="parent"
      app:layout_constraintBottom_toBottomOf="@+id/bottom_topic_bar"/>
  </androidx.constraintlayout.widget.ConstraintLayout>
</layout>

Setting up the adapter for the RecyclerView

  private fun createRecyclerViewAdapter(): BindableAdapter<TopicSummary> {
    return BindableAdapter.Builder
      .newBuilder<TopicSummary>()
      .registerViewDataBinder(
        inflateDataBinding = TopicSummaryViewBinding::inflate,
        setViewModel = TopicSummaryViewBinding::setTopicSummary)
      .build()
  }

Creating the root RecyclerView

    val binding = TopicListFragmentBinding.inflate(inflater, container, /* attachToRoot= */ false)
    binding.recyclerView.apply {
      adapter = createRecyclerViewAdapter()
      // https://stackoverflow.com/a/50075019/3689782
      layoutManager = GridLayoutManager(context, /* spanCount= */ 2)
    }
    binding.let {
      it.viewModel = getTopicListViewModel()
      it.lifecycleOwner = fragment
    }
    return binding.root

There are some limitations right now (such as assuming only one view model and nothing else needs to be bound to child views), however since functions are passed in these can be worked around. The builder interface for the adapter also isn't great, and runtime type checking is needed due to an issue with the data-binding library not supporting binding to reified inline Kotlin functions (for the custom binding adapter). That being said, this approach is really powerful given that it enables reactive data-binding fully through RecyclerView, and it significantly simplifies the creation process for a RecyclerView adapter.

I haven't tested the multiple view types case yet, and there aren't yet any tests for this adapter. I'm looking for early feedback before I work on stabilizing this.

[BenHenning]

@veena14cs answering your question from #106, setting up multiple views should look something like this:

  private enum class ItemTypes(internal val numericType: Int) {
    FIRST_ITEM_TYPE(0),
    SECOND_ITEM_TYPE(1)
  }

  private fun createRecyclerViewAdapter(): BindableAdapter<TopicSummary> {
    return BindableAdapter.Builder
      .newBuilder<TopicSummary>()
      .registerViewTypeComputer { item ->
        return when(item) {
          is FirstItemType -> FIRST_ITEM_TYPE.numericType
          is SecondItemType -> SECOND_ITEM_TYPE.numericType
          else throw Exception("Unexpected item: $item")
        }
      }.registerViewDataBinder(
        viewType = FIRST_ITEM_TYPE.numericType,
        inflateDataBinding = FirstViewBinding::inflate,
        setViewModel = FirstViewBinding::setFirstViewModel)
      .registerViewDataBinder(
        viewType = SECOND_ITEM_TYPE.numericType,
        inflateDataBinding = SecondViewBinding::inflate,
        setViewModel = SecondViewBinding::setSecondViewModel)
      .build()
  }

[rt4914]

LGTM

[vinitamurthi]

General lint question to @BenHenning and others. Are we going to follow Github's line length or keep it to android studio?
I personally would prefer keeping it same as Github because reviewing gets a little weird when comments/code wrap to the next line in the review view

[vinitamurthi]

remove 'should' in the comment

[BenHenning]

Done. Good catch.

[jamesxu0]

LGTM

[BenHenning]

@jamesxu0 this has now been updated to develop for you to merge downstream for your pending PR. I still need to finish it before both PRs can be submitted, though.

[BenHenning]

I found my issue with the tests. It turns out that not setting a content view and simply adding a fragment to an activity without a container results in its views never being attached to the activity (presumably because there's no root view). This led to both Robolectric & Espresso failing (the Espresso tests also had an unintentional deadlock). Both are fixed and now writing new tests is unblocked.

[BenHenning]

Thanks all for the review.

@vinitamurthi regarding your earlier line length comment: GitHub doesn't enforce a line length. We should follow the Google style guide 100 characters, but at the moment I'm arbitrarily following Android Studio's 120 characters. I'm hesitant to enforce anything below 120 until we have a decent reformatter to use to fix existing code.

[BenHenning]

NB: Please do take a look at tests @vinitamurthi / @rt4914 / @jamesxu0 however I'm submitting this as-is to unblock downstream work.