Telegram Web
​​SQLite FTS в Room
#room

Одной из самых нераспространённых, но полезных фич Room является FTS поиск.
FTS или full-text search — это функция, которая позволяет делать поиск по тексту при помощи созданной виртуальной таблицы.

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

Виртуальные таблицы позволяют значительно увеличить скорость выполнения подобных запросов. Если в приложении много SQL-запросов с LIKE, то стоит присмотреться к этому решению.

Всё что нужно — это использовать аннотацию @Fts4 с указанием родительской таблицы:
@Fts4(contentEntity = Route::class)
@Entity(tableName = "routesFts")
class RoutesFts(val id: String, val title: String)


А также немного изменить написанных запрос, убрав из него LIKE:
@Dao
abstract class RouteFtsDao {
@Query("SELECT * FROM route JOIN routesFts ON route.id == routesFts.id WHERE routesFts.title MATCH :text GROUP BY route.id" )
abstract fun routesWithText(text: String): List<Route>
}


Немного подробнее можно почитать в двух статьях: тут и тут.
​​Custom View с нуля
#view #optimizations

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

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

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

Ну и конечно, с Рождеством, друзья! 😉
​​Showkase: визуализация Jetpack Compose
#compose #library

Jetpack Compose имеет как минимум одно важное преимущество перед традиционным императивным подходом: переиспользование компонентов.

Но, при этом добавляется ряд проблем:
1️⃣ Разработчики добавляют новые компоненты, которые со временем тяжело визуализировать.
2️⃣ Сложная навигация по сохранённым компонентам, что может привести к дублированию похожих элементов.
3️⃣ Аналогичные проблемы связаны и с другими частями UI: шрифты, цвета, иконки.

Хорошим решением проблем является использование дизайн системы в виде дерева компонентов, которое показывает текущую визуальную структуру проекта.✌️

Для Jetpack Compose уже есть библиотека, которая делает всю работу за разработчика: Showkase. По сути она генерирует Activity со всеми Composable-функциями, где есть аннотация Preview. Также есть функции для цветов и шрифтов.

Почитать подробнее про использование можно тут, а ссылка на библиотеку тут.
​​Ошибки при модуляризации приложения
#architecture

При разделении приложения на несколько модулей есть шанс допустить ошибку, когда мы распределяем код на модули.
Например, можно распределять код по слоям: :networking, :persistence или :models. Но со временем подобные модули превращаются в несколько монолитов, и разработчики возвращаются к той же самой проблеме... 🙄

Более правильным подходом является разделение кода на фичи: каждая часть приложения становится независимой друг от друга и связность становится минимальной.

Автор статьи рассказывает об этой ошибке у себя в проекте и даёт несколько советов, связанных с переходом на feature-first модуляризацию.
​​Разновидности commit()
#interview #intro

При использовании Fragment есть 4 способа совершить транзакцию: commit(), commitAllowingStateLoss(), commitNow(), commitNowAllowingStateLoss().

По логике, должно быть достаточно только первого метода, но на практике их 4.
Для чего нужны все эти методы и чем они отличаются?
Это распространённый вопрос на собеседованиях, да и при повседневном кодинге подобная информация может быть важной. Давайте рассмотрим подробнее.

🔸commit() vs commitAllowingStateLoss(). Иногда при использовании Fragment или DialogFragment можно столкнуться с ошибкой can’t perform a commit after onSaveInstanceState(). Детальная статья об этой ошибке тут, а главный недостаток этого бага в том, что его не так просто отловить при разработке и он легко может проявиться в проде.
commit() и commitAllowingStateLoss() почти одинаковы в своей работе за исключением одного: при вызове commit FragmentManager проверяет, сохранил ли он своё состояние или нет. Если сохранил, то появляется эта ошибка.
При вызове commitAllowingStateLoss() вы не получите ошибку, однако FragmentManager может потерять своё состояние, и, соответственно, других фрагментов, добавленных после метода onSaveInstanceState().

🔸commit() vs commitNow(). Другая альтернатива использования commit влияет на время выполнения транзакции.
При вызове commit() транзакция не совершается мгновенно: она планируется в главном потоке и выполняется только тогда, когда этот поток готов к выполнению. На практике это даёт возможность выполнять любое число транзакций, но следует помнить, что они не выполнятся сразу.
При вызове commitNow() транзакция выполняется в тот же момент: если вызвать несколько транзакций, то все другие будут ожидать, пока первая не завершит своё выполнение. Стоит знать, что документация предостерегает не использовать этот метод, если вам нужно добавлять фрагмент в back stack.

В итоге получаем такую картину: если нужно выполнять транзакции синхронно и без добавления в back stack, то стоит использовать commitNow(). Если же транзакций несколько и важно добавлять их в back stack, то commit(). При возникновении ошибки стоит постараться выяснить причину её появления, и если победить её не удаётся, то лучше использовать методы с префиксом AllowingStateLoss.

Почитать подробнее про использование методов можно в этой статье.
​​Keyboard Transitions с MotionLayout
#view

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

По сути, главная задача — это связать MotionLayout и Instets при помощи WindowInsetsAnimation.Callback.
И конечно, отдельно рассматривается работа и на более низких версиях Android (да, 11 версия сейчас далеко не у всех пользователей).

Ссылка на статью тут.
​​Удалёнка зарубежом
#stream #youtube

Одним из «трендов» ушедшего года можно назвать удалённую работу. Многие компании, которые никогда не нанимали удалённых сотрудников сейчас охотно это делают, а разработчики, которым по душе был офис привыкают к новым правилам... 🙄
Тем не менее, вопросов остаётся много, особенно если вы хотите работать удалённо с зарубежной компанией.

Давайте вместе погрузимся в тему удалёнки и поговорим о ней с разработчиком, который последние 3 года работает на зарубежные компании — Артур Бадретдинов.
Сейчас Артур является Android Team Lead в компании Squire Technologies, а за свою удалённую карьеру посетил 24 страны!🤯

Как найти такую работу, как платить налоги, как привыкнуть к разнице в часовых поясах, какие особенности в менталитете есть при работе? Эти и другие вопросы мы обсудим на YouTube канале Android Live во вторник, 26 января в 18:30.
А ещё, вы можете задать интересующие вас вопросы в форме.

Ссылка на трансляцию тут. До встречи! 😉
​​На чём писать код для Android?
#benchmark

Скорость разработки напрямую зависит от машины, на которой установлена среда разработки: ведь с повышением сложности проекта растёт и время его сборки, а чем шустрее работает машина, тем больше кода мы можем написать.
Да и опытные разработчики не по наслышке знают, как много Android Studio съедает ресурсов. 🙄

Выбрать компьютер для разработки не так просто: обзоры обычно не рассказывают про разработчиков, а статьи часто не дают полной картины.

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

Ссылка на репозиторий тут, там же и инструкция по тестированию своей машины. А тут можно почитать уже финальные результаты и решить для себя, что же прикупить для улучшения качества своей работы.
А на какой операционной системе вы работаете?
Anonymous Poll
48%
Windows
35%
Mac OS
17%
Linux
0%
Другое (сообщите в ЛС)
​​Android Dependency Analyzer
#tools

Ресурс, который поможет проанализировать размер зависимостей в Android-проекте: ведь размер приложения — это важная метрика.

Следует сделать два простых действия: перейти на сайт ➡️ Droidanalyser, ➡️ ввести необходимую зависимость. Опционально можно ввести адрес репозитория.

Например, можно понять, что androidx.appcompat:appcompat:1.2.0
занимает около 380 килобайт в проекте.

🔻К недостатку можно отнести относительно медленную скорость работу ресурса.

Уверен, что после анализа зависимостей вы будете внимательнее относиться к тому, стоит ли заносить в проект какую-то новую либу. 👌🏻
​​Инструменты для Room
#tools #comments

Room — отличная библиотека для работы с базой данных, которую сейчас используют многие приложения. Мне кажется, что это один из самых удачных и удобных инструментов из Jetpack. Плюс к этому — это и рекомендованный инструмент от Google.
Но работу с Room можно улучшить, используя следующие библиотеки:

🔹Roomigrantинструмент, который позволяет автоматически генерировать миграции для Room, используя compile-time генерацию кода. По сути, библиотека использует созданные Room схемы и делает миграцию на их основе. Не уверен, что библиотека сделает всю работу за вас, но уж точно поможет автоматизировать эту рутинную работу

🔹RoomExplorer — быстрый viewer базы данных вашего приложения в отдельной Activity. Кроме этого, можно писать запросы для базы данных и видеть результат их работы. По сути, дублирует инструмент из Android Studio, но может быть полезным в случае работы с тестовым билдом.

А какие инструменты для улучшения работы с Room вы знаете?
​​Podlodka Android Crew 3 сезон

Ребята из Podlodka снова делают конференцию для Android-разработчиков. На этот раз нас ждут две недели, которые разделены на секции UI и алгоритмов.

На первой неделе рассмотрим UI: лайфхаки верстки, Constraint best practice, анимации, дизайн-системы, рендеринг UI на уровне системы. Выглядит всё довольно интересно, ведь с вёрсткой мы сталкиваемся на практике очень часто, но даже в этой области всегда есть куда расти.

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

Начало конференции — 1 февраля, а билет сейчас стоит 3900 рублей. Подробнее о программе конфереции можно почитать тут, там же можно приобрести билет.

Для подписчиков Android Live есть две крутых новости.
Во-первых, вы можете получить билет бесплатно, просто оставив свой ник в Telegram в форме до этой пятницы 29 января 18:00. Розыгрыш проведём в этот же день.
Во-вторых, есть промокод на скидку 300 рублей при покупке билета — ANDROID_LIVE_DC3.

Кстати, если вы выиграете билет в розыгрыше, но предварительно купите билет, то вам вернут за него деньги, так что нет смысла тянуть с покупкой до пятницы 😉.
​​Проясним TransactionTooLargeException
#theory

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

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

Кстати, одной из главных оптимизаций является передача небольшого количества данных через Bundle, но уверен, что это вы и сами знаете 😉.
​​ WorkManager 2.5.0
#updates #jetpack

Вышла новая версия WorkManager — 2.5.0. Что нового:

▪️управления процессами для установки фоновой работы. Полезная штука, если ваше приложение активно использует несколько процессов, и таким образом можно улучшить производительность фоновых операций. Для этого добавили новый артифакт: androidx.work:work-multiprocess:2.5.0 и метод для установки процесса по умолчанию для работы;

▪️повысили стабильность старта JobService из ActivityManager;

▪️ уменьшили размер буфера повторяемых задач с 7 дней до 1 + продолжительность keepResultsForAtLeast. Стоит быть осторожным, если вы выполняете свои задачи раз в несколько дней;

▪️добавили WorkManager Inspector, что на мой взгляд очень крутое обновление. Пока только в alpha версиях Android Studio, но уже выглядит обещающе и улучшит процесс отладки фоновых задач.

Подробнее про изменения можно почитать тут.
​​​​Результаты конкурса Podlodka Android Crew — 3 сезон
#конкурс

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

В конкурсе принял участие 61 человек, при помощи генератора случайных чисел был выбран победитель — @max_ultra, с чем я его поздравляю! 🎊

Видео с выбором победителя тут. Обязательно участвуйте в новых конкурсах!
Жизнь разработчика в Германии
#интервью #экспаты

Друзья, наконец, вторая статья из рубрики, связанной с жизнью разработчиков в других странах готова.

Как всегда, она получилась объёмной и отвечает на все вопросы, которые вы задавали (и даже больше). Не скупитесь на лайки, потому что это мотивирует искать для вас авторов, а авторов — писать статьи. 🙃

Ссылка на статью тут, а вы обязательно пишите обратную связь в чат или мне в личные сообщения.
​​Kotlin Delegation
#kotlin

Kotlin delegates — одна из самых недооценённых фич языка.
Для многих разработчиков они кажутся сложными, а также многие не знают, для чего именно им нужно писать свои собственные делегаты. 🙄
Но на практике Kotlin delegates оказывается весьма полезной фичей, которая упрощает код и делает его более читаемым.

По сути, делегат передаёт обращения get()и set() к свойству: причём достаточно, чтобы у класса были методы getValue() и setValue() с определённой сигнатурой, без переопределения какого-то интерфейса.

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

Ну и не забывайте про документацию, где можно также вдохновиться полезными примерами. ✌️
​​Подробнее про Paging 3
#jetpack #room

Библиотека Paging 3 помогает отображать большие списки в RecyclerView. Сейчас она в статусе alpha, но уже хорошо работает.

Отмечу явные плюсы:
▪️поддержка Flow и Coroutines. Ну и кроме этого есть поддержка RxJava и LiveData, если она вам нужна;
▪️полностью написана на Kotlin;
▪️поддержка разделителей, статусов загрузки, состояний ошибки;
▪️интеграция с Room. Добавлю, что интеграция работает также и при использовании RawQuery из Room. Эта интеграция заметно упрощает работу с Paging 3.

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

Добавлю также один баг, который важно учитывать при использовании Paging 3. Эта библиотека работает некорректно, если поместить RecyclerView в ScrollView. Будьте внимательны при использовании!
​​Kotlin 1.4.30 и новый компилятор
#kotlin

Сегодня вышла новая версия языка Kotlin. Появилось достаточно много изменений: ▪️inline-интерфейсы;
▪️изменения в работе inline-классов;
▪️поддержка JVM records.
Полный список изменений можно найти тут.

Плюс к этому JVM IR backend компилятор перешёл в стадию beta 🎊.
О новом компиляторе говорят уже давно, и вообще он обещает быть интересным. Однако, для начала, надо убедиться, что он достаточно стабилен для public релиза. И это то, где вы можете помочь ему стать лучше 📈.

Сделать это достаточно просто:
1️⃣Включите новый компилятор его в своём конфиг файле и соберите проект хотя бы раз. В идеале включить его по умолчанию для вашего проекта, потому что не только сборка, но и дебаг имеют значение в этом тестировании.
2️⃣В случае если будут баги, то можно репортить их в Youtrack или публичный Slack Kotlin.

Давайте вместе доведём новый JVM IR backend до стабильного состояния!
​​Модуляризация Android-приложений
#architecture

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

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

Во второй и третьей частях рассматривается пример ручной и ленивой илициализации модулей их их сбрасывания.
2025/09/03 00:44:26
Back to Top
HTML Embed Code: