Скрытые фичи текстового поля

Что рассмотрят по ссылке выше:

👉 Динамический градиентный текст и курсор, внося изменения всего в 2 строки
👉 Кастомизация decorationBox в зависимости от написанного текста
👉 Изменения шрифта без задания font (как на гифке)
👉 Текстовое поле с маской для кредитной карты
👉 Перехват взаимодействия пользователя с текстовым полем
👉 User tagging в реальном времени
👉 Подмена экшн кнопки в клавиатуре
👉 Haptic feedback для разных символов
👉 Как поддержать media content вставляемый из клавиатуры (гифки или картинки из буфера обмена)

Добавляем проверку на номер задачки в TODO через линтер

Пустые TODO маловероятно будут исправлены, если не имеют за собой закрепленной задачи. А имея задачу очень просто найти место где возникла проблема. Автоматизация проверки формата TODO через lint и как ее делать: тут и тут

Как под капотом работает @Preview?

👉 Для просмотра метода с @Preview аннотацией используется androidx.compose.ui.tooling.PreviewActivity, который собирает параметры из @PreviewParameter и свойства из @Preview
👉 Все это должно как то собираться воедино, да? Это происходит во время градловской команды androidTest. На выходе получаем apk с превьюшками, который выводится в Android Studio.
👉 Как можно этим воспользоваться? Например, положить AndroidManifest.xml в module/src/androidTest и поменять параметры приложения, которое запускается для preview. А значит, мы можем и сами собрать приложение из наших @Preview и любых @Composable элементов на девайс!

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

Цикл статей про архитектуру от 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