Обновление данных из одного элемента в RecyclerView с помощью ViewModel и LiveData

1. создать класс PlaceListener

class PlaceListener (val clickListener: (p: Place) -> Unit) {
    fun onClick (p: Place) = clickListener (p)
}

2. поменяй адаптер

class RecyclerViewPlacesAdapter (
private val deleteClickListener: PlaceListener,
 private val updateClickListener: PlaceListener,
): ListAdapter <Place, RecyclerViewPlacesAdapter.ViewHolder> (PlaceDiffCallback ()) {

    override fun onCreateViewHolder (parent: ViewGroup, viewType: Int): RecyclerViewPlacesAdapter.ViewHolder {
       return RecyclerViewPlacesAdapter.ViewHolder.from (parent)
    }

    override fun onBindViewHolder (holder: RecyclerViewPlacesAdapter.ViewHolder, position: Int) {
        val item = getItem (position)
        return holder.bind (item, deleteClickListener, updateClickListener)
    }

    class ViewHolder private constructor (private val binding: ListTilePlacesBinding):
        RecyclerView.ViewHolder (binding.root) {

        fun bind (item: Place, deleteliCkListener: PlaceListener, updateClickListener: PlaceListener) {
            binding.apply {
                   buttonDelete.setOnClickListener {
                 deleteClickListener.onClick(item)
}
              buttonEdit.setOnClickListener {
           updateClickListener.onClick(item)
}
            }
        }

       companion object {
            fun from (parent: ViewGroup): RecyclerViewPlacesAdapter.ViewHolder {
                val layoutInflater = LayoutInflater.from (parent.context)
                val binding = ListTilePlacesBinding.inflate (layoutInflater, parent, false)
                return RecyclerViewPlacesAdapter.ViewHolder (binding)
            }
        }
    }

    class PlaceDiffCallback: DiffUtil.ItemCallback <Place> () {
        override fun areItemsTheSame (oldItem: Place, newItem: Place): Boolean {
            return oldItem == newItem
        }
        override fun areContentsTheSame (oldItem: Place, newItem: Place): Boolean {
// example of control of 3 properties
            return (
                    oldItem.property1 == newItem.property1 &&
                            oldItem.property2 == newItem.property2 &&
                            oldItem.property3 == newItem.property3
                    )
        }
    }
}

3. во фрагменте:

 private lateinit var adapter: RecyclerViewPlacesAdapter

// after you initialize the binding
adapter = RecyclerViewPlacesAdapter (
PlaceListener {place -> mViewModel.deletePlace (place)},
PlaceListener {place -> mViewModel.updatePlace (place)},
 )
val recyclerView = _binding!!.recyclerViewPlaces
recyclerView.adapter = adapter
      mViewModel.places.observe (viewLifecycleOwner) {places ->
            adapter.submitList (places)
            adapter.notifyDataSetChanged ()
        }

Если вам не нравится использовать adapter.submitList(places) и adapter.notifyDataSetChanged(), вы всегда можете передать им список в конструкторе (в этом случае в конструкторе адаптера у вас будет список объектов Place и 2 объекта placeClickListener )

В широком смысле идея состоит в том, что ваш ViewModel — это то, с чем общается слой пользовательского интерфейса (представление). Он предоставляет состояние данных (например, через объект LiveData), которое ваш пользовательский интерфейс observes, и это то, что управляет тем, что отображает пользовательский интерфейс. Наблюдатель получает новые данные -> вы их отображаете.

Пользовательский интерфейс также уведомляет виртуальную машину о взаимодействиях с пользователем — нажатиях кнопок и т.п. Итак, в вашем случае у вас есть функция deletePlace, которая в основном говорит виртуальной машине: «Эй, пользователь только что решил удалить это, делай то, что тебе нужно». Поскольку виртуальная машина представляет текущее состояние, это то, что вам нужно обновлять всякий раз, когда что-либо происходит (и она внутренне обрабатывает такие вещи, как сохранение этого состояния).

Это два совершенно разных пути, изолированных друг от друга. Помните, что пользовательский интерфейс отображает что виртуальная машина говорит ему, поэтому ему не нужно реагировать на нажатие пользователем кнопки удаления. Это просто перенаправляется на виртуальную машину. Если виртуальная машина решает, что состояние изменилось обновит свой LiveData, пользовательский интерфейс будет отслеживать новые данные, а потом обновит. Вы в основном рассматриваете виртуальную машину как источник правды и храните логику обновления вне уровня представления.

Это значительно упрощает работу, потому что, когда вашему пользовательскому интерфейсу просто нужно наблюдать за некоторым состоянием виртуальной машины, каждое обновление будет одинаковым. Фрагмент загружен, заполнение списка? Наблюдайте за LiveData, получайте результат, покажите его. Приложение восстановлено из фона, возможно, с уничтоженным процессом? Наблюдать за вещью, отображать всякий раз, когда приходит обновление. Пользователь удаляет вещь или обновляет ее? Вы наблюдаете за данными, когда изменение сохраняется, оно обновляется. И т.д! Каждый раз одна и та же логика. Не нужно беспокоиться о сохранении состояния при уничтожении фрагмента — все состояние находится в ВМ!

(Из этого могут быть некоторые исключения, например, если удаление требует сетевого вызова, может занять некоторое время, но вы хотите, чтобы изменение произошло немедленно в представлении. Но опять же, это может быть просто деталь реализации в виртуальной машине - это может обновить свое локальное состояние данных и позволить удаленному обновлению происходить в фоновом режиме)

Что касается реализации, лично мне кажется, что чище, чтобы ViewHolder вызывал метод в Adapter, например deleteItem(index: Int) или что-то еще — просто потому, что VH — это компонент пользовательского интерфейса, а адаптер — это то, что находится между набором данных и пользовательский интерфейс, предназначенный для его отображения. Больше похоже на то, что работа адаптера заключается в обработке «пользователь щелкнул удалить этот элемент» и т. д., Если это имеет смысл. Хотя это не имеет большого значения.

И типично делать Adapterinner class своего родителя Fragment - таким образом, если фрагмент имеет ссылку на модель представления, адаптер может просто ее увидеть. В противном случае вы можете просто передать/установить его на адаптере в качестве свойства во время установки. ViewModel — это общий ресурс, поэтому не беспокойтесь о его передаче.