MotionLayout
#разработка 

На последней конференции Google IO был анонсирован новый класс — MotionLayout. Он входит в ConstraintLayout 2.0 и помогает в анимации приложений. Особенностью является то, что при помощи него можно легко создавать сложный анимации переходов между различными View. По сути, это смесь стандартных анимаций, TransitionManager и CoordinatorLayout. 

Поведение MotionLayout описывается при помощи xml-файла. На мой взгляд, это также упрощает создание анимаций. Так как MotionLayout входит в support library, то поддержка устройств идет с 18 версии API. 

Сейчас layout в alpha, поэтому использовать его в реальных продуктах не стоит. Но попробовать в своих проектах или просто ознакомиться настоятельно рекомендую. Можно посмотреть доклад с Google IO о возможностях нового ConstraintLayout (примерно с 29 минуты идет разговор о MotionLayout). Но удобнее почитать серию статей о начале работы с этим layout. Особенно понравилась третья часть, где описывается взаимодействие MotionLayout с другими библиотеками и компонентами: ViewPager, DrawerLayout, LottieAnimationView. Серия пополняется, поэтому дальше будет только интереснее.

​​Рефакторить или переписать с нуля?
#мысли 

На глаза попалась статья Джоэля Спольски (основателя stackoverflow) о той ошибке, которую совершают часто многие программисты, приходящие в команду на новый проект — переписывание кода с нуля. Описывается пример браузера, о котором уже никто не знает — Netscape.

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

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

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

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

​​Формы для ввода
#дизайн

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

Например, показ ошибки. При авторизации пользователь может ввести некорректный e-mail. Можно показать ошибку сразу после окончания ввода email, что даст возможность сразу исправить ошибку. Некорректным поведением является показ ошибок после нажания на кнопку логина. 

Второй кейс —  блокировка кнопки входа. Для входа в приложение необходимыми полями является e-mail и пароль, поэтому если у пользователя эти два поля пустые или некорректные, то кнопку следует блокировать. 

В статье с примерам показываются распространенные ошибки дизайна. Рекомендую отправить эту статью знакомым дизайнерам, а также не допускать эти ошибки при создании форм.

Фокус группы
#мысли #продукт

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

Чтобы уменьшить риски не только при старте, то и во время разработки существуют фокус-группы. 

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

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

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

Разработка прототипа достаточно дешева. Для старта приложения стоит задуматься про MVP, однако не пытайтесь сделать сразу все идеально. Объясняйте людям, что это только первая версия, а также смотрите за той реакцией, которая идет от пользователей. 

Собеседования
#мысли #совет

Решил составить пост о собеседованиях вместе с админом канала @java_developer. Хотя сейчас и тренд перехода на Kotlin, но знания Java никто не отменял, особенно при приеме на работу. Сам с удовольствием читаю этот канал и получаю новые знания. Крайне рекомендую и новичкам, и опытным разработчикам.

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

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

Второе — вопросы, связанные с Android. Тут многое зависит от того, на какой уровень вы претендуете. Если junior, то это базовые вопросы: Activity, Fragment, верстка и другие. Если middle и seniour, то вопросы чаще связаны с архитектурой и применением специфических для проекта библиотек. Хороший список вопросов и ответов тут.

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

Code review
#разработка

Одним из процессов, который повышает качество кода в команде является code review.

В этом процессе принимают участие две стороны: автор кода и рецензент. Собственно, рецензент и принимает участие о добавлении кода в общую базу проекта.

На практике я сталкивался с двумя типами ревью:
• ревью проводит один человек (чаще всего тимлид)
• ревью проводят все члены команды, а решение в спорных ситуациях принимает тимлид.

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

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

А вы поводите ревью кода в своей команде?

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

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

Недостатки, помимо психологического фактора:
• время. Пулл реквесты могут накапливаться и есть риск не влезть в релиз из-за накопившегося ревью.
• зависимости. Если пуллреквест один, то терпимо, но если надо работать только после того, как будут смерджены чужие изменения (один код или PR в общую библиотеку), то ты будешь заблокирован до тех пор, пока не закончится кодревью.
• возможность удобной работы с инструментами CI: можно еще на уровне пулл реквеста прогнать все тесты, собрать целиком приложение, пройтись всеми линтами до того, как изменение попадет в мастер. 

Также теоретически возможно инспекционное тестирование: когда инженер QA после ревью и прохождения  СI-тестов сначала тестирует изменение, забирая его и собирая приложение с новым изменением, а потом уже позволяют мерджить, если тестирование прошло успешно.

P.S. Приятно, когда вы даете обратную связь по постам и присылаете #вопросы. Всегда на связи тут.

​​Полезные Rx-шаблоны
#статьи #разработка

Сегодня попалась небольшая, но полезная статья о некоторых типичных шаблонах в Android, написанных при помощи Rx.

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

Хотя эти примеры и достаточно простые, но читая каналы, связанные с Rx, понимаешь, что у новичков возникают эти вопросы.

Кейсы посложнее:
• повторить запрос или какую-то операцию несколько раз, каждый раз увеличивая задержку следующей попытки;
• создать задержку для выполнения операции на некоторое время.

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

Android App Bundle
#разработка

Одной из последних фич, представленных на Google IO, была Android App Bundle. Во время презентации мне очень понравилось это нововведение.

Это формат для публикации приложений, который поддерживает загрузку частей приложения только тогда, когда эти части действительно нужны. Android App Bundles имеют разрешение .aab и являются альтернативой .apk. Для каждого пользователя генерируется файл приложения, когда он начинает скачивать его с Google Play.

Плюсы подобного подхода:
• меньший размер приложений;
• отсутствие multiple apk;
• динамические модули;

Пока эта фича в beta, и ее уже можно попробовать. Пошаговый алгоритм применения Bundle к приложению тут.

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

Конвертация списка в строку
#разработка #советы

Часто нужно конвертировать список объектов в строку, разделенную определенным знаком. Это можно сделать несколькими способами:

1) Работает только тогда, когда нужно сконвертировать список из строк.
List<String> list = new ArrayList<String>();
String joined = TextUtils.join(", ", list);

2) Если объекты не являются строками, то придется прибегнуть к другому, более длинному способу:
StringBuilder sb = new StringBuilder();
for (User user: users) {
   sb.append(user.name + " " + user.surname + "\n");
}

Нужны ли алгоритмы?
#мысли

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

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

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

Как считаете вы, нужно ли знать алгоритмы?

​​Давно у нас не было рубрики «Интервью с разработчиком», которая мне крайне нравится. Хочу исправиться и представляю вам следующего респондента — Звиад Кардава.

Звиад работает DevRel’ом(Developer Relations) в Google. Общается с разработчиками, выступает на конференциях, рассказывает про новинки, разные API и продукты google для разработчиков. До того как присоединиться к Google, имел статус Google Developer Expert.

Поговорим о кроссплатформенных языках, особенно о Flutter, о текущих трендах разработки, о работе в Google.

Свои вопросы вы, как обычно, можете задать тут.

Хочу поздравить вас с нашим профессиональным праздником — Днем программиста! 
Желаю побольше чистого кода, архитектуры, адекватного руководства и вдохновляющих проектов. А также поменьше непонимающих менеджеров, невоспроизводимых багов и легаси-кода. 

Кстати, организаторы конференции MBLT DEV 2018 решили в честь праздника сделать скидку на покупку билетов в виде 20%. До 16 сентября можно воспользоваться промокодом MBLTDEVHAPPYDDAY. Ссылка на конфу тут.

Полная программа уже опубликована на официальной странице конференции. Спикеры из Netflix, Google, Uber, The New York Times, Badoo и других компаний расскажут о последних трендах мобильной разработки. Будет много полезных знаний, активностей и подарков от партнёров и организаторов конференции, а также нетворкинг и ещё раз нетворкинг. С нетерпением жду начала конференции, которую обязательно посещу.

​​RxJava: subscribeOn vs observeOn
#разработка

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

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

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

Что будет, если расположить в цепочке несколько операторов? Если с observeOn понятно, то что поток будет изменяться каждый раз, когда мы пишем его, то с subscribeOn не все так однозначно.

Распространенным мнением является то, что учитывается только первый оператор. Однако недавно мне попалась статья о том, что несколько операторов subscribeOn могут влиять на цепочку. Подробно и с примерами кода ее можно прочитать тут

На мой взгляд, использовать несколько операторов в одной цепочке — это чаще всего неочевидно и излишне. Но вопрос: «Что будет, если расположить подряд несколько операторов observeOn\ subscribeOn?» очень распространен в различных квестах, викторинах и на собеседованиях. Теперь вы точно знаете ответ на этот вопрос!

AppsConf

Продолжаю свой рассказ о предстоящих конференциях мобильных разработчиков. Сегодня я расскажу о конференции AppsConf. Она пройдет с 8 по 9 октября.

Я еще не посещал эту конференцию, однако после ознакомления со списком докладов и спикеров это желание возникло. 

Например, заинтересовал доклад «Автор, пиши меньше. Котлин для разработки в iOS и Android» Николая Иготти. Возможно, кто-то слышал о том, что общую бизнес-логику следует писать сразу на Android и iOS. При этом возникают вопросы. Какие инструменты использовать для правильной организации архитектуры? На каком языке писать общие компоненты? Не будет ли уменьшения в производительности? Автор будет делиться своим опытом написания под Kotlin Native, что позволит не дублировать общий код под каждую платформу.

Еще один доклад «Как ускорить интернет, или Оптимизация приложений в мобильных сетях» Александра Тоболя. Основная масса приложения на смартфонах использует Интернет. Большинство разработчиков считает, что Интернет постоянно высокоскоростной и безлимитный. Если приложение загружает небольшие объемы данных, то все работает быстро. Но если в приложении нужен стриминг видео или загрузка изображений в высоком разрешении, то на слабом Интернете все становится грустно. Автор расскажет, на примере приложения OKLive, про отмену и варианты загрузки данных в мобильном приложении.

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

Список докладов еще пополняется. Полный список докладчиков тут. Кстати, у конференции есть подкаст, который называется Run Loop.

​​Многомодульность
#разработка

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

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

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

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

Движение FIRE
#мысли #статьи #опрос

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

Есть разработчик, который работает в среднестатистической компании, но при это получает достаточно большие деньги для комфортного проживания. Но вместо комфортного жилья, дорогой одежды и вкусной еды, наш герой откладывает 80% своего ежемесячного дохода. Он снимает комнату в общежитии, ест одну и ту же еду каждый день и спит на надувном матрасе. Для чего же откладывать столько средств?

Цель такой экстримальной экономии — закончить работу к 30-35 годам. Накопленных средств хватит для того, чтобы жить на проценты. После этого можно посвятить жизнь тому, что хочешь. Такие люди считают, что работа — рабство для того, чтобы заработать деньги. И единственным способом выйти из него — накопить достаточно денег для жизни. Эта тенденция получила название FIRE (financial independence, retire early, финансовая независимость и ранняя пенсия).

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

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

А что вы думаете о FIRE?

A/B тестирование
#разработка

Если открыть Google Play, то мы найдем там миллионы различных приложений. Но очень маленький процент из них имеет большое количество пользователей, а также хорошее качество. Из-за большой конкуренции важно, чтобы пользователям нравилось приложение.

Но, например, как понять, какой дизайн больше нравится пользователям? Или не раздражает ли их новая функциональность? А что сделать, чтобы текущая функциональность была заметнее? Ответы на эти вопросы может дать A/B-тестирование.

Если упрощенно, то A/B-тест позволяет распространить разные версии одного и того же приложения и в реальном времени определить, какая из версий является «лидером». Лидер определяется по определенным параметрам, которые задаются при создании A\B-теста.

Распространенным инструментом для создания A/B-тестов является Firebase Remote Config. Сейчас он в стадии beta. Судя по моему опыту, не зря. Config иногда не приходит, а Activation event не срабатывает. Поэтому, будьте внимательны при его использовании, проверяйте каждый тест внимательно.

Хорошая статья о настройке и раздачи тестов тут.

Не так давно писал вам о конференции AppsConf.

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

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

Больше информации тут. Спешите купить билет по более низкой цене!

EditText и inputType
#разработка #статьи 

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

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

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