Для 7-го случая есть DiffUtils
Зачем вот это «distinctLiveData.postValue(lastObj)» — подписка на LD всегда в MainThread, а в нем нужно вызывать setValue()

Наверное retain фрагменты не подойдут, если у нас clear arcitecture or mvvm.
По сути retain позволяет сохранять данные во фрагменте но все равно пересоздает UI. А если мы храним данные в другом слое необходимости в этом нет.

Если только мы не привязываем один хостовой фрвгмент к ЖЦ приложения для обработки чего либо ранее бывшего в application))(но я так не делал)

Вообще странно, что по умолчанию GOOGL не сделал активити android:configChanges=«orientation» а фрагмент retain, в противном случае это похоже уже на костыль против порочной логики пересоздания. Хотя я могу заблуждаться

Да, спасибо!
Буду разбираться.

Я так и говорю. Обрабатываем повороты, но если Вы предлагаете увязать жизненный цикл активити к циклу приложения то не обойтись без android:configChanges=«orientation» (я так понял другого варианта нет?), что нам не мешает обрабатывать повороты, но придется в сложных случаях обрабатывать колбэк onConfigurationChanged()

Просто сейчас реализую Single Activity App со всеми поворотами, но в моем проекте она все же пересоздается при поворотах т.е. параметра android:configChanges в манифесте нет.

override fun onResume() {
   super.onResume()
   activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_SENSOR
}

override fun onPause() {
   super.onPause()
   activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
}

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

<activity android:name=".AppActivity"
android:configChanges=«orientation» />

нам же не нужно устанавливать в моем случае флаги SCREEN_ORIENTATION_PORTRAIT и SCREEN_ORIENTATION_SENSOR

Замечательная статья, спасибо!

Немного не понятен один вопрос. Предположим мы берем приложуху с не залоченным экраном, а нормальное полностью адаптивное приложене, обрабатывающие повороты и разные размеры и все что только нужно. Вы предлагаете использовать SinglActivity и увязывать ее жизненный цикл с жизненным циклом приложения. Если я правильно Вас понял, то такой подход возможен только при android:configChanges=«orientation», в противном случае наша активити при повороте будет пересоздаваться.
Резюмируя — для адаптивных приложении Вы советуете использовать android:configChanges=«orientation»?

protected val items: ArrayList = ArrayList()
protected val items: List = mutableListOf<>()
Это же Kotlin

override fun addAtPosition(pos: Int, newItem: IBaseListItem) {
items.add(pos, newItem)
notifyItemChanged(pos)
}
По мне data binding адское зло…

Изначально при разработке приложения было некое подобие MVC, где контроллером служили Activity/Fragment

Хм, а что тогда View, если контроллер это Activity/Fragment?
Все время считал View — это Activity/Fragment а Controller — это отдельные сущности / классы, что бы можно было при необходимости заменить Activity/Fragment на другую view (на другой платформе), но при этом не менять внутренней логики.

Отличная серия! Спасибо))
Rx будет прям в тему.