Room (абстракция над SQLite) — одна из основных технологий, используемая почти во всех Android-приложениях для кэширования данных, оффлайновости, как cross-process хранилище данных и тому подобное.

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

Встает вопрос: “А не является ли сама работа с БД узким местом скорости старта приложения?”

В Wildberries это особенно актуально, так как приложение построено на парадигме offline-first, когда почти вся информация кэшируется в БД, чтобы приложение работало даже с медленным интернетом или без него.

Для ответа на этот вопрос в статье разберем рантайм реализацию автоматического трекинга скорости выполнения запросов и транзакций в Room Database на основе Java Dynamic Proxy.

Привет! Сегодня я расскажу о своём опыте написания простого Android-приложения  для отправки биткоинов с существующего кошелька, отображения его баланса и списка транзакций. Кажется, чего уж проще? Да, но есть нюансы. О них и поговорим.

Привет! Меня зовут Даниил, я Android-разработчик в команде VK ID SDK в VK. Наша команда создала легковесный SDK для авторизации через приложения экосистемы VK. Он состоит из кнопки One Tap для входа в один клик, кнопки входа в другую учётную запись и виджета для авторизации через Mail или Одноклассники.

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

Я расскажу, как мы писали плагин для сбора метрик и с какими проблемами столкнулись. Вы узнаете, как устроен наш сборщик изнутри, и даже сможете потестить его в своём проекте.

Всем привет! На связи Дима Котиков, и мы завершаем цикл статей о том, как облегчить себе жизнь и уменьшить boilerplate в gradle-файлах. В предыдущих статьях мы подготовили и настроили базовый модуль для написания Gradle Convention Plugins, написали несколько convention-плагинов в файлах -.gradle.kts, сделали еще один модуль и создали convention-плагины на базе kotlin-классов. В заключительной части мы немного порефакторим написанный код, попытаемся настроить области видимости convention-плагинов и extension-функций для конфигурации сборки, а также подведем итоги. 

Всем привет! На связи Дима Котиков и мы продолжаем разговор о том, как облегчить себе жизнь и уменьшить bolierplate в gradle-файлах. В предыдущих статьях мы сделали отдельный модуль для написания Convention Plugins, провели необходимые настройки и написали несколько Convention Plugin‑ов в «‑.gradle.kts»‑файлах. В этой части мы будем создавать Convention Plugin‑ы на базе Kotlin‑классов.

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

— в чём его суть и чем он отличается от классического подхода в разработке;
— что такое контракт экрана и контракт компонента, почему они главный источник истины в BDUI подходе, и как с ним работать дизайнеру;
— как дизайнеру читать JSON, разберём ключи и значения.

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

Всем привет! На связи Дима Котиков, и мы продолжаем разговор о том, как облегчить себе жизнь и уменьшить Boilerplate в gradle-файлах. В первой части поговорили о том, как подготовиться к созданию модулей для Gradle Convention Plugin. Двигаемся дальше!

Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»

Привет, Хабр! Я Дима Котиков, ведущий android-разработчик в Т-Банке. Работаю в команде приложения Долями. Разработкой под Android начал увлекаться в 2020 году, а потом хобби переросло в работу. Люблю разбираться в технологиях, разрабатывать под Android и KMP и латте на фундучном молоке :)

Я расскажу о том, как облегчить работу с Gradle с использованием Gradle Convention Plugins. Всю информацию я разбил на серию статей для удобства. Они будут полезны всем, кто пользуется Gradle в качестве сборщика проектов. В первой части поговорим о проблеме с build.gradle-файлами и сделаем начальную настройку для написания Gradle Convention Plugins.

Продолжение первой части цикла. В первой части мы разобрались в причинах, по которым загрузка данных в блоке init{} может помешать прогрессу; изучили наиболее рациональные методы организации пользовательского интерфейса и логики приложения с помощью ViewModels. Также мы обсудили простые решения и важные тактики, позволяющие избежать часто встречающихся подводных камней.

В этой части мы продолжим фокусироваться на важных принципах разработки и оптимизации ViewModel в Android, направленных на улучшение архитектуры приложения и повышение его производительности. Рассмотрим подробнее рекомендации, касающиеся раскрытия изменяемых состояний, использования update{} при использовании MutableStateFlows и «ленивого» внедрения зависимостей в конструктор.

Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных.

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

На бумаге такие идеи кажутся идеальными, иногда даже «серебряной пулей». Однако на практике всё не так однозначно, и многое зависит от конкретного кейса. В этой статье я поделюсь опытом нашей компании, расскажу о нюансах, которые позволили нам извлечь пользу из BDUI, и представлю рабочий инструмент. Мы использовали нестандартные подходы, которые, надеюсь, вдохновят вас. Похоже, что для нас BDUI — это скорее удовольствие, чем боль. Давайте разберёмся, как нам это удалось!

Привет, меня зовут Вера, я Android‑разработчик в Яндекс Диске. Мы в Диске сейчас активно работаем над переездом на Compose с использованием дизайн‑системы. Про стабильность в Compose есть немало статей, однако ошибки продолжают cовершаться, поэтому решила поделиться своим опытом в формате ликбез‑статьи.

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

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

Представлюсь – я java разработчик, работаю в крупном банке, создаю (и поддерживаю существующие) микросервисы.

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

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

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

Давайте узнаем, как хватать и чем траффик.

В огромном приложении Android с Clean Architecture много рутинной работы, связанной с отображением объектов между различными слоями. Хорошим решением будет автоматизация этого процесса.

В этой статье рассматривается опыт использования библиотеки MapStruct, которая помогает mapp-ить объекты.

Библиотека очень гибка в настройке. И позволяет минимизировать написание шаблонного кода.

Вот пример того, как реализовать gradle зависимости в вашем проекте.

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

Полный разбор корутинного мира с нуля, который может послужить отличной шпаргалкой на собеседовании!
Разберем разницу между многопоточностью и асинхронностью; раскроем все основные понятия корутин, параллельно ссылаясь на исходники kotlinx.coroutines; посмотрим их применение на практике и в конце напишем свой собственный CoroutineScope.

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

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

В этой статье:

• Когда юикса стало недостаточно?

• Что такое User Joy?

• Зачем нам думать про кайф?

• Как измерять кайфовость?

• С кого брать пример?

• 15 способов достижения кайфа.

• Что поменять в дизайн-процессе?

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

В нашу жизнь андроид разработчиков уже прочно вошел фреймворк Compose. И при создании composable функций возникает соблазн добавить в качестве параметра viewModel. А уже в самой compose функции подписываться на состояния, которые находятся внутри viewModel. Я хочу рассказать, почему так делать не стоит, а передавать в качестве параметров простые классы.