Android Live 🤖 Telegram 帖子

SQLite Parallelism
#android

Отличная статья с неочевидными советами по работе с SQLite в Android, особенно в контексте параллельных запросов (а это встречается довольно часто).

Основная идея в том, что использование Dispatchers.IO по умолчанию для работы с базой может привести к переполнению пула потоков. В результате другие задачи, запущенные на нём, могут быть приостановлены.

Это может стать неприятным сюрпризом, если параллельных запросов слишком много.

Автор объясняет, как добиться корректного поведения, ограничивая число потоков, которые SQLite может использовать. Кстати, все эти рекомендации подходят и для Room.

Ещё узнал про Bundled SQLite — его можно использовать без переживаний о том, как база работает на старых версиях Android, при этом поддерживая последние возможности либы.

Признавайтесь кто-нибудь из вас использует Bundled SQLite? Есть ли от него реальный профит?

Что нового в Android 16?
#android #google

Что же, в этом году нас ждёт свежий Android, и к его нововведениям стоит подготовиться. Давайте разберём основные изменения, опираясь на официальную документацию Google.

🔴Progress-centric Notifications — фактически аналог Live Activities на iOS, где теперь у нас добавляется Notification.ProgressStyle для отображения прогресса текущего процесса. Полезно для приложений с загрузками, доставками и навигацией. Выглядит здорово, одобряем.

🔴Predictive back updates — новые API для предсказуемого поведения жестов "назад". Теперь onBackInvokedCallback позволяет точнее обрабатывать нажатия. Пока неясно, насколько это улучшит UX — навигация жестами и так работает достаточно стабильно.

🔴Richer Haptics — более классная обработка haptic-эффектов. В VibrationEffect.Compositions, добавили более точную настройку вибрационных эффектов. Одобряю, очень мало приложений хорошо используют haptic-эффект.

🔴System-triggered profiling — обновлённый ProfilingManager, появившийся в Android 15, теперь собирает ещё больше данных о производительности приложений. Не тестировал, если пробовали — расскажите, как вам?

🔴Better job introspection — полезное обновление, призванное улучшить дебаг запущенных Job. Теперь можно просматривать их историю и анализировать причины задержек или неудачного выполнения. Круто.

🔴Photo picker improvements — Google активно продвигает использование Photo Picker, а в новой версии API добавляет Embedded Photo Picker который делает выбор изображений ещё более естественным и встроенным в приложение. Отличное обновление.

🔴Vertical text — небольшая, но любопытная доработка: теперь Paint поддерживает вертикальный текст. Не знаю, можно ли было раньше сделать это без библиотек, но Google решил это подстветить как фичу. Подсвечу и я.

Тут только некоторые из фичей, хотя и основные, а все можно увидеть тут.

Screenshots detecting
#android

Раньше для детектирования скриншотов в Android приходилось использовать довольно сложные решения, требующие разрешений на чтение файлов или изображений.

Но оказывается, есть гораздо более простой путь, который появился совсем недавно. Для этого достаточно добавить в AndroidManifest.xml:

<uses-permission android:name="android.permission.DETECT_SCREEN_CAPTURE" />

и сделать вызов методов:

val screenCaptureCallback = Activity.ScreenCaptureCallback {
    // Add logic to take action in your app.
}

registerScreenCaptureCallback(mainExecutor, screenCaptureCallback)
////
unregisterScreenCaptureCallback(screenCaptureCallback)

Главный недостаток этого метода в том, что работает он только с Android 14. Ну что ж, подождём, пока все обновятся. 🫡

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

Media Performance Class Level
#google

Google опубликовали статью о своём опыте использования Media Performance Class (MPC) в контексте работы Google Maps.

Недавно вышел стабильный релиз Jetpack Core Performance library, который позволяет получить актуальный MPC для текущего устройства.
Под капотом — класс PlayServicesDevicePerformance, который запрашивает Google Play Services о текущем уровне MPC. По сути, всё довольно просто.

В статье описан кейс Google Maps, где разработчики начали использовать полупрозрачные окна только на высокопроизводительных устройствах, чтобы обеспечить лучший UX для разных категорий пользователей. Вероятно, у вас тоже есть подобные высокотребовательные фичи?

Не уверен, что у этого подхода нет альтернатив, особенно учитывая обязательное наличие Play Services для работы. Что думаете? 🤔

ViewModel под капотом
#viewmodel #code

Полезная статья, объясняющая, как устроен всем известный ViewModel под капотом.

После изучения вы сможете легко написать собственный аналог ViewModel (но лучше не использовать его в боевых проектах) или разобраться, как внутренние компоненты связаны со скоупом, что такое AutoCloseable и CloseableCoroutineScope.

Люблю подобные статьи про внутренние части всем известных компонентов.

Legacy Shmegacy
#code

Legacy — популярное слово, которое часто ассоциируется с «плохим» кодом. В проектах часто есть участки кода, куда не хочется заглядывать или править баги, но до переписывания руки так и не доходят. Но задумывались ли вы, как появляется legacy? Ведь в большинстве команд опытные и умные инженеры, которые хотят, чтобы их проект был только лучше.

Автор статьи смотрит на legacy не как на код, а как на наше отношение к этому коду.

Например, несколько любопытных тезисов:
🔴чем дольше разработчики работают в одной команде, тем меньше появляется legacy-кода, так как авторы могут поддерживать и улучшать его сами;
🔴хорошая документация и покрытие тестами снижают вероятность превращения кода в legacy, так как увеличивают шансы, что автор или коллеги смогут в нём разобраться в далёком или не очень будущем;
🔴использование стандартных инструментов и библиотек в команде снижает риск превращения кода в legacy.

В статье рассказывается, как избежать появления legacy-кода в проектах и сделать жизнь команды проще. Так что — не плодите legacy, а потихоньку избавляйтесь от него, делая код чище и проще. 🥰

Optimised Out в Kotlin Coroutines
#kotlin #coroutines

Иногда при отладке coroutines можно увидеть сообщение «optimised out», из-за которого debugging усложняется.

Это связано с особенностями работы Kotlin coroutines и их преобразования в state machine. В таких случаях переменные, которые больше не нужны после точки остановки, очищаются, и становятся невидимыми для отладки. Кроме того, при использовании inline также выполняются оптимизации, скрывающие ненужные переменные.

Однако существует простая настройка, которая позволяет увидеть эти переменные и значительно упростить debugging. 🥳

Друзья, поздравляю вас с наступающим Новым годом! 🎅

Этот год для канала выдался не самым продуктивным: мало постов и полезного контента для вас. Вероятно, самая банальная причина — самая верная: отсутствие желания и дисциплины.

Себе желаю исправиться и писать здесь регулярно. А вам желаю, чтобы все ваши желания исполнились, а новый год принёс как можно больше позитивных моментов! 🎄

GitHub Wrapped
#git

Под конец года попался клёвый сервис для анализа активности в Github.
И как раньше никому эта идея не приходила в голову?

Если вдруг не учитываются приватные репозитории — в настройках профиля надо выбрать «Include private contributions on my profile».

Делитесь в комментариях своей статой, будем мериться сравнивать коммиты.

When и Guard Conditions
#kotlin

С релизом Kotlin 2.1.0 появился апдейт для when — guard conditions. Эта новая фича улучшает читаемость кода, делая его более наглядным.
Давайте рассмотрим на примере, что она делает.

Предположим, есть базовый класс для получения ответа от сервера:

sealed interface HttpResult {
    data class Success(val response: String) : HttpResult
    data class Failed(val statusCode: Int) : HttpResult
}

Если включить Guard Conditions, то проверка в when специальных юзкейсов будет выглядеть так:

when (response) {
    is HttpResult.Success -> println("Success")
    is HttpResult.Failed if response.statusCode == 503 -> println("Maintenance")
    is HttpResult.Failed -> println("Failed with code ${response.statusCode}")
}

Как мы видим, одну ошибку от бэка мы обработали без добавления if внутри условия:

when (response) {
    is HttpResult.Success -> println("Success")
    is HttpResult.Failed -> {
        if (response.statusCode == 503) {
            println("Maintenance")
        } else {
            println("Failed with code ${response.statusCode}")
        }
    }
}

Похоже, что стало удобнее, но нужно попробовать на практике.
Чтобы включить фичу, надо убедиться, что K2 Compiler включен, а потом добавить опцию:

kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xwhen-guards")
    }
}

Чуть больше информации можно найти тут.