Если проект отличается от используемого вами патерна, это совсем не значит проект написан плохо. Послушать вас, так все MVP-проекты — «тяп-ляп», там знаете ли тоже presenter-ы есть))
Пардон, но статья о MVVM, а там Presenter отсутствует в принципе.
Отсюда у меня возникает логичный вопрос: зачем было приводить этот пример в самом начале, если ленивая инициализация не меняет принципов разработки?
Затем, чтобы опровергнуть постулат о том, что мы ДОЛЖНЫ использовать или Nullable переменную или lateinit.
Что же касается ленивого объявления, то в каком именно состоянии находится переменная до инициализация делигатом — документация умалчивает.
Можно написать простейший код, поставить точку останова и посмотреть, если интересно.
Если же нужно проверить и обработать данные та же google-документация рекомендует писать так:
Это все прекрасно может жить во ViewModel. Поверьте, и Гугл может быть не прав ))
При использовании Interactor получается идеально кристальные фрагменты и активити, которые служат только для обновления UI (если все сделать правильно). Полагаю, для крупных проектов такой подход имеет очевидные преимущества, но для небольших проектов разница едва ли будет заметна.
То есть если надо один гвоздь забить, а не десять — это можно делать тяп-ляп?))
Переменная так или иначе была проинициализирована, она не обрели 3-го состояния между Null и lateinit.
Хорошо, в каком она состоянии до первого обращения к ней?
Возникает логичный вопрос: зачем городить огород с прокидыванием моделей внутрь XML-файлов, вызывать в XML-файлах Java-методы, перегружать логику XML-части, если всего этого можно избежать?
А кто сказал, что это все необходимо при использовании Data Binding? Все что требуется это объявить переменную в начале файла, и затем ссылаться на нее в XML:
android:text=@{viewModel.text}
все функции обработки должны быть вынесены в сторонние классы и файлы («Presenters»), дабы не загромождать ViewModel и не отвлекать от сути.
Почему не Interactor или Usecase?
В результате архитектура стала кристально чистой, что является большим плюсом.
Если под чистой вы имеете ввиду Clean Architecture, то нет, получилась совсем не она.
Выглядит она примерно так: View -> ViewModel -> Interactor -> Repository. Уж точно без всяких классов Presenter, принадлежащих фрагментам. View должен делать одно и только одно: мапить уже подготовленные данные в лэйаут, без каких либо дополнительных преобразований, неважно используя синтетические импорты ли или Data Binding.
Kotlin старается защитить программиста от некорректного написания кода, поэтому мы должны либо сразу сказать, что объект может быть null, либо поставить lateinit.
вот прям кусок кода из оф документации без того и другого:
val lazyValue: String by lazy {
println("computed!")
"Hello"
}
В общем текст неплохой, но уж больно безапелляционный, с кучей маркетинговых словечек и фактических ошибок. Извините.
Работа с UI сейчас это одна из областей где все очень мутно. Типа вот вам ViewBindings — то же самый DataBinding но полегче и попроще, а вот еще Compose — абсолютно новая парадигма, где все надо вообще с нуля писать, а если и этого мало — во второй бете Q добавили экспериментальный компилятор View, который будет xml компилировать, чтобы не приходилось делать inflate в рантайме — выбирай, что хочешь, а что хотеть непонятно
про Kotlin-first и новый UI-framework(Jetpack compose) говорили на developer keynote, сразу после обычного. Фреймворк, видимо, переносят с Flutter, там в коде еще даже упоминания Dart не вычистили
Начиная с версии AGP 3.2 kapt не нужно указывать в зависимости, плагин сам все сделает. Ну и полная совместимость с Java это тоже не совсем верно. Те же самые функции с reified из Java просто не будут видны
В США нет обязательной прослойки GP, которым вы платите 20-40 евро из своего кармана при наличии страховки просто для того, чтобы получить направление к специалисту.
Возможно от страховки зависит, но бывает так, что без направления от PCP страховка не будет оплачивать анализы/мед. процедуры