Георгий Чеботарев Georrg

хмм… а что насчет модулей? работает ли такой подход для перехвата exception в модулях? например, в canvas-библиотеке?

Если проект отличается от используемого вами патерна, это совсем не значит проект написан плохо. Послушать вас, так все MVP-проекты — «тяп-ляп», там знаете ли тоже presenter-ы есть)) Что же касается ленивого объявления, то в каком именно состоянии находится переменная до инициализация делигатом — документация умалчивает. Логично было бы предположить, что до вызова setValue (метода делигата) переменная находится в неопределенном состоянии. Однако, без вскрытия компилятора вы никак не получите ее в этом состоянии. Отсюда у меня возникает логичный вопрос: зачем было приводить этот пример в самом начале, если ленивая инициализация не меняет принципов разработки? Идея lateinit и объявления переменной null заключается в том, чтобы свести вероятность NullPointerException к нулю, и конечно lazy-инициализация не нарушает этой идеи.

Спасибо за ответ. Приятно, когда статью не только читают, но и рассматривают критически.

Все что требуется это объявить переменную в начале файла, и затем ссылаться на нее в XML

+ обернуть все в

<layout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto">
    <data>
        <variable
            name="viewmodel"
            type="com.myapp.data.ViewModel" />
    </data>
    <ConstraintLayout... /> <!-- UI layout's root element -->
</layout>

И конечно, это самый простой случай использования data binding. Если же нужно проверить и обработать данные та же google-документация рекомендует писать так:

android:text="@{String.valueOf(index + 1)}"
android:visibility="@{age > 13 ? View.GONE : View.VISIBLE}"
android:transitionName='@{"image_" + id}'

Не знаю, как Вас, но меня скручивает от возможности написать такое. Это выглядит программированием из 2000-х или даже из 90-ых. Синтаксис и конструкции морально устарели, и нуждаются в качественном осовременивании. На всякий случае, еще раз скажу — я не против data binding, но только там, где он по-настоящему уместен. Без острой нужды, я не стану им пользоваться.

Почему не Interactor или Usecase?

При использовании Interactor получается идеально кристальные фрагменты и активити, которые служат только для обновления UI (если все сделать правильно). Полагаю, для крупных проектов такой подход имеет очевидные преимущества, но для небольших проектов разница едва ли будет заметна. И в случае с Presenter, и в случае с Interactor результат будет аналогичным — фрагменты и активити будут чисты от data-преобразований.

val lazyValue: String by lazy {
    println("computed!")
    "Hello"
}

На сколько я помню, этот код выполняет отложенную инициализацию: при первом обращении к переменной lazyValue, присвоить ей значение «Hello» и вывести в консоль «computed!». Переменная так или иначе была проинициализирована, она не обрели 3-го состояния между Null и lateinit. Разумеется, Kotlin не защитит разработчика от желания стрелять себе в ноги, но значительно снизить эту вероятность. Думаю Вы с этим согласитесь.

P.S. искренни благодарен за feedback.

а как вы обрабатываете дубляжи view, при пересоздание view-фрагмента? Если залезть в Profiler, то обнаружиться, что при каждом заходе на экран, canvas-библиотека будет создавать новую view, а вместо того, чтобы попытаться старую или хотя бы удалить ее. Как вы решаете эту проблему?