Android Live 🤖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте 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).

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

​​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.

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

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

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

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

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

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

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

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

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

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

​​Mobius 2018 Piter. День 1

Итак, доклады первого дня конференции подошли к концу. Я посетил 5 докладов:

1) Профайлинг в примерах. Ищем бутылочное горлышко. Артур Бадретдинов.
Автор рассказывал о инструментах, которые помогают в обнаружении косяков во View. Это интересный доклад, из которого узнал про правило 16 миллисекунд, Vsync, ViewStub. Интересны встроенные инструменты для обнаружения медленной отрисовки объектов, о которых я расскажу позже, потому что это тема для отдельного поста. Доклад понравился, и я уверен, что инструменты помогут сделать приложения плавнее.

2) Мультиплатформенная архитектура на Kotlin для iOS и Android.
Авторы рассказывали об эксперименте, где они вынесли общую логику в отдельный модуль на Kotlin, который позволил им переиспользовать его на двух платформах. Как мне показалось, это был эксперимент, и такой подход не стоит использовать в проде.

3) Сервисы: нельзя без них, а как с ними жить? Йонатан Левин.
Еще один отличный доклад, где Йонатан делился опытом работы с сервисами. В последних версиях Android работа с сервисами претерпела много изменений. Понравилось то, что автор не давал сценариев решений проблемы, а заставил задуматься над проблемой и предложил подход для решения. 

4) Рождение, жизнь и смерть, или Что происходит с приложением в системе. Антон Дудаков.
Доклад связан с системой Android. Автор рассказал, что происходит с системой при ее старте, к чему идет обращение при создании новых процессов, как выдаются права и как может уничтожиться приложение. Особенно в этом докладе понравились вопросы, которые задавали слушатели. 

5) На плечах гигантов: языки, у которых учился Kotlin. Андрей Бреслав.
Автор — один из создателей языка Kotlin, рассказывал о том, какими языками они вдохновлялись при создании Kotlin. Подумал о том, насколько круто было бы видеть такого преподавателя в универе. 

Конференция мне дико нравится. Уверен, что завтра услышу еще много нового.

Друзья, уже завтра будет конференция мобильных разработчиков Mobius 2018 Piter.

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

AdaptiveIconPlayground
#дизайн #приложение

В Android O был анонсирован новый тип иконок — адаптипные.

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

Если у вас установлена Android Studio 3.0 и выше, то при создании новой иконки вы можете сделать также и адаптивные.
При этом, возникает вопрос: как узнать, как будет выглядеть иконка в округлой или квадратной форме? Как она будет смотреться вместе с остальными иконками, а также как она будет выглядеть при скролле?

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

​​Давно у нас не было топа статей из Medium
#статьи #medium

1) Mastering the World of Android Testing. — (8 минут)
Тестирование приложений — это то, чем часто пренебрегают даже опытные разработчики. Иногда не по их вине, а по вине руководителей. Большинство хочет видеть новые фичи, а покрытие тестами считают лишней тратой времени, и не оставляют на это часть времени при разработке. Со временем приложение, которое не покрывается тестами может приносить сюрпризы: отваливается уже готовая функциональность, появляются краши.
Автор в статье делится тезисами, которые относятся к тестированию Android-приложений. А тут вторая часть.

2) Why Flutter Will Change Mobile Development for the Best. — (11 минут)
На канале уже много раз упоминал язык Flutter. Мне попадались статьи, которые говорят, что язык очень сырой и его еще долго нельзя использовать. Другие говорят, что это тот язык, на котором уже можно писать простые приложения, и которые успешно себя чувствуют в проде.
Автор рассуждает о Flutter, сравнивает нативно написанное приложение под Android и кроссплатформенное на Flutter. В любом случае, Flutter достойный язык для того, чтобы попробовать его и немного изучить.