​​#новыйкурс #тестирование #room #viewmodel
Тестирование LiveData, ViewModel и Room

🚀Архитектурные компоненты Android (Android Architecture Components, AAC) – уже давно стали частью большинства приложений. Они помогают создавать надежные, тестируемые и масштабируемые Android-приложения. В большинстве проектов от Android разработчика требуется не только использовать AAC, но и умение покрывать ваш код тестами и использовать при этом различные инструменты. В данном туториале вы сможете освоить основы написания Unit-тестов, покрывающих работу Android Architecture Components.

В этом мини-курсе вы научитесь тестировать Android Architecture Components, а именно: ViewModel, LiveData, Room. Кроме этого мы рассмотрим процесс создания кастомных правил для переиспользования логики. В качестве демонстрационного приложения вы разработаете приложение для составления списка ежедневных задач. Для прохождения этого мини-курса желательно, чтобы вы имели представление о работе с ViewModel.

В результате прохождения курса вы:

📌Освоите базовые аннотации JUnit
📌Научитесь тестировать ViewModel и LiveData
📌Научитесь тестировать Data Access Objects в Room
📌Создадите собственные кастомные правила для переиспользования логики между тестами.

Курс бесплатный, но требуется регистрация. После регистрации вам доступны уроки и примеры кода. Не забудьте оставить обратную связь и оценить курс.
📚Ссылка на курс

​​#mockwebserver #espresso #новыйкурс
Использование MockWebServer при разработке и тестировании Android-приложений

📌 Очень часто бывает так, что нужно замокать какие-то данные от сервера и проверить, как приложение поведёт себя в случае пустого ответа или ошибки от сервера. Уверен, что такой кейс был у каждого. MockWebServer - простая и удобная библиотека от Square, которая позволит вам легко и просто создать фиктивный веб-сервер и не зависеть от реального. Это упрощает тестирование различных сценариев без доступа к Интернету и без необходимости вносить изменения в удаленный сервер. Для проверки того, как реагирует приложение на ошибки сервера мы напишем UI-тесты на Espresso.

В этом мини-курсе вы узнаете:

✅ Преимущества использования фиктивного сервера при тестировании.
✅ Как настроить MockWebServer.
✅ Как заставить MockWebServer имитировать поведение вашего реального сервера.
✅ Как писать UI-тесты, чтобы убедиться, что ваше приложение работает должным образом.

Не забудьте оставить комментарий к туториалу и поставить лайки репозиторию с исходным кодом.
📚 Ссылка на курс

@android_school_ru

​​#rxjava #собеседование #article
8 Каверзных вопросов по RxJava
Несмотря на то, что Kotlin Coroutines и Flow потихоньку перетягивают одеяло, всё-таки на многих больших проектах всё также используется RxJava. Если у вас сложное приложение, то задачи выходят за рамки обычного сценария: сходить в сеть и отобразить данные. И тут в дело вступают различные операторы RxJava — как раз то, почему Rx ещё долго не будет заменена на мой взгляд. В данной статье приведены вопросы от простого к сложному, которые могут ввести в ступор даже продвинутых пользователей RxJava

Читать подробнее

@android_school_ru

#room #автомиграции
Если миграции базы данных для вас были тёмным лесом и вместо правильной обработки смены версии БД, вы выбирали просто удаление старой базы данных вместе с данными, то спешу вас обрадовать: в Room появились автомиграции!

С версии 2.4.0-alpha01 появилась возможность использования автомиграций.
Это подойдёт для простых случаев, когда нужно:

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

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

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

@android_school_ru

У меня часто спрашивают, как подготовиться к собеседованию. Мой ответ краткий: практика, очень много практики. Но конечно, чтобы понимать векторы для изучения можно и нужно смотреть вопросы и искать на них ответы. Примером такого списка может быть вот этот репозиторий с вопросами. Обратите внимание на блок с многопоточностью-по моему опыту он самый сложный и его активно задают на собеседованиях. https://github.com/enhorse/java-interview

​​#appsearch #fulltextsearch #sqlite
App Search Library для локального full-text поиска документов в Android-приложениях.

📌Совсем недавно Google анонсировал библиотеку для локального поиска документов AppSearch. Библиотека пока находится на стадии alpha-версии, но тем не менее уже можно применить её и рассмотреть ряд возможностей. В этом туториале мы разработаем небольшое приложение для локального поиска разного рода документов и отобразим их пользователю для демонстрации работы AppSearch. Кроме этого кратко поговорим про ListenableFuture и ExecutorService, так как поддержки RX или Kotlin Coroutines пока нет и приходится работать с ListenableFuture.

📚Ссылка на туториал
Не забудьте оставить комментарий к туториалу и поставить лайки репозиторию с исходным кодом.

Кроме того, опубликовал краткий обзор на хабре
📌Обзор AppSearch на хабре

​​#flow #room #coroutines
Kotlin Flow + Room на примере создания todo-списка

📌Новый туториал будет интересен тем, кто хотел на практике освоить Kotlin Flow и Kotlin Coroutines в связке с хранением данных через Room. В этом туториале мы разработаем небольшое приложение для создания списка дел. Помимо сохранения данных, используя Room, вы научитесь работать с Kotlin Flow для получения данных. В результате прохождения мини-курса вы разработаете собственное приложение, позволяющее сохранять список дел.

📚Ссылка на туториал
Не забудьте оставить комментарий к туториалу и поставить лайки репозиторию с исходным кодом.

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

По своему опыту могу сказать, что очень мало Android-разработчиков могут внятно ответить на перечисленные вопросы.Где терабайты информациия в БД и где мобильная разработка с одной таблицей или SharedPreferences. Но если вы хотите быть хорошим инженером - то очень советую проработать эти вопросы. Когда я учился, в моём университете был целый семестр, посвященный реляционным БД - и это было очень полезно, теперь у меня есть ряд каверзных вопросов для собеседования)
Поэтому в этом посте будет две ссылки.

📌 Первая ссылка как раз очень поможет вам проработать теоретическую базу
https://habr.com/ru/company/yandex/blog/522164/

📌 А вторая - моя статья про новую фичу в Room, облегчающая работу с join. Там и обзор join-ов и демонстрационный пример.
https://habr.com/ru/post/570400/

​​📌Как отрефакторить код на примере паттерна Шаблонный метод.

Почему-то большинство статей про паттерны демонстрируют какие-то нереальные примеры с квадратиками/кружочками/котиками и т.д. Но мало примеров которые прямо в реальном проекте показывают: вот так было плохо, а вот теперь хорошо и почему. Написал для вас статью с примером из реальной жизни Android-разработчика, которая прямо на примере показывает плохое решение с последующим рефакторингом с применением паттерна Template. Прямо бери и внедряй.

В больших проектах с множеством логики, порой возникает момент, когда логика вобщем то базовая одинаковая, но вот конкретные шаги отличаются, например от типа данных. И тогда в дело вступает конструкция if else. А дальше, все как в тумане и вот у вас уже нечитабельная лапша 🍝 из миллиона if-ов. Признавайтесь, у кого такое было?

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

Ссылка на статью c примерами кода

@android_school_ru

Переиспользование логики в тестах через аннотацию Rule

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

#rxjava3 #retrofit
Программирование на RxJava 3.0 для Android

🚀Новый туториал будет интересен тем, кто хотел на практике освоить RxJava3. Библиотека RxJava - уже давно стала стандартом в мире разработки мобильных приложений. В этом мини-курсе вы научитесь использовать основные возможности Rx для повышения эффективности ваших приложений. Мы рассмотрим концепцию реактивного программирования, научимся писать многопоточный код и использовать основные операторы Rx.

В результате вы на базовом уровне освоите RxJava и сможете использовать в своих Android-приложениях эту библиотеку для сетевых запросов, взаимодействия с UI, осуществления запросов к БД и многое другое.

📚Ссылка на туториал
Не забудьте оставить комментарий к туториалу и поставить лайки репозиторию с исходным кодом. P.S. Скоро будет и Flow 😉

Канал @android_school_ru

В ближайшее время 20 мая буду выступать на конференции Merge в Иннополисе, так что если планируете участвовать буду рад встретиться. Описание доклада и тезисы можно посмотреть тут https://innopolis2022.mergeconf.ru/development/mobile/valuysky

📌Паттерн Стратегия - гибкость или излишняя сложность?

Начинающие разработчики часто имеют проблемы с разделением presentation-слоя и domain. Репозитории вроде бы все научились создавать, но часто их создают просто потому что "так принято" и не осознают гибкости при работе с ними. А гибкость как раз достигается за счёт паттерна Стратегия, который скорее всего многие использовали, но не знали что это он. Так что в этой статье рассмотрим плюсы, которые предлагает этот паттерн и применим его на реальном примере.

Пример паттерна стратегия

#многомодульность #архитектура
Принципы построения многомодульных Android-приложений

Современные Android-приложения уже давно переваливают за несколько сотен экранов. Во всех проектах где я работал, так или иначе приходили к разбиению приложения и переходу от монолитного app-модуля до нескольких feature-модулей. Где-то сразу проектировали модули, где-то при масштабировании проекта. Как раз и на текущем проекте мы в команде активно распиливаем монолитные модули, поэтому последнее время уделяю много внимания теме многомодульности. Совсем недавно Google добавил несколько рекомендаций по этой теме. Решил перевести статью и выложить на хабр, на родном языке читать приятнее, да и давно в рунете не было на эту тему свежих статей. В комментариях к статье уже начался холивар на тему многомодульности, так что накидывайте аргументы.
https://habr.com/ru/post/687882/

​​Смешиваем Android-разработку с музыкой и получаем крутой летний Android Meetup.

🤘Друзья, всем привет, у меня есть крутая новость. Напомню, сейчас я работаю лидом платформенной команды в стриминговом сервисе Звук.Наша платформенная команда создаёт инструменты для разработки и улучшает функциональность.

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

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

🎸 Ну а в конце много общения, afterparty с Dj, вайбом домашней вечеринки и легкими закусками. Регистрируйтесь и приходите в Москве или онлайн. Буду всех ждать!
PS. А еще мы ищем Android-разработчиков - пишите в личку, расскажу.

Регистрация и подробная программа тут

🤘В прошлый четверг выступил на Android-митапе в Звуке, где я являюсь лидом Android-платформы.

Рассказал о том какой путь мы прошли от обычной Android-команды из пары человек в отдел мобильной разработки из 25 Android-разработчиков, работающих в 10 продуктовых и платформенной команде. Особое внимание уделил рефакторингу и работе с техдолгом, а также показал пример Roadmap'a платформенной команды.

Вообще Android-митап вышел очень структурным, сначала я рассказал о платформе, а потом ребята из платформы поделились своим опытом: как разрабатывали дизайн-систему в Звуке и как работает музыкальный плеер.

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

​​👨‍💻 Зачем ходить на конференции? Выводы и ссылка на доклады

На прошлой недели посетил в Сколково крупнейшую конференцию для тим и техлидов TeamLead Conf 2023. Напомню, что являюсь тимлидом платформенной команды в стриминговом сервисе Звук, где мы занимаемся архитектурой и оптимизациями проекта.

Помимо постоянного расширения технического кругозора тимлиду приходится еще и прокачиваться в навыках управления командой, мотивировать и обучать команду, улучшать процессы. И все это очень специфично и зависит от команды, количества человек, культуры компании. Короче говоря, единственного правильного рецепта тут нет. И именно поэтому я стараюсь учиться у практиков-коллег, которые передают свой опыт как на докладах конференции так и в кулуарном общении. Помимо просмотра докладов, в этом году специально решил уделить время просто общению и знакомству с коллегами из других компаний, и знаете, это было чуть ли не так же полезно, как сходить на крутой доклад. Общаясь с коллегами можно обменяться опытом, расспросить как решались те или иные проблемы. Многие компании прямо на стенде предлагали решить и обсудить те или иные кейсы. Например на стенде яндекса ребята предлагали решить необычные случаи из реальной тимлидской практики. Ну а еще у нас был собственный стенд Звука где тоже было много общения на разные темы.

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

📚Ну и в качестве бонуса плейлист на все доклады прошлой конференции, будет полезно не только тимлидам, но и тем, кто хочет ими стать или улучшить софт-скилы.

📚 Реальные задачи на System Design собеседовании для мобильного разработчика

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

Итак, какого типа задачи ожидать на System Design интервью для мобильного разработчика? Это реальные задачи которые я видел:

📌 Спроектировать приложение прогноз погоды.
📌 Спроектировать банковское приложение для отслеживания котировок акций.
📌 Спроектировать приложение для отслеживания заказа.
📌 Спроектировать приложение редактор картинок

Таким образом, на позиции мобильного разработчика от вас никто не ждет что вы сможете спроектировать высоконагруженный бэкенд, однако иметь представление о сетевом слое все-таки необходимо. Вы должны уметь рассказать о плюсах и минусах например REST API vs GraphQL и доказать почему именно REST подойдет вашему приложению которое вы проектируете.

О чем еще неплохо порассуждать и показать что вы знаете о чем говорите:

📌 Реляционные БД vs No-SQL решения
📌 Server-Driven UI
📌 Способы тестирования и плюсы минусы тех или иных подходов
📌 MVP vs MVVM vs MVI.

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

Ну и напоследок, самое главное что от вас ожидают на System Design интервью - это способность задать уточняющие вопросы, предложить идеи. Не начинайте рисовать диаграммы пока не спросите 5-10 вопросов. Если молча начать проектировать архитектуру - это красный флаг.

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

- Набор примеров задач для System Design Interview
- System Design. Подготовка к сложному интервью. Автор:Алекс Сюй
- System Design Template
- System Design CheatSheet

⚙️ Взламываем System Design интервью для мобильного разработчика.

Как и обещал, написал детальную статью по System Design интервью для мобильных разработчиков. Тут кратко расскажу про этапы и рекомендации, а на хабре более подробно с примерами и диаграммами. https://habr.com/ru/articles/781404/

В зависимости от процессов найма в компании на System Design у вас будет скорее всего около 1 часа. Это супер мало, поэтому четко планируйте время и старайтесь придерживаться следующего тайминга:

1️⃣ Понять условие задачи и собрать требования (5-10 минут). На этом этапе важно собрать как можно больше требований и досконально понять проблему какую вам нужно решить. Иногда вам могут дать уже какую-то заготовку, например скриншот какого-то приложения и спросить как спроектировать функционал показанный на этом скриншоте. На данном этапе приветствуется задавать вопросы. В первую очередь запишите что именно будут делать пользователи, опишите возможные сценарии использования.

2️⃣ Построение общей архитектуры верхнего уровня. (10-15 минут).

На этом этапе вы уже можете брать виртуальный маркер и начать рисовать верхнеуровневую диаграмму. Вам необходимо нарисовать блоки с ключевыми компонентами системы. Если говорить про Android-разработку, то нужно упомянуть принципы Clean Architecture и разделение по слоям. Комментируйте вслух почему вы решили использовать тот или иной компонент, какая у него будет ответственность. Например: DataSource будет отвечать за кэширование данных, потому что мы будем использовать offline-first подход.

3️⃣ Детальное описание каждого компонента вашей архитектуры и выбор решения. (20 минут).

На данном шаге вы согласовали требования и спроектировали примерную архитектуру. Теперь необходимо углубиться в каждый из компонентов и описать как бы вы реализовывали тот или иной компонент. Имея список компонентов (в реальном интервью он у вас на схеме перед глазами) вам необходимо пройтись по каждому и рассказать плюсы минусы альтернативных решений и почему вы выбрали именно это. Например реализация кэширования через Room vs Realm, использование сокетов или Rest API и т.д.

4️⃣ Подведение итогов и ответы на вопросы. (10 минут).

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

Рекомендации

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

⏰ Следите за временем. Интервьюер может вас отвлекать - ваша задача максимально полно представить решение за короткий срок. Заранее ознакомьтесь со средой в которой будете рисовать. Это может быть Draw.io, Excalidraw.

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