"Повышение производительности вашего приложения за счет кэширования API-запросов с использованием OkHttp":
Реализация кэширования с OkHttp: Кэширование API-запросов с использованием класса CacheControl из OkHttp помогает улучшить производительность приложения. Этот метод позволяет сохранять ответы API с заданным сроком годности, уменьшая количество API-запросов и снижая время отклика.
Определение правил кэширования: Правила кэширования могут быть установлены в зависимости от статуса интернет-соединения. Например, когда соединение активное, можно использовать кэшированные ответы за последние 30 минут, а в режиме офлайн — ответы, возраст которых составляет до 1 дня, для улучшения пользовательского опыта.
Использование перехватчиков для кэширования: Механизм перехватчиков из OkHttp позволяет модифицировать HTTP-запросы и ответы, что способствует реализации правил кэширования. Функции, такие как maxAge() и maxStale(), контролируют свежесть ответов, помогая эффективно управлять кэшем.

Проблемы с традиционным подходом

В Jetpack Compose компонуемые элементы глубоко вложены, что затрудняет управление состоянием и зависимостями.
Традиционный подход передачи состояния и зависимостей через несколько уровней компонуемых элементов может привести к проблемам в обслуживании.
Инверсия и внедрение зависимостей

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

Hilt: Популярный фреймворк внедрения зависимостей для Android, который можно использовать с Jetpack Compose.
Koin: Легковесный фреймворк внедрения зависимостей, который поддерживает Jetpack Compose и мультиплатформенную разработку.
Ручное внедрение зависимостей: Может быть реализовано вручную, но требует больше шаблонного кода и может быть подвержено ошибкам.
Наилучшие практики

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

https://medium.com/androiddevelopers/navigation-compose-meet-type-safety-e081fb3cf2f8

1. Navigation Compose предлагает новый способ навигации между компонуемыми элементами в приложении Jetpack Compose: API Navigation Compose позволяет разработчикам перемещаться между компонуемыми элементами в Compose-приложении, используя компонент Jetpack Navigation. Этот новый подход заменяет традиционную навигацию на основе XML более функциональным стилем программирования, используя функции composable() для объявления направлений и navController для навигации между ними.

2. Безопасность типов — ключевой вопрос в Navigation Compose: В отличие от оригинального компонента Navigation, Navigation Compose не поддерживает плагин Safe Args для генерации кода, который обеспечивал безопасность типов для аргументов навигации. Вместо этого разработчикам необходимо структурировать свой код для обеспечения безопасности типов во время выполнения, используя такие техники, как обертки направлений в закрытых классах и создание типобезопасных оберток для извлечения аргументов из SavedStateHandle.

3. Наилучшие практики для Navigation Compose включают инкапсуляцию логики навигации и использование типобезопасных расширений: Чтобы достичь безопасности типов и избежать сбоев, разработчикам следует инкапсулировать логику навигации в отдельных файлах, открывать расширения NavController для безопасной навигации и использовать типобезопасные обертки для извлечения аргументов. Этот подход помогает убедиться, что аргументы имеют правильный тип и все необходимые аргументы присутствуют, делая навигацию более надежной и устойчивой.

https://proandroiddev.com/whats-native-c8d84ccda667

Статья обсуждает концепцию "native" в контексте мобильной разработки, особенно в экосистемах Android и iOS. Автор аргументирует, что определение "native" стало сложным и тонким с появлением кроссплатформенных технологий.

Исторически "native" относилось к приложениям, разработанным с использованием языков, специфичных для платформы, таких как Java для Android и Objective-C для iOS. Однако с появлением дизайн-систем, таких как Material Design для Android и плоского дизайна для iOS, акцент сместился с технической реализации на пользовательский опыт и интерфейс.

Автор предлагает, что дизайн-системы и пользовательский опыт не определяют, является ли приложение native или нативным. Вместо этого термин "native" зависит от контекста платформы, для которой оно предназначено. Например, JavaScript считается нативным в веб-разработке, потому что это основной язык взаимодействия с веб-браузерами.

Современные мобильные фреймворки, такие как React Native и Flutter, созданы для помощи разработчикам в создании приложений для мобильных платформ, но они не соответствуют техническим критериям для нативной функциональности. Они работают в своих изолированных средах, требуя промежуточных слоев или переводов для взаимодействия с системой, что может привести к избыточности и неэффективности.

В отличие от этого, Kotlin выделяется как нативный язык благодаря своей архитектуре компилятора, позволяющей прямое взаимодействие с Java, Swift, JavaScript и WebAssembly. Встроенная интероперабельность Kotlin устраняет необходимость в промежуточном слое или виртуальной машине, позволяя ему без проблем обмениваться объектами между платформами и генерировать нативный код для каждой целевой платформы.

Статья заключает, что концепция "native" относительна и зависит от контекста платформы, для которой она предназначена. В то время как дизайн-системы и пользовательский опыт важны, они не определяют, что означает быть нативным. Вместо этого способность к обмену памятью и стеком вызовов с базовой системой является ключевым критерием для нативной функциональности, и Kotlin соответствует этому критерию.

Понимание порядка модификаторов:
Модификаторы применяются в порядке "с конца к началу" и "изнутри наружу".
Чем выше по цепочке находится модификатор, тем позже он будет применён.
Последний применяемый модификатор — это модификатор, который стоит самым первым в цепочке для компонентов, так как кастомизация, поступающая извне, должна быть применена вокруг того, что компонент уже содержит.
Параметр modifier:
Хорошо написанные функции UI-компонентов с аннотацией @Composable должны принимать параметр modifier: Modifier, который по умолчанию равен Modifier (пустая реализация).
Этот модификатор применяется к корневому узлу компонента, и дополнительные модификаторы могут быть присоединены после него.
Визуализация порядка модификаторов:
При добавлении отступов или границы к компоненту логично применять их вокруг компонента.
Этот визуальный подход помогает понять, что модификаторы применяются "с конца к началу" и "изнутри наружу".
Пример кода:
В статье приводятся примеры правильного использования модификаторов, демонстрируя, как связывать модификаторы и как они применяются в правильном порядке.
Общий вывод:
Статья направлена на упрощение понимания порядка модификаторов в Jetpack Compose, используя визуальный и интуитивный подход.
https://zsmb.co/remembering-modifier-order/

Делай проще, сложнее не делай

Преимущества Feature Gates: Они обеспечивают согласованные графики выпуска, позволяют проводить A/B-тестирование и помогают снизить риски во время развертывания новых функций.
Временный характер: Feature Gates требуют сосуществования старых и новых версий кода, что требует плановых очисток, чтобы избежать долгосрочных обязательств кодовой базы.
Проблемы с удалением: Встроенные условные операторы (if/else) для feature gates могут усложнить усилия по очистке.
Упрощение очистки: Использование интерфейсов и модулей Dagger может изолировать код, специфичный для функций, что упрощает будущие удаления.
Общий принцип: Упрощение задач увеличивает вероятность их завершения, подчеркивая важность упрощения процессов в целом.

Сравнение MutableState и MutableStateFlow
1. Область применения и варианты использования
MutableState

Область применения: в первую очередь предназначено для управления состоянием пользовательского интерфейса в компонуемых элементах в Jetpack Compose.
Вариант использования: этот подход лучше всего подходит для простого состояния, которое является локальным для отдельных компонуемых объектов, или когда состояние не нужно распределять между различными уровнями приложения.
MutableStateFlow

Область применения: универсальный держатель состояний, который является частью сопрограмм и библиотек потоков Kotlin, что делает его полезным на всех уровнях приложения.
Вариант использования: Идеально подходит для состояний, которые наблюдаются или совместно используются несколькими компонентами или уровнями приложения, например, в бизнес-логике или обработке данных.
2. Безопасность потоков и параллелизм
MutableState

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

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

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

Учитывает жизненный цикл при использовании в таких областях, как viewModelScope, повышая его надежность при длительной эксплуатации.
Как поток, он естественным образом поддерживает отправку нескольких значений с течением времени, предоставляя надежное решение для динамических потоков данных.
4. Экспозиция «Только для чтения»
MutableState

Не поддерживает преобразование в состояние только для чтения напрямую. Если раскрыто, может быть приведено обратно к MutableState, что потенциально может привести к непреднамеренным мутациям.
MutableStateFlow

Его можно представить как StateFlow — интерфейс только для чтения, который предотвращает внешние мутации и соответствует лучшим практикам инкапсуляции.

Статья объясняет, как реализовать систему предоплаченных платежей с использованием NFC (Near Field Communication) и меток NDEF (NFC Data Exchange Format) на устройствах Android. • Рассматриваются основы технологии NFC, структура сообщений NDEF и процесс чтения/записи данных на NFC-метки. • Автор предоставляет пошаговое руководство по созданию простой системы предоплаченных платежей, где NFC-метки выступают в роли "кошельков".

Ключевые компоненты:

NFC-адаптер: используется для взаимодействия с NFC-оборудованием.
PendingIntent: для обработки NFC-интентов в фоновом режиме.
IntentFilter: для фильтрации интентов, связанных с NFC.
NdefMessage и NdefRecord: для структурирования данных на NFC-метках.
Преимущества для Android-разработчиков:

Интеграция NFC: статья предоставляет практический пример интеграции технологии NFC в Android-приложения, что становится все более важным для бесконтактных взаимодействий.
Реальное применение: система предоплаченных платежей является наглядным примером использования технологии NFC в реальной жизни.
Понимание NDEF: разработчики могут узнать больше о работе с сообщениями и записями NDEF — основой обмена данными через NFC.
Безопасность: статья рассматривает аспекты безопасности NFC-транзакций, что важно для разработчиков, работающих с конфиденциальными данными.
Примеры кода: предоставленные фрагменты кода служат отправной точкой для реализации аналогичных функций.
Использование Android API: статья демонстрирует работу с различными Android API для NFC, помогая разработчикам освоить эти инструменты.
Пользовательский опыт: обсуждается создание удобного пользовательского интерфейса для работы с NFC, что важно для создания комфортных приложений.

https://proandroiddev.com/nfc-on-android-creating-a-prepaid-payment-system-using-ndef-tags-8105e46340b4

https://davidreiscto.substack.com/p/legacy-shmegacy
Легаси - шмегаси

Demystifying Maestro’s UI Testing Implementation
Что такое Maestro?
Фреймворк для UI-тестирования Android, iOS и веб-приложений.
Использует YAML для описания команд.
Maestro Studio: веб-инструмент для генерации YAML-файлов, отображения дерева UI и запуска тестов.
Как работает Maestro?
Установка APK: CLI устанавливает собственные APK (test APK + инструментальный APK).
GRPC-сервер:
Запускается внутри инструментального APK через adb instrument.
Используется для взаимодействия между CLI и устройством.
UiAutomator:
Считывает иерархию UI (в формате XML).
Выполняет команды взаимодействия.
ADB: CLI также использует команды ADB для управления устройством.
Ожидание событий: CLI делает регулярные скриншоты, сравнивает их и отслеживает изменения экрана.

https://android-developers.googleblog.com/2025/01/orientation-and-resizability-changes-in-android-16.html?m=1&s=31

Будет больно

(c) Черновик канала @droidgr

Разбираем использование runBlocking в Android:

👉 Что такое runBlocking?

Функция, которая запускает новую корутину и блокирует текущий поток до её завершения.
Часто используется в примерах для демонстрации корутин в main() функции.
👉 Почему стоит быть осторожным с runBlocking в Android?

Блокирует текущий поток, что на Android может привести к замораживанию UI и возникновению ANR (Application Not Responding).
Особенно критично при выполнении операций ввода-вывода в главном потоке.
👉 Пример неправильного использования:
´´´
class MainViewModel(private val mainRepository: MainRepository) : ViewModel() {
// Не рекомендуется
private fun fetchPosters() = runBlocking {
mainRepository.fetchPosters()
}
}
´´
В этом примере runBlocking блокирует главный поток, что может привести к проблемам с отзывчивостью приложения.
👉 Рекомендуемые альтернативы:

Используйте viewModelScope для запуска корутин, что обеспечивает автоматическую отмену задач при уничтожении ViewModel.
Применяйте launch или async для асинхронных операций без блокировки главного потока.

(c) Черновик канала @droidgr

Разбираем библиотеку Immutable Collections в Kotlin:

👉 Почему стандартные коллекции Kotlin не всегда безопасны?

Стандартные коллекции (List, Set, Map) по умолчанию изменяемы, что может привести к непреднамеренным изменениям данных.
Даже коллекции, созданные с помощью listOf(), setOf(), mapOf(), являются только "только для чтения", но не по-настоящему неизменяемыми.
👉 Что предлагает библиотека Immutable Collections?

Предоставляет действительно неизменяемые коллекции, которые предотвращают случайные изменения и повышают безопасность в многопоточных средах.
Использует структурное разделение для оптимизации производительности и предотвращения ненужного копирования данных.
👉 Как начать использовать?

Добавьте зависимость в build.gradle.kts:

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-collections-immutable:0.3.5")
}

Создание неизменяемых коллекций:

import kotlinx.collections.immutable.*

val immutableList = persistentListOf("A", "B", "C")
val immutableSet = persistentSetOf(1, 2, 3)
val immutableMap = persistentMapOf("key1" to 100, "key2" to 200)
Добавление и удаление элементов:
kotlin
Копировать
Редактировать
val newList = immutableList.add("D") // Создает новый список
println(newList)  // Вывод: [A, B, C, D]

val newMap = immutableMap.put("key3", 300)
println(newMap)   // Вывод: {key1=100, key2=200, key3=300}

Оригинальные immutableList и immutableMap остаются без изменений.
👉 Преимущества в Jetpack Compose:

Избежание ненужных рекомпозиций: Неизменяемые коллекции помогают Compose отслеживать изменения состояния и предотвращают избыточные обновления UI.
Стабильность состояния: Благодаря структурному разделению, изменения создают новые объекты, сохраняя неизменность предыдущих версий, что улучшает производительность.
Предсказуемое поведение UI: Исключение случайных мутаций данных обеспечивает более надежную работу интерфейса.
Подробнее о библиотеке Immutable Collections и её использовании читайте в статье:

#Kotlin #ImmutableCollections #JetpackCompose #AndroidDevelopment

(c) Черновик канала @droidgr

Разбираем, что происходит при нажатии кнопки "Старт" в Android Studio:

👉 Шаг 1: Сборка приложения

Команда: ./gradlew assembleDebug
Описание: Компилирует код и генерирует APK-файл в директории app/build/outputs/apk/debug/.
👉 Шаг 2: Запуск эмулятора

Команды:
emulator -list-avds
emulator -avd <имя_эмулятора>
Описание: Первая команда отображает список доступных виртуальных устройств, вторая запускает выбранный эмулятор.
👉 Шаг 3: Установка APK на устройство

Команда: adb install -r app/build/outputs/apk/debug/app-debug.apk
Описание: Устанавливает или переустанавливает APK на подключенное устройство или эмулятор.
👉 Шаг 4: Запуск приложения

Команда: adb shell am start -n <package_name>/<activity_name>
Описание: Запускает указанную Activity приложения на устройстве.
Эти команды позволяют управлять процессом сборки и запуска приложения напрямую из терминала, что особенно полезно для разработчиков, предпочитающих минималистичные среды разработки.

Подробнее о процессе читайте в статье:

#AndroidStudio #CommandLine #AndroidDevelopment

(c) Черновик канала @droidgr

Да, мемы тоже тут будут

(с) @droidgr