​​​​Mobius 2018 Piter. День 2

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

1) Многомодульная архитектура проекта Евгений Суворов. Автор делился опытом переделки архитектуры проекта в множество модулей. Во-первых, благодаря этой переделке, проект стал быстрее собираться. Во-вторых, это позволяет работать над одним проектом большому количеству команд. Думаю, что для больших команд подобная архитектура — единственная возможность работы. Жаль, что для реализации подобного подхода в маленьких командах понадобится очень много времени. Но тогда возникает вопрос: а нужно ли это в маленькой команде? 

2) Как не состариться во время сборки: Kapt и другие приключения. Денис Неклюдов. Доклад был связан с оптимизациями, которые позволяют собирать приложение в несколько раз быстрее благодаря распараллериванию и модульности. Думаю, это то, что обязательно стоит применить к проекту. Автор дал крутую информацию, очень понравилось.

3) Введение в AOSP, или Как потратить ночь на сборку Android. Виктор Лапин. Автор много лет занимается созданием прошивок для Android-систем. Рассказал, из чего состоит загрузка Android, и как создать свою прошивку. Немного захотелось попробовать сделать ее самостоятельно. 

4) Релизы мобильных приложений в Avito. Алексей Шпирко. Автор делился опытом создания релизов в команде мобильного приложения Avito. Думаю, что доклад опять же больше актуален для больших команд. Но тем не менее, было интересно послушать о приложении, в котором 10 000 тестов и регрессионное тестирование проходит за один день. Впечатляет.

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

При закрытии конференции был батл между Android и iOS. Неожиданно было увидеть Йонатана Левина в костюме единорога. 

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

​​D8 dexer
#разработка

В последней версии Android Studio добавлен новый dex-компилятор, который называется D8.

Dex-компиляция — это процесс преобразования байткода из .class в байткод .dex для Android Runtime (ART) или для Dalvik (старые версии Android).

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

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

• уменьшение размера выходного apk;
• уменьшение времени сборки проекта (с огромными проектами этот параметр крайне важный).

Чтобы попробовать новый компилятор, обновитесь до Android Studio 3.1.0, и пропишите свойство в gradle.properties : android.enableD8.desugaring = true.

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

Используйте Stream API с умом
#разработка

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

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

На днях прочитал статью, где автор делится примерами некорректного использования Stream API. Например:
• вместо collection.stream().forEach() , которая делает какую-то операцию для каждого элемента, лучше использовать collection.forEach();
• вместо stream.filter(condition).findFirst().isPresent() удобнее и короче использовать stream.anyMatch(condition);
• заменить stream.sorted(comparator).findFirst() нужно на stream.min(comparator).

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

​​Сегодня утром решил почитать статьи, связанные с Git.
Если вы новичок, то рекомендую почитать статью, которая рассказывает о том, как работает #git и на примерах объясняются базовые команды.

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

1) В работе иногда сталкиваюсь с тем, что после совершения коммита понимаю, что добавил в него не все нужные мне файлы. Для добавления создаётся новый коммит, в котором указывается сообщение "Add to previous commit". На практике это выглядит не очень красиво, ведь данный коммит не несет никакой пользы. Лучше не создавать новый коммит, а добавить файлы в последний при помощи команды git commit --amend.

2) В некоторых компаниях руководство требует отправлять отчеты о проделанной работе за неделю. Для быстрого составления отчета можно воспользоваться командой git log --author="author_name" --after="1 week ago" --oneline.

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

Попалась история создания стартапа Kidkin.

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

Читая историю понял несколько вещей:
1) Важно хотеть создать крутой продукт. Думаю, что первоначальным желанием должно быть именно создание продукта, а не получение прибыли.

2) Для продукта важна команда. В одиночку никто, даже самый умный и вдохновленный идеей человек, ничего не сможет сделать.

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

А как вы думаете, где интереснее работать, в компании или стартапе?
🔴 — стартап;
🔵 — компания.

Эффект последней строки
#статьи

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

Автор статьи исследует исходных код open source приложений на предмет в них ошибок при помощи статических анализаторов. В результате выяснился такой феномен как эффект последней строки.

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

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

private void addVector(Vector vector) {
x = vector.x;
y = vector.y;
z = vector.y;
}

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

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

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

(Не)Безопасность 101
#разработка

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

Если вкратце, то: всё, что есть у вас в apk файле реально достать. Будь это JNI код или нативный. Вопрос заключается только во времени и цене того, что получит «исследующий» приложение.

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

Новая навигация от Google
#разработка

Уверен, что все Android-разработчики пристально следили за конференцией Google IO. На ней Google представила много интересных вещей.

Для разработчиков представлен Jetpack, который содержит набор средств для создания приложений.

Одним из компонентов является The Navigation Architecture Component, упрощающий навигацию в приложениях. Я попробовал это решение, и мне оно показалось достаточно удобным. Конечно, пока его нельзя встраивать в реальные проекты, потому что версия alpha, но то, что мы получили достойный инструмент — очень радует.

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

В личку пришел вопрос о просьбе провести #опрос: какой операционной системой вы пользуетесь?

Например, я долгое время пользовался только компьютерами с Windows. Давно это было Windows 7, потом на смену пришла 8, и даже сейчас в офисе стоит достаточно мощный компьютер с Windows 10, на котором и пишу код. Как по мне, «восьмерка» и «десятка» — прекрасные операционные системы.

Дома у меня Macbook Pro 17 года, который появился где-то полгода назад. Я не делал замеры, но по ощущениям сборка одного и того же проекта на нем быстрее (примерно на 15-20%). Возможно, дело в железе. Что касается самой операционки MacOS, то к ней быстро привыкаешь. А в совокупности с отличным экраном Macbook, работать шикарно. Из недостатков операционной системы могу отметить иные горячие клавиши. Нужно или переопределять, или ставить другую схему, но полной совместимости все равно нет.

Когда-то давно был опыт работы на Ubuntu, но отсеял этот вариант, потому что мой прошлый ноутбук быстро разряжался из-за дискретной карты, на которую было сложно поставить драйвера. Хотя знаю людей, которые пользуются Linux для разработки под Android.

Какой же ваш выбор?
🔴 — Windows;
🔵 — MacOS;
⚫️ — Linux.

​​Room
#разработка #библиотека 

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

Вся работа с библиотекой осуществляется при помощи 3 аннотаций:

1) @Entity — аннотация, которая говорит о необходимости создания таблицы для данного класса. При этом, нужно указать @PrimaryKey, а также при желании имя таблицы, имена колонок и те поля, которые не нужно добавлять в базу. 

2) @Dao — аннотация для интерфейса, в которой описываются все методы для доступа к БД. Для методов этого интерфейса нужно указывать типы запросов, а также при желании можно написать свой запрос с помощью @Query. 

3) @Database — аннотация для абстрактного класса, где необходимо проинициализировать БД. 

Этих 3 сущностей достаточно для начала работы с базой. 

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

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

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

Package by layers vs Package by features
#разработка #опрос 

При создании проекта, существует два основных подхода для организации кода. 

Первый подход называется Package by layers. Его смысл в том, что вы раскладываете классы по папкам, которые разбиты по слоям: например, модели содержатся в папке models; работа с интерфейсом, и view содержатся в папке ui. Далее внутри каждой папки создается каталог с названием фичи. Пример можно посмотреть тут

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

Минус в том, что при разработке проекта нужно создавать огромное количество одинаковых подкаталогов, и следить за тем, чтобы их названия совпадали для удобства и читаемости. Для ускорения этого процесса стоит создать template в Android Studio.

Второй подход Package by features говорит о том, что необходимо раскладывать классы для каждой из фич в отдельную папку. Например, каталог login будет содержать все необходимое для модуля авторизации: views, api, di. 

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

А какой из подходов используете вы?
🔴 — Package by layers;
🔵 — Package by features;

​​Гамбургерное меню
#дизайн

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

Исследование говорит, что пользователи сайтов использовали скрытое меню только в 27% случаев, а видимую часть в 50%. На мобильных устройствах эта цифра составляет 57% для скрытого меню и 87% для видимого.

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

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

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

Из всего этого можно сделать один вывод: по возможности нужно использовать видимое меню. Если приложение состоит из 5 разделов, то смысл скрытого меню теряется, а о некоторых функциях пользователь может догадаться не сразу.

Dagger 2
#разработка #статьи

Мне кажется, что про библиотеку Dagger 2 слышал каждый Android-разработчик. Тема заезжанная, есть много статей для быстрого старта, но мне хочется собрать их вместе и помочь начинающим разработчикам в изучении этой библиотеки, чтобы они могли стать чуть лучше в программировании.

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

В одной из статей прочел пример из реальной жизни, который примерно описывает то, что делает Dagger.

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

Примерно по такому же принципу и работает паттерн Dependency Injection. Dagger выполняет роль помощника, а наше приложение — хирург, который делает операцию.

Второй цикл статей, который помог мне в освоении этой библиотеки можно найти тут.

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

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

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

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

​​Fill RAM
#разработка #приложение

Давненько не писал для вас ничего интересного. Сегодня постараюсь исправить это недоразумение и не пропадать надолго.

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

Для того, чтобы это сделать можно попытаться открывать одновременно большое количество приложений, которые в итоге действительно займут большую часть оперативной памяти. Но ведь текущие смартфоны порой имеют и 4, и 6, а то и 8 гигабайт оперативной памяти. Такой объем заполнить не так просто и придется захламить кучей приложений телефон.

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

Android Sunflower
#разработка 

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

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

• Android KTX — позволяет писать лаконичный и краткий код на Kotlin;
• Navigation — инструмент для создания навигации внутри приложения;
• Room — база данных, обёртка над SQLite (упоминал, кстати, о ней);
• WorkManager — работа с фоновыми операциями в Android.

Помимо этих, в проекте использовано куча других инструментов из Jetpack. Рекомендую для ознакомления и изучения.

​​ButterKnife или Data binding?
#разработка #библиотеки

Сегодня на работе спорили о том, что лучше использовать: ButterKnife или Data binding?

Помню, что когда ещё не было ButterKnife, то приходилось писать findViewById, после чего кастовать найденную View к нужной. Было слишком много лишнего кода. Например, если в вашей Activity есть 10 View, то для использования их нужно было писать 20 строк кода с findViewById. С появлением в проектах ButterKnife число строк сократилось вдвое, и теперь нужно было просто написать @BindView(R.id.textView) TextView text.

Не так давно появился Data Binding. Для использования нужно немного модифицировать xml-файл разметки и написать в Activity ActivityMainBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_main);, после чего у вас появляется доступ к вашему layout напрямую: binding.textView. Количество View не играет никакой роли при использовании Data Binding. Ведь строк кода всегда остается только 2!

Какие плюсы у ButterKnife? Например, есть другие аннотации, которые упрощают работу, например: @OnClick, @OnItemSelected, @BindColor. Также можно примененить аннотации на несколько View.

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

С появлением Kotlin появились kotlin-android-extensions, которые ещё больше упростили базовую работу с View.

Так уж повелось, то в Java-проектах я использую ButterKnife, а в новых, написанных на Kotlin проектах — Kotlin Extensions. С Binding сталкивался на ранних этапах его появления, но уверен, что это отличный инструмент.

А что больше нравится вам?
🔴 — ButterKnife;
🔵 — Data Binding;
⚫️ — Kotlin Extensions.

Скорость сборки проекта
#разработка

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

И вот, когда время сборки проекта стало приближаться к 5 минутам, то решил найти варианты решения этой проблемы.

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

Думаю, что проблемы долгой сборки у большинства крупных проектов одинаковые:
• Annotation processing;
• переплетенность модулей между собой;
• Data binding и Dagger в каждом модуле;
• огромный модуль и Application модуль.

Первые шаги, которые помогут уменьшить время сборки проекта:
1) Использование implementation вместо api в gradle.
2) Ядро приложения должно быть максимально тонким. Сюда лучше всего добавлять только интерфейсы, а все реализации описываются в конкретной фиче.
3) Код приложения нельзя шарить между модулями.
4) Модули не должны взаимодействать друг с другом.

Также стоит помнить про инструмент gradlew clean assembleDebug --scan. Он покажет интерактивную диаграмму с этапами сборки проект.

Чтобы лучше разобраться с модульностью рекомендую ознакомиться с проектом.

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

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

В Android можно очень просто создать повторяющийся фон:
1) Вырежьте небольшой кусок того фрагмента, который будет повторяться
2) Добавьте новый drawable, где создайте <bitmap>, указав src и android:tileMode="repeat"

Подробнее можно прочитать тут

​​Найм
#мысли 

Около недели назад послушал свежий выпуск подкаста Про найм. А тут вторая часть. Я, например, нашёл там несколько интересных пунктов:

1) Не стоит указывать среди первых своих навыков кроссплатформенные фреймворки, типа Xamarin. Если собеседуетесь на вакансию Android разработчика, то лучше сосредоточиться на его навыках и используемых библиотеках. Из своего опыта собеседований могу сказать, что о таком человеке складывается мнение, что он не знаком ни с чем, а попробовал все на уровне тестовых и документации. Если же вы чувствуете свою мощь, то составьте несколько резюме для каждой из вакансий.

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

3) Прокачивайте теоретическую и алгоритмическую базу. Поэтому заходите на HackerRank, чтобы решить пару задач.

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

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

RxJava: flatMap, switchMap и concatMap
#разработка 

Это достаточно распространные операторы, и между ними есть существенная разница, о которой стоит помнить. В качестве примера для списка элементов "a", "b", "c", "d", "e", "f" применяется фукнция конкатенации x. Вот краткое объяснение:

• flatMap — применяет функцию к каждому элементу, соединяет элементы вместе и после чего возвращает Observable. Следует помнить, что элементы могут чередоваться, поэтому функция не заботится о порядке возвращения. В примере увидим cx, ex, fx, bx, dx, ax. 

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

• concatMap — в отличии от flatMap, заботится о порядке элементов. При этом ему необходимо дождаться, пока каждый из элементов завершит свою работу перед получением нового. Поэтому, этот оператор нужно использовать осторожно. В примере увидим ax, bx, cx, dx, ex, fx. 

Больше объяснений и примеров использования операторов тут.