Перешли ли вы на AndroidX в своих проектах?
public poll
Да – 11
👍👍👍👍👍👍👍 48%
@artnester, @mikshka, @Belogurow, @pavel_bp, @Helpa, @ch13mob, Dzmitry, @koren_ivan, Ihor, @k_sergeevich, @PavelSha
Жду обновления сторонних библиотек – 10
👍👍👍👍👍👍 43%
@katso, @OlegTarashkevich, @alexey_zubkovskiy, @vla3089, @MikeKr1, @lumiandrey, @Dartlen, @krlrozov, @andorke, @ArtemBagritsevich
Что это такое? – 2
👍 9%
Anatole, @Ant1skilla
👥 23 people voted so far. Poll closed.
public poll
Да – 11
👍👍👍👍👍👍👍 48%
@artnester, @mikshka, @Belogurow, @pavel_bp, @Helpa, @ch13mob, Dzmitry, @koren_ivan, Ihor, @k_sergeevich, @PavelSha
Жду обновления сторонних библиотек – 10
👍👍👍👍👍👍 43%
@katso, @OlegTarashkevich, @alexey_zubkovskiy, @vla3089, @MikeKr1, @lumiandrey, @Dartlen, @krlrozov, @andorke, @ArtemBagritsevich
Что это такое? – 2
👍 9%
Anatole, @Ant1skilla
👥 23 people voted so far. Poll closed.
#Dagger #AndroidX #Fragment
Преимущественный способ доставки зависимостей в объекты является конструктор. Это позволяет гарантировать, что при создание объекта у вас есть все необходимое для его работы. К сожалению, стандартные компоненты Android системы (Activity, Fragment, Service и пр.) должны создаваться с помощью конструктора по умолчанию (без параметров) и это рушит описаный выше принцип. Например, Fragment создается сейчас так:
Пример того как реализовать FragmentFactory с Dagger 2 на основе Multibindings:
https://gist.github.com/kirich1409/45dc22004246c7a9fa7c1ef282c72fbe
Преимущественный способ доставки зависимостей в объекты является конструктор. Это позволяет гарантировать, что при создание объекта у вас есть все необходимое для его работы. К сожалению, стандартные компоненты Android системы (Activity, Fragment, Service и пр.) должны создаваться с помощью конструктора по умолчанию (без параметров) и это рушит описаный выше принцип. Например, Fragment создается сейчас так:
class MainFragment : Fragment() {
@Inject
lateinit var sampleDep: SampleDependency
override fun onAttach(context: Context) {
super.onAttach(context)
// Делаеv inject зависимостей
}
}
Проблема этого решения состоит в том, что sampleDep используется только внутри MainFragment и должна инициализировать только один раз. Было бы хорошо сделать так, чтобы sampleDep была приватной и немодифицируемой, например это выглядело бы так:class MainFragment @Inject constructor(
private val dependency: SampleDependency
) : Fragment()
Есть изящное решение для Fragment, которое появилось в androidx.fragment версии 1.1.0 - FragmentFactory. Это позволит вам кастомизировать создание Fragment. Android команда снова показала почему AndroidX заслуживает миграции на нее.Пример того как реализовать FragmentFactory с Dagger 2 на основе Multibindings:
https://gist.github.com/kirich1409/45dc22004246c7a9fa7c1ef282c72fbe
То что я описал для Fragment можно сделать и для всех стандартных компонентов приложения с помощью AppComponentFactory. единственное огорчение - чтобы это можно было сделать у вашего приложения должно быть minSdk=28.
Остается дождаться этак года 2023, чтобы начать это использовать все приложения тотально стали писаться на Android P+. 😁
Остается дождаться этак года 2023, чтобы начать это использовать все приложения тотально стали писаться на Android P+. 😁
#Kotlin #Coroutines #Concurrency
В продолжение своей серии статей о concurrency и корутинах Роман Елизаров поведывает о том как ситанксис Kotlin позволяет явно писать асинхронный вызовы и управлять ими
https://medium.com/@elizarov/explicit-concurrency-67a8e8fd9b25
В продолжение своей серии статей о concurrency и корутинах Роман Елизаров поведывает о том как ситанксис Kotlin позволяет явно писать асинхронный вызовы и управлять ими
https://medium.com/@elizarov/explicit-concurrency-67a8e8fd9b25
Medium
Explicit concurrency
Concurrency is important in the modern world, but we need to be explicit about it.
#ArchitectureComponents #LiveData #ViewModel
Architecture Component (AC) довольно популярны в современной Android разработки, компоненты внутри #AndroidX переходят на использование их под капотом, SDK устаревают и рекомендуют переходить на AC. Но важно помнить один принцип: "С большой силой приходит большая отвественность", поэтому любая библиотека или паттерн должны использоваться правильно, чтобы приносить пользу.
Наиболее распространненые ошибки при работе с AC
1. Учечка LiveData observer в Fragment-ах
Все LiveData в Fragment которые обновляют UI, должны быть подписаны на изменения между onCreateView() и onDesctoyView(). Проблема в том, что стандартный LifecycleOwner Fragment-а отписывается после onDestroyView(). Решение этого является использование Fragment.viewLifecycleOwner, который доступен в AndroidX либо Android Support Library 28.0.0. На старых версихя Android придется отписываться руками в onDestroyView() 😢
2. Перезагрузка данных на каждом повороте/смене конфигурации
Тут рекомендую посмотреть код из статьи, там описан подробно пример того как это делается.
3. Утечка ViewModel-ей
Хранение ссылки на ViewModel не должно происходить где-либо кроме Fragment/Activity
4. Предоставление доступа к LiveData как изменяемой (MutableLiveData) to views
LiveData лежат в ViewModel и не должны быть публично модифицируемыми.
5. Создание зависимостей ViewModel-ей после каждого изменения конфигурации
Все зависимости, которые вы собирайтесь Inject-ить в ViewModel, в ViewModelProvider.Factory должны быть объвляне через Provider, который позволит корректно работать со Scope зависимостей.
"5 common mistakes when using Architecture Components"
Architecture Component (AC) довольно популярны в современной Android разработки, компоненты внутри #AndroidX переходят на использование их под капотом, SDK устаревают и рекомендуют переходить на AC. Но важно помнить один принцип: "С большой силой приходит большая отвественность", поэтому любая библиотека или паттерн должны использоваться правильно, чтобы приносить пользу.
Наиболее распространненые ошибки при работе с AC
1. Учечка LiveData observer в Fragment-ах
Все LiveData в Fragment которые обновляют UI, должны быть подписаны на изменения между onCreateView() и onDesctoyView(). Проблема в том, что стандартный LifecycleOwner Fragment-а отписывается после onDestroyView(). Решение этого является использование Fragment.viewLifecycleOwner, который доступен в AndroidX либо Android Support Library 28.0.0. На старых версихя Android придется отписываться руками в onDestroyView() 😢
2. Перезагрузка данных на каждом повороте/смене конфигурации
Тут рекомендую посмотреть код из статьи, там описан подробно пример того как это делается.
3. Утечка ViewModel-ей
Хранение ссылки на ViewModel не должно происходить где-либо кроме Fragment/Activity
4. Предоставление доступа к LiveData как изменяемой (MutableLiveData) to views
LiveData лежат в ViewModel и не должны быть публично модифицируемыми.
5. Создание зависимостей ViewModel-ей после каждого изменения конфигурации
Все зависимости, которые вы собирайтесь Inject-ить в ViewModel, в ViewModelProvider.Factory должны быть объвляне через Provider, который позволит корректно работать со Scope зависимостей.
class MoviesViewModelFactory(Выбрал я эти советы из статьи
val repository: Provider<MoviesRepository>,
val stringProvider: Provider<StringProvider>,
) : ViewModelProvider.Factory
"5 common mistakes when using Architecture Components"
Medium
5 common mistakes when using Architecture Components
Subtle oversights with more or less serious consequences - even if you’re not making these mistakes it should be worth keeping them in…
#Animations #Transitions #Library #Kotlin
Transition X - новая удобная библиотека для описание Transition анимаций при помощи Kotlin DSL
Transition X - новая удобная библиотека для описание Transition анимаций при помощи Kotlin DSL
#AndroidX #Migration
Результаты быстрого опроса по использованию AndroidX показали, что большая часть уже обновилась с Android Support Library. Правда перевес совсем незначительный.
Для тех кто не в курсе что это такое рекомендую начать отсюда "AndroidX Overview"
Результаты быстрого опроса по использованию AndroidX показали, что большая часть уже обновилась с Android Support Library. Правда перевес совсем незначительный.
Для тех кто не в курсе что это такое рекомендую начать отсюда "AndroidX Overview"
Android Studio поможет вам в миграции, но не все так гладко 😔
Подробнее о миграции читайте в статье "The Reality of Migrating to AndroidX"
Подробнее о миграции читайте в статье "The Reality of Migrating to AndroidX"
Dan Lew Codes
The Reality of Migrating to AndroidX
This year, Google rebranded the support Android libraries to Android Jetpack
(aka AndroidX) [https://developer.android.com/jetpack/].
Particularly pertinent to developers was how they repackaged all the libraries.
Not only have their maven coordinates changed…
(aka AndroidX) [https://developer.android.com/jetpack/].
Particularly pertinent to developers was how they repackaged all the libraries.
Not only have their maven coordinates changed…
#Retrofit #LibUpdates #Networking
Вышел Retrofit 2.5.0. Основные изменения:
* Поддержка Unit типа из Kotlin. Ведет себя аналогично Void из Java.
* Поддержка Java 8 Optional и CompletableFuture. Поддержка заменяет необходимость настройки конвертера и зависимость "converter-java8" больше не поддерживается.
* Новые расширения для Kotlin, которые позволяют создавать реализацию, передавая только интерфейс как параметр generic-а.
* Добавлены R8 правила внутри JAR. Теперь при использование R8 вам не надо добавлять собственные правила для Retrofit.
* Улучшения API
* Багфикс
Подробности
https://github.com/square/retrofit/blob/master/CHANGELOG.md#version-250-2018-11-18
Вышел Retrofit 2.5.0. Основные изменения:
* Поддержка Unit типа из Kotlin. Ведет себя аналогично Void из Java.
* Поддержка Java 8 Optional и CompletableFuture. Поддержка заменяет необходимость настройки конвертера и зависимость "converter-java8" больше не поддерживается.
* Новые расширения для Kotlin, которые позволяют создавать реализацию, передавая только интерфейс как параметр generic-а.
retrofit.create<MyService>()
* Добавлены R8 правила внутри JAR. Теперь при использование R8 вам не надо добавлять собственные правила для Retrofit.
* Улучшения API
* Багфикс
Подробности
https://github.com/square/retrofit/blob/master/CHANGELOG.md#version-250-2018-11-18
Kotlin
Unit - Kotlin Programming Language
#AndroidX #NightMode #Energy
Современные телефоны становятся мощнее, процессоры с каждым годом улучшаются, оперативной памяти становится больше, обычная память становится быстрее, но все это ограничивается батарейкой. Пользователи iPhone все время ходят с Power Bank 😁.
Сколько нулей будет состояние челока, который сможет сделать технологию, позволяющую избавиться от этих ограничений?
Android делает много в плане улучшения батарейки с софтвой стороны: Doze, Battery Saver, App Standby, Adaptive Battery, App Standby Buckets, Background Restricitions, JobScheduler, Power Consumption Proilers и др. К сожалению, это не дает больших преимуществ, когда вы используете свои приложения активно 😞
Хотите это исправить - добавьте темную (night) тему в свои приложения. Она позволяет сэкономить энергию, особенно на OLED дисплеях.
Почему это стоит делать и что для этого есть в AndroidX очень хорошо рассказали на Android Dev Summit.
Современные телефоны становятся мощнее, процессоры с каждым годом улучшаются, оперативной памяти становится больше, обычная память становится быстрее, но все это ограничивается батарейкой. Пользователи iPhone все время ходят с Power Bank 😁.
Сколько нулей будет состояние челока, который сможет сделать технологию, позволяющую избавиться от этих ограничений?
Android делает много в плане улучшения батарейки с софтвой стороны: Doze, Battery Saver, App Standby, Adaptive Battery, App Standby Buckets, Background Restricitions, JobScheduler, Power Consumption Proilers и др. К сожалению, это не дает больших преимуществ, когда вы используете свои приложения активно 😞
Хотите это исправить - добавьте темную (night) тему в свои приложения. Она позволяет сэкономить энергию, особенно на OLED дисплеях.
Почему это стоит делать и что для этого есть в AndroidX очень хорошо рассказали на Android Dev Summit.