Со стороны пользователя, это скорее правда. Необходимо подождать, пока буду исправлены основные баги и все приложения поддержат новые фичи, для более комфортного использования системы.
Круто получилось. Когда разбирался с template тоже думал о подобном, но успокоился, когда FreeMarker стал работать и оставалось править только в файлах темлейтов, если что-то изменилось.
Вопрос: вы для темлейтов отдельный модуль делаете или где-то в common храните?
На самом деле способ при помощи которого другим в ногу стреляешь. Если человек не знает что нужно ставить именно через стандартные стили, будет долго гадать что пошло не так.
Предпочитаю явно ставить всегда font
Впринципе не плохая статья.
Пара замечаний:
1) в одном файле разный стиль, где то when где то каскад if else
2) вынести рессивером binding отчистить код
Хорошее дополнение, только нужно не забыть указать, что нужна зависимость androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha01 или выше.
Также нам нужен: viewLifecycleOwner.lifecycleScope
Потому что обычный lifecycleScope фрагмента будет отменяться в onDestroy, а нам нужно в onDestoryView
Есть пример экрана с recycler view с 8 разными view type, в которых ещё один recycler view, и это всё в некоторых случаях обновляется по diff callback а в некоторых через notify для изменения анимации
Нет, я имею ввиду саму операционную систему. Класс Application создаётся системой аналогично Activity. Если создать просто Application и нигде его не регистрировать lifecycle callbak не будут вызывать.
Вообще интересный подход к разработке.
Если назвать KittenComponent — KittenPresenter, всё встаёт на свои места. По сути это тот же MVP, только state храниться в моделях, а Presenter уже больше proxy.
Из плюсов, явно, это восстановление состояния после пересоздания Fragment, не нужно никаких дополнительных фреймворков.
Хотел бы увидеть большой пример, не будет ли это всё громоздко.
Да, живее всех живых. В нашей компании 90% проектов на ней.
Сейчас Google активно продвигают MVVM, поэтому может казаться, что MVP уходит, но оно как выполняло все необходимые функции, так и выполняет.
Вижу в этом смысл, когда реально тесты написаны, и ты уже не знаешь чем себя занять. Для меня реальность такова что обычно не успеваешь даже половину запланированных тестов написать. Было бы интересно узнать какой процент счастливчиков, которые написали все тесты
По поводу RecyclerView, не пробовали ли вы использовать ListAdapter, который использует DiffUtils под капотом? Было бы более интересно если бы вы описали старинный кейс, когда при notify, пересоздается view. А если в общем, всё что вы здесь представили напрочь нарушает разделение по слоям приложение. Если у вас безнес логика напрямую вызывает View, у меня для вас плохие новости
Хм.
В моём понимании чистый build - это сборка без каких-либо кешей. В статья кокраз для этого привожу option no-build-cache
Крутой подход на самом деле!
Убирает много магии и главное не упадёшь в runtime.
Остаётся только донести до остальных, что di не всегда сложный.
Вопрос только в данных, которые вы приложили.
Выглядит, что это не чистый build, поскольку пропущено много задач
Хотел бы добавить, что посмотреть PSI структуру текущего кода хорошо помогает Psi Viewer
Флаги мутабильности интентов выползли в очень многих библиотеках.
Есть ощущение что Google нужно было это подготовить и сделать вначале warning, и объявить на всех. А уже потом делать error.
Со стороны пользователя, это скорее правда. Необходимо подождать, пока буду исправлены основные баги и все приложения поддержат новые фичи, для более комфортного использования системы.
Не рассматривали вариант просто вернуться к адаптору от Вортана?
Интересный подход сам по себе.
Главный вопрос — на сколько сильно раздувается AppState в большом приложении?
То есть вы его собрали как артефакт и через dependencies подключаете?
Вопрос: вы для темлейтов отдельный модуль делаете или где-то в common храните?
На самом деле способ при помощи которого другим в ногу стреляешь. Если человек не знает что нужно ставить именно через стандартные стили, будет долго гадать что пошло не так.
Предпочитаю явно ставить всегда font
Впринципе не плохая статья.
Пара замечаний:
1) в одном файле разный стиль, где то when где то каскад if else
2) вынести рессивером binding отчистить код
Хорошее дополнение, только нужно не забыть указать, что нужна зависимость
androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha01 или выше.
Также нам нужен:
viewLifecycleOwner.lifecycleScopeПотому что обычный lifecycleScope фрагмента будет отменяться в onDestroy, а нам нужно в onDestoryView
Есть пример экрана с recycler view с 8 разными view type, в которых ещё один recycler view, и это всё в некоторых случаях обновляется по diff callback а в некоторых через notify для изменения анимации
Нет, я имею ввиду саму операционную систему. Класс Application создаётся системой аналогично Activity. Если создать просто Application и нигде его не регистрировать lifecycle callbak не будут вызывать.
Вообще интересный подход к разработке.
Если назвать KittenComponent — KittenPresenter, всё встаёт на свои места. По сути это тот же MVP, только state храниться в моделях, а Presenter уже больше proxy.
Из плюсов, явно, это восстановление состояния после пересоздания Fragment, не нужно никаких дополнительных фреймворков.
Хотел бы увидеть большой пример, не будет ли это всё громоздко.
Да, живее всех живых. В нашей компании 90% проектов на ней.
Сейчас Google активно продвигают MVVM, поэтому может казаться, что MVP уходит, но оно как выполняло все необходимые функции, так и выполняет.