Подробный разбор использования MVI в мультиплатформенных мобильных проектах:
https://habr.com/ru/companies/kts/articles/729832/

Не компоузом единым! 🚀

Рецепты решения популярных задач на корутинах
👉 Asynchronous map
👉 Ленивая инициализация в suspend функции
👉 Переиспользование соединений
👉 Гонка между корутинами
👉 Повторное выполнение suspend функции

Репозиторий с кодом

#coroutines

Migrate your build configuration from Groovy to Kotlin

Надеюсь уже все видели (раз, два и три) о том, что Kotlin DSL теперь будет использоваться по умолчанию в Gradle скриптах вместо Groovy.

Поэтому, для тех, кто еще не мигрировал, оставляю список полезных ссылок👇

👉 Migrate your build configuration from Groovy to Kotlin
👉 Migrating build logic from Groovy to Kotlin
👉 What is Gradle Kotlin DSL
👉 Kotlin DSL: Gradle noscripts in Android made easy
👉 Migrate from Groovy to Kotlin DSL

FlorisBoard - это бесплатная клавиатура с открытым исходным кодом для устройств Android 7.0+. Ее цель - быть современной, удобной и настраиваемой, при этом полностью уважая конфиденциальность пользователя. В настоящее время находится в состоянии ранней бета-версии.

FlorisBoard на GitHub: https://github.com/florisboard/florisboard
Платформа: Android
⭐️: 4.1K

Photo picker, который был добавлен в Android 13, теперь доступен и в старых версиях, начиная с Android KitKat (4.4).

#android #picker #media #photo

https://android-developers.googleblog.com/2023/04/photo-picker-everywhere.html

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

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

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

По пирамиде тестирования есть 4 типа тестов:
👉 end-to-end
👉 системные
👉 интеграционные
👉 юниты

С end-to-end тестами вроде как все понятно. Поднимаем все приложение, библиотеку или что мы там разрабатываем, которая работает в условиях очень близко к продовым. А вот остальные 3 это котел холивара. Юнит тесты мы пишем вроде как на один модуль или класс. Интеграционные тесты затрагивают несколько компонентов, классов, модулей и т.д. Системные это вроде как что-то между интеграционным и end-to-end. Даже из описания системного теста появляется вот какая проблема.

Смотрите, я делаю класс A. Затем пишу тесты только на этот класс. Казалось бы это юнит тест. Затем в этом классе A из-за сложности, я выношу часть функционала в другой класс B. Класс A использует код капотом класс B. И вот юнит тесты которые я написал на первый класс А это все еще юнит тесты или уже интеграционные, ведь вроде как уже несколько компонентов?

Еще можно на юнит тесты посмотреть с другой стороны, они запускают кучу процессов под капотом, это и jvm и загрузка классов и выделение памяти. Если думать про это в таком ключе то даже самый простой юнит тест на самом деле системный.

Эта баллада к тому, что не существует абсолютной шкалы или разделения тестов. То что для одного проекта будет интеграционным тестом, для другого будет просто юнитом и наоборот. Например если мы делаем какую-то библиотеку, то в ней end-to-end тестом может быть просто проверка вызова метода какого-то системного API.

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

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

Короче, как бы это не звучало банально, все сводится к старому доброму “все относительно“ и не слушайте фанатиков пирамиды.

​​Вход в приложение
#security #android

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

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

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

1️⃣ Тут автор рассказывает про пример некорректной авторизации в приложение и про свойства CryptoObject, setUserAuthenticationRequired и о том, как эксплуатировать эти хаки.

2️⃣ Отличное видео, где по шагам описывается процесс создания биометрической авторизации в приложение: разницу между различными классами для авторизации, как затащить alpha-версию библиотеки для входа (удивился, что она до сих пор в alpha) и наконец-то сделать корректный вход по отпечатку.

3️⃣ Библиотека PINkman, которая позволяет добавить вход по пину в приложение: можете не тащить всю либу в проект, но внутри — много крутых идей по корректному хранению пароля в системе. А можете и затащить, если не хочется разбираться.

4️⃣ Статья, где автор описывает ещё одно хитрое свойство — setUserAuthenticationValidityDurationSeconds, которое также может быть использовано как уязвимость для входа.

5️⃣ Ну и напоследок — больше информации про составляющие качественной криптографии в Android: KeyStore, MasterKeys, Blocking, Padding и другие страшные слова.

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

Автоматизация публикации Android приложений в Google Play и Huawei AppGallery — инструкция от А до Я

Детальный гайд по тому, как автоматизировать процесс релизов Android-приложений в Google Play и Huawei AppStore.

👉 Структура Gradle‑проекта
👉 Android App Bundles (AAB) vs Android Packages (APK)
👉 Генерация номеров версий
👉 Получение ключей доступа от Google Play
👉 Загрузка сборок в Google Play
👉 Управление метаданными Google Play
👉 Получение ключей доступа от Huawei AppGallery
👉 Загрузка сборок и release notes в Huawei AppGallery
👉 Добавление CI/CD
👉 Заключение

Читать (Ru)

Только что провели в Отус открытый урок, где я показала, как писать полноценное приложение KMM от начала до конца с бизнес-логикой, сетью и DI
https://www.youtube.com/watch?v=aZhsZbF8CEg

Hugging Face совместно с ServiceNow собрали и выложили свою собственную модель, которая умеет то, что делает GitHub CoPilot — подсказывать код, по сути писать 80% кода без всяких программистов. Только в отличие от CoPilot это не платная услуга, а доступный всем опенсорс код и веса модели.

Я проверил его на любимом моем примере — написании кода игры в морской бой. У меня есть претензии к результату с точки зрения качества кода. Но он получился работоспособным и это самое важное. Внутри у нее кроме неонки всё традиционно — GPT2 модель на примерно триллион токенов. Качество работы на моих примерах чуть хуже CoPilot, но начало положено.

https://huggingface.co/bigcode/starcoder

Frida для начинающих

Всем привет!
Что-то последнее время часто встречаю гайды для только вкатывающихся в тему безопасности мобилок.

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

Весьма советую тем, кто использует (начинает) Frida и тем, кому от неё защищаться (ведь всегда полезно знать, как работает то, от чего ты пытаешься написать защиту). Ведь даже если ты зашифровал что-то, для расшифровки вполне можно вызвать функцию напрямую, конечно, если не использовать биометрию в качестве права на получение доступа к криптообъекту ;)

В общем, хорошая штука.

И всех с праздником!!

#Frida #beginnerguide #android

по мотивам прошедшего Keynote

А вы знали, что в IDEA (ну и в Android Studio) можно поменять иконку проекта?
Я не знал, а это возможно. Надо всего лишь... Нет, сода ни при чём. Надо на welcome-скрине нажать "Change Project Icon..." и выбрать иконку. Другой вариант — положить файл с названием icon.noscript или icon.png в папку .idea и ваш проект будет отличаться в списке проектов от всех остальных.

Интересно, что возможность такая есть уже давно. Я пытался найти когда она появилась, но нашёл только косвенные признаки, что в IDEA 2021 она уже была.

Всё, мне некогда, я пошёл ставить иконки всем проектам.
#idea

Гитхаб выкатил новый дизайн навигатора кода, который до этого обкатывали в превью. Было только для желающих, а теперь и для нежелающих. Это, кстати, кажется единственная превью-фича, которую я почти сразу же отключил.

Вкратце, помимо собственно файла слева теперь панель с деревом кода, справа — панель символов в текущем файле, сверху sticky заголовок, который показывает начало функции, если ты долистал до ее середины, а кнопка T (перейти к файлу) теперь в малюсеньком попапе.

Вот что я хочу про него сказать: да, функций стало больше, так что формально, на бумаге, стало полезнее. Я уверен, что они даже иногда приходятся кстати.

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

Второй момент — это лайаут. Я уже писал, как не нравятся дебаггеры и devtools чисто визуально, потому что там миллион панелей, расставленных более-менее случайно. Так и тут. Еще я когда-то писал, что первое ощущение от Идеи — что тебя обложили. Потому что панели со всех сторон — слева, справа, снизу и сверху. Хотя вроде особо выраженной клаустрофобией я не страдаю, но все равно, тесновато. Удивительно, что гитхаберы снизу никакой панели не влепили. А чего, место же есть!

В принципе, собрать «как было» в новом дизайне почти можно. Можно скрыть обе панели, и тогда из ухудшений останутся только трехуровневая прилипающая шапка и засунутый в попап go to file, который будет выровнен по правому краю (бе).

Я это пишу, потому что наверняка набегут умники только чтобы сказать «чего ты разнылся, вот же, можно сделать как было». А разнылся я, конечно, не для себя, а для моих дорогих читателей, которым не просто надо как-то приспособиться, а которые будут когда-нибудь дизайнить свой продукт и им это наблюдение пригодится: помнить нужно не только о функциях, но и визуальной простоте, лаконичности, легкости. Этот блог вообще не о том, как мне плохо с текущими инструментами, а как делать хорошие, новые.

А с Гитхабом, я думаю, дальше будет все хуже и хуже. Теперь, когда туда пришли vs-кодовцы и у них появились свободные руки, которые надо чем-то занять, он будет только усложняться. В здоровом стартапе, где рук сильно не хватает, фичи взвешиваются по коэффициенту легкость реализации/важность, и делается в основном только самое главное. В успешном энтерпрайзе же рук сильно больше, чем хороших идей, куда эти руки приложить. Поэтому реализуются даже супер неэффективные/ненужные фичи, просто потому что могут и потому что надо чем-то занимать программистов. Ровно то же самое произошло и с VS Code. Так что держитесь, зима близко.

Легальное клонирование приложений в Android 14

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

Чтобы включить эту возможность, надо зайти в Настройки -> Приложения -> Склонированные приложения (Settings > Apps > Cloned Apps)

Для нас это значит, что может быть сильно проще тестировать разные баги, связанные с некорректной авторизацией, иметь несколько приложений с разными аккаунтами или просто не бояться совсем «убить» один из клонов.

А на самом деле, это сильно напоминает историю с твиками для Jailbreak. Apple долгое время (и по сей день), борется с джейлом, но самые популярные твики со временем были перенесены в сам iOS. Раз люди этим активно пользуется, значит это может быть удобно и полезно.

И этом случае все аналогично, огромное количество приложений, которые помогают клонировать приложения на Android и вот эта фича уже в релизе :) Удобно!

#android #clone #news

В LazyColumn добавляют поддержку Lookahead, что позволит делать Shared element transition 🌚
Даже есть небольшой пример как это будет работать

https://android-review.googlesource.com/c/platform/frameworks/support/+/2507256