🛶 Новый сезон Podlodka Android Crew стартует уже через два месяца, а значит, пора выбрать тему сезона и нам нужна ваша помощь выбрать лучшую.

Мы подготовили три потенциальных темы:

🛠 Тулинг: от AI до Я
- Расскажем как грамотно использовать AI-агенты
- Узнаем тайную магию дебаггера
- Поделимся must-have плагинами

🔋 Работа в фоне
- Узнаем как сделать музыкальный плеер
- Разберемся как работать в фоне в KMP
- Поговорим про новые фичи, вроде Live Updates

⚙️ Архитектура: AI, KMP, SDK
- Научимся проектировать SDK
- Посмотрим дебаты про BDUI
- Узнаем, чем занимается мобильный архитектор

📊 Пройдите, пожалуйста, опрос по ссылке.

А среди тех, кто пройдет опрос до 20 июля включительно, мы разыграем проходку на грядущий сезон 🎁

Make Snackbar Great Again

В Compose реализация показа snackbar получилась не самой удобной, на каждом экране приходится:
🔘 Оборачивать контент в Scaffold
🔘 Вызывать suspend-функции для показа snackbar
🔘 Не забывать предусмотреть отмену предыдущего snackbar
🔘 Страдать из-за BottomSheet, так как там не получится использовать Scaffold, иначе он растянется на весь экран

И даже если сделать один глобальный обработчик, snackbar будет залезать на BottomNavigation, что выглядит довольно плохо 🤔

Вот что я предлагаю:
🟢Отказаться от показа snackbar через Scaffold и написать простую логику с декларативным отображением snackbar с анимацией в зависимости от состояния.
🟢Чтобы snackbar не перекрывал лишние элементы интерфейса, можно написать кастомный модификатор в Compose, который будет запоминать верхнюю позицию элемента, к которому он применён, и добавлять неявный отступ к snackbar.

Таким образом, эта реализация не только решает проблемы выше, но и позволяет отображать snackbar как внизу, так и вверху экрана.

🔥 Если тема интересна, ставьте реакции и я попробую собрать пример с такой реализацией.

#Compose

📂 Папка с Android-блогерами

Мы решили заколлабиться с крутыми инженерами, которые ведут блоги об Android-разработке и делятся авторским контентом.

Добавляйте папку себе, если вам интересно послушать разные мнения и советы на повседневные темы разработки 😉

Как слить кодовую базу из-за Compose Multiplatform

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

Если в Android мы переживаем за то, чтобы никто не зареверсил наш код, подключаем R8 и так далее, то как обеспечить такой же уровень защиты в вебе?

Казалось бы, там всё ок из коробки: в релизном билде что-то понять из итогового JS-файла не получится, особенно с Wasm.

Но есть один маленький нюанс: по умолчанию в настройках Webpack исходный код тоже публикуется, и его любой может успешно посмотреть в Developer Tools. А в документации по Compose Multiplatform нет ни одного упоминания о том, как это предотвратить 🤡

Так что обязательно отключайте публикацию сорсов в настройках Webpack на релизе. Как это сделать — смотрите в комментариях 👇

#Security #Compose #WEB

Как AI помогает в мобильной разработке

Да, AI добрался и до этого канала... Знаю, что многих уже тошнит от упоминания этих букв в инфополе, но таков путь. При этом, по моим наблюдениям, далеко не все разработчики поработали с AI-агентами, а зря, ведь многие задачи уже можно не делать самому:

Что уже можно отдать AI
🟢 Любую задачу, которую вы понимаете, как решить, и можете это сформулировать в тексте
🟢 Генерацию вёрстки по макетам в Figma
🟢 Написание документации
🟢 Код-ревью
🟢 Анализ крашей и ошибок
🟢 Объяснение сложных участков в коде и так далее

Что пока не стоит
🔘 Задачи, в которых нужно проявить креативность и нет понятного решения
🔘 Работу с экзотическими технологиями, вроде интеропа с Objective-C в Kotlin Native
🔘 Обновление зависимостей в проекте
🔘 Создание архитектуры приложения

✅ Напоследок порекомендую доклады (раз, два) от наших коллег из сообщества, которые делятся своим опытом применения AI.

#AI #Mobile

Тестирование мобильных приложений

Давайте поговорим о том, как можно организовать процесс тестирования мобильных приложений. За свою практику я познакомился с разными подходами и вот какие плюсы и минусы я вижу:

1. Ручное тестирование
Самый распространённый вариант, когда в команде есть QA, и он тестирует новые фичи и проводит регрессию.
➕ Лучший способ находить самые непредсказуемые баги, о которых разработчик даже не мог подумать.
➖ Дорого: нужно содержать штат QA, покупать девайсы для тестирования. А если регресс занимает пару дней, получаем ещё и выгоревших сотрудников.

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

➕ Позволяет автоматизировать регресс, UI-тесты проходят значительно быстрее ручного тестирования.
➖ Есть множество проблем с поддержкой UI-тестов, и далеко не всё можно проверить на эмуляторе/симуляторе.

3. Мобильная ферма
В этом случае мы используем ферму из реальных устройств, на ней можно проводить как ручное тестирование, так и запускать UI-тесты.

Такой подход используют, например, в Яндексе с более чем 800 устройствами. Я не представляю, сколько это стоит, ведь для каждого iPhone нужен отдельный MacBook ☠️
Из open source-решений есть STF и DeviceHub, у которых тоже есть свои плюсы и минусы.
Другой вариант — аренда фермы девайсов. Например, такие услуги предоставляет компания Selectel.

➕ Самое качественное тестирование: множество разных девайсов позволяет воспроизводить самые специфичные баги.
➖ Очень дорого создавать собственное решение. Позволить себе это могут только крупные компании, но можно воспользоваться арендой устройств, чтобы значительно сэкономить.

🔖 Если тема заинтересовала и хотите узнать подробнее, то есть хорошая статья по теме, рекомендую!

#Testing #MobileFarm