Flutter
#опрос

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

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

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

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

Пишите в комментариях или в личные сообщения.

Ну и небольшой опрос: что будет с Flutter?

Как увеличить скорость работы Android Studio?
#разработка

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

И вроде компьютеры становятся мощнее, а оптимизация операционной системы и Android Studio лучше, но при этом все равно скорость не увеличивается.

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

Еще одна рекомендация — отключение ненужных плагинов. Для этого нужно открыть File -> Settings -> Plugins и отключить в списке ненужные плагины.

Например, можно попробовать отключить следующие: Android APK Support, Android Games, Android NDK, App Links Assistant, Copyright, Coverage, CVS Integeration, Editor Config, Fabric for Android Studio, Firebase (App Indexing, Services, Testing), Github, Google (Cloud Tools Core, Cloud Tools for Android, Developer Samples, Login, Services), Markdown Support, Mercurial, integration, hg4idea, Settings repository, Subversion integration, Task management, Test recorder, TestNG-J, YAML

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

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

Приятно, что среди ответов на вопрос «Что слушаете и читаете?» в разделе Android присутствует и мой канал. Большое вам спасибо! 🥳

Git bisect
#разработка

Недавно, во время разработки, столкнулся с проблемой: проявился достаточно серьезный баг. Куда копать и как его решить — непонятно. В предыдущем релизном билде все хорошо и баг не проявляется.

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

И тут на помощь мне пришел инструмент, который я не использовал раньше. Называется он git bisect. Я нашел проблемный коммит за 4 шага и примерно 20 минут.

Чтобы его использовать необходимо:
1) Открыть консоль git и перейти в папку проекта.
2) Ввести git checkout <commit hash>, где вместо скобок записать коммит, в котором проявилась проблема.
3) Начать процесс поиска при помощи команды git bisect start.
4) Пометить этот коммит плохим при помощи команды git bisect bad.
5) Пометить коммит, где точно нет проблемы при помощи команды git bisect good <commit hash>.
6) Далее повторяете процесс. Каждый раз git будет переключать в нужный коммит между предыдущим хорошим и плохим коммитом при помощи бинарного поиска. Собираете проект и проверяете, проявляется ли проблема. Если да, то вводите git bisect bad, если же нет, то git bisect good.
7) После завершения поиска вводите git bisect reset, чтобы вернуть репозиторий в начальное состояние.

У вас получится найти проблемный коммит за log n шагов, где n — число коммитов между первыми помеченными коммитами.

Иногда на моем канале появляются анонсы интересных для разработчиков мероприятий. Недавно ко мне обратились с просьбой рассказать о предстоящем хакатоне,  PhotoHack: Visual Messaging.

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

Он будет 16-17 марта 2019 года в ВДНХ, павильон № 461 “Умный город”. Призовой фонд 500 000 рублей.

Участие бесплатное. Надо просто зарегистрироваться на сайте.

Прием заявок до 13 марта.

Сайт мероприятия: http://bit.ly/2IR2q3B

​​Еще немного про анимации
#разработка #статьи

Для многих разработчиков написание анимаций — это отдельная и непростая задача.

Мне нравится, что сейчас создание анимаций становится более простой задачей.

Если хочешь красивые статические анимации — можешь использовать Lottie. Если хочешь красивые переходы между View, в то время как пользователь взаимодействует с приложением, то есть новый MotionLayout, о котором я недавно писал.

Но немногие знают, что существуют так называемые Physics-based motion. В документации сказано, что где возможно необходимо использовать анимации, которые напоминают естесственное движение объектов. И действительно, если использовать эти анимации, то приложение становится более живым и привлекательным.

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

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

1) Using Dagger in a multi-module project — (8 минут)
Использование многомодульных приложений сегодня является не только хорошей, но и необходимой практикой, особенно в больших приложениях. Одним из самых сложных этапов является использование dependency injection. В статье автор делится опытом использования Dagger в многомодульных приложениях. Особенно полезно, если вы на пути перехода вашего монолита на многомодульность.

2) Android Instant Apps 101: what they are and how they work — (6 минут)
Небольшая статья про Android Instant Apps: это часть приложения, которая доступна пользователю без установки самого приложения на телефон. Я не часто вижу их при установке приложений из Google Play, но, возможно, он подходит для конкретно вашего случая.

3) My Most Used Android Studio Shortcuts — (7 минут)
Полезная статья-справка о горячих клавишах в Android Studio. Думаю, что каждый найдет себе несколько полезных сочетаний клавиш, которые в перспективе ускорят разработку.

​​Surf Android Standard
#разработка

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

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

Тут достаточно подробно собрана база знаний студии разработки Surf. Здорово, что помимо закрытого использования, этими знаниями может пользоваться любой разработчик. Найдется многое: работа с аналитикой, с кэшем, архитектура, views, списками, rx… Ну и отдельно — пункт про стандарты кода и качества. Вроде все это знают, но порой не все соблюдают.

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

​​Digital nomads
#статьи #комментарии

На неделе прочитал интересную статью про людей, которые называют себя Digital nomads. Я не знал, что есть такой термин: так называют себя люди, которые совмещают постоянную работу и путешествия.

Кто-то за удаленку, кто-то против. Сегодня это распространенная практика не только среди программистов, но и среди дизайнеров, редакторов, сотрудников call-центров. Например, для меня удаленная работа — отличный способ планировать свое время и путешествовать.

Но работать в путешествии не всегда просто. Даже если мы говорим про то, что у удаленно работающего сотрудника все хорошо с самодисциплиной, то есть факторы, которые не зависят от человека: скорость Интернета, погода, рабочее место, часовые пояса. Эти вещи крайне важны, и о них задумываешься больше вдали от своего дома и рабочего места. Например, судя по статье, у автора есть проблема с Интернетом в Риме, потому что очень сложно найти хороший Wi-Fi в общественном месте.

Свои ответы про удаленку я публиковал в этом посте.

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

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

​​Android Gradle и невидимые зависимости
#разработка #статьи

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

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

Тогда на помощь пришла команда gradlew app:dependencies, которая показывает дерево всех зависимостей в проекте. Понять формат этого дерева и найти «невидимую» зависимость помогла эта статья.

​​Как бы вы начали новый проект?
#комментарии

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

Например, сейчас существуют Android Architecture Components, где есть компоненты для организации приложения. Хотя раньше разработчики придумывали свои подходы для организации архитектуры, которые вполне хорошо работают и сегодня. В других областях такое же многообразие: есть альтернативы DI, писать через Conductor или Fragments, какую БД выбрать…

Хочется узнать: если бы сейчас вы начинали проект, то какую архитектуру, технологии и библиотеки использовали бы?

Уже пару месяцев думаю про новый проект и очень интересно ваше мнение.

​​Технический долг
#разработка

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

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

В одной статье встретил отличную аналогию понятия «технический долг» — игра тетрис. Думаю, все играли в эту игру и отлично ее представляют.

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

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

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

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

​​Немного статей с Medium
#статьи #medium

1) Breaking up the App-module Monolith — 10 минут
Большое количество докладов в сообществе связано с разбиением монолитного приложения на модули. В этом есть много преимуществ, но нет универсального решения того, как это делать. Остается только читать опыт тех, кто уже это сделал и брать некоторые приемы для своего приложения. В статье автор делится своим опытом разделения монолитного приложения на многомодульное.

2) How to make Google’s Work Manager work for you — 7 минут
Работа в фоновом режиме — это актуальная задача для большинства приложений. Некоторые инструменты, которые используются для работы в фоне, показывают себя не с самой лучшей стороны. Но современный Work Manager работает на удивление хорошо. По крайней мере, в своем приложении я не наблюдал с ним проблем. Автор сравнивает некоторые инструмены для работы в фоне и приводит аргументы для работы с WorkManager. Используйте его, работает отлично.

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

22 и 23 апреля в Москве пройдет конференция AppsConf, что меня очень радует как Android-разработчика.

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

И как обычно, цена билета увеличивается ближе к началу конференции, поэтому торопитесь с покупкой! До встречи на конференции!

​​Android Tools Attributes 
#разработка #статьи

Вероятно, большинство использовали или видели атрибуты, которые начинаются с префикса tools:.

Самый распространенный пример — это tools:text, когда нужно добавить в сверстанную TextView текст, чтобы посмотреть ее внешний вид, но не отображать этот текст в приложении. Кто-то использует tools: не только для текста: можно заменить им любой атрибут android:, и в верстке будет видно именно то, что применено при помощи tools:.

Однако, возможности этого инструмента гораздо шире. Например, можно заполнить RecyclerView холдерами из вашей верстки и заполнить их или реальными данными, или же предустановленными данными в Android Studio. Возможностей много, и они не оказывают негативного влияния на производительность и время сборки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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