​​Ошибка выжившего
#думы

Уверен, что вам часто попадались статьи из разряда  «Топ 10 привычек успешных людей» или  «15 вещей, которые состоявшиеся люди делают до завтрака». Подобные статьи очень популярны во всевозможных пабликах. В них даются советы, делая которые можно прийти к успеху. Говорят, что эти советы основаны на жизни людей, которые достигли определенных высот в жизни. Логично, что делая так же, можно прийти к тому же результату. Или нет?

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

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

Любому человеку важно стремиться к успеху. Думаю, что секрет успеха не в следовании советам, а в постоянном труде и решимости. В мире разработки это особенно актуально. Профессия программиста требует постоянного обучения и развития. Те знания, которые разработчики получили пару лет назад могут быть не актуальными сегодня. И я точно знаю, что находясь в таком состоянии вы будете успешным разработчиком, даже если вы пьете кофе или не делаете утром зарядку.

​​Удаление неиспользуемых языков
#разработка #советы

Сегодня расскажу один способ уменьшения размера apk-файла.

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

Это происходит потому, что некоторые библиотеки и компоненты переведены на много языков. Мало кому нужны все языки сразу, поэтому их нужно удалять из приложения при помощи: resConfigs "auto". Его необходимо добавить в defaultConfig.

Чуть больше информации об этом вы можете почитать тут.

Сегодня моё рабочее утро началось со статьи с кучей советов для Android-разработчиков. Автор потрудился и собрал вместе много полезных техник. Уверен, что даже опытные разработчики найдут здесь для себя новое. Тут собраны:

• #советы по Android Studio, среди которых горячие клавиши, плагины, templates, советы по шрифтам;
• выбор эмуляторов;
• советы при написании кода;
• консольные команды;
• целый пласт лучших библиотек.

Я изучил ещё не весь документ, но уже взял несколько интересных вещей, например:
1) Постфиксное завершение кода. Например можно написать <expr>.null вместо if(<expr> == null).
2) Команда для обновления всех зависимостей это ./gradlew --refresh-dependencies.
3) Узнал, почему нельзя использовать @android:color/transparent в градиентах.
4) Нашёл библиотеку, которая позволяет создавать скриншоты прямо из приложения. Хочу попробовать.
5) Узнал про атрибут tools:parentTag, когда используешь <merge> в верстке.

Добавил в закладки и буду ещё не раз обращаться к этому репозиторию.

Арабская локализация. Особые знаки процентов
#разработка

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

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

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

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

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

​​Техника Pomodoro
#планирование

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

Стандартный «помидор» — это 25 минут, но время можно подкорректировать под себя. После завершения этого промежутка необходимо сделать перерыв. Обычно это 5 минут. После 4 «помидоров» надо сделать большой перерыв — 20 минут.

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

Я решил испробовать эту технику. Для этого воспользовался плагином для Google Chrome, который сообщает о завершении «помидор», перерыва, а также ведет статистику эффективности.

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

А вы пробовали использовать эту технику?

​​Давно у нас не было топа статей из 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 достойный язык для того, чтобы попробовать его и немного изучить.

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

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

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

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

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

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

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

​​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. День 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@Entity — аннотация, которая говорит о необходимости создания таблицы для данного класса. При этом, нужно указать @PrimaryKey, а также при желании имя таблицы, имена колонок и те поля, которые не нужно добавлять в базу. 

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

3) @Database@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;