Как Uber мигрирует нетворк слой на gRPC

Знакомая боль всех мобильный разработчиков с миграцией чего либо на слое данных. Как решает проблему Uber:

👉 Protocol Buffers вместо JSON, HTTP/2 без откатов к HTTP/1.1
👉 Использование gRPC, на который мигрировали постепенно.
С помощью shadow calls проверяли скорость работы и PoC. Это позволило провести небольшое исследование на проде и увидеть результаты без больших затрат.
Поэтапно переводили API, по принципу A/B тестирования и откату к старой REST версии в случае возникновения проблем. Круто же!
👉 Эксперимент привел к снижению нагрузки на 45% и уменьшению задержки запросов на 27%

У компаний сейчас большой запрос на оптимизацию затрат, и это одно из технических решений которые вы можете предложить! Чуть больше по поводу gRPC и Android разработке: https://developer.android.com/guide/topics/connectivity/grpc

Разбираемся с FileProvider

Банальная вещь, но сэкномит вам время

👉 Базово в манифесте определяем провайдер. Решаем нужно ли давать разрешениями на пользование нашими данными другим приложениям (grantUriPermissions, exported)
👉 Определяем <paths>:
<files-path> Для файлов внутреннего хранилища ([pm]/files/)
<cache-path> Для кэша ([pm]/cache/)
<external-path> Внешнее хранилище (/storage/emulated/0/). Учитывайте, что доступ сюда будет иметь любое приложение и без вашего ведома
<external-files-path> Внешнее приватное хранилище (/storage/emulated/0/Android/data/[package_name]/files/)
<external-cache-path> Внешний приватный кэш (/storage/emulated/0/Android/data/[package_name]/cache/)
<root-path> Доступ напрямую из корня. Тут надо осторожно, у вашего приложения может не быть прав на запись
👉 Не забываем про permissions. Можно обойтись без прямого доступа к файловой системе:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
intent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Пример использования для того чтобы пошарить картинку из кэша в email без выгрузки bitmap:

val imagePath = File(context.getCacheDir(), "images")
val newFile = File(imagePath, "image.png")
val contentUri = FileProvider.getUriForFile(context, "com.example.myapp.fileprovider", newFile)

if (contentUri != null) {
    val shareIntent = Intent()
    shareIntent.setAction(Intent.ACTION_SEND)
    shareIntent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
    shareIntent.setDataAndType(contentUri, context.getContentResolver().getType(contentUri))
    shareIntent.putExtra(Intent.EXTRA_STREAM, contentUri)
    startActivity(Intent.createChooser(shareIntent, "Choose an app"))
}

Ink API, поддержка рисовалок для Android приложений

Корректная поддержка стилусов. Работает с API 21 (Android 5.0)
Возможности включают в себя кисти, обьекты, обработка отрисованной линии, чтобы она казалась более плавной. Не хватало этого во многих приложениях, особенно если ты пользуешься стилусом. Теперь поддержка стилуса является частью гайдлайнов гугла по созданию приложений. Глянуть и вдохновиться можно тут: https://developer.android.com/adaptive-apps

Абстракция для работы со строками

Возникали вопросы как работать со строками в Compose на UI и на data слое чтоб это выглядело удобно? А еще чтобы строки с разных источников были закрыты общей абстракцией и не нужно было разделять строки от пользователя, string.xml и пришедшие с бекенда

Автор предлагает воспользоваться sealed interface такого вида:

sealed interface StringHolder {
    // These are the 2 essential Holders
    data class Value(val value: String) : StringHolder
    data class Resource(@StringRes val resId: Int) : StringHolder

    // These are additional and will come in handy!
    class ParametrizedResource(@StringRes val resId: Int, vararg val formatArgs: Any) : StringHolder
    class Plural(@PluralsRes val resId: Int, val count: Int, vararg val formatArgs: Any) : StringHolder
}

Пример использования:

@Composable
fun ExampleText(stringHolder: StringHolder) {
    Text(text = stringHolder.value)
}

class MessageDataSource(private val context: Context, private val api: Api) {
    suspend fun sendMessage(message: StringHolder) {
        api.sendMessage(message.fromContext(context))
    }
}

Из минусов - конечно сложновато это адаптировать к CMP, да и протекание логики в UI может не соответствовать вашей архитектуре.

А вот и демонстрация Kotlin RPC. На примере создания фуллстак приложения с KMM, Koin, Wasm
Самый приятный момент это в том что клиент и сервер шарят интерфейсы, модели и статусы. В самой статье много кода, так рекомендую взглянуть.
Из болезненного, со слов автора, это WASM, который еще в альфе, и высокий порог входа. Нужно быть чуть знакомым с kmm концепцией, чтобы разобраться в этом.

Все чаще мне попадаются статьи с отказом от DI фреймворков. Пока что не видел какого-либо жизнеспособного решения в продакшене без DI.
Автор одной из минималистичных DI библиотек - Magnet тоже предлагает отказаться от DI и использовать явные зависимости. И почему же?
👉 Это сложно
👉 Время сборки сильно вырастает
👉 Время холодного старта тоже увеличивается
👉 Часто обьекты графа остаются в памяти дольше чем нужно. Да, большинство команд просто плодит синглтоны в том или ином виде и инжектит их. Увы, это и правда плохой подход

Взамен предлагается подход, кратно увеличивающий количество обслуживающего кода, однако использующий ручное и явное внедрение зависимостей:

interface NetworkModule {
    val httpClient: HttpClient

    class Default : NetworkModule {
        override val httpClient: HttpClient by lazy ...
    }
}

interface DatabaseModule {
    val database: Database

    class Default : DatabaseModule {
        override val database: Database by lazy ...
    }
}

interface RssReaderModule {
    fun fetchRss(): FetchRss

    class Default(
        private val networkModule: NetworkModule,
        private val databaseModule: DatabaseModule,
    ) : UserModule {
        override fun fetchRss(): FetchRss ...
    }
}

Больше примеров внутри статьи

Таким образом, мы получим достаточно прозрачную систему внедрения зависимостей в проекте, где нет никакой магии и у нас в руках полный контроль над всеми обьектами, однако масштабируемость этого подхода вызывает вопросы. Что вы думаете про тренд отказа от DI?

Преиспользуем стили в Jetpack Compose

Чтобы сотню раз не проставлять паддинги и обводки в дизайн/системе, объединяем в простой универсальный Modifier:

fun Modifier.paddedBorder(): Modifier {
  return this
    .border(1.dp, Color.Black)
    .padding(8.dp)
}

fun Modifier.cardStyle(): Modifier {
  val shape = RoundedCornerShape(4.dp)

  return this
    .shadow(4.dp, shape)
    .background(Color.White)
}

И несколько предупреждений:
👉 Не нужно паковать весь интерфейс внутрь одной функции, сохраняйте атомарность и переиспользуемость таких модификаторов
👉 Не делайте слишком глубокую вложенность из таких модификаторов. Это намного сложнее исправлять

По мере роста проекта возникает всё больше и больше проблем с производительностью UI. Что-то мы отлавливаем автоматически на пулреквестах, что то по репортам пользователей. О том как от релиза к релизу найти снижение производительности в Compose элементах и пишет автор статьи

👉 Берем Macrobenchmark (запуск сценариев), Perfetto (анализ и визуализация трассировок) и Diffetto (сравнения трассировок и определение что за элемент деградировал)

👉 Последовательно перекладываем данные из инструмента в инструмент и находим источник. В статье пример на маленьком приложении со сценарием замедления и тем как смотреть метрики

👉 В больших проектах множество @Composable элементов, тут то Diffeto и выступает незаменимым помошником для фильтрации огромного количества трассировок

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

Koin Annotations 1.4 в Compose Multiplatform

Зачем использвать:

👉 Код чище: аннотации обеспечивают декларативный и краткий способ определения зависимостей
👉 Поддержка IDE: проще навигация по коду и рефакторинг
👉 Проверка во время компиляции: более раннее обнаружение проблем с внедрением зависимостей (Немного жертвуем скоростью сборки)
👉 Убираем обслуживающий код: KSP автоматически генерирует необходимые extension функции
👉 Multiplatform поддерживается!

Документация: https://insert-koin.io/docs/reference/koin-annotations/start/
Выглядит хорошей возможностью для масштабирования koin как DI в проекте

Kotlin Multiplatform Roadmap 2025

Дорожная карта на 2025 год. Как будет развиваться мультиплатформа:
👉 В Compose Multiplatform будет упор на интеграцию Jetpack Compose, улучшение перфоманса iOS. Стабилизация и доведение до релизного состояния таких фичей как навигация, управление ресурсами и переводы, а так же accessibility!
👉 Kotlin-to-Swift экспорт, вместо существующего проблемного Kotlin-to-Objective-C . Первую публичную версию ожидаем в 2025 году.
👉 Больше интеграций с Android Studio для удобной работы. Обещают отдельную KMP IDE базирующуюся на существующей IDE Fleet. Очень хочется попробовать, мы в команде иногда используем Fleet, но не как полноценную IDE, а как вспомогательный инструмент
👉 Развитие экосистемы библиотек для KMP. Очень схоже с тем, чем планирует заниматься и Kotlin команда
👉 Amper и его улучшения, как инструмента для сборки. Пока что выглядит сыро, но обещают ряд доработок в особенности для Compose Multiplatform. Gradle, конечно, плох, а bazel сложен для малых команд, но это вдоль и поперек исследованные инструменты. Amper будет сложно конкурировать, но некоторые сценарии просто невозможно реализовать без глубокой интеграции в KMP (ex. Фуллстак приложение на KMP с бекендом)
👉 Продолжат работать над Gradle и другими инструментами для сборки приложений. Обещают упрощение подключения зависимостей для KMP проектов

PDD - Preview Driven Development

👉 Snapshot Testing лежит в основе. Есть много инструментов помогающих в реализации, начиная от встроенных, заканчивая paparazzi и облачными решениями
👉 Запускаем каждый отдельный экран или часть, как Сomposable функци в превью внутри нашего окружения. Автор мокает весь уровень данных, что позволяет включить в тестирование viewModel и увидеть реально возможное поведение приложения
👉 В каждом пулреквесте вы видите какие части приложения были затронуты вашими изменениями
👉 Для автоматизации сразу же предлагается Github Action и Gradle плагин с глубокой интеграцией в один из облачных инструментов

Еще чуть чуть про PDD было вот тут и на Droidcon тут

Как лямды ломают хэширование в data class

Надеюсь, вы не кладете лямды напрямую в data class, а если кладете, то делаете это правильно!

val detective1 = DetectiveDataClass(
    name = "Sherlock",
    age = 40,
    alias = "Holmes",
    onDetectiveAlert = { println("Elementary!") }
)

val detective2 = DetectiveDataClass(
    name = "Sherlock",
    age = 40,
    alias = "Holmes",
    onDetectiveAlert = { println("Elementary!") }
)

println(detective1 == detective2)
// false, хотя ожидается true

println(detective1.hashCode() == detective2.hashCode())
// false, хотя ожидается true

Сравнивая два одинаковых data class’а, получаем неожиданный результат

А исправить можно вот так:
👉 Переопределяем equals и hashCode для этого класса. Не оптимально
👉 Используем method reference

val detective1 = DetectiveDataClass(
      name = "Sherlock",
      age = 40,
      alias = "Holmes",
      onDetectiveAlert = ::alertFunction
  )

👉 Используем интерфейс и передаем полноценный объект внутрь

Лучше всего, конечно, вынести лямду куда подальше от data class

Android 16 Preview BAKLAVA

Вроде, только-только Android 15 проводили в релиз, а уже выходит следующая версия. План такой: Превью сегодня ➡️ Бета в Январе ➡️Стабильная бета в Марте ➡️ релиз по готовности (Июнь)

👉 Изменения в API можно глянуть тут
👉 Внутри релиза теперь есть разделение на минорный и мажорный:

val minorSdkVersion = Build.getMinorSdkVersion(VERSION_CODES_FULL.BAKLAVA)

👉 Новый встроенный photo picker.
👉 Немного интеграции с Health Connect
👉 Privacy Sandbox

По ощущениям, работы, с релизом Privacy Sandbox, прибавится у всех Android разработчиков. А вы что думаете?

Kotlin 2.1.0-RC2

Внутри много доработок, но самая важная для меня - стабильная работа в xCode 16+. Я, по-глупости, обновился на macOS Sequoia месяц назад, что потянуло за собой новый xCode, и iOS сборка нашего KMM проекта сломалась на моей ноутбуке.

Да, всегда можно указать xCode через xcodes в командной строке, но потеря возможности манипулировать нативной частью приложения сильно ограничивала меня. Beta версии 2.1.0 продолжили сыпать ошибками в наш проект, а вот RC2 наконец-таки решил все проблемы и все стало как раньше!

Вывод: Не забывайте отключать автообновления 😅

Тестируйте умнее, а не усерднее
Google обновили документацию по тестированию приложений

👉 Акцент на продуктивности разработки. Пишем тесты пропорционально пирамиде тестирования, не переусердствуем с частотой запуска тестов. Все ради минимизации стоимости запуска и написания тестов. Если вы все еще плаваете в терминологии и не отличаете где интеграционные, а где Unit тесты, то внутри есть примеры
👉 Дополнили рекомендации по популярным ныне видам тестирования: Скриншот тестирование (недавно разбирали тут), тестирование производительности
👉 Новый термин для UI тестов, не делающих скриншоты, - поведенческое тестирование
👉 Несколько рекомендаций для больших тестов и robolectric
👉 В связи с распространение Foldable девайсов с нестандартным разрешением. Рекомендации по их тестированию, а так же инструменты которые вам в этом помогут