Android Live 🤖

​​Уязвимости в приложениях Samsung
#security

Любопытное исследование, которое рассказывает о списке уязвимостей в предустановленных приложениях на телефонах Samsung.

Автор провёл несколько недель в поиске уязвимостей в родных приложениях Samsung и нашёл несколько интересных деталей о том, как можно подменить установку этих приложений, как дать доступ к контактам, SMS или файлам.

Рекомендую ознакомиться, если интересуетесь безопасностью приложений. Ну и можно взять парочку примеров и проверить свои приложения на предмет уязвимости. Выглядит очень интересно, и жду ещё подобных исследований.

Ссылка на первую и вторую часть статьи.

​​Jetpack Compose и эквивалентные View
#compose

Я уже упоминал на канале классный ресурс, который здорово экономит время при переходе с обычных xml View на Compose. Однако с релизом Jetpack Compose он стал ещё более актуальным. 👍🏻

Сайт позволяет найти эквиваленты различным свойствам, функциям и View в Jetpack Compose. Всё, что нужно сделать — это ввести соответсвующее свойство в поле ввода и получить результат.

Конечно, там описаны далеко не все элементы, но основные в наличии.
Ссылка на ресурс тут.

​​Сегодня не совсем #опрос, но неплохая тема для оффтопа.

Расскажите о самом ужасном опыте собеседования в компанию?

Это может быть всё что угодно: странные требования, несоответствие описанию, или например, неадекватные вопросы… да и вообще то, после чего у вас осталось неприятное ощущение и чувство потерянного времени.

Если хотите, то можете написать сразу в комментариях, а если комфортнее сохранить анонимность – пишите в личку, рассказ "без имен" опубликую за вас.

Ну и огромная просьба не писать названия компаний или прямых намёков на неё. Такие сообщения будут удаляться. Ведь это ваш опыт, а разводить холивар о компаниях не тема этого треда. 🙃

​​Переговоры о зарплате

Одной из самых неприятных частей у разработчиков (да и не только 🙄) при найме на работу является обсуждение зарплаты.
Довольно часто мы недооцениваем свои знания и боимся торговаться при трудоустройстве на новое место. Думаю, что одной из причин является то, что слово торг в нашей голове — звучит как что-то неприятное да и в целом не близкое к обсуждению высоких зарплат.

Крутая статья, которая описывает процесс переговоров о зарплатных ожиданиях из которой можно почерпнуть несколько интересных кейсов. Тут перевод на русский, хотя лучше читать в оригинале.

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

Вообще, обсуждение зарплаты очень интересная тема, поэтому буду рад, если поделитесь полезными статьями в этой сфере. ✌🏻

​​Landscapist для изображений в Jetpack Compose
#compose #library

С появлением Jetpack Compose появилось много библиотек, которые совместимы с его парадигмой и требованиями.

Для загрузки изображений уже существует несколько вариантов, и самым известным является библиотека Coil. И хотя я не пробовал её на практике, выглядит она многообещающей: под капотом использует coroutines, добавляет не так много методов по сравнению с аналогами и из коробки поддерживает Compose.

Правда, если у вас в проекте уже есть добавленная зависимость для загрузки изображений, такая как Glide или Picasso и вы не хотите переходить на аналог, то вы можете воспользоваться библиотекой Landscapist для загрузки через одну из них в Compose.

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

​​Конечный автомат на Jetpack Compose
#compose

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

Давайте рассмотрим небольшой практический пример, описанный в статье. Тут автор делает экран, где есть достаточно большое количество состояний, но с подходом Finite State Machine — получается всё предсказуемо и просто.

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

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

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

​​Настройка видимости extension-функций
#kotlin

Extension-функции — довольно крутая фича языка Kotlin. Это позволяет расширять функциональность классов без изменения класса. Ну а вызываются эти функции совершенно также, как и те, которые относятся к этому классу, правда выделяются другим цветом в IDE.

Сегодня я нашёл не самую очевидную функциональность, которая позволяет настраивать области видимости этих функций при помощи интерфейсов и дженериков.

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

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

fun Vehicle.cruiseTheBoulevard(): String {

return "cruising the boulevard with my ${getMakeAndModel()}"
}

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

fun <T> T.cruiseTheBoulevard(): String where T: Vehicle, T: LandVehicle {

return "cruising the boulevard with my ${getMakeAndModel()}"
}

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

​​Серия статей Flows и Channels
#flow #kotlin

Крутая серия статей, которая посвящена более глубокой проработке вопроса, связанного с Flow и Channel.

Автор начинает рассказ с общего понятия потоков, cold и hot streams, их разницы и кейсов применения. Так что это всё подойдёт тем, кто совсем не в теме и хочет детально с этим разобраться.

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

​​Выводы о KMM после небольшого приложения
#kmm

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

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

Ну и далее любопытный список выводов, которые будут полезны, если вы думаете о создании проекта на KMM.
Кстати, если вы хотите мигрировать текущий проект, то вот вам хороший опыт о переезде, ну и описание преимуществ, которые в результате появились. ✌🏻

​​Microsoft Teams поддерживает нативные уведомления под MacOS
#tools

Новость совсем не про Android разработку, но для тех кто использует MacOS и Teams для работы — новость то, что надо.
Дело в том, что Microsoft Teams не поддерживал показ нативных уведомлений на MacOS, показывая вместо них самописные, которые мало того, что выглядели не очень, так ещё и частенько бажили. 🙄

Теперь мучениям пришёл конец, и можно настроить показ уведомлений в том же стиле, что и все уведомления на MacOS в «Настройки и другое» (Settings and more) -> «Настройки» (Settings) -> «Уведомления» (Notifications).

А что вы используете на работе в качестве мессенджера и средства для общения? 🤓

​​Как Telegram оптимизирует изображения перед отправкой
#library #cases

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

Автор статьи решил изучить вопрос и посмотреть, как Telegram делает такую оптимизацию. Покопавшись в коде, нашёл класс ImageOptimizer, который отвечает за алгоритм сжатия изображений. Он состоит из следующих шагов:

🔹декодирование изображения из файла в Bitmap;

🔹рассчёт коэффициента сжатия — в Telegram используется 1280 для обычных изображений и 90 для миниатюр;

🔹рассчёт ближайшего inSampleSize — первый этап оптимизации изображений, где рассчитывается BitmapFactory.Options.inSampleSize на основании коэффициента из предыдущего шага. Поддерживается шаг кратный степени 2;

🔹рассчёт Image Matrix — после предыдущего шага меняется ориентация изображения, чтобы применить к нему, если необходимо, дополнительные оптимизации. Делается это при помощи Matrix и Exif данных об изображении;

🔹создание сжатого изображения — делается на основе передаваемых в функцию BitmapFactory.Options и Matrix, с которыми работал алгоритм на предыдущих шагах;

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

🔹сжатие и сохранение изображения — при помощи функции Bitmap.compress() осуществляется сжатие с заданными параметрами качества. В Telegram это Bitmap.CompressFormat.JPEG с качеством 80 для изображений и 50 для миниатюр.

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

Готовая функция из статьи тут, которую при желании вы можете использовать и у себя в проектах.

​​Релиз Lottie для Compose
#compose #library

Не успел выйти релиз Compose, как контрибьюторы начали изменять свои библиотеки для совместимости с ним.
И вот, уже в стадии релиза библиотека Lottie, которая позволяет отображать созданные в Adobe After Effects анимации в приложениях.

Ребята рассказали, что они изменили внутрянку библиотеки для совместимости с экосистемой Compose, с самой ранней версией общались с разработчиками Compose для того, чтобы сделать всё правильно.

Радует такой подход, и рад, что одна из самых красивых библиотек для работы с анимациями теперь есть и на Compose. 💛

​​Релиз Jetpack Compose
#compose

Сегодня состоялось важное событие — релиз Jetpack Compose🔥.
Теперь уже нет сомнений, что это новый вектор развития UI в Android-разработке, а у разработчиков появилась новая задача в бэклоге, связанная с переездом или пробой нового фреимворка.😁

Ну и к более практическим вещам. У команды большие планы на развитие этого проекта, роадмап можно найти тут, а сам текст анонса можно почитать тут.

Вот вам несколько примеров готовых приложений.
И конечно, обязательно посмотрите видео на канале Android Live с пошаговым написанием приложения.

Поделитесь своим мнением в комментариях. А какие материалы по Jetpack Compose вам интересны?

​​Фоновые задачи в Android 12
#android #workmanager

С релизом последней версии Android, мы снова получили ряд ограничений, связанных с работой фоновых операций. Теперь нельзя стартовать foreground services, за исключением особых случаев, описанных тут.

Альтернатива — WorkManager, которые уже довольно долго являетя приоритетным средством для запуска фоновых задач, с новой фичей — Expedited jobs. Они позволяют запускать короткие и важные задачи, давая системе больше контроля над доступом к ресурсам.
Теперь можно будет не выводить уведомление пользователям, однако не всё так просто.

Из плюсов можно выделить:
• минимальное время запуска;
• меньшая зависимость от Battery Saver и Doze.

Ну а минусы:
• отсутствие поддержки констант, связанных с зарядом батареи и режимом работы устройства;
• ограниченное время на работу: система может убрать запущенную задачу, если она выполняется больше 3 минут.

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

​​Annotation processors с KSP
#kotlin #api

KSP — это API от Google для создания лёгковесных плагинов для компилятора Kotlin и annotation processors.
На практике мало кто использует написание плагинов с нуля, но подобные знания могут значительно увеличить скорость решения некоторых задач. Да и в целом полезно знать что ещё можно сделать и какие API для этого есть.

Если эта тема хоть немного вам интересна, то вот простой туториал для старта. В нём автор пишет плагин, который преобразовывает:
@Function(name = "myAmazingFunction")
interface MyAmazingFunction {
val arg1: String
val arg2: Map<String, List<*>>
}

В функцию следующего вида:
fun myAmazingFunction(
arg1: String,
arg2: Map<String, List<*>>
) {
println("Hello from myAmazingFunction")
}

Рассматривается всё, начиная с информации о базовой структуре проекта и заканчивая реализацией и примерами кода.

Ссылка на статью тут.

​​Room и multimap return types
#jetpack #library

Последний релиз Room добавил нам новую фукнциональность: теперь можно возвращать объекты, обёрнутые в тип Map.

Эта фича полезна, если вам нужно сделать JOIN в запросе. Для 1-M связей запрос будет выглядеть так:
@Query("SELECT * FROM Song JOIN Artist ON Song.artistId = Artist.artistId")
fun getSongAndArtist(): Map<Song, Artist>

А если вы хотите использовать связь M-M, то запись немного поменяется:
@Query("SELECT * FROM Artist JOIN Album ON Artist.id = Album.artistId")
fun getArtistAndAlbums(): Map<Artist, List<Album>>.

Если по какой-то причине вы не хотите или не можете создать дополнительный Embedded класс, то это решение отлично зайдёт. Ну и конечно, есть встроенные обёртки над Map с LiveData, Observable и Flow.

Пока что фича в alpha, а подробнее можно почитать о ней тут.

​​Список Public API
#tools

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

Вероятно самый распространённый API — это Weather API. Правда, тестовые задания с подобным описанием уже порядком надоели, ну и для пробы новых технологий он не всегда подходит.

На будущее, вот вам огромный список публичных API для бесплатного использования. 🤓
Тут есть API и с напитками, и с животными, и с финансами, и с мероприятиями… в общем куча всего, каждый найдёт себе подходящее, а тестовые проекты станут разнообразнее.

​​Google Fast Pair Service
#tools #library

Продолжаем знакомство с довольно редкими, но интересными API в Android. Вероятно, большинство из нас не будет использовать данный API, но лично мне было интересно, как подобная функциональность работает под капотом.
Ну и да, если вдруг вы заняты разработкой своего Bluetooth устройства, то этот API для вас.

Fast Pair Service — это сервис, который позволяет уменьшить количество действий, которые надо совершить пользователю, чтобы присоединиться к Bluetooth устройству.

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

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

​​Архитектура для Compose: MVVM или MVI?
#compose #architecture

Сегодня Compose набирает всё больше оборотов и большее число разработчиков выбирают его для использования в своих проектах. Однако, важным моментом является выбор корректной архитектуры для работы с Compose.
Насколько хорошо работает наиболее распространённый сейчас MVVM? Стоит ли разбираться с MVI или это усложнение логики?

Автор статьи решил выбрать идеальную архитектуру для работы с Compose, и рассказал о своём опыте. У него получилась MVVM с некоторыми фичами от MVI: State, Event и Effect. Ну а для взаимодействия между слоями тут используется Flow.

Получилось довольно неплохо, с проектом можно ознакомиться тут. Автор подчёркивает, что о подобном подходе стоит задуматься, если у вас намечается сложное приложение с большим количеством логики. Для простых же достаточно стандартного MVVM подхода.