Android Live 🤖

2021-04-27 17:05:00 ​​Android Runtime: как работают Dalvik и ART
#theory

Android Runtime — одна из самых ключевых вещей в Android. Большинство слышали такие аббревиатуры как Dalvik, ART, JIT или AOT. Но далеко не все понимают, что они значат и как вообще работает среда выполнения Android.

В статье или видео можно найти детальную информацию об этом. Для начала рассматривается вообще понятие среды выполнения, а далее сравниваются все современные (и не очень) среды.

Подобная информация полезна для общего понимания того, из чего состоит приложение и как оно работает, ну и будет полезна при прохождении собеседований. Открыть/Комментировать

2021-04-26 15:05:00 ​​Модуль навигации в Jetpack Compose
#jetpack #compose

Нашёл отличную статью, где автор приводит пример навигации при помощи Navigation Compose в приложении.

Получается, что навигация находится в отдельном модуле, который ответственнен только за это, а все остальные части приложения вообще не знают о том, что навигация реализована при помощи Navigation Component.

Статья получилась объёмной, но описанный подход заслуживает внимания. Ну и ссылка на проект, который там упоминается. В нём используется довольно свежий стек технологий, можно посмотреть, как ведут себя сырые библиотеки на готовом проекте. Открыть/Комментировать

2021-04-23 12:05:00 ​​Автомиграции в Room
#room #jetpack

В версии Room 2.4.0-alpha01 добавили новую функциональность, которая значительно упрощает миграцию с одной версии базы данных на другую — автомиграции. До этой версии у вас было два пути при изменении схемы базы:
• писать миграцию вручную;
• заполнять базу данных заново, удаляя предыдущую версию базы.

Теперь появился гораздо более интересный способ. При повышении версии базы данных, вы можете указать параметр autoMigrations и добавить AutoMigration (from = 1, to = 2). Это всё, вы автоматически получите миграцию на новую версию. Более того, есть возможность комбинировать автомиграции и обычные миграции.

Но не всё так просто: подобная функциольность будет работать только тогда, когда вы делаете какие-то простые изменения в структуре базы, такие как: добавление новой колонки, изменение primary key, foreign key или индексов, изменение значений по умолчанию в колонке. Для случаев посложнее, например разделение таблицы на несколько, всё равно придётся писать ручную миграцию.

Кроме этого, добавили AutoMigrationSpec, которая может помочь Room сделать автомиграцию, если он не справляется сам. Там есть несколько аннотаций: DeleteTable, RenameTable, DeleteColumn, RenameColumn. В случае, если Room сам не сможет сделать миграцию, то вы получите exception. Это и будет являться признаком того, что надо использовать эти аннотации.

На мой взгляд — это отличная новость, которая избавит нас от написания большого числа лишнего кода в проекте. С нетерпением жду beta-версии. Открыть/Комментировать

2021-04-22 15:05:00 OTUS открывает набор онлайн-курса «Flutter Developer». Пройдите тест и успейте в группу по спеццене!

ПРОЙТИ ТЕСТ НА ЗНАНИЕ FLUTTER: https://otus.pw/gSRM/

Хотите протестировать учебный процесс заранее? Регистрируйтесь на бесплатный двухдневный интенсив «Создаем приложение на Flutter для Web, iOS и Android»: https://otus.pw/GaQ0/
Регистрируйтесь сейчас — напомним в день интенсива! Открыть/Комментировать

2021-04-21 15:05:00 ​​Лайфхаки для Firebase Remote Config
#firebase

Firebase Remote Config — это удобный сервис, который позволяет отправлять некий набор параметров через Firebase без участия вашего собственного сервера. Это удобно, ведь могут быть ситуации, когда у вас вообще нет сервера (например, в pet-проекте) или вам не просто добавить новую функциональность на ваш сервер.

Я активно использую инструменты Firebase, в том числе и этот. Нашёл статью, где автор описывает несколько хитростей для работы с Remote Config, возможно вы тоже найдёте для себя что-то полезное.

Не забывайте о значениях по умолчанию в приложении. Об этом мало кто помнит, но вы можете установить значения по умолчанию для сервиса до тех пор, пока сервис не получить свой первый instance с Firebase. Это может быть полезно в случае каких-то проблем при получении данных. Сделать это можно двумя способами. Первый — это определение значений по умолчанию при получении определённой переменной, а второй — определить в самом config:
Firebase.remoteConfig.apply {
setDefaultsAsync(mapOf(
"key" to "default_value"
))
}

Оберните получение данных в WorkManager. При использовании методов fetch или fetchAndActivate, вы можете получить исключение, например когда пользователь не имеет подключения к Интернет. Правильнее всего попробовать получить эти данные ещё раз, когда будет восстановлено соединение. Можно испльзовать Worker, где в конфигурации настроить запуск только при наличии соединения: setRequiredNetworkType(NetworkType.CONNECTED).

Свяжите Remote Config с Cloud Functions. Довольно спорное решение, но оно может быть полезно, если вы хотите доставить обновления Config как можно быстрее. Идея в том, что вы отправляете пуш-уведомление пользователям при изменении Remote Config, делая текущее состояние данных неактуальными и заставляя FirebaseRemoteConfig получить данные как можно быстрее при следующем запуске приложения. Открыть/Комментировать

2021-04-19 14:05:00 ​​Планируем задачи с WorkManager
#workmanager #jetpack #beginners

WorkManager — довольно важный компонент из Jetpack, который позволяет планировать задачи вне зависимости от того было ли закрыто ваше приложение или перезагружено устройство.
У него есть несколько преимуществ в сравнении с предшественниками: например, работа при определённом заряде батареи или Интернета, гибкие настройки для повторного запуска, интеграция с Coroutines и RxJava.

Если вы использовали только базовую часть WorkManager или не использовали его совсем, то вот отличная статья с примерами, описывающая большинство кейсов использования: запуск периодичных задач, кастомные менеджеры для запуска, тестирование и debug. Ну и здесь же немного информации о том, как он работает под капотом для разных версий операционной системы.

Ссылка на статью тут.

Были ли у вас проблемы с использованием WorkManager? Открыть/Комментировать

2021-04-17 19:05:00 ​​Как правильно передавать данные между Fragments?
#jetpack #fragment

Для передачи данных между Fragments есть несколько способов:
• использовать интерфейсы и callbacks;
• использовать Shared ViewModel;
• использовать setTargetFragment, правда он сейчас deprecated.

Но есть ещё один способ, который сейчас является самым удобным и основным. Начиная с версии Fragments 1.3.0-alpha04, FragmentManager имплементит FragmentResultOwner.

Дальше мы должны добавить ключ, который хотели бы слушать, и будем принимать Bundle с информацией. Для отправки результата надо использовать setFragmentResult с этим ключом, и добавить нужный нам Bundle.

Важно следить за уникальным использованием ключей, а также есть небольшие особенности при работе с childFragmentManager. Больше деталей и примеров кода можно найти тут. Открыть/Комментировать

2021-04-15 18:05:00 ​​Kotlin Flows — шпаргалка
#flow

Многие на своих проектах уже давно используют Flow в связке с Coroutines. На канале также было несколько постов о том, как лучше использовать эту связку и на что стоит обратить внимание.

Вот вам ещё одна небольшая заметка про Flow, где автор собрал в одну таблицу краткую информацию о них и о всех существующих типах Flow: в чём их разница, какие есть эквиваленты в RxJava, ссылки на документацию, примеры кода, где лучше применить их в Android.

Для тех, кто хочет шпаргалку сразу в pdf — вот ссылка, а сама статья с описание тут. Открыть/Комментировать

2021-04-14 11:07:44 ​​Dependency Injection vs Service Locator
#patterns

Многие разработчики не задумываются о разнице этих двух подходов. На первый взгляд, они одинаковы, решают одну и ту же проблему — увеличивают декомпозицию кода. Или простым языком — уменьшают связность разных участков кода, что даёт нам улучшенную тестируемость, масштабируемость и простоту.

Более того, разница между подходами может становиться ещё менее заметной, когда мы используем библиотеки. Но давайте остановимся более подробно на каждом из подходов, рассмотрим пример, чтобы увидеть разницу и понимать достоинства и недостатки каждого из них.

Хорошее определение этих паттернов нашёл в этой статье.

если описать DI одним словом, то идеально подходит слово «отдавать». И в самом деле, при помощи DI мы просто даём нужные объекты другому объекту. В примере ниже классу House нужны объекты Door и Window, которые мы передаём ему в конструктор.

val window = Window()
val door = Door()
val house = House(window, door)

DI именно о том, что зависимости предоставляются нам кем-то. И нашему классу не важно, где этот кто-то данные зависимости берёт. Поэтому, мы и используем для DI конструктор, а не setter.

если мы описываем Service Locator одним словом, то идеально подходит слово «взять». Так, и есть: у нас есть какой-то класс (локатор, фабрика) у которого мы берём объекты, которые нужны нашему классу. В примере ниже, мы возьмём объект класса House напрямую из какого-то локатора и будем использовать его дальше.

val house = serviceLocator.get(House::class)

То есть локатор — это некая фабрика или контейнер, который наполняется готовыми объектами и из которого мы их получаем. Также нашему локатору не важно, как и кто положил эти объекты в него, его главная задача — предоставить объект, если он есть.

Современные библиотеки для внедрения зависимостей, такие как Dagger, Hilt, Koin, используют оба этих подхода в связке, хотя это и не всегда очевидно на первый взгляд. Но как мне кажется — это здорово, ведь каждый из них имеет свои плюсы, а подобное сосуществование уменьшает число недостатков. Открыть/Комментировать

2021-04-12 15:05:00 ​​Сервисы для аналитики приложений
#library

Сервисы для анализа приложений — важные вещи для бизнеса: можно собрать информацию о пользователях, анализировать воронки, анализировать то, откуда пришли ваши пользователи и т.д.

Разработчики чаще используют Crashlytics, иногда добавляя сюда набор инструментов от Firebase. В целом, это хорошие инструменты, но ведь есть ещё ряд крутых сервисов, которые помогают анализировать приложения и их качество.
Ну а знания этих инструметов будет полезно в случае, если ваша роль в текущем проекте начинает выходить за рамки обычной разработки, или вы думаете о создании своего продукта. В любом случае, вы знаете, где взять их список, когда они понадобятся.

Весь список с детальным объяснением можно найти в этой статье, а мы рассмотрим несколько из описанных.

продуктовая аналитика — нужна для получения информации о том, что конкретно делает пользователь в приложении. Сервисы — App Metrica и Firebase Analytics, Amplitude, Mixpanel.

отправка пуш-уведомлений — полезны, если вы настраиваете группы пользователей, которым хотите их отправить. Сервисы — Firebase Cloud Messaging, AWS SNS, OneSignal.

подключение платежей и подписок — очевидная и простая на первый взгляд вещь, но довольно непростая в реализации. Сервисы — Adapty, AppHud, RevenueCat.

аналитика падений — наиболее близкая разработчикам вещь. Сервисы — AppMetrica, Firebase Crashlytics, Sentry.

Помните, что многие из описанных выше сервисов — платные, но многие из них дают бесплатную функциональность для маленьких продуктов. Открыть/Комментировать