Получаем результат правильно (Часть 2). Fragment Result API

Спасибо, интересно и профессионально

Cordova. Quick start

честно говоря не знаю нормально ли для кордовы или это у нас такая дичь была:
— ui на html и ccs. Плюс, что оно отлично скейлиться, минус, что все это генериться js. Буквально все, весь html код в строках. Размеры js — бесконечные полотна. Т.к. нельзя подключить один скрипт к другому, то легко было найти файлы по 2к строк — такое просто не может произойти на нативной реализации
— краши в WebView, и с этим ничего сделать не удалось — приложение просто вылетает с нативной ошибкой в WebView
В общем, при всей моей любви к разным фраемворкам и зверям это показался мне «самым-самым»)) Уж скорее я брошу программирование, чем начну писать так код. Кстати второй проект, так и не переписали на натив. У нас есть человек, который продолжает там что-то воять… о, ужас

Cordova. Quick start

Кордова это мрак. Получили в наследство 2 проекта на ней — один уже переписали на Натив, второй скорее всего переведем на flutter. Cordova быстрый старт для веб разработчика, и потому кажется лёгким решением, на самом же дело в конце вас ждёт фул-рефакторинг

Делаем простейший сборщик ошибок для Android

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

Meeting Room L̶i̶t̶t̶l̶e̶ Helper v 2

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

Meeting Room L̶i̶t̶t̶l̶e̶ Helper v 2

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

Все что требуется это объявить переменную в начале файла, и затем ссылаться на нее в 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, при пересоздание view-фрагмента? Если залезть в Profiler, то обнаружиться, что при каждом заходе на экран, canvas-библиотека будет создавать новую view, а вместо того, чтобы попытаться старую или хотя бы удалить ее. Как вы решаете эту проблему?