• Описание того или иного паттерна, является моей сугубо личной интерпретацией теоретического и практического материала, собранного из книг и интернет-статей;
• При построении UML-диаграмм, я буду использовать свободный редактор от компании astah, ввиду его простоты и независимости от конкретного языка или среды. При этом, диаграммы не будут отличатся изобилием картинок и цветов, но будут ясно отображать суть паттерна;
• При реализации практических примеров, язык программирования будет выбираться совершенно случайно. Однако, я буду стараться подбирать те языковые средства, на которых данный паттерн реализуется не тривиально;
• Каждый мой пост, будет содержать как минимум 5 секций — Проблема, Описание патерна, Практическая задача, Диаграмма классов и Реализация;
• Если Вы, с чем-то не согласны или у Вас есть дополнения к материалу, изложенному мной — я буду рад их почитать в комментариях. Однако, помните — я тоже изучаю паттерны вместе с Вами :)

1. «обезопасить» свои адаптеры от внесения туда лишней логики;
2. переиспользовать биндинги ячеек;
3. добиться какой-то универсальности для работы с несколькими типами ячеек.

• как можно упростить поддержку DiffUtil в этой реализации;
• как добавить поддержку вложенных RecyclerView.

Всегда приятно общаться с приложением, которое запоминает твои повадки и словно чувствует тебя, того, что ты хочешь. Любая UI библиотека или платформа обладает увы лишь базовым функционалом и набором компонент. Например, если колонка в таблице не перемещается или по ней нельзя отсортировать, то такое приложение, в котором она используется сложно назвать дружелюбным. К счастью, сегодня таким функционалом никого не удивишь. Однако, не каждая программа запомнит положение этой колонки и в следующем сеансе отобразит ее именно на том же месте. Возможно, также будет раздражать каждый раз устанавливать положение разделителя в SplitPane или вводить одни и те же параметры фильтра. Как правило, такие удобства приходится обеспечивать самим разработчикам.

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

• формируем несколько базовых классов и интерфейсов для работы с RecyclerView и RecyclerView.Adapter
• подключим одну библиотеку из Android Jetpack (по желанию, сначала без нее)
• для еще более быстрой разработки — вариант темплейта в конце статьи ;)

Уже примерно после 3-его самописного адаптера, в котором надо было реализовывать логику запоминания выбранного элемента, у меня появились мысли, что должно же быть какое-то решение, которое уже включит в себя всё необходимое. Особенно, если в процессе разработки приходилось менять возможность выбора только одного элемента на множественный выбор.

После изучения подхода MVVM и полноценного погружения в него, упомянутый выше вопрос встал намного более заметно. Тем более, что сам адаптер находится на уровне View, в то время как информация о выбранных элементах зачастую крайне необходима для ViewModel.

Возможно, я провёл за поиском ответов в интернете недостаточное количество времени, но, в любом случае, готового решения я не нашёл. Однако в одном из проектов мне пришла идея реализации, которая вполне могла бы быть универсальной, поэтому мне захотелось поделиться ею.

Для отображения списка данных мы используем RecyclerView (– Спасибо, кэп!). Он много чего умеет из коробки и другие всем известные блаблабла. Но и боли с ним предостаточно. Никто не любит писать один и тот же boilerplate-код. И я вот не особо...

В своей предыдущей статье я рассказал о первой попытке написать библиотеку для простого и удобного выбора элементов из списка в Android с учётом подхода MVVM. В прошлый раз решение не было привязано к платформе, поэтому конечной цели я не достиг.

Спустя несколько месяцев, когда я достаточно подумал, попрокрастинировал и поработал, у меня уже получилось решение, более подходящее именно для Android, так как основано на LiveData. Прошу всех интересующихся ознакомиться.

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