Слишком хитро завернул)) А там потом пойдет слабая связанность, "типа реюз" кода, и туда-же тесты которые без DI нормально не написать

Аргументы переданные в кастомный конструктор фрагмента не переживают смену ориентации

смотря как его использовать

🤦‍♂, почему я никогда до этого не додумывался :)
Спасибо за идею)

и не я это придумал. Взял у Harmonizr

Скорее понять, стоит ли их разделять в этой архитектуре(mvvm) Т.к. думаю,что есть вероятность, что после редактирования наблюдатель(подписка же во view идёт?) может не получить событие,что нужно сохранить данные. Например после нажатия редактирования и нажатия ок, пользователь ожидант,что данные сохранятся, но происходит вход.звонок и система убивает приложение = наблюдатель не успел получить событие🤷

я не понял, для чего

Конструктор в фрагментах нельзя использовать, так как при восстановлении фрагмента, приложение упадет

Можно, надо просто завести фабрику.

для чистоты архитектуры ) я в процессе изучения

не упадет
https://t.me/Android_Architecture/120241

У кого есть рецепт, как нормально создать integrationTest сорссет (либо любое другое название) в андроид модуле? Сейчас у меня вот такой хак, то есть тесты оттуда запускаются вместе с обычным test, и все проходит, но в студии поддержка не работает: не находятся импорты, нет gutter иконок никаких, и т.д.

sourceSets {
       androidTest {

Не, androidTest это не то, это ui тесты, а я хочу на обычном жвм запускать

Я правильно понимаю, что паттерны проектирования MVP, MVC, MVVM и т.д независимы от платформы, т.е одни и те же паттерны применяются на iOS, Android, Desktop? Меняется только их соотношение в использовании?

В целом да

Есть книга "Чистая архитектура" (Роберт Мартин). Думаю, она поможет по полочкам разложить принципы построения приложения. Так то эти паттерны построены на базовых принципах разработки и выбор между этими паттернами это все-таки детали

Да, я слышал о ней и о других не менее полезных книгах. Тут, скорее проблема не в том, что я этого пока не знаю, а в количестве возможных вариаций. Ведь даже если все в идеале освоят SOLID, чистую архитектуру, основные паттерны, код все равно одинаково писать не будут. Появятся компоненты или какие-нибудь нюансы, которые нарушат четкие границы между слоями. Однозначности для всех очень сложно достичь. Я до сих пор не могу найти однозначного расположения методов внутри одного класса - кто-то считает, что переопределенные должны быть вверху, кто-то считает внизу, то же самое и с companion object в Kotlin. Что делать?

Для начала понять, какую задачу решаешь. Единого решения для всех кейсов нет, только трейдоффы.
Нужно придти к единому мнению с командой. Утвердить кодстайл, определить скоуп бизнес задач.

Тоже самое и с архитектурными решениями. Исходя из временных ограничений, наличия готового инструментария будет решаться что выбирать.

Это все очень размыто и дать конкретный ответ не получится, поэтому и столько споров