Flutter не нужен, нужен натив!

Название кликбейтное, привлекает внимание, но не совсем правдивое. Flutter, конечно же, нужен.

Привет! Меня зовут Егор Федяев, я мобильный разработчик финтеха в Яндекс Про. В статье расскажу, почему важен и Flutter, и натив, а также поделюсь примерами, как мы используем натив в кроссплатформенном приложении Яндекс Про.

Почему нужен и Flutter, и натив

Начну с того, зачем нужен Flutter и в чем его преимущества для нас в Про.

• Flutter как технология активно развивается, популярность фреймворка растет.
• Разработка на Flutter чаще всего идет быстрее. Можно посчитать, сработает ли это для вашего проекта: подробно о формуле для расчет времени рассказал Сергей Кольцов на Яндекс Go Mobile Day&Night.
• Flutter объединяет две мобильных платформы и дает возможность писать под десктоп и веб на единой кодовой базе. Загвоздка только в том, что база не такая уж единая.

Мы провели исследование кодовой базы в Про, и оказалось, что 80% проекта действительно написана на Dart, то есть это база кода используется на двух платформах. Целых 80% неплохо, да?

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

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

Поэтому мы используем его в нескольких случаях:

1. Работа с аппаратными функциями: Bluetooth, GPS, гироскопом, камерой и другими. Flutter — в первую очередь UI-фреймворк, который не умеет работать с аппаратными функциями напрямую. Для таких задач у нас есть нативный код и разработчики на Android и iOS, которые делают обработчики для аппаратных функций.
2. Код уже написан на нативе: дешевле сделать плагин, чем переписывать на Flutter. Бывает уже написанный код, который не хочется просто брать и выбрасывать. И если есть нативная SDK, то гораздо лучше взять и обернуть её во Flutter-плагин. Таких кейсов у нас достаточно много, потому что Яндекс делает много внутренних и внешний проектов, в первую очередь, на нативе.

У нас есть несколько нативных плагинов, с которыми активно работаем:

• Карты и геолокация — база Яндекс Про. Если вы сидите на заднем сиденье такси и смотрите на экран таксиста, то первое, что вы видите — карта, основанная на SDK Яндекс Карт.
• Подключение к постаматам и датчикам. Этот кейс связан с работой курьеров. Например, курьеры Яндекс Маркета используют постаматы, к которым подключаются по Bluetooth.
• Обработка жестов, камеры, считыватели QR-кодов, видео- и аудиопроигрыватели, а также нативные SDK.

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

Кейс: Яндекс Банк для водителей

Яндекс Банк — привычный всем банк, только не в отдельном мобильном приложении, а в Яндекс Про. В нём есть много плюсов: моментальные выплаты, бонусы, кешбэк. Самое удобное — сервис встроен в приложение, не нужно скачивать и авторизовываться отдельно.

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

Банк выглядит так: экран дашборда, экран кешбэка и экран пластиковой карты. Особенность сервиса в том, что в нём только один экран с дашбордом, написанным на Flutter, всё остальное — это BankSDK, который мы открываем, используя уже готовые решения.

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

Работает всё достаточно просто: есть банк-фича, в в нее интегрируется банковский плагин, который является просто оберткой для BankSDK iOS и BankSDK на Android.

Что мы берем из нативного SDK?

• Показываем готовые сценарии из нескольких экранов. Через SDK создаем UI-сценарий — один или несколько экранов, которые мы можем показывать из нашего Flutter-приложения. Например, экран кешбэка, экран пластиковой карты.
• Обрабатываем часть бизнес-логики. Всё, что происходит при нажатии на кнопки Получить или Кешбэк за сентябрь, открывается нативом.
• Открываем диплинки.
• Получаем пуши с помощью EventChannel.

Расскажу подробнее о сложности и процессе создания и масштабирования таких фичей:

1. Сценарии и диплинки — первый уровень сложности. Для разработки пишем плагин-wrapper для BankSDK — в этой задаче вам не нужны особые знания натива. Нужно базово пройтись по синтаксису Swift или Kotlin и понять, как открывать экраны. Далее либо берем на стороне Dart MethodChannel и добавляем методы открытия экранов и обработку диплинков, либо на стороне натива создаем экран с помощью фабрики и открываем его.
2. Возможность скрыть информацию (не только SDK) — второй уровень сложности. Мы используем другие функциональности девайса, в том числе гироскоп. В этом случае нужно уметь разбираться в API гироскопа и понимать, как работает CMMotionManager на iOS и SensorManager на Android. Далее с помощью EventChannel нужно обрабатывать эти события — а события у нас приходят в виде матрицы переворота экрана — чтобы на стороне Flutter скрывать информацию, которую водитель хочет скрыть.
    
   Зачем нужна фича: многие водители не хотят, чтобы пассажиры видели их баланс или транзакции. Это достаточно приватная информация, и водитель может либо встряхнуть телефон, либо нажать кнопку и скрыть ее.
3. Карточки водителей из Яндекс Про в Яндекс Go — третий уровень сложности. Это максимальный натив и полный переход в нативную разработку. В Яндекс Про мы сделали карточки для водителей, перешли в Яндекс Go и поняли, что они работают не так, как мы ожидали. Обратились к команде разработки Яндекс Go и предложили внедрить фичу прямо в суперапп, чтобы сделать оптимальный UX. Договорились, а дальше наши ребята, которые работают с нативом, пришли и дописали под новый API карту из Яндекс Про внутри Яндекс Go.
    
   Этот кейс — пример, как в нашей экосистеме могут происходить обмены ресурсами и как наши компетенции в нативе помогли улучшить пользовательский опыт не только в Яндекс Про.

Все примеры основаны на нашей работе над Яндекс Банком. Это только одна фича, в экосистеме их намного больше, и у большинства из них так или иначе есть либо какие-то аппаратные функции, либо SDK, которые под ними используются.

Например, Заправки — полностью готовая SDK на iOS и Android, которую мы оборачиваем и показываем внутри модалки. В Маркете есть подключение по Bluetooth к постаматам для курьеров и сканеры QR-кодов. В Еде используется подключение к биконам в ресторанах, то есть неким Bluetooth-станциям. Когда курьер заходит в ресторан, ему сразу приходят пуши о статусе заказа, а ресторан узнает, что курьер уже пришел.

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

Навыки разработчиков в нативе

Мы провели в нашей команде небольшое исследование на 50 человек и узнали, кто пришел из какой платформы и какие знания пригодились в работе. Как оказалось, большинству Android-разработчиков и всем iOS-разработчикам пригодились знания своей платформы, их применяли и писали фичи конкретно с использованием этих технологий. Здесь стоит обратить внимание, что Android-разработчики чаще приходят во Flutter, чем iOS-специалисты.

В результате мы решили, что идеальный кроссплатформенный разработчик должен хорошо знать Flutter и одну из платформ, при этом уметь писать и понимать код как на iOS, так и на Android.

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

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

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

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

Какие навыки должны быть у разработчика

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

Финальный совет для разработчиков: если вы обладаете хотя бы базовыми навыками в iOS и Android, это сильно увеличивает вашу ценность на рынке. Поэтому изучайте обе платформы — так вы точно будете востребованы и сможете решать сто процентов задач для бизнеса.