Был законопроект на ограничение ввоза терминалов (только операторы связи и только терминалы, на которые есть разрешение). Только не знаю, приняли его или нет.
Я долгое время использовал Moxy, и меня не покидало ощущение, что с этим ViewState я делаю абсолютно тоже самое что и в MVVM. 99% времени я использовал только AddToEndSingleStrategy и OneExecutionStateStrategy (как наверное и все пользователи этой библиотеки).
@StateStrategyType(AddToEndSingleStrategy::class)
fun switchProgress(show: Boolean)
// Тоже самое что и
val progress: LiveData<Boolean> // или BehaviourRelay / StateFlow
@StateStrategyType(OneExecutionStateStrategy::class)
fun showToastError()
// Тоже самое что и
val toastError: SingleLiveEvent<Unit>
В итоге с кодогенерацией получался некий мост между MVP и MVVM, когда ViewState всегда хранил актуальное состояние экрана и выступал в роли ViewModel, на которую "подписывалась" View, а Presenter менял состояние через ViewState. Так нужен ли этот мост сейчас, когда есть LiveData (либо любой другой Android-независимый Observable) и ViewModel? (раньше точно нужен был, т.к. в то время Jetpack'a еще не было)
Фича пока недоступна для пользователей, так что даже после релиза сравнивать будет не с чем.
Честно, не знаю. Все зависит от Вашего проекта. В моем случае на создание прототипа ушел один день, потом несколько дней я его причесывал, чтобы показать на код ревью было не стыдно, и чтобы можно было легко переиспользовать.
Диалог появляется только на тяжелых фичах от 10 мегабайт, мне кажется такой размер набить можно либо нативными либами, либо видеофайлами. Так что в большинстве случаев, для юзера все выглядит как обычная загрузка данных экрана.
Важно конечно экономить по возможности и место, и трафик. Но Dynamic Delivery про экономию именно места. Приложения ведь чаще всего по Wi-Fi обновляются.
Но будет экономия в размере апк в 10-20мб
Это же очень много. Каждый сэкономленный мегабайт в APK, это 3 после установки. А экономить нужно как минимум по двум причинам (кроме чистой совести):
Согласно законодательству о защите прав потребителей, разработчики платных приложений и приложений с платным контентом обязаны указывать в аккаунтах свой физический адрес. Отсутствие этих данных может привести к блокировке приложений в Google Play.
Требование Google. Для юридических лиц можно указать адрес регистрации, а вот для физических лиц нужно видимо указывать домашний адрес.
@Keep это не только про обфускацию, но и про оптимизацию тоже. Например, геттеры могут быть удалены и заменены прямой работой с полем класса. Может в R8 еще каких-нибудь оптимизаций добавят (или уже добавили).
написав новый ивент легко забыть добавить его в when
А вот если бы Event был sealed class'ом, то не забыли бы. Но вот разрастание when'a никак остановить не получилось бы. Как вариант размазать этот when по куче маленьких классов-обработчиков конкретного типа события.
Мы уже начали экспериментировать интеграцией MVICore с Reaktive, но публичных результатов в ближайшее время не будет. А пока в качестве теста мы для небольшого внутреннего продукта сделали сильно урезанную версию MVICore, в которой нет Postprocessor, News и некоторых других вещей.
Так что советую пока пользоваться своим собственным велосипедом, ведь он уже ездит.
Тогда используйте эту перегрузку в примере с RecycleView. Иначе складывается впечатление, что такой важной функциональности нет, и заданные в xml LayoutParameters безнадежно теряются.
А там только 1 параметр передать можно? Без родительского контейнера как в обычном inflate(id, viewGroup, attach)? Таким образом не потеряются ли LayoutParameters, которые я описал в xml? Например в том же примере с RecyclerView, если я задам item_person.xml высоту в 50dp, то разве она не будет заменена на WRAP_CONTENT, поскольку он является значением по-умолчанию для LinearLayoutManager? Или если этот layout – кусок ConstraintLayout'a, который я добавляю в рантайме?
Был законопроект на ограничение ввоза терминалов (только операторы связи и только терминалы, на которые есть разрешение). Только не знаю, приняли его или нет.
А с coreLibraryDesugaringEnabled пробовали?
Так Google сам считает diff между старой APK и новой и сам этот патч устанавливает без какого-либо участия разработчиков.
В Play Market есть патчи.
Я долгое время использовал Moxy, и меня не покидало ощущение, что с этим ViewState я делаю абсолютно тоже самое что и в MVVM. 99% времени я использовал только
AddToEndSingleStrategy
иOneExecutionStateStrategy
(как наверное и все пользователи этой библиотеки).В итоге с кодогенерацией получался некий мост между MVP и MVVM, когда ViewState всегда хранил актуальное состояние экрана и выступал в роли ViewModel, на которую "подписывалась" View, а Presenter менял состояние через ViewState. Так нужен ли этот мост сейчас, когда есть LiveData (либо любой другой Android-независимый Observable) и ViewModel? (раньше точно нужен был, т.к. в то время Jetpack'a еще не было)
Судя по всему заблокировали работу всех расширений на собственных сайтах почти полгода назад.
https://twitter.com/ay_meshkov/status/1230258054257618945
Фича пока недоступна для пользователей, так что даже после релиза сравнивать будет не с чем.
Важно конечно экономить по возможности и место, и трафик. Но Dynamic Delivery про экономию именно места. Приложения ведь чаще всего по Wi-Fi обновляются.
Это же очень много. Каждый сэкономленный мегабайт в APK, это 3 после установки. А экономить нужно как минимум по двум причинам (кроме чистой совести):
На андроиде уже есть поддержка DNS over TLS на уровне системы. Можно настроить тот же Cloudflare, и проверка будет проходить даже из хрома.
А вот Gradle будет каждый раз скачиваться, т.к. используется Gradle Wrapper через
./gradlew task
, а не простоgradle task
.Android SDK не будет, он уже установлен. Gradle и все зависимости – будут.
Требование Google. Для юридических лиц можно указать адрес регистрации, а вот для физических лиц нужно видимо указывать домашний адрес.
@Keep
это не только про обфускацию, но и про оптимизацию тоже. Например, геттеры могут быть удалены и заменены прямой работой с полем класса. Может в R8 еще каких-нибудь оптимизаций добавят (или уже добавили).А вот если бы Event был sealed class'ом, то не забыли бы. Но вот разрастание when'a никак остановить не получилось бы. Как вариант размазать этот when по куче маленьких классов-обработчиков конкретного типа события.
Мы уже начали экспериментировать интеграцией MVICore с Reaktive, но публичных результатов в ближайшее время не будет. А пока в качестве теста мы для небольшого внутреннего продукта сделали сильно урезанную версию MVICore, в которой нет Postprocessor, News и некоторых других вещей.
Так что советую пока пользоваться своим собственным велосипедом, ведь он уже ездит.
Тогда используйте эту перегрузку в примере с RecycleView. Иначе складывается впечатление, что такой важной функциональности нет, и заданные в xml LayoutParameters безнадежно теряются.
А там только 1 параметр передать можно? Без родительского контейнера как в обычном
inflate(id, viewGroup, attach)
? Таким образом не потеряются ли LayoutParameters, которые я описал в xml? Например в том же примере с RecyclerView, если я задамitem_person.xml
высоту в 50dp, то разве она не будет заменена на WRAP_CONTENT, поскольку он является значением по-умолчанию для LinearLayoutManager? Или если этот layout – кусок ConstraintLayout'a, который я добавляю в рантайме?developer.android.com/studio/preview/features
Flutter не поддерживает saveInstanceState. Он все просто держит в памяти до смерти процесса. При смерти процесса в фоне состояние потеряется.
На самом деле не выглядят, если все же следовать рекомендациям на максимальный размер VectorDrawable в 200dp. Размер изображений выше около 600dp.
В этой статье даже замерили отрисовку такого большого VectorDrawable и получили около 16 мс. Но это первоначальная отрисовка до кэширования в Bitmap.