Android-разработчики могут знать Давида Гонсалеса в связи с несколькими разными вещами. Например, он участвует в open source-проекте Android Architecture Blueprints, где разные архитектурные подходы демонстрируются на конкретных примерах (недавно проект преодолел рубеж в 25 000 GitHub-звёзд). А также выступает с докладами, занимается бельгийской Kotlin User Group, ранее активно писал блог-посты — в общем, помогает сообществу многими способами, и звание Google Developer Expert неудивительно.

Так что в интервью мы тоже расспросили Давида сразу о нескольких темах: начали с Android Architecture Blueprints, перешли к Kotlin, а закончили аутентификацией в Android, которой посвящён его новый доклад.

— Главные подробности об Android Architecture Blueprints можно узнать из вашего доклада 2016 года. А что изменилось в проекте со времён того доклада?

— Проект разросся, теперь в нём больше образцов разных подходов. На тот момент образцы RxJava и Dagger ещё не дошли до stable-состояния, а на Kotlin вообще не было ни единой версии.

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

Помимо основного проекта, существуют ещё «внешние» примеры архитектур, и я поучаствовал в таком: помог Бенуа Квенадону с его примером MVI-RxJava-Kotlin.

— Приходится ли слышать «Ну, в Blueprints вылизанные образцы архитектур выглядят хорошо, но я попробовал сделать так же в реальном проекте, и всё тут же развалилось»?

— Вы правы, приходится. Но Blueprints — это просто примеры реализации архитектуры, а не «единственный верный способ реализовать её, вы обязаны копипастить всё отсюда». Это скорее гайдлайн, чем Библия.

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

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

— Куратором Android Architecture Blueprints выступает Google. Не бывает ли так, что там отвергают что-то полезное, потому что это расходится с интересами компании?

— Нет, совершенно. Например, есть образец для RxJava, хотя Google внутри может такое и не использовать. Вот в чём помогает сила сообщества: мы можем взять и сами сделать. Это опенсорсный проект, так что можно возглавить его составляющие. Другая ситуация с Dagger: это продукт Google, используемый внутри компании, так что в примере его реализации участвует больше гуглеров. Но они не указывают нам, что делать или не делать, подход полностью опенсорсный.

— Часто ли у участников расходятся мнения по поводу имплементации конкретной архитектуры? Бывают ли такие расхождения, когда непонятно, что включать в проект?

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

— Android Architecture Blueprints отличается от большинства проектов: разбит на несколько ветвей-примеров, каждая из которых может достигнуть «готовой» стадии. Означает ли это, что работа над проектом идёт «волнами» по мере появления новых ветвей?

— Ну, хотя по сути там всегда одно и то же to do-приложение, иногда в каком-то примере могут появиться новые фичи, а тогда их надо реализовать и во всех остальных ветвях тоже. К тому же сейчас Хосе разбирается, какое ещё приложение можно реализовать с помощью blueprints.

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



— В фидбэке, который вы видите, спрос на Kotlin-примеры в Android Architecture Blueprints уже стал выше, чем на Java-примеры?

— Думаю, да. Уже на следующей неделе после объявления о поддержке Kotlin на Google I/O куча людей писала «Привет, а когда мы сможем это получить?» А затем люди начали контрибьютить: «Я думаю, надо вот так, что скажете?» Несколько сотрудников Google тоже помогали с Kotlin-примерами, это было очень полезно, эти ребята знают, как надо.

— А есть ли ощущение, что Kotlin скоро станет однозначным лидером Android-разработки, или консервативные компании с легаси-кодом означают, что большинство в любом случае долго будет на Java? Это, конечно, спекулятивный вопрос, но вам как организатору Kotlin User Group должны быть видны тенденции.

— Ну… В мире до сих пор существуют компании, у которых COBOL в продакшне. И до сих пор нужны люди, пишущие на COBOL, чтобы поддерживать это. Но таким системам лет 20. Не знаю, будет ли кто-то использовать мобильное приложение 20-летней давности. И похоже, что мобильные разработчики любят рефакторить всё гораздо чаще, можно увидеть, как приложения переписывают каждые 2-3 года. Так что время жизни кода тут куда меньше по сравнению со старым энтерпрайзным. И если через три года появится новый язык, тут же пойдут новые блог-посты и доклады о миграции с Kotlin на этот новый язык.

— Поскольку вы жили в Лондоне, а теперь организуете Kotlin User Group в Бельгии, интересно сравнить: как в бельгийском Android-сообществе обстоят дела с Kotlin и не только, в чём отличие от Лондона?

— Разница ощущается. В Лондоне очень много разработчиков, постоянно проходят митапы. Бельгия другая страна, тут в этом отношении всё гораздо медленнее. Даже количество людей, приходящих на мероприятия: оно постепенно растёт, но очень отличается. И убедить бельгийские компании перейти на Kotlin — куда более медленный процесс по сравнению с Лондоном.

Но разработчики воодушевлены Kotlin, с ним увлекательно работать, а все хотят увлекательной работы. Когда проводишь на работе 8-10 часов каждый день, он этого хочешь получать удовольствие, и думаю, что Kotlin привнёс эту струю свежего воздуха, позволяющую снова увлечься Android-разработкой или даже бэкендом. Думаю, сейчас для разработки отличное время.

— Рассказывая в докладе о работе над приложением Help Scout, вы упоминали, как создавали его с нуля: «Стоит ли написать на Kotlin? А что, если я уйду из компании через полгода, и им займётся кто-то другой? Java надёжнее». Тогда это звучало очень разумно, а теперь ситуация изменилась. Что в итоге, переписываете теперь всё это на Kotlin? :)

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

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

Ещё мы сейчас работаем над новым проектом, он написан на Kotlin с самого начала.

— Вы обращали внимание на появление библиотеки ?RROW, предназначенной для того, чтобы писать на Kotlin «функциональнее» — а как по-вашему, на такое есть спрос?

— Думаю, да. Её создатели проделали отличную работу. Во-первых, они объединили две существовавших ранее библиотеки в одну. А во-вторых, уделили очень много времени и усилий документации, сайту и примерам. В итоге это привлекает людей.

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

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

— Вы уже давно в Android-разработке, вашим первым устройством был HTC Magic. По-вашему, в чём главные отличия разработки «тогда» и «сейчас»?

— Я бы сказал, что когда начинал заниматься этим, толком негде было искать примеры. Было только 3-5 блогов об Android-разработке. Сегодня есть прорва блогов, курсов и примеров. У любого встречного код на GitHub, можно почитать и поучиться. Можно прочитать книгу, пройти онлайн-курс или курс с личным посещением, конференции по всему миру проходят почти каждую неделю. Постоянно что-то происходит. Сейчас определённо легче влиться в Android-разработку из-за обилия доступной информации.

И ещё устройства очень изменились. Тогда мы и помыслить не могли о современных многоядерных смартфонах с несколькими гигабайтами оперативки. Теперь не так много времени уделяют тщательной подстройке своего приложения, потому что на Pixel 2 никогда не столкнёшься с нехваткой памяти — ну, если только не происходит что-то совсем-совсем неправильное.

— Сегодня Android-разработчики нередко говорят «жду, когда наконец смогу дропнуть такую-то версию API». А тогда смена версий была ещё важнее и болезненнее?

— Тогда не было developer previews, как сейчас, когда за месяцы до релиза новой версии уже можно тестировать приложение с новым SDK.

А когда вышел Honeycomb 3.0, это вообще поменяло всё. Появились фрагменты. Что нам делать с ними? Зачем они нам? API менялись куда радикальнее, чем сейчас.



— Хочется задать несколько вопросов об аутентификации. На Хабрахабре не так давно писали, что многие используют Account Manager не из-за него самого, а из-за Sync Adapter. Вы видите ту же картину? По-вашему, нет ли в этом проблемы?

— Да, ту же, это всё из-за того, как устроен фреймворк. Для Sync Adapter нужен Google-аккаунт. А этот аккаунт виден в фреймворке только через Account Manager.

Это печально, потому что это не имеет никакого отношения к аутентификации, это о потребности в Sync Adapter самом по себе. И поэтому многие люди перестали его использовать: нужна куча boilerplate-кода только для синхронизации данных, и это мешает.

Но, к счастью, сейчас существуют и другие варианты для синхронизации данных между устройством и сервером, не требующие Account Manager. Есть Android Priority Job Queue от гуглера, есть Android-Job от Evernote.

— В том же хабрапосте Account Manager хвалили также за общую авторизацию для нескольких приложений. Но хвалил сотрудник «Яндекса», где приложений целая куча, а это всё-таки нетипичная ситуация. Раз у Sync Adapter есть достойные альтернативы, а среднестатистический разработчик работает не в компании-гиганте, то насколько Account Manager для такого разработчика актуален?

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

Но даже если у вас всего одно приложение, Account Manager всё равно может приносить пользу. Главное, что тогда от него получаешь — безопасное хранение пользовательской информации. Эту тему я как раз подробнее разовью в докладе на Mobius.

— Вспоминая о том, что вы давно в Android-разработке: а насколько аутентификация менялась со временем?

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

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

А аутентификация с помощью Firebase развилась и стала популярнее. Несколько лет назад, если вы хотели использовать в приложении Facebook или Twitter в качестве способа залогиниться, необходимо было использовать их SDK. А теперь можно положиться на Firebase, и это облегчает жизнь, убирая зависимости от Facebook и Twitter. Это очень привлекательно для многих разработчиков.

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

— Но при всём этом развитии вы не считаете никакой способ «лучшим», всё зависит от конкретного сценария?

— Да, метод аутентификации очень зависит от компании и её размера. Если вы маленькая компания, уже использующая сервисы вроде Firebase, которые позволяют заодно ещё и с аутентификацией разобраться, это очень упростит вам жизнь.

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

— Раз одного лучшего способа нет и необходимо сравнивать, возможно, было бы полезно по аналогии с Android Architecture Blueprints создать Android Authentication Blueprints? :)

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

Минутка рекламы: мы и организуем в Петербурге конференцию Mobius, на которой будет доклад Давида «Android Authentication made simple», а также много другого. Посмотреть все уже известные подробности и приобрести билет можно на сайте конференции.