​​RxJava и планировщики
#разработка #начинающим

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

Для начала работы с многопоточностью используются операторы subscribeOn() и observeOn(), а также планировщики (Schedulers).

Например, в приложении есть метод getNames(), который возвращает список имен в приложение с сервера, после чего нам надо показать эти имена в списке. Для того, чтобы выполнить этот запрос в отдельном потоке мы должны использовать оператор subscribeOn() и указать в качестве Scheduler’а Schedulers.io(). Для обработки у нас есть оператор observeOn() с Scheduler’ом AndroidSchedulers.mainThread(), что позволит нам показать эти данные в main-thread.
Кроме этого есть дополнительные Scheduler’ы, которые важно применять с пониманием:
• Schedulers.io() — его стоит использовать для операций, которые не связаны с интенсивной нагрузкой на процессор. Он использует неограниченный пул потоков, и количество потоков может расти по мере необходимости. В нашем примере мы использовали его для доступа в сеть. Также, его используют для доступа к файлам, получения информации из базы и прочим подобным операциям.
• Schedulers.computation() — его рекомендуют использовать для операций, которые высоко нагружают процессор: обработка изображений, огромный объем данных. Но не стоит слепо ставить его во все запросы: пул у этого планировщика ограничен количеством процессоров на устройстве. Это сделано для того, чтобы отсутствовала конкуренция за ресурсы процессора в случае выполнения нескольких операций.
• Schedulers.newThread() — его лучше использовать для операций, которые выполняются долгосрочно в фоне. Стоит также использовать осторожно, потому что создает новый поток при каждой обработке элемента.
• Schedulers.single() — его стоит использовать в случае последовательного выполнения задач. Например, если вам важно, чтобы две задачи не выполнялись одновременно в приложении. Тоже не самый частый сценарий.
• Schedulers.from(Executor executor) — можно написать собственный Executor и описать логику распределения потоков. Например, вы хотите ограничить количество запросов в сеть или в базу данных. Тогда можно использовать этот планировщик, это значительно упростит задачу.
• AndroidSchedulers.mainThread() — используйте его, чтобы выполнить операцию в main-thread. В нашем примере — это показ списка имен на экран.

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

Надеюсь, что эта шпаргалка поможет лучше понимать логику работы с Scheduler в RxJava.

AppsConf. Список докладов
#конференции

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

Например, меня заинтересовал доклад Александра Ефременкова «Android binary XML: deep dive». Каждый сталкивался с написанием кода черезе xml, однако мало кто задумывается о том, что происходит с этими файлами после компиляции и что с ними можно сделать.

Еще один доклад — «Деливерим фичи быстрее. Опыт Badoo» Анатолия Варивончика расскажет о том, как творчески подходить к быстрой реализации фич. Интересно узнать, подходят ли эти практические советы всем командам, а не только большим, имеющим много ресурсов.

Андрей Шиков в докладе «Многоразовые компоненты Android-приложений Badoo. От копипасты к модулям» поделится опытом разбиения дублированных частей кода в модули и их переиспользования. Достаточно насущная проблема для больших приложений, а также для тех компаний/разработчиков, которые имеют в своем арсенале монолит и планируют разбиение на модули.

В докладе «Как pet-проекты поднимают уровень и доход мобильного разработчика» Вячеслава Слуцкера интересно узнать больше про то, как созавать свои приложения не просто для удовольствия и повышения уровня разработчика, но и для того, чтобы они приносили какой-то доход.

Про тестирование приложений часто забывают даже в опытных командах, а про UI тестирование еще больше. Доклад «Как перестать бояться и начать писать UI-тесты вместе с Kakao» Константина Аксенова предлагает окунуться в тему тестирования UI при помощи Kakao. Никогда не использовал этот фреимворк, интересно будет узнать про его возможности.

До встречи на конференции!

​​Don’t Keep Activities
#разработка

Если вы некоторое время являетесь Android-разработчиком, то вы наверняка слышали про настройку Don’t Keep Activities. Она находится в самом конце списка настроек для разработчика. И это очень полезная настройка, чтобы протестировать приложение на предмет того, что случится с приложением, если Activity убьется системой.

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

Для того, чтобы посмотреть, что будет с приложением при убийстве системой самого Application, необходимо включить настройку «Background process limit», и в полученном окне выбрать «No background processes».

Если после установки этих двух настроек, ваше приложение падает при загрузке из фона, то вы делаете что-то не так.

​​Cloud Firestore
#разработка

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

И не так давно открыл себе сервис от Google, который называется Cloud Firestore. Он представляет собой облачную базу данных, которую Google позиционирует как замену Realtime Database.

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

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

​​-nodpi и -anydpi
#разработка #начинающим #опрос

После создания первого проекта возникают вопросы, связанные с расположением ресурсов. С появлением векторных изображений, ситуация стала проще: можно пользоваться только папкой /res/drawable, и изображения будут правильно отображаться на устройствах с разными размерами экрана.

Однако, бывают исключения, когда необходимо использовать png изображения в проекте. И если с разрешениями экрана и их ресурсами все более менее ясно (drawable-hdpi, drawable-mdpi, drawable-ldpi и прочие), то с папками drawable-nodpi и drawable-anydpi возникает непонимание.

На самом деле, все просто:
• -nodpi используется в качестве «запасной» папки. Например, если у вас есть ресурсы в res/drawable-nodpi/foo.xml и res/drawable-xxhdpi/foo.png, то все устройсва, кроме xxhdpi будут использовать векторное изображение.
• -anydpi используется в качестве «приоритетной» папки. Если взять наш пример: res/drawable-anydpi/foo.xml и res/drawable-xxhdpi/foo.png, то все устройства будут использовать векторный ресурс, в том числе и xxhdpi.

Знали об этом?

​​Эмулятор notch
#разработка

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

Но не каждый знает, что поведение и внешний вид подобных устройств можно получить и на обычном смартфоне. Для этого нужно:
• открыть настройки для разработчика;
• пролистать до раздела «Отрисовка»;
• выбрать пункт «Симуляция экрана с вырезом».

Данная функция доступна только на последней версии Android.

​​try-catch или проверка?
#разработка

Наткнулся на интересный пост, который сравнивает проверку на null и обработку исключений при помощи try-catch.

На практике несколько раз сталкивался с тем, что разработчик ленится корректно обрабатывать исключение и просто пишет try-catch, возвращая значение по умолчанию.

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

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

​​Переход на Room
#разработка

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

Еще есть несколько дополнительных причин.
Первая — нестандартность библиотеки. Хотя ObjectBox имеет достаточно простые методы для работы, тем не менее нужно некоторое время на то, чтобы разобраться с ними вновь прибывшим разработчикам.

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

Задача не самая простая, так как необходимо обеспечить работу приложения у текущих пользователей. Если у вас есть подобная проблема, то вот несколько рекомендаций:
1) Добавьте Room в приложение, создайте необходимые сущности.
2) Сохраните данные в созданные сущности, при этом сохраняя все в предыдущую базу данных.
3) Добавьте анатилику, чтобы убедиться в том, что все действительно успешно сохраняется, проверьте, что будет, если убрать сохранение в вашу старую базу.
4) Выполняйте переход в несколько этапов, не пытайтесь сделать все в один спринт. Чаще всего, это приведет к неправильной работе.

Нашел также пару статей о переходе на Room из старой базы данных. Подробнее тут и тут.

​​Как устроен DiffUtils?
#разработка

Уверен, что большинство разработчиков используют в своих проектах DiffUtils. Он появился уже давно, и он дает возможность обновлять список в RecyclerView оптимальным способом. Алгоритм сравнивает два списка: старый и новый, и с помощью необходимых методов notify оптимально обновит адаптер.

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

Больше информации об алгоритме Майерса, о том, как оптимизировать и улучшить работу DiffUtils вы найдете тут.

​​Pull request. Как правильно организовать?
#разработка #вопрос #комментарии

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

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

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

Мы всем используем эту технику, но насколько правильно? Например, в нашей команде существует ряд правил, которые связаны с PR:
1) Объем каждого PR не должен превышать 500 строк кода. Если же фича занимает больший объем, то ее надо разбить на несколько PR, помечая, что текущая ветка должна вливаться не в dev, а в родительскую.
2) Каждый PR должен сопровождаться кратким описанием того, что в нем было сделано.
3) Добавление ресурсов и переименование желательно выносить в отдельный PR.
4) Те pull request, которые надо влить в общую ветку должны быть проверены при помощи тестов, развернутых на CI.

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

А какие есть правила у вас в команде, связанные с PR?
Очень интересно узнать и взять на заметку что-то новое для себя. Прошу поделиться в комментариях.

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

На первых уровнях все кажется просто, но уже к концу уровня medium ситуация становится не такой очевидной.

Всячески рекомендую всем разработчикам и дизайнерам.

Сколько получилось набрать?

​​WorkManager
#разработка

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

Но на Google IO 2018 нам предоставили такой компонент как WorkManager. Он имеет много преимуществ:
• поддержка устройств, начиная с API версии 14;
• оптимизирован для сохранения заряда устройсва;
• поддерживает как одноразовые, так и периодические задачи;
• и что самое важное: гарантирует выполнение задачи.

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

Хорошие статьи об использовании можно найти тут и тут.

​​Хоть и не часто, но тем не менее на канале появляется рубрика «Интервью с разработчиком».

Сегодня хочу представить вам не одного разработчика, а сразу нескольких.
Это Android-разработчики из команды Surf:
• Евгений Сатуров — Android Teamlead;
• Максим Туев — руководитель Android отдела.

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

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

​​Git Immersion
#разработка #новичкам

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

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

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

​​Переработки в IT
#мысли #комментарии

Переработки — это печальная практика нашей индустрии. Большинство из нас перерабатывает, кто-то больше, кто-то меньше. И многие считают это уже не проблемой, а «особенностью» с которой просто надо смириться. Но так ли это?

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

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

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

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

А как считаете вы? Насколько проблема переработок характерна для IT-сферы?

​​Адаптируем RecyclerView
#разработка #библиотека

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

1) Adapter. Каждый RecyclerView для отображения данных использует адаптер. Если рассмотреть адаптер как паттерн, то это прослойка, которая позволяет интерфейсам уже созданных классов использоваться в других интерфейсах. Все адаптеры используют разные реализации ViewHolder, поэтому адаптер RecyclerView подходит под это определение. Но одной из наиболее известных ошибок, которая встречается в написании адаптеров является бизнес-логика внутри них. Надо помнить, что Adapter — это слой, который связывает логику отображения, и в нем нет места для бизнес-логики.

2) В любом адаптере надо переопределить много методов:
• установку данных в конструкторе или через сеттер;
• переопределить getItemCount();
• если есть несколько типов данных, то переопределить getItemViewType();
• переопределить onCreateViewHolder();
• ну и напоследок написать onBindViewHolder();

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

3) DiffUtil — это класс, который решает проблему установки новых данных в адаптер, изменяя только те данные, которые нужно. Но недостаток в том же, что и во втором пункте: повторяющийся код. Для каждого Callback надо переопределить areItemsTheSame() и areContentsTheSame() и число этих методов растет в зависимости от числа типов элементов.

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

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

​​Android Lint в темной теме
#разработка #опрос #статьи

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

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

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

Сегодня попалась статья, которая помогает в нахождении этих цветов при помощи Android Lint. Это здорово, что можно сэкономить время вместо того, чтобы тратить его на нахождение этих цветов вручную. Автор рекомендует установить эту проверку в CI, чтобы избежать появления новых цветов, которые не соответствуют правилам.

А у вас в приложении есть темная тема?

​​Android Developer Roadmap
#разработка #статьи

Попалась любопытная схема — «дорожная карта» Android-разработчиков. Ведь в нашей довольно обширной области не всегда просто понять о каких вещах нужно знать, а какие стоит пропускать.

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

Ссылка на roadmap тут.

​​Java vs. Kotlin. Производительность
#статьи #комментарии

Сегодня приоритетным языком для программирования под Android, по мнению Google, является Kotlin.
Но спрашивали ли вы себя, какая производительность у этих двух языков?

В статье автор поставил себе задачу: сравнить производительность Java и Kotlin при выполнении одинаковых программ.

Для этого он воспользовался бенчмарком, где сравнивал версии нескольких программ на Java, сконвертированные версии с Java на Kotlin и Kotlin-idiomatic версии, которые использует все плюшки языка Kotlin.

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

Любопытно, что в большинстве тестов победила Java: она обычно была лучше в управлении памятью и времени исполнения.

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

Интересно, были ли у вас подобные случаи?

​​Как использовать Android Lint
#разработка #статьи

Одной из вещей, которую игнорируют Android-разработчики, является инструмент Android Lint. И причина этому то, что он для большинства он является раздражающим.

Даже при создании нового проекта и при его первой компиляции, можно увидеть несколько lint-warning, которые чаще всего игнорируются. Но Android Lint можно и нужно использовать как полезный инструмент, который помогает в написании качественного кода.

Я уже писал о том, как можно использовать свое правило для lint для нахождения «захардкоженных» цветов. Но вот небольшая инструкция о том, как настроить и использовать стандартные правила lint в своем проекте.

Для того, чтобы увидеть отчет по своему приложению, надо выполнить команду gradlew lint. В результате вы получите подробное описание всех потенциальных проблем в приложении. Большинство из них будут не критичные и связаны с «красивым» написанием кода.

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