Цикл статей про архитектуру от Zsolt.

👉 Вводная часть про инструменты и что нас ждет в следующих частях
👉 Про обработку ошибок и Монады. Читаем про то что такое монады, как это связано с архитектурой Android и на какому слое приложить
👉 Mapping Зачем это делать и почему нельзя использовать 1 серверную модель на всех слоях. Нужно ли тестировать этот процесс, и как именовать функции чтобы не запутаться
👉 Response vs Reply классы Отличия и когда-какие используем. Организация нетворк слоя

Это не гайд для архитекторов, а скорее для мидлов, которым нужно начать углубляться в детали организации слоя данных

Google Workspace переносит свои продукты на KMP

Прошедший KotlinConf24 принес еще одну новость. Команда Google Workspace, а это такие приложения как Gmail, Docs, Meet, Calendar переводит свои продукты на KMP. Первым будет приложение Google Docs.

И это очень крутая поддержка для KMP и расширение комьюнити.

Как Google поможет найти уязвимости в вашем коде

В ходе проверки линтером выявляются известные уязвимости и выводятся рекомендации по их исправлению со ссылкой на источник. Это полезно, потому что держать в голове весь OWASP в области мобильной разработки (https://mas.owasp.org/MASVS/) попросту невозможно. Работает начиная с AS Giraffe+

Квиз!

В Composable, в большинстве случаев, если мы используем mutableStateOf(), мы фиксируем его состояние через remember(), чтобы сохранить его при рекомпозициях. Но если мы используем mutableStateOf() в Activity — нужно ли нам использовать remember()?

Пример кода:

class MainActivity : ComponentActivity() {

  private var text = mutableStateOf("Hello!")

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      AppTheme {
        Surface(modifier = Modifier.fillMaxSize(), color = MaterialTheme.colorScheme.background) {
          TextField(value = text.value, onValueChange = {
            text.value = it
          })

          Text(text = text.value)
        }
      }
    }
  }
}

Ответ: клик

Замените UseCase на Интерфейсы

Нашел невероятно красивое решение, как слой usecase, являющихся прокси к репозиторию, облегчить.

Допустим у нас есть репозиторий:

class CounterRepository {
  private val _value = StateFlow(0)
  val value: Flow<Int> = _value

  fun addOne() { _value.update { it + 1 } }
  fun subOne() { _value.update { it - 1 } }
}

Тогда примитивные прокси usecase(представим их сразу как интерфейсы) будут выглядеть так:

interface AddUseCase { fun addOne() }

interface SubUseCase { fun subOne() }

interface GetValueUseCase { 
    val value: Flow<Int> 
}

Значит, в целом, мы можем представить репозиторий, как реализацию этих интерфейсов:

class CounterRepository: 
  AddUseCase, 
  SubUseCase, 
  GetValueUseCase {
    override val value: Flow<Int> ...

    override fun addOne() ...
    override fun subOne() ...
}

А раз есть реализация, значит можно инжектить ее напрямую в VM

class CountingViewModel(
  private val addOne: AddOneUseCase,
  private val subOne: SubUseCase,
  private val getValue: GetValueUseCase,
): ViewModel() {
  ...
}

Пример целиком, но с большим количеством обслуживающего кода: Гист

Вроде бы использованы базовые паттерны, но такой реализации еще не видел

Немного контекста к посту выше.

Подразумевалось избавление от сценариев, когда у вас UseCase выглядит вот так:

class GetTaskListUseCase(
  private val taskRepository: TaskRepository,
) {
  operator fun invoke(): List<TaskItem> {
    return taskRepository.getTaskItems()
  }
}

Убирая этот UseCase вам придется обращаться к репозиторию напрямую из ViewModel, что позволит вызывать и другие функции репозитория напрямую

Крутая дискуссия случилась в комментариях с разными точками зрения, спасибо!

Со сложных архитектурных задач прошлой недели обратимся к популярным ошибкам в Jetpack Compose:

👉 Забываете использовать remember, или используете его когда не надо, как тут
👉 Постоянно используете Modifier.fillMaxSize() без надобности
👉 Игнорируете оптимизации производительности. Делаете тяжелые операции при каждой рекомпозиции
👉 Путаете State и MutableState. Почитать отличия можно тут
👉 Не знаете как устроены LaunchedEffect и DisposableEffect. Почитать тут, а в самой статье неплохие примеры про неверный key, лишние рекомпозиции и ошибки жизненного цикла
👉 Создаете сложные и неподдерживаемые Composable с глубокой вложенностью
👉 Не используете тему и и цвета из нее, а применяете значения напрямую
👉 Забываете тестировать Composable. Для этого, кстати, не обязательно проходиться тест кейсами по пути до элемента, достаточно вызвать его отдельно и потыкать. Способы найти элемент внутри Composable описаны тут
👉 Игнорируете contentDescription. Доступность вашего приложения для людей с ограниченными возможностями очень важна! Не пренебрегайте этим, пожалуйста. О том как проверить свое приложение был пост тут

Внутри статьи есть примеры ошибок и правильной версии по мнению автора.

Если вы теряетесь в ответе на вопрос "Почему нужно использовать тут class, а не data class", то эта статья для вас. Конечно, документацию тоже нужно глянуть

👉 Как работает data class под капотом
👉 Какие есть ограничения
👉 Какой синтаксический сахар предлагает

Бонус
Посмотреть на то как выглядит голый код вашего датакласса, возможно так понятнее, зайдя в Tools -> Kotlin -> Show Kotlin Bytecode и кликнуть Decompile

Ну штош...

Варианты организации мультимодульной архитектуры

1️⃣ Каждая фиче-директория содержит 2 сабмодуля: domain и presentation, разделяя эти слои физически.
Это сильно усложняет проект, но дает масштабируемость на больших проектах

2️⃣ Один общий модуль features для всех фичей приложения.
Сильно упрощает проект, но если это небольшое приложение, то поможет в выделении всей бизнес-логики в отдельный модуль. Я, честно говоря, не вижу никаких преимуществ в таком подходе

3️⃣ Превращаем фиче-деректорию из п.1 в фиче-модуль с двумя сабмодулями domain и presentation.
Бенефиты в виде дополнительного модуля на каждую фичу могут повлиять на скорость сборки, но дадут удобство в способе подключения модулей

4️⃣ Отдельный модуль для каждой фичи, и все это лежит в папке features
Наверно это самый базовый способ вкатиться проекту в мультимодульную архитектуру, физически разделяя компоненты в приложении

Как и, главное, почему именно так, вы организовали разделение на модули в своем приложении?

Интересный сравнительный анализ кроссплатформы и нативной разработки у Никиты Куликова(@localhost_ru) . Понятно откуда берется использование излишних ресурсов, но для некоторых продуктов это реальный повод задуматься над резонностью использования Flutter/CMP

Обновляем приложение через Github Releases без маркета

Все достаточно очевидно:
👉 Выкладываем приложение на GitHub как последний релиз
👉 Через api GitHub'а тянем последнюю версию и информацию о ней
👉 Вытягиваем из артефактов релиза apk
👉 Запрашиваем установку пакета у пользователя

Для публичных релизов необходимо, чтобы ваш проект был опенсорсным + весь флоу немного портит пользовательский опыт. Откат от app bundle к apk файлу тоже выглядит грустно
Из плюсов, если вы используете гитхаб, то этот способ отлично встроится в ваш релизный процесс и моментально раскатит приложение на ваших пользователей, избегая длительного процесса код-ревью.

Про Coroutine и Dispatchers

Если не знаете что-либо из списка ниже - смело открывайте статью. Подойдет больше для подготовки к теоретической части собеседований:
👉 Coroutine Scope, Coroutine Context, Job
👉 Отличия между Dispatchers.Default, Dispatchers.Main, Dispatchers.IO и Dispatchers.Unconfined
👉 Зачем нужен newSingleThreadContext

Хорошая новость прошедшей недели!
Android 15 доступен в AOSP, а значит скоро появится на большем числе девайсов

👉 Улучшили разные API, писал про это тут
👉 Новые шрифты для японского, корейского и китайского языка, и расширение возможностей работы со шрифтами для разработчиков
👉 Более тонкая программная настройка камеры
👉 Изменения в связанные с безопасностью и приватностью

Upgrade assistant уже доступен
Проверить совместимость вашего приложения тут: https://developer.android.com/about/versions/15/reference/compat-framework-changes
Все нововведения тут: https://developer.android.com/about/versions/15

Исправляем автоимпорт в Android Studio

При автоимпорте на первое место часто всплывают ненужные пакеты.
Например Modifier из java.lang.reflect, а не из compose или Flow из java.util.concurrent, а не из пакета с корутинами

Как исправить:
👉 Alt/Opt + Enter на предлагаемом пакете импорта и нажимаем на Exclude xxx from completion
👉 Исправить на уровне проекта для всей вашей команды: добавить файл codeInsightSettings.xml в .idea вашего проекта и заполнить его ненужными импортами. Ниже пример для стандартного проекта Jetpack Compose + Kotlin Flow + Dagger/Hilt:

<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
  <component name="JavaProjectCodeInsightSettings">
    <excluded-names>
      <name>android.graphics.Canvas</name>
      <name>android.graphics.Color</name>
      <name>android.graphics.Paint</name>
      <name>android.graphics.drawable.Icon</name>
      <name>android.inputmethodservice.Keyboard.Row</name>
      <name>android.text.Layout.Alignment</name>
      <name>android.view.Surface</name>
      <name>android.widget.Button</name>
      <name>android.widget.GridLayout.Alignment</name>
      <name>androidx.core.content.pm.ShortcutInfoCompat.Surface</name>
      <name>java.lang.reflect.Modifier</name>
      <name>java.nio.file.WatchEvent.Modifier</name>
      <name>java.time.format.TextStyle</name>
      <name>javax.annotation.concurrent.Immutable</name>
      <name>org.threeten.bp.format.TextStyle</name>
      <name>org.w3c.dom.Text</name>
      <name>java.util.concurrent.Flow</name>
      <name>org.intellij.lang.annotations.Flow</name>
      <name>jakarta.inject.Inject</name>
    </excluded-names>
  </component>
</project>