Привет, Хабр! Представляем вашему вниманию перевод статьи How Kotlin Multiplatform helps reduce app development time.

Kotlin Multiplatform может сократить время разработки на 30 процентов об этом написали статью наши коллеги из компании Archer Software. Они подробно разобрали проблемы, которые возникают в процессе работы, и то, может ли кроссплатформенная технология их решить. Мы считаем, что материал нужный и полезный, поэтому публикуем в бло перевод.

Из этой статьи вы узнаете

1. Какие проблемы возникают, когда над приложением работают несколько команд
2. Может ли кроссплатформенная технология решить эти проблемы
3. Чем хорош Kotlin Multiplatform при разработке кроссплатформенных приложений
4. Недостатки Kotlin Multiplatform
5. Заключение

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

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

Какие проблемы возникают, когда над приложением работают несколько команд

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

Разные решения одних и тех же задач

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

Трудности коммуникации

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

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

Специфические особенности платформ

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

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

Взаимозаменяемость разработчиков

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

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

Может ли кроссплатформенная технология решить эти проблемы

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

Недостатки кроссплатформенных решений:

• трудно получить доступ к API системы;
• обновления запаздывают;
• нет возможности работать с устаревшим кодом;
• большинство кроссплатформенных комплектов для разработки (SDK) доступны только в бета-версии или на экспериментальной стадии;
• одинаковый вид приложения на всех платформах может испортить впечатление пользователя.

Чем хорош Kotlin Multiplatform при разработке кроссплатформенных приложений

Эти недостатки не настолько критичны, если знать, как с ними справляться. Чтобы ускорить разработку и облегчить взаимодействие между отдельными командами, наша компания использует Kotlin.

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

Как работает Kotlin Multiplatform

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

Функции, которые неэффективно кодить с помощью Kotlin, можно прописать в нативной среде. Так ниже риск разработки двух или более решений для разных платформ. И это не единственное преимущество.

Основные преимущества Kotlin Multiplatform

Значительная экономия денег и времени. Разработчики при работе на Kotlin экономят 3050% рабочего времени. Поэтому экономит и клиент: разработчикам не надо платить за то, что они воспроизводят один и тот же код несколько раз.

Меньше ошибок. Kotlin позволяет создавать максимально чистый код. Однако, если ошибки все-таки закрались, их можно найти и исправить до начала исполнения. Это экономит время и деньги в процессе тестирования и контроля качества (QA).

Эффективная работа в команде. Kotlin помогает командам программистов взаимодействовать и фокусироваться на приоритетных задачах. Более того, он позволяет распределять задачи между разработчиками. Например, команда Android может работать над реализацией регистрации (user signup flow), а команда iOS созданием поста (post create flow). На следующем этапе команда Android может использовать код, написанный командой iOS, и наоборот.

Практически нативное решение. Код Kotlin очень похож на Swift и на 100% совместим с Java.

Недостатки Kotlin Multiplatform

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

Нужно время на обучение

Разработчики часто спрашивают, как можно бесплатно изучить Kotlin или сколько времени на это нужно. Изучать основы вы можете бесплатно. Если владеете Java, вам потребуется меньше времени, чтобы их освоить.

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

Так что лучше: Kotlin или Java? Это зависит от цели, которую вы хотите достичь.

Нехватка разработчиков-экспертов

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

Заключение

Если вам нужно приложение для двух платформ и веб-версия, обращайтесь к экспертам по Kotlin, это беспроигрышный вариант. Мы в компании IceRock Development, как и наши коллеги в Archer Software, знаем, насколько он эффективен.

Наша компания делает заметный вклад в развитие технологии Kotlin Multiplatform:

• наши опенсорс библиотеки для быстрого старта при использовании Kotlin Multiplatform;
• телеграм-канал, где тему обсуждают 800+ программистов;
• сайт с библиотеками и ссылками на проекты;
• сайт с библиотеками для Kotlin Multiplatform.

Приходите к нам, и мы покажем, как Kotlin Multiplatform может быть полезен вашему бизнесу!

Привет! На связи Евгений Сатуров из Surf.

Команда Google опубликовала результаты опроса Flutter-разработчиков за третий квартал 2020 года. Публикую перевод материала с моими комментариями.




Статью подготовила команда Flutter по изучению UX (Flutter UXR) (ДжаЁн Ли, Йоян Хоу, Джек Ким, Тао Дон)

В августе 2020 года команда Flutter запустила 10-й ежеквартальный опрос разработчиков. За 10 дней его прошли 7 668 Flutter-разработчиков по всему миру. Каждый из них потратил на ответы около 7,4 минут суммарно это 39,4 дней. Мы высоко ценим время, которое вы потратили, чтобы оставить свой отзыв, и хотим поделиться с вами результатами.

Как обычно мы спрашивали о степени вашей удовлетворённости различными компонентами Flutter. Кроме того, в этом квартале нас интересовали отзывы по новым темам, таким как Flutter for web, сливеры (виджеты для создания сложных эффектов скроллинга) и отладка проблем, характерных для конкретных платформ. В этой статье мы подробнее рассмотрим каждую из тем.

Сводные данные

• 94% опрошенных были довольны фреймворком Flutter в целом (PSAT positively satisfied), а 58% были очень им довольны (VSAT very satisfied). Доля PSAT не изменилась, однако процент VSAT неуклонно растёт.
  
• Доля профессиональных разработчиков выросла с 26% до 31%. Увеличивается и доля продвинутых пользователей.
  
• Из тех, кто за последние 3 месяца использовал Flutter for web, 59% были довольны его работой. 71% довольны способностью Flutter реализовать пользовательский интерфейс, который ведёт себя как нативный веб-UI.
  
• Из пользователей, которым хотелось реализовать сложные эффекты скроллинга с помощью сливеров, 79% пробовали их использовать. Основная проблема (36%) состояла в том, что подходящий виджет было трудно найти.
  
• 71% пользователей выполняли отладку проблем, характерных для конкретных платформ. Часто проблемы возникали с инструментами (32%), визуальными различиями (28%) и управлением зависимостями (28%).
  

Степень удовлетворённости и изменения пользовательской базы

В этом квартале процент пользователей, очень довольных Flutter, достиг рекордных 58%. В целом пользователи Flutter всё так же довольны продуктом (94%), несмотря на экспоненциальный рост сообщества. На следующем графике показано, как степень удовлетворенности Flutter менялась с течением времени.


58% пользователей ответили Очень доволен на вопрос: Насколько вы довольны Flutter в целом?

Наша пользовательская база претерпела несколько существенных изменений. Во-первых, процент корпоративных пользователей Flutter-фреймворка значительно вырос с 26% в первом и втором кварталах до 31%, в то время как процент разработчиков из стартапов по-прежнему составляет около 35%.


Несмотря на то, что большинство пользователей Flutter работают на стартапы, процент корпоративных разработчиков значительно вырос с 26% до 31%

Комментарий
Удивляет то, насколько медленно Flutter покоряет агентства разработки. Мы в Surf проверили и убедились: качественная кроссплатформа решает большое количество проблем сервисной разработки.

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

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

Кроме того, в пользовательской базе существенно изменилась субъективная оценка опыта работы с Flutter. Как видно на следующем графике, доля начинающих пользователей постепенно уменьшалась, в то время как доля продвинутых пользователей постепенно увеличивалась. Это значит, что в нашем сообществе есть более опытные пользователи, которые могут поделиться своими знаниями с начинающими. Если вам интересно чему-то научиться или обменяться знаниями, можете поучаствовать в онлайн-обсуждениях с другими разработчиками Flutter. Заходите во вкладку Community на flutter.dev.


Доля продвинутых пользователей неуклонно растёт

Комментарий
Поразительный график. И дело не в природной скромности каждого, кто склонен называть себя Flutter-разработчиком. Ситуация на рынке труда молодой технологии уникальна тем, что прослойка бородатых гуру-специалистов отсутствует как класс. Это в разы усложняет развитие Flutter-компетенции в крупных компаниях. Часть проектов, которые могли бы быть написаны на этой технологии, оказываются в итоге написаны на другом фреймворке просто потому, что собрать скилловую команду в горящие сроки не удаётся.

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

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

Flutter for Web

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

Участники опроса активно использовали Flutter для создания веб-приложений. Согласно третьей строке следующего графика, около 33% сообщили, что оценивали возможность применения Flutter в коммерческих веб-приложениях (15%), собрали с его помощью демо-версию приложения (11%) или выпустили коммерческое приложение (7%).


33% пользователей (1468 из 4449) сообщили, что оценивали возможность применения Flutter в коммерческих веб-приложениях (15%), собрали с его помощью демо-версию приложения (11%), или выпустили коммерческое приложение (7%)

В частности, 29,5% пользователей с опытом как в мобильной, так и в веб-разработке, за последние 3 месяца более серьёзно использовали Flutter for Web (в потенциально коммерческих целях). Процент варьировался в зависимости от предыдущего опыта взаимодействия разработчиков с платформами. По всей видимости, респонденты, ранее занимавшиеся только веб-разработкой, использовали Flutter в качестве альтернативного веб-фреймворка (22% использовали Flutter for Web в потенциально коммерческих целях), а респонденты, ранее занимавшиеся только мобильной разработкой, активно использовали Flutter for Web для интеграции с веб-разработкой (16% использовали Flutter for Web).


Процент пользователей, применявших Flutter в веб в коммерческих целях за последние 3 месяца, варьировался в зависимости от их предыдущего опыта работы с мобильными и веб-платформами

Также веб-команда Flutter собрала отзывы о различных проблемах, связанных с внешним видом и функциями веб-приложения. Во-первых, мы узнали, что наиболее важными участники опроса считают навигацию в браузере и историю переходов по страницам (55%), копирование/вставку выделенного текста (34%), физику скроллинга (33%) и выделение текста (32%). Респонденты также попросили улучшить документацию по переходам по страницам и адаптации мобильных макетов к веб.

Комментарий
Flutter for Web интересует многих. Кажется, что прямо сейчас основные силы Flutter Team брошены на доработку фреймворка и адаптацию его под web. В недавнем выпуске FlutterDevPodcast мы обсудили текущее состояние Flutter for Web с гостями, которые уже могут похвастаться продуктом, запущенном на этой технологии в продакшне. Мы обсудили производительность, нативный UX, особенности вёрстки и реализации асинхронного кода. Затронули также темы CEO и хостинга для проекта.

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

Команда Flutter учитывает отзывы разработчиков и активно работает над улучшениями. Для решения основных проблем пользователей, связанных с навигацией и переходами по страницам, команда недавно выпустила Navigator 2. Мы также добавили поддержку копирования/вставки выделенного текста и планируем усовершенствовать функциональность выделенного текста (особенно в форматированном тексте). Мы продолжаем работать над проблемами с физикой скроллинга и производительностью, учитывая issues, полученные от сообщества.

В заключение наша группа получила отзывы о рабочих процессах, производительности и сторонних API. Среди всех основных рабочих процессов самым сложным, по мнению респондентов, оказался дебаггинг. Скорость загрузки страниц и скроллинг аспекты, в которых респонденты чаще всего сталкивались с проблемами производительности. Участники опроса попросили улучшить поддержку локального хранилища (например, SQLite), хранилища Firebase и Google карт для Flutter for Web. Наша команда будет работать над улучшением этих аспектов по мере развития Flutter for Web.

Комментарий
Безусловно, стремление довести Flutter for Web до идеала похвально. Готов ли фреймворк стать полноценной заменой своим более традиционным конкурентам? Моё мнение однозначно: нет. Впереди ещё долгий путь улучшений и доработок.

Сливеры

Sliver-виджеты (виджеты, названия которых начинаются с Sliver, например SliverAppBar и SliverList) используются для создания сложных эффектов скроллинга. Многие эффекты скроллинга можно реализовать с помощью таких виджетов, как ListView, GridView, PageView или AnimatedList, однако sliver-виджеты помогают кастомизировать scroll view и сделать UI красивее.


Такие сложные эффекты скроллинга можно реализовать с помощью sliver-виджетов

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

Первым делом мы узнали, что большинство участников опроса (49%) разрабатывает UI с простыми эффектами скроллинга. UI со сложными эффектами разрабатывают 39%. (В опросе были представлены примеры простого и сложного эффектов скроллинга.) Из тех, кому требуются сложные эффекты, 78% сказали, что для реализации необходимых эффектов им нужны сливеры.


UI с простыми эффектами скроллинга разрабатывает больше пользователей (49%), чем UI со сложными эффектами (39%)

20% пользователей, которым нужны сливеры, сообщили, что не пробовали их использовать. А что ещё интереснее, 35% пользователей, воспользовавшихся сливерами, сообщили, что у них возникли проблемы. Когда мы спросили, с чем возникли наибольшие сложности, первое место занял поиск (36%), затем изучение (30%) и, наконец, удобство использования (19%).


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

Поскольку мы не хотим, чтобы эти проблемы повлияли на ваш пользовательский интерфейс, мы планируем обновить flutter.dev, чтобы упростить поиск sliver-виджетов и изучение соответствующей информации. Если вы ищете новые сливеры, которых нет во фреймворке Flutter, попробуйте использовать программные пакеты, разработанные сообществом, например sliver_tools или sticky_headers. Также в сообществе Flutter всегда приветствуется ваш вклад в данную область.

А если вы ещё не знакомы со сливерами и хотите больше о них узнать, предлагаем вам следующие ресурсы:

Slivers, demystified (Небольшая статья)

Slivers explained making dynamic layouts (The Boring Flutter Development Show на YouTube, эпизод 12)

Комментарий
Сливеры камень преткновения для многих Flutter-разработчиков. Их боятся и не понимают. Может быть, виной тому не самый прозрачный API для работы с компонентами, а также хитрая вложенность виджетов. CustomScrollView, SliverList, SliverChildBuilderDelegate пока не разберёшься, какую роль играет каждый из этих компонентов в построении общей картины, кажется, что пытаешься разгадать фокус опытного иллюзиониста. На самом деле сливеры и им подобные механизмы одна из основных причин, почему я люблю Flutter. Возможность просто делать сложные вещи дорогого стоит.

Отладка проблем, характерных для конкретных платформ

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

Во-первых, мы спросили пользователей, какие платформо-специфичные проблемы они дебажили. В результате мы обнаружили, что наиболее часто возникают проблемы с тулингом (32%), визуальными различиями на разных платформах (28%), управлением зависимостями (28%), различиями в функционировании на разных платформах (27%), различиями в функционировании плагинов на разных платформах (26%), а также часто отсутствуют нативные фичи (25%).

Комментарий
Совсем недавно на просторах GitHub появилась кастомная сборка Flutter Engine с отключённым Metal. Оказалось, что без него приложение, собранное под iOS, работает в разы плавнее! С такими по-настоящему неприятными платформенными проблемами мы сталкиваемся не часто. Тем не менее, к ним всегда надо быть готовым. Чтобы быть во всеоружии, поможет только глубокое погружение в фундаментальные основы поддерживаемых платформ.

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

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


Примечание к рисунку (слева-направо): Difficulty сложность, Test issues проблемы с тестированием, Visual differences визуальные различия, Importance важность, Device-specific issues проблемы, характерные для конкретных устройств, Dependency management issues проблемы с управлением зависимостями, Release issues проблемы с релизом, Tooling issues проблемы с инструментами, Behavioral differences различия в функционировании, Missing native features отсутствие нативных средств, Plugin behavior differences различия в функционировании плагинов, Performance discrepancies различия в производительности.

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


Что касается тестирования приложений на нескольких платформах, 85% респондентов заявили, что это очень или крайне важно. Тем не менее, это оказалось очень или крайне сложно для 27% опрошенных. Следовательно, тестирование приложений на нескольких платформах важно, но для большинства разработчиков оно не представляет большой сложности. Из развёрнутых ответов на вопросы мы узнали, что наиболее часто проблемы с тестированием возникают при тестировании для iOS (особенно у разработчиков под Windows), тестировании для нескольких размеров экрана и тестировании на нескольких физических устройствах.

В следующем квартале наша команда потратит больше времени, основательно сократит число ошибок и решит основные проблемы, связанные с инструментами, управлением зависимостями и релизом. Также мы продолжим совершенствовать документацию на эти темы. Например, мы улучшим пользовательскую документацию для таких инструментов CI, как например, GitHub Actions и Bitrise, которые помогают пользователям тестировать приложения на iOS.

Комментарий
GitHub Actions прекрасен до тех пор, пока ваш репозиторий не становится приватным. С этого момента у вас будет всего лишь 200 бесплатных минут билд-тайма в месяц для сборки на виртуалке под macOS. Прочитайте мою статью про настройку идеального workflow для Flutter-проекта.

Что дальше

Ваш вклад каждый день влияет на наши решения. Мы сохраним верность этой традиции и продолжим принимать решения, исходя из ваших ответов на наши опросы. Поэтому просим вас и дальше участвовать и делиться своими мыслями. Также исследовательская группа Flutter UX проводит широкий спектр исследований пользовательского опыта (UX), чтобы улучшить ваш опыт работы с Flutter. Если вы хотите принять участие в исследовании, зарегистрируйтесь, и вашу кандидатуру рассмотрят в будущих исследованиях.

Привет!

20 октября в 18:00 мск проводим вебинар Flutter vs технология, на которой пишете вы: за чем будущее?

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

Регистрация




Flutter кроссплатформенная технология от Google и причина частых холиваров: одни ей восторгаются, другие критикуют.

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

Расскажем, каков Flutter в деле и стоит ли обратить на него внимание.

О чём поговорим:

• Что такое Flutter и какие у него перспективы.
• Какие проекты можно делать на Flutter.
• Как сменить привычный стек и перейти во Flutter.

Спикеры

Из Android во Flutter. Как распознать технологию, которая выстрелит

Евгений Сатуров, Flutter TeamLead Surf
Flutter/Android-разработчик, тимлид, активный спикер и технический евангелист в Surf. Основатель Flutter Dev Podcast. Один из организаторов крупнейшей российской мобильной конференции Mobius, а также лидер регионального IT-коммьюнити GDG Voronezh. За плечами 14 проектов, включая Росбанк Бизнес (Flutter), SBI bank (Android), MDK (Android).

Уйти во Flutter, чтобы не быть привязанным к ОС

Артём Зайцев, руководитель Flutter-отдела Surf
В прошлом Android-разработчик и тимлид. Прошёл путь от стажёра до head of. Загорелся кроссплатформой из желания, наконец, не быть привязанным к конкретной ОС. Cо-ведущий Flutter Dev Podcast, выступает на конфах. Приложил руку ко многим проектам, включая Магнит, МДК, KFC.

Путь из сурового энтерпрайза во Flutter

Алексей Радионов, Flutter-разработчик Surf
Занимался автоматизацией торговли нефтепродуктами. Это были серверные решения на C#, позже на Java Spring. Десктопные интерфейсы на Delphi и С++/Qt. Встраиваемые решения на C/С++ с использованием микропроцессоров Atmel или аппаратных платформ с embedded-linux.

Позже увлекся мобильной разработкой. Когда закончил проект под Android, задумался о разработке такого же приложения под iOS. В процессе поиска материалов узнал, что недавно вышел Flutter. Cосредоточился на его изучении. Через какое-то время попал на работу в Surf и уже поучаствовал в разработке приложения Росбанк Бизнес на Flutter.

Из геймдева во Flutter

Михаил Зотьев, Flutter-разработчик Surf
До мобильной разработки работал 5 лет в геймдеве. За это время успел попробовать множество технологий и клиентских, и серверных. Увлекся кроссплатформенной мобильной разработкой и понял, что это именно то, что искал всё время. Сейчас активно работает над проектом КFC. Периодически пишет статьи по разработке на Flutter, делится опытом и знаниями с комьюнити.

Чем Dart очаровал фулл-стек разработчика

Андрей Савостьянов, Flutter-разработчик Surf
В прошлом full-stack Java/Spring/Android, железные решения и протоколы, прикладные системы по автоматизации и мониторингу технологических комплексов. Придерживается широких взглядов на разработку. Language agnostic (Java, TypeScript, Dart). Dart 2.х и Flutter очаровали возможностями: мультиплатформа, производительность, нативная компиляция. Почти 2 года назад сменил специализацию и ни разу не пожалел. Работает на e-commerce проекте.

Регистрация

Вебинар начнётся 20 октября в 18:00. Место встречи YouTube-канал Surf.

Чтобы поучаствовать в вебинаре, заполните форму регистрации. Мы напомним вам о вебинаре за день и за час до события и пришлём ссылку на трансляцию.

До встречи!

В статье речь пойдет о Xamarin.Forms на примере живого проекта. Кратко поговорим о том, что такое Xamarin.Forms, сравним с похожей технологией WPF, увидим, как достигается кроссплатформенность. Также разберём узкие места, с которыми мы столкнулись в процессе разработки, и добавим немного реактивного программирования с ReactiveUI.

Кроссплатформа что выбрать?

В современном мире, в век огромного количества различных устройств и операционных систем, более конкурентноспособными являются приложения, способные работать сразу на нескольких платформах. Для реализации кроссплатформенности существуют разные подходы: написание нативного кода для каждой целевой платформы (по сути, нескольких различных приложений) или использование специальных фреймворков, позволяющих разрабатывать единый код для всех случаев. Есть еще кроссплатформенные языки программирования или же среды исполнения, например, Java Virtual Machine, но здесь я их касаться не буду.

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

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

А теперь к сути

Не так давно нашей команде пришлось лицом к лицу столкнуться с кроссплатформенной разработкой. Задача от заказчика звучала так:

• Создать iOS-приложение, работающее на iPad;
• Разработать такое же приложение с расширенным функционалом под Windows 10;
• Всё это при условии, что правки в дальнейшем могут вноситься как в оба приложения одновременно, так и по отдельности;
• Сделать приложение максимально гибким, поддерживаемым и расширяемым, потому что техническое задание, как обычно, менялось со скоростью света.

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

Xamarin это инструмент для создания приложений на языках семейства .NET (C#, F#, Visual Basic), который позволяет создавать единый код, работающий на Android, iOS и Windows (UWP-приложения). Это xaml-подобная технология, то есть интерфейс описывается декларативно в формате xml, вы сразу видите, как элементы расположены на форме и какие свойства имеют. Такой подход очень удобен, в отличие, например, от Windows.Forms, в котором, если бы не графический редактор, разрабатывать и редактировать пользовательские интерфейсы было бы крайне сложно, так как все элементы и их свойства создаются динамически. У меня был опыт разработки подобных интерфейсов без декларативных описаний в среде, не имеющей удобного графического редактора, и я не хочу его повторять. В Xamarin.Forms сохранена возможность динамического создания элементов интерфейса в программном коде, но для чистоты кармы и благодарности от последователей вашего кода всё, что можно описать декларативно, лучше так и описывать.

Xamarin.Forms и WPF

Еще одной известной xaml-подобной технологией является WPF (Windows Presentation Foundation). Это потрясающий инструмент для создания красивых интерактивных пользовательских интерфейсов. На мой взгляд, это один из лучших инструментов, созданных Microsoft, имеющий, правда, серьезный недостаток такие приложения можно разрабатывать только под Windows.

Xamarin.Forms включает в себя урезанную версию WPF, агрегируя лишь те компоненты, которые имеют аналоги на других платформах. С одной стороны, это даёт разработчикам, имеющим опыт работы с WPF, неплохую фору для входа в Xamarin.Forms. С другой же, познав всю прелесть и возможности WPF, программисту будет трудно то тут, то там натыкаться на отсутствие всех этих преимуществ в Xamarin.Forms. Мне было крайне грустно осознать, что я не могу использовать шаблоны для элементов управления, которыми так привыкла жонглировать в WPF, в Xamarin.Forms их попросту нет. Или удобный и мощный ItemControl компонент WPF, позволяющий разместить на форме список элементов, задавая каким угодно образом их внешний вид и расположение. С помощью одного только этого компонента как основного можно написать, например, простенький прототип игры в бильярд. В Xamarin.Forms существуют аналоги ItemControl, но все они имеют конкретную реализацию внешнего вида списка, что лишает их необходимой гибкости и вынуждает разработчиков идти на GitHub за велосипедами.

Кроссплатформенность в Xamarin.Forms

Однако не бывает худа без добра. Своими ограничениями Xamarin.Forms платит за кроссплатформенность, которая действительно легко и удобно достигается средствами этого инструмента. Вы пишете общий код для iOS, Android и Windows, а Xamarin сам разбирается, как связать ваш код с родным для каждой платформы API. Кроме того, есть возможность писать не только общий, но и платформозависимый код, и Xamarin тоже поймет, что и где вызывать. Одним из главных механизмов достижения кроссплатформенности является наличие умных сервисов, способных осуществлять кросс-зависимые вызовы, то есть обращаться к той или иной реализации определённого функционала в зависимости от платформы. Платформозависимый код можно писать не только на C#, но и добавлять его в xaml-разметку. В нашем случае iOS версия была урезанной и часть графического интерфейса нужно было скрыть, размеры некоторых элементов также зависели от платформы.

Для большей наглядности приведу небольшой пример. В нашем проекте мы использовали библиотеку классов, предоставленную заказчиком, которая была написана на C++. Назовём её MedicalLib. MedicalLib собиралась в две разные сборки в зависимости от платформы (статическая MedicalLib.a для iOS и динамическая MedicalLib.dll для Windows). Кроме того, она имела различные wrapper-классы (классы-переходники) для вызова неуправляемого кода. Основной проект (общая кодовая база) содержал описание API MedicalLib (интерфейс), а платформозависимые проекты для iOS и Windows конкретные реализации этого интерфейса и ссылки на сборки MedicalLib.a и MedicalLib.dll соответственно. Из основного кода мы вызывали те или иные функции абстракции, не задумываясь, как именно они реализованы, а механизмы Xamarin.Forms, понимая, на какой платформе запущено приложение, вызывали необходимую реализацию и подгружали конкретную сборку.

Примерно так это можно изобразить схематично:

Среда разработки

Для написания программ с Xamarin.Forms используется Visual Studio. На MacOS Visual Studio for Mac. Многие разработчики считают это больше недостатком, ссылаясь на тяжеловесность этой IDE. Для меня Visual Studio является привычной средой разработки и на высокопроизводительных компьютерах не доставляет каких-либо неудобств. Хотя Mac-версия этой IDE пока еще далека от идеала и имеет на порядок больше недочетов, чем её Windows-собрат. Для мобильной разработки имеется целый ряд встроенных эмуляторов мобильных устройств, а также возможность подключить реальный девайс для отладки.

Reactive UI и реактивная модель

В основу любого проекта Xamarin.Forms отлично ложится паттерн проектирования MVVM (Model View View Model), главным принципом которого является отделение внешнего вида пользовательского интерфейса от бизнес-логики. В нашем случае мы использовали MVVM, что действительно оказалось удобно. Важным моментом реализации MVVM является механизм оповещений View о том, что какие-то данные изменились и это необходимо отобразить на интерфейсе. Думаю, многие разработчики на WPF слышали об интерфейсе INotifyPropertyChanged, реализуя который во вью-моделях, мы получаем возможность оповещать интерфейс об изменениях. Этот способ имеет свои плюсы и минусы, но главным недостатком является запутанность и громоздкость кода в случаях, когда во вью-моделях есть вычисляемые свойства (например, Name, Surname и вычисляемое FullName). Мы выбрали более удобный фреймворк ReactiveUI. Он уже содержит реализацию INotifyPropertyChanged, а также много других преимуществ например, IObservable.

IObservable это реактивные push-based провайдеры уведомлений о наличии обновлений для подписчиков. Очень похоже на события и подписки на них, но с рядом дополнительных встроенных фич. Например, мы можем реагировать не на все обновления, а с какими-нибудь фильтрами (допустим, наш IObservable поток целых чисел, и мы хотим принимать во внимание только четные). Или одним подписчиком можно подписаться на комбинацию из двух IObservable, первый из которых типа bool, и реагировать или не реагировать на обновления второго в зависимости от того, что пришло в первый. IObservable можно представить как поток данных, хотя по сути это коллекция.

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

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

Взаимодействие с интерфейсом в обратном направлении (т.е. обработка действий пользователя), было реализовано с помощью так называемых Interaction взаимодействий, которые инициировались при работе пользователя с UI (например, при нажатии на кнопку), а обрабатывались в любом месте приложения. Что-то наподобие интерфейса ICommand и команд в WPF, только интеракции в нашем случае назначались на интерфейсные элементы не декларативно (как с командами в WPF), а программно, что показалось не очень удобным.

Выше я уже проводила аналогию с WPF. Для наглядности покажу, как выглядит наша архитектура в сравнении со стандартным WPF-приложением:

Весь набор инструментов, описанных на этой схеме, мы получили, используя Reactive UI.

Сложности в процессе разработки

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

Наиболее сложные моменты были связаны с разработкой UWP приложения, Windows добавила немало головной боли из-за некоторых особенностей и ограничений в отношении этих программ.

При сворачивании окна приложение переходит в состояние Suspended, и Windows выделяет ему меньше ресурсов. Это было критично, так как в одной из вариаций наш Data Generator работал, интегрируясь с внешними источниками и получая данные через сокеты. При сворачивании окна сокеты продолжали получать данные, заполняя свой внутренний буфер пакетами. А при выходе из режима Suspended все эти пакеты тут же помещались в буфер приложения, начиная обрабатываться только в этот момент. Из-за этого происходила задержка в отображении данных после развертывания окна, которая была пропорциональна времени, проведенному в свёрнутом виде. Всё решилось грамотной обработкой событий Suspending и Resuming, при наступлении которых мы сохраняли состояние приложения и закрывали сокеты, открывая их снова при восстановлении штатного режима работы.

Ещё одной непростой задачей стало добавление второго окна приложения (это было необходимо в рамках технического задания). Сейчас я не могу сказать, были ли это ограничения UWP, Xamarin.Forms или же наша собственная ошибка краш происходил в конструкторе одного из представлений из-за UI-потоков. Позже выяснилось, что библиотека, предоставленная заказчиком и являющаяся ядром обработки данных, однопользовательская и хранит в себе состояние. Таким образом, два независимых окна требовали двух независимых экземпляров библиотеки, что добавило нам одну большую низкоуровневую задачу, решение которой не было бы тривиальным. Мы решили, что овчинка выделки не стоит и проще не открывать отдельное окно, а создавать новый экземпляр приложения со своими настройками и адресным пространством. В итоге со стороны пользователя это выглядело в точности как второе окно (даже при закрытии главного окна второе тоже завершало свою деятельность), и разницу можно было заметить, только заглянув в диспетчер задач и увидев второй процесс.

Ну, и главный недостаток UWP, с которым пришло немало повозиться, это политика его распространения. Чтобы установить приложение, его либо необходимо загрузить в Microsoft Store и скачивать оттуда, либо поставлять дистрибутив другим способом с одним ограничением тогда при его установке необходимо дать операционной системе соответствующие разрешения (Sideloaded Apps в настройках Windows). Техническое задание требовало реализации второго подхода, однако политика безопасности заказчика запрещала сотрудникам компании менять подобные настройки. В итоге нам пришлось написать инсталлер, который перед установкой включал Sideloaded Apps, устанавливал пакет и в конце выключал эту настройку (естественно, по согласованию с заказчиком).

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

Что касается архитектуры и каких ошибок можно было бы избежать?

Выше я уже писала об использовании для взаимодействия с пользователем Interaction от ReactiveUI. Такие интеракции можно обработать в любом месте приложения, что является не только их достоинством, но и недостатком, так как может внести большую путаницу. Чтобы понять, почему при нажатии на кнопку она окрашивается в красный цвет, а не в зелёный, вам нужно найти все обработчики интеракции и проверить код в них. Договоренность внутри команды обрабатывать интеракции унифицированно может помочь снизить негативное влияние этого фактора, но избежать его совсем вряд ли удастся.

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

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

Итог

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

Благодаря архитектуре и выбранным решениям, со всеми их достоинствами и недостатками, проект уже полтора года наращивает функционал без какого-либо глобального рефакторинга и чувствует себя твёрдо стоящим на ногах. Инструмент работает и со своими основными задачами справляется. Кроме того, он не является новым для IT-сообщества, поэтому документации, которая помогает разобраться в тонкостях, достаточно. То, что теперь кроссплатформенную разработку можно вести на платформе .NET и удобном С#, которые предпочитают многие программисты, является неоспоримым преимуществом и может стать финальным аккордом в решении использовать Xamarin.Forms и на вашем проекте.

Повышенная производительность, автозаполнение, новый виджет и многое другое!

Всем привет, я Евгений Сатуров из Surf. Представляю перевод официальной статьи про последний апдейт Flutter 1.20 с моими комментариями. Фреймворк с каждым новым релизом становится всё более отполированным, и сегодня мы рассмотрим, что принес нам stable-канал в конце лета.



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

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

Чтобы сделать Flutter-приложения ещё более эстетичными, мы добавили в этот релиз несколько улучшений для UI, включая долгожданную поддержку автозаполнения, новый способ двигать и масштабировать виджеты, поддержку курсора мыши, обновили избранные Material-виджеты (например, виджеты для выбора даты и времени), а также добавили новую адаптивную страницу с лицензиями в окно About, для десктопных и мобильных Flutter-приложений.

Чтобы вы могли работать более продуктивно, мы обновили расширение Flutter для Visual Studio Code:

• оно позволяет использовать Dart DevTools прямо в вашем IDE;
• теперь можно перемещать файлы по проекту, и импорты будут автоматически обновляться;
• появился новый набор метаданных, чтобы вы могли писать свои собственные инструменты.

Благодаря открытости Flutter и участникам удивительного Flutter-сообщества, этот релиз включает 3029 слитых пулл-реквестов и 5485 закрытых issuesот 359 участников со всего мира, в том числе 270 участников из сообщества Flutter. Более того, это рекордное число контрибьюторов, которое у нас было на момент очередного релиза. Мы хотим выразить особую благодарность участникам под никами CareF за 28 пулл-реквестов, AyushBherwani1998 за 26 (включая 10 сэмплов, написанных в рамках Google Summer of Code), и a14n за 13 пулл-реквестов, многие из которых мы взяли на вооружение, работая над null safety во Flutter (скоро мы напишем об этом подробнее). Мы не смогли бы создать Flutter без такой огромной поддержки со стороны сообщества. Спасибо за ваш вклад!

С каждым новым релизом Flutter мы видим, как быстро растёт количество пользователей. Только в апреле мы писали, что число Flutter-приложений в Google Play достигло 50 тысяч. В пиковый период прирост составил 10 тысяч новых приложений в месяц. Сейчас, спустя всего три месяца, в Google Play опубликовано более 90 тысяч.

Flutter-приложений. Мы наблюдаем наибольший рост в Индии, которая стала регионом номер один для Flutter-разработчиков. За последние полгода их численность удвоилась, что является прямым следствием увеличения инвестиций Google в этот регион. Наконец, Flutter не был бы Flutter, если бы не Dart. Приятно видеть, что Dart занял 12-е место в топ-50 языков программирования по версии журнала IEEE Spectrum, поднявшись на четыре позиции по сравнению с прошлым годом.

Улучшение производительности для Flutter и Dart

Мы в команде Flutter всегда ищем новые способы уменьшить размер и увеличить скорость работы ваших приложений. Например, в этом релизе мы исправили проблему производительности с удалением font icon при tree shaking, а также включили это поведение по-умолчанию при создании приложений, не предназначенных для веба. Вышеупомянутые доработки приводят к удалению неиспользуемых шрифтов, уменьшая его размер. Мы опробовали это на приложении Flutter Gallery его размер сократился на 100 КБ. Теперь это поведение по умолчанию для релизных сборок. Пока это работает только со шрифтами TrueType Fonts, но в последующих релизах это ограничение будет снято.

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


Сравнение анимации до и после введения прогрева SkSL

В случае, если Flutter-приложение отображает рваную анимацию во время первого запуска, это можно исправить с помощью шейдера Skia Shading Language. При проведении предварительной компиляции на этапе сборки приложения, он может ускорить анимацию более чем в 2 раза. Если вы хотите воспользоваться этой функциональностью, переходите на страницу SkSL прогрева на flutter.dev.

Комментарий

Невероятно важное и долгожданное обновление, возможно важнейшее для всей Flutter-индустрии за долгое время. Почему? Да потому что джанки-анимации всё ещё бывают заметны и порой мешают клиентам окончательно принять Flutter в качестве продакшн-реди решения для своих проектов. В 1.20 эта проблема осталась в прошлом. Тем не менее, всё немного сложнее, чем кажется.

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

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

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

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

Комментарий

Из-за отсутствия поддержки таких важных мелочей Flutter for Web многими пока не воспринимается как решение для серьёзных задач. Это далеко не единственное улучшение в релизе 1.20, приближающее фреймворк к стабильному статусу. Мы отфильтровали для вас всё, что достойно внимания.

Новые курсоры мыши в виджетах на Android

Эта версия Flutter основана на Dart 2.9 и включает в себя новый двухпроходный декодер UTF-8. Он основан на состояниях и содержит примитивы декодирования, оптимизированные в виртуальной машине Dart и частично использующие преимущества инструкций SIMD.

UTF-8 самый распространённый методом кодирования символов в интернете. Способность быстро декодировать играет решающую роль при получении больших сетевых ответов. В наших бенчмарках декодирования UTF-8 мы заметили улучшения по всем направлениям. Прирост к скорости составил почти 200% для англоязычных и до 400% для китайских текстов на низкопроизводительных ARM устройствах.

Автозаполнение для Flutter-приложений

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


Автозаполнение в действии

Более того, мы уже начали адаптировать этот функционал для веба.

Новый виджет для шаблонных действий

В этот релиз мы добавили новый виджет InteractiveViewer. InteractiveViewer предназначен для имплементации шаблонных действий в вашем приложении, таких как сдвиг, масштабирование и drag n drop, которые работают даже при изменении размера. Вот как работает этот виджет на примере с доской в игре Go.


Масштабирование, сдвиг, изменение размера, drag n drop с помощью InteractiveViewer

Чтобы интегрировать InteractiveViewer в ваше приложение, ознакомьтесь с документацией API. Также вы можете опробовать его в действии в DartPad. Если вам интересно узнать больше о разработке InteractiveViewer, посмотрите эту презентацию на YouTube-канале Chicago Flutter.

В новой версии мы также добавили больше возможностей для drag n drop. Например, если вам нужно точно знать, где на целевом виджете произошло отпускание (такая опция раньше была доступна только для объекта Draggable), то теперь вы можете получить эти данные с помощью метода DragTarget onAcceptDetails.


onAcceptDetails в действии

Ознакомьтесь с этим примером, чтобы узнать больше об этой функции. В следующей версии Flutter эта информация станет доступна и во время перетаскивания, что позволит DragTarget своевременно обновлять визуальное состояние.

Комментарий

InteractiveViewer точно найдет применение в разработке, возможно, сделав бессмысленным существование нескольких библиотек от сторонних разработчиков. Особенно примечательно то, что этот виджет имеет имя и фамилию: его автор Justin McCandless. Он большую часть времени работал над всем, что связано с редактированием текста во Flutter. Justin сделал получасовой толк на ChicagoFlutter и рассказал, как из связки Transform и GestureDetector родился InteractiveViewer, а также поделился рецептами его использования.

Обновлённые Material-виджеты Slider, RangeSlider, TimePicker и DatePicker

Наряду с новыми виджетами, этот релиз содержит ряд обновлённых виджетов, соответствующих новым принципам Material дизайна. В частности, Sliderи RangeSlider. Вы найдёте дополнительную информацию в статье Whats new with the Slider widget?.

Обновлённый Material Slider


Обновлённый Material RangeSlider

DatePicker получил новый компактный дизайн, а также поддержку диапазонов дат.


Обновлённый DatePicker

Наконец, мы полностью переработали дизайн TimePicker.


Обновлённый TimePicker

Вы можете протестировать новый TimePicker в этом демо, написанном на Flutter.

Адаптивная страница лицензий

Мы создали новую адаптивную страницу с лицензиями, которая доступна в AboutDialog.


Новая страница с лицензиями

Пулл-реквест 57588 от участника под никомTonicArtos был обновлён в соответствии с принципами Material дизайна. Это не только сделало виджет красивее, но и улучшило навигацию: теперь его удобно использовать на планшетах, настольных компьютерах и смартфонах. Спасибо, TonicArtos! Учитывая, что каждое Flutter-приложение должно показывать лицензии для используемых пакетов, вы сделали все приложения на Flutter лучше!

Новый формат pubspec.yaml для публикации плагинов

Конечно, Flutter это не только виджеты. Это ещё и инструменты. В этом релизе обновлений слишком много, поэтому расскажем о самых примечательных.

Начнём с объявления для авторов Flutter-плагинов: старый формат pubspec.yaml больше не поддерживается при публикации плагинов. Если вы попытаетесь его использовать, то получите сообщение об ошибке при выполнении pub publish.


Ошибка при публикации плагина в устаревшем формате pubspec

Старый формат не поддерживал указание платформ, на которых работают ваши плагины. Он устарел с момента Flutter 1.12. Теперь для публикации новых или обновленных плагинов требуется новый формат pubspec.yaml.

Пользователи плагинов всё ещё могут использовать старый формат pubspec. Все существующие плагины на pub.dev, использующие устаревший pubspec.yaml, продолжат работать с Flutter-приложениями в обозримом будущем.

Превью встроенных Dart DevTools в Visual Studio Code

Самое крупное обновление инструментов в этой версии затрагивает Visual Studio Code: туда добавили превью новой функции, позволяющее перенести инструменты Dart DevTools прямо в пространство разработки.


Превью Layout Explorer в Visual Studio Code

Включите эту функцию с помощью новой настройки dart.previewEmbeddedDevTools. На скриншоте выше показан Flutter Widget Inspector, встроенный в Visual Studio Code. С помощью этой настройки вы можете назначить избранную страницу в меню Dart DevTools, расположенном в строке состояния.


Это меню позволяет вам выбрать, какие страницы показывать


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

Комментарий

А вот это то самое обновление, которого ждал, вероятно, каждый Flutter-разработчик, использующий VS Code в качестве основного инструмента! Что и говорить, каждый раз переключаться в браузер для дебага не девелопер-френдли. Я не говорю про то, что из-за этого не работали некоторые важные фичи, вроде навигации по коду из инспектора. Отныне про браузер можно забыть: все нужные утилиты доступны не выходя из VS Code. Закат эры превосходства Android Studio всё ближе.

Обновления в отслеживании запросов

Последняя версия Dart DevTools поставляется с обновленной версией утилиты Network, которая позволяет профилировать веб-запросы.


Продолжительность, статус и тип содержимого сокетных соединений на странице Network в Dart DevTools

Страница Network теперь добавляет информацию о времени к сетевым вызовам из вашего приложения наряду с другими данными, такими как статус и тип содержимого. Дополнительные улучшения получил интерфейс деталей запроса, который теперь отображает данные из веб-сокета или http-запроса. У нас есть ещё планы для этой страницы, например, мы хотим добавить отображение тела HTTP -запроса и ответа, а также мониторинг gRPC-трафика.

Обновление импортов при переименовании файлов

Ещё одна новая функция Visual Studio Code обновление импортов при перемещении или переименовании файлов.


Обновление Dart-файлов при перемещении

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

Комментарий

Android Studio, вот теперь на твоём месте я бы серьёзно забеспокоился. Одна из самых незаметных, но таких важных возможностей любимой IDE теперь и на VS Code. Теперь можно переименовывать файлы сколько угодно! Вам не придётся вручную корректировать все импорты (да-да, я знаю, мы все через это прошли). Ах, сколько человекочасов сэкономило нам обновление плагина для VS Code. Будет интересно узнать, а какими ещё возможностями продвинутого рефакторинга в VS Code пользуетесь вы? Пишите в комментариях.

Метаданные инструментов

Ещё одно обновление предназначено для людей, создающих инструменты Flutter. Мы сделали новый проект на GitHub: там мы будем собирать и публиковать метаданные о самом фреймворке. В нём вы найдёте машиночитаемые файлы, содержащие эти данные:

• каталог всех текущих виджетов Flutter (395 штук!),
• сопоставление названий цветов во Flutter со значениями цветов для наборов цветов Material и Cupertino,
• метаданные Icon для иконок Material и Cupertino, включая названия иконок и значки предварительного просмотра.

Это те метаданные, которые мы сами используем для расширений Android Studio / IntelliJ и VS Code. Мы подумали, что они могут пригодиться вам при создании новых инструментов. В приложениях семейства IntelliJ эти метаданные позволяют включить функцию отображения цвета, используемого в вашем коде на Flutter.



С этим связана новая функция в IntelliJ и Android Studio, которая отображает цветовые блоки для Color.fromARGB() и Color.fromRGBO().



Хотим выразить особую благодарность dratushnyy на GitHub за вклад в улучшение превью цветов в IntelliJ!

Типобезопасные платформенные каналы для межплатформенного взаимодействия

В ответ на популярный запрос от авторов плагинов, мы решили поэкспериментировать с тем, как сделать коммуникацию между Flutter и платформой безопаснее и проще для плагинов и Add-to-App. Для этого мы создали Pigeon инструмент командной строки, использующий синтаксис Dart для генерации типобезопасного кода поверх платформенных каналов без дополнительных runtime-зависимостей. Pigeon позволяет вызывать методы Java/Objective-C/Kotlin/Swift и передавать непримитивные объекты, напрямую вызывая Dart-методы (и наоборот) вместо ручного сопоставления названий методов в платформенных каналах и сериализации аргументов.



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

Комментарий

Настоятельно рекомендую обратить внимание на Pigeon. Это именно то, как будут писаться все платформенные каналы уже в самое ближайшее время. Совсем недавно я представил новый воркшоп на Mobius и GDG DevParty, посвящённый именно плотной интеграции Flutter-приложения и нативного модуля с доменным и сетевым слоем. В процессе него пришлось написать довольно толстый платформенный канал, который позволил прочувствовать все боли сполна. Основная проблема заключалась именно в отсутствии типобезопасности и необходимости написания достаточно грязного бойлерплейт-кода. Pigeon решает эту проблему это определённо шаг вперёд.

Прочие обновления

За время подготовки Flutter 1.20 инструменты получили так много отличных обновлений, что мы не сможем все их здесь перечислить. Тем не менее, наверняка вам будет интересно взглянуть на них:

• VS Code extensions v3.13
• VS Code extensions v3.12
• VS Code extensions v3.11
• Flutter IntelliJ Plugin M46 Release
• Flutter IntelliJ Plugin M47 Release
• Flutter IntelliJ Plugin M48 Release
• Новые встроенные инструменты для разработчиков Flutter

Ломающие изменения

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

• 55336Adding tabSemanticsLabel to CupertinoLocalizations Migration guide PR
• 55977Add clipBehavior to widgets with clipRect
• 55998Fixes the navigator pages update crashes when there is still route wa
• 56582Update Tab semantics in Cupertino to be the same as Material
• 57065Remove deprecated child parameter for NestedScrollViews overlap managing slivers
• 58392iOS mid-drag activity indicator

Резюме

Это самый объёмный релиз Flutter. В статье мы затронули только самые значительные улучшения инструментов и производительности и рассказали о самых интересных виджетах, новых и обновлённых.

Мы планируем добавить поддержку null safety (подробная статья Боба Нистрома Understanding null safety), выпустить новые версии плагинов Ads, Maps и WebView, а также расширить поддержку инструментов.

Как бы вы применили новые возможности Flutter в вашем проекте?

Привет! На связи Flutter Dev Podcast и его создатель и ведущий Евгений Сатуров.

Вместе с коллегами из Flutter-комьюнити мы делаем подкаст про Flutter. Первый эпизод вышел 29 января 2019 года. С тех пор каждый месяц мы приглашаем коллег из мира Flutter и других сфер IT: обсуждаем новости, события, технические нюансы, даём советы из боевого опыта в общем, смотрим на Flutter с разных ракурсов.

Как и зачем мы делаем подкаст, я подробно рассказал на vc.ru. В этой статье я сделал обзор самых интересных и популярных эпизодов Flutter Dev Podcast.




Во Flutter я пришел из Android: узнал о новой технологии в кулуарах конференции от Звиада Кардавы, Developer Relations из Google Russia, который потом стал первым гостем нашего подкаста. Идея создать СМИ про Flutter возникла потому, что мы одни из первых в стране начали что-то делать на этом фреймворке: ниша была свободна.

Flutter это технология кроссплатформенной разработки приложений под iOS, Android, веб и десктоп от Google.

Flutter Dev Podcast я запустил с коллегой Артёмом Зайцевым мы вместе работаем в Surf. На тот момент мы практически ничего не знали про Flutter, и, можно сказать, росли вместе с подкастом. Параллельно с подкастом развивали Flutter в Surf. Теперь у нас целый Flutter-отдел в нём работает 13 человек.Мы с ребятами ведём публичный репозиторий SurfGear на GitHub, где выкладываем всякие полезности для разработки на Flutter: набор библиотек, стандартов, инструментов.

Спасибо Google и лично Екатерине Винниченко и Звиаду Кардаве за поддержку нашего подкаста и за приглашение сделать обзор выпусков в блоге Google.

Выпуски Flutter Dev Podcast: от свежих к ранним

Целая платформа для заработка всевозможных людей

#19 Яндекс.Про

Геннадий Евстратов: Глобальная цель сделать громадного франкенштейна, в котором процент Flutter будет нарастать, нарастать, нарастать, и можно будет просто взять маленькой лопаточкой Android-код, вышвырнуть его и оставить просто Flutter-приложение.

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

Гости из Яндекса рассказывают, почему и в каком виде проникает Flutter в проекты компании: фреймворк уже используют для отдельных модулей в Яндекс.Лавке, Яндекс.Такси, Яндекс.Go. Говорят о том, что мешает перейти целиком на Flutter прямо сейчас, какие проблемы вскрылись при работе с Fish Redux из-за масштабирования и через что нужно будет пройти разработчику, чтобы интегрировать Flutter в нативное приложение.

Я много чем занимаюсь во Flutter-команде, но в первую очередь забочусь, чтобы внешние разработчики получали хороший опыт

#17 Flutter Day 2020

Chris Sells: Вы всегда можете написать нативный код в своём приложении или даже создать собственный плагин. Если вы напишете собственный плагин, и у нас такого нет, пожалуйста, поделитесь им с миром. Именно так растёт экосистема Flutter.

Это во многом необычный выпуск: впервые часть подкаста мы вели на английском и впервые сделали онлайн-трансляцию на Youtube.

В гости к Flutter Dev Podcast пришёл Chris Sells продакт менеджер из Google: вместе с Flutter-командой он занимается развитием Flutter. Обсудили разное: возможность одновременно дебажить на большом количестве устройств и эмуляторов, откуда появился Dash символ Flutter, какие проблемы у Flutter-команды есть в режиме удалённой работы.

Chris рассказал, как будет внедряться Null safety и что сильнее всего влияет на архитектуру приложения (и это не выбор State management). Вы узнаете, будет ли во Flutter свой Jetpack, почему из ранних версий Dart убрали Reflection API и добавят ли его обратно, сделают ли поддержку data value объектов. Eщё ведущие обсудили с Chris компиляцию Flutter-приложений на процессоры Arm в новых устройствах от Apple, что мешает выпустить альфа-версию Flutter с поддержкой сборки приложений для Windows и Linux и будет ли во Flutter динамическая загрузка кода.

Медиа это тот тип активности человечества, где все постоянно идёт не так, как ты хочешь

#16 Meduza

Борис Горячев: Я встретил сопротивление, которое я всегда встречаю у нативных разработчиков. Когда они слышат что-то про кроссплатформу, они сразу встают в позу, говорят, что это отстой полный, что всё плохо работает, всё медленно и вообще отстой. У них аргументы примерно такие:
А что если тебе надо будет показать вот это, вот это, вот это?
Но нам не надо будет это показать.
Нет, а что если надо будет?
Очень вряд ли.
Ну плохой перформанс!
Ну вроде как нет.
Нет, ну плохой, на нативе будет быстрее.

Новое приложение Meduza написано на Flutter с нуля. В 16 выпуске Flutter Dev Podcast CTO Meduza Борис Горячев рассказывает, зачем Meduza это надо. Начинаем с истоков: обсуждаем, почему в 2014 провалилась концепция mobile first, говорим про непростые отношения с нативными разработчиками, удивительный мир медиа-разработки, игры со шрифтами, тяготы работы с WebView и Backend Driven UI. А ещё Борис отвечает на претензии Артемия Лебедева.

Подробный пересказ выпуска Flutter Dev Podcast с Борисом Горячевым

Изначально я хотел сделать что-то похожее на VS Code, но лучше

#15 Flide IDE на Flutter

Андрей Лесницкий: Я начал продукт для себя, чтобы повысить свою продуктивность. Если это повышает мою продуктивность, это может повысить продуктивность и всех разработчиков в экосистеме Flutter.

Андрей Лесницкий из Минска пишет среду разработки на Flutter. Он вдохновился Android Studio и VS Code, и старается взять из них всё лучшее но хочет сделать IDE по-своему. Почему для проекта он выбрал Flutter: это челлендж или специальная задумка? Каким продукт задумывался и каким получился?

В выпуске Андрей рассказывает, как ему пришла в голову эта идея, с какими основными вызовами он столкнулся и в каком состоянии проект сегодня.

Мне очень понравилось быть водителем такси. Если бы тарифы были повыше, я бы переквалифицировался

#11 Яндекс.Такси

Геннадий Евстратов: Служба безопасности сказала: React Native только через их труп.

Команда Яндекс.Такси делает на Flutter программный комплекс для службы такси приложение Яндекс.Таксометр. В выпуске они рассказывают, почему сначала пилили проект на React Native, но потом перешли на Flutter, зачем сотрудники Яндекса таксуют по ночам и за счёт чего приложение на Flutter делается в два с половиной раза быстрее, чем на Android. А ещё про иероглифы в документации Fish redux, интеграцию Яндекс Map Kit и собственный виджет пак.

CI/CD сделает всё за вас, даже если у вас нету техники от Apple

#9 CI/CD Jenkins, Bitrise, Codemagic

Михаил Токарев: Когда мы разговаривали с Flutter Team по поводу CI/CD, они очень чётко сказали: Мы хотим видеть CI, которым могла бы пользоваться даже моя бабушка. С этой установкой мы и начали делать Codemagic.

Вместе с CTO Codemagic разбирались, зачем нужен CI/CD, в какой момент становится понятно, что без него не обойтись, и чем чреваты локальные сборки. Сравнивали Jenkins, Bitrise и Codemagic по всем параметрам, до которых смогли дотянуться: возможности, ограничения, стабильность, кастомизация, цены. Выясняли, откуда появился Codemagic и почему он позиционируется именно как CI/CD для Flutter, а не для всего подряд, в чем его отличие от остальных инструментов и какая компенсация положена пользователю, если сборка упала по вине инструмента.

Работает на всём, на чём есть экран

#7 Всё про кроссплатформу

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

Максим Биянов: Xamarin подошёл к максимальной матюрности. К состоянию, когда все основные проблемы решены и началось экстенсивное развитие. Есть фишки, которые малозаметны. Сейчас внимание уделяется нативному iOS.

Александр Фёдоров: React Native это промежуточное решение между нативным и вебом. Нативное получается быстрее, веб медленнее. Что-то посередине это React Native. Наверно, самый большой плюс что он пишется на JS. JS-разработчиков много, вход в разработку быстрый. React тоже не очень сложный.

Артём Зайцев: Ключевое отличие Flutter от того же React или Xamarin то, что он имеет собственный движок под капотом. И не использует нативные элементы, а просто рисует такие же.

Роман Яцына: Кotlin Native в целом тот же самый Kotlin, просто зарестрикченный. Сейчас очень сложно найти человека, который согласился бы писать на Java. Многие прям уходят из своих компаний, потому что там нет Kotlin.

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

React Native, Xamarin, PWA, QT, C++, Kotlin Native, Flutter Кроссплатформа достаточно общее слово, за которым кроется много разных технологий.

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

Мобильные разработчики пришли во Flutter, посмотрели на async/await и ужаснулись

#6 Асинхронность

Евгений Кот: Чтобы понимать стримы, нужно понимать, как сантехника работает.

Есть async/await, Future API, Stream API, есть метод Compute, есть даже RXDart. Как из этого многообразия понять, что из этого надо использовать, а что нет. Что делать со всей этой асинхронщиной, если вы пришли из мира iOS или Android. Почему изолят как пирожок с полки, и как Flutter обрабатывает асинхронные операции если Dart однопоточен.

Все виртуальные машины действительно на одно лицо

Слушать выпуск #5 Dart VM

Вячеслав Егоров: Начать можно с того, Dart VM название оно немножко неправильное. Правильно его называть Dart Runtime, потому что он не всегда из себя представляет виртуальную машину. Люди, которые представляют себе виртуальную машину, они представляют себе, что внутри какой-то байт-код исполняется. А более правильно, наверно, это все-таки называть Dart Runtime.

Вячеслав Егоров, разработчик Dart VM, рассказывает, почему Flutter написан на Dart, какую чёрную магию применяет Hot reload, в чем особенности Garbage collector. Про компиляцию из 90-х, прогретые функции и Flutter-веб. Как соотносятся изоляты в Dart и многопоточность, во что компилируется Flutter-приложение в релизной сборке и что у Flutter с реверс-инжинирингом.

Все выпуски Flutter Dev Podcast на Soundcloud

Всем привет! Я Евгений Сатуров, Flutter TeamLead в Surf. Представляю перевод официальной статьи про свежий апдейт Flutter 1.22 как обычно, дополненный моими комментариями.

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

Погнали ближе знакомиться с новой версией Flutter 1.22.




Мы рады представить последний релиз Flutter с обширной поддержкой iOS 14 и Android 11. Flutter 1.22 основан на фундаменте, заложенном предыдущими версиями, и позволяет разработчикам создавать быстрые и красивые пользовательские интерфейсы для нескольких платформ из единой кодовой базы. В наших ежеквартальных stable релизах новые функции, улучшенная производительность и bug fixы.

Недавно вышли новые версии мобильных ОС. Мы сфокусировались на том, чтобы Android 11 и iOS 14 превосходно работали на этом релизе Flutter.

Обновление Flutter для iOS 14: поддержка нового Xcode 12, новых иконок и поддержка App Clips запуска iOS-приложения без установки. App Clips полный аналог Instant Apps for Android.

Обновление Flutter для Android 11: добавили поддержку разных типов чёлок у дисплеев, а также более плавную анимацию при вызове soft keyboard.

Этот релиз выходит всего через два месяца после выхода версии 1.20, но даже за это небольшое время мы закрыли 3024 issues и замёрджили 1944 PR от 197 контрибьюторов.

Комментарий

Кстати, если вы давно хотите стать контрибьютором Flutter, но не знаете с чего начать, вот вам пара советов. Фильтруйте issues по тэгу good first contribution: время от времени там появляются интересные задачи, с которых можно начать свой путь в опенсорс. Также вы можете реализовать фичу чьей-то мечты, отфильтровав issues по тэгу new feature. Там есть задачки даже для начинающих. Вы сможете увековечить своё имя в истории фреймворка конечно, в том случае, если разработчики Flutter-team согласны с тем, что такая фича должна быть реализована.

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

• восстановление состояния,
  
• новая вселенная Material кнопок,
  
• новая библиотека для поддержки локализации и интернационализации, работающая с Hot Reload,
  
• новый Navigator,
  
• стабильная версия для Platform Views (основа для плагинов Google Maps и WebView),
  
• переключатель, который вы можете добавьте свой код, чтобы улучшить прокрутку на устройствах с высокочастотными дисплеями.
  

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

Целевая платформа iOS 14

Каждый раз, когда анонсируется новая версия мобильной ОС, мы тщательно её тестируем: ищем несовместимости или изменения, которые могут повлиять на работу Flutter и его инструментов.

В случае с iOS 14 мы сделали некоторые изменения во Flutter, чтобы убедиться, что он будет работать ровно так, как того хотят разработчики:

• Xcode 12 требует iOS 9.0 или выше, поэтому в нашем шаблон по умолчанию теперь вместо версии платформы 8.0 указана версия 9.0.
  
• В Flutter 1.22 были исправлены специфические сбои iOS 14 и проблемы с отрисовкой шрифтов.
  
• Проблемы с развёртыванием на физические устройства (приложение не запускалось на устройстве только на эмуляторе) были исправлены в Flutter 1.20.4.
  
• Новая политика, которая показывает уведомления, когда приложения обращаются к своему буферу обмена, вызвала ложные уведомления в приложениях Flutter и была исправлена в Flutter 1.20.4.
  
• Новая политика сетевой безопасности для локальной отладки приложений Flutter заставляет iOS 14 показывать одноразовое диалоговое окно подтверждения (только во время разработки, а не для выпущенных Flutter-приложений).
  

Итог: если iOS 14 целевая платформа для вашего Flutter-приложения, мы настоятельно рекомендуем вам пересобрать его с помощью Flutter 1.22 и задеплоить его в App Store прямо сейчас, чтобы обеспечить наилучший пользовательский опыт для тех, у кого iOS 14.

Дополнительную информацию, включая некоторые соображения по поводу Add-to-App, дип линкам и уведомлениям, смотрите в документации iOS 14 на flutter.dev.

Отдельно хотим сказать про обновлённую поддержку нового шрифта iOS SF Symbols, который вдохновил нас потратить некоторое время на обновление пакета cupertino_icon. Существующие варианты использования CupertinoIcons будут автоматически отображаться в новом стиле, как только вы обновите зависимость cupertino_icons до новой основной версии 1.0. Если вы используете cupertino_icons 1.0 вместе с Flutter 1.22, у вас будет доступ к ~ 900 новым иконкам через API CupertinoIcons.



Полный список иконок вы найдёте на странице предварительного просмотра cupertino_icons и на странице сведений о миграции на flutter.dev.

Еще одна функция, которую вы можете попробовать с Flutter на iOS 14, это App Clips. App Clips новая фича iOS 14: приложения быстро запускаются без установки на телефон, если весят меньше 10 мб. Flutter версии 1.22 умеет работать с App Clips в предварительном варианте реализации.


App Clips на Flutter

Подробнее о том, как создавать App Clips приложений с помощью Flutter, в документации на flutter.dev. Посмотрите также образец простого проекта.

Комментарий

Помните Instant Apps for Android? Похоже, Apple решили вернуть наш 2017 год и представили свой полный аналог этой фишки App Clips. Теперь вы можете запускать приложения без установки и на iOS. Более того, вы не теряете эту возможность даже в том случае, если вы пишете не нативное приложение, а кроссплатформенное.

Не забывайте про ограничения: если ваша сборка весит более 10 Мб, то запустить её в формате App Clips не получится. В случае с Flutter-приложением это может быть действительно актуальной проблемой. Но об этом вы узнаете во второй половине статьи: там мы расскажем, как вы сможете мониторить размер сборки вашего приложения при помощи удобного инструмента.

Android 11

Этот релиз Flutter вышел практически одновременно с релизом Android 11. Фреймворк и движок Flutter обновились, чтобы поддерживать две новые фичи, представленные в последней версии Android.

Во-первых, Flutter теперь учитывает расположение чёлок и вырезов на экране Android-телефона, а также закруглённые края экрана.



Используя API MediaQuery и SafeArea, теперь легко написать UI, в котором интерактивные области не будут попадать на вырезы и закруглённые края экрана.

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


Обратите внимание на FAB

Issue 19279 давняя проблема, когда анимация отображения / скрытия экранной клавиатуры не синхронизируется с Flutter inset. Для Android 11 это исправлено.

Раньше из-за плагинов Flutter были проблемы, когда в нативное Android-приложение вставляли Flutter-код. Мы переписали API для интеграции Flutter c Android и выпустили API v2, которая лишена этих недостатков. Начиная с версии 1.22, мы прекращаем поддержку старых API v1.

Если вы продолжаете использовать Android v1 API, вот что это для вас значит:

• Новые плагины создаются без поддержки v1 API.
  
• Флаг конфигурации инструмента Flutter no-enable-android-embedding-v2 был удалён. Теперь это поведение по умолчанию.
  
• В более старых приложениях, всё ещё использующих API v1, во время сборки будет отображаться предупреждение об устаревании, которое ссылается на документацию по поддержке новых API-интерфейсов плагинов Android.
  

Между тем, если у вас всё ещё есть приложение Flutter на основе API версии 1 для Android, оно продолжит работать. Однако вы можете начать встречать новые плагины, у которых целевая API v2. Они не могут использоваться API v1 для Android. Дополнительные сведения см. В документации по критическим изменениям.

Комментарий

Пожалуй, основным страхом разработчиков относительно Flutter была неуверенность в оперативной поддержке новых фич операционных систем, которые могут быть использованы в нативных решениях уже с первого дня. На примере релиза 1.22 мы видим, что поддержка всех новых возможностей платформ приоритет для команды. Даже App Clips, который (я уверен) не найдёт широкого применения, уже доступен к реализации. А что касается Android, куда более важное изменение в новом релизе, касающееся его, это сохранение состояния экрана после смерти процесса. О нём ниже.

Расширение вселенной кнопок

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

Чтобы идти в ногу с Material гайдлайнами, мы представляем новую вселенную кнопок во Flutter 1.22.


Новая вселенная Material design кнопок

У новых виджетов и тем новые имена классов. Мы переименовали классы во Flutter, чтобы они соответствовали спецификации Material Design.



Новые темы следуют нормализованному шаблону, который Flutter недавно принял для новых виджетов Material. Демо-версия на DartPad

Это не критическое изменение, поскольку семантика FlatButton, OutlineButton, RaisedButton, ButtonBar, ButtonBarTheme и ButtonTheme не изменится. Вы можете смешивать и сочетать старые кнопки с новыми.

Новая поддержка интернационализации и локализации

Основные функции, необходимые для интернационализации (i18n) и локализации (l10n) ваших приложений, доступны во Flutter с самого начала. В этом релизе мы сделали поддержку Hot reload для обновления вашего приложения по мере добавления новой l10n информации.



Если вам нужна дополнительная информация о поддержке Flutterом l10n, включая локализованные сообщения, сообщения с параметрами, датами, числами и валютами, прочтите Flutter Internationalization User Guide.

Кроме того, если вас интересуют i18n и l10n, вам, возможно, потребуется использовать строки с символами, которые не вписываются в простой старый ASCII например, Unicode и эмодзи. Недавно команда Dart выпустила characters package, который помогает разработчикам работать с кластерами графем Unicode (расширенным). Этот пакет помогает решить проблемы, например, как правильно сократить строку типа A [эмодзи британского флага] text in English до первых 15 символов. Используя класс String, это сокращение будет A [эмодзи британского флага] text in, что составляет всего 12 символов, воспринимаемых пользователем. С другой стороны, использование пакета characters даёт правильное сокращение A [эмодзи британского флага] text in Eng.

С этим PR Flutter использует пакет символов для правильной обработки этих сложных символов. Например, при использовании TextField с ограничением maxLength такие символы, как [эмодзи семьи из трёх человек], теперь правильно считаются как один символ. Кроме того, с этим PR пакет символов доступен в Flutter-проектах автоматически, без необходимости добавлять его вручную. Надеюсь, это упростит работу со строками всех типов из всех локалов. Чтобы узнать больше о пакете символов, ознакомьтесь с отличной статьёй Правильные манипуляции со строками в Dart.

Плагины Google Maps и WebView можно использовать в продакшн-приложении

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


webview_flutter plugin, отображающий flutter.dev

Во Flutter 1.22 мы добавили альтернативную реализацию Platform Views, которая устраняет все известные проблемы с клавиатурой и проблемы доступности на Android Views. Это работает с Android API уровня 19 и выше (раньше требовался уровень 20). Мы также внесли улучшения в потоки в iOS, которые делают platform views более эффективными и надёжными (и больше не требует добавления флага io.flutter.embedded_views_preview в ваш iOS Info.plist).

Плагин webview_flutter поддерживает новый режим Android Platform Views, но в настоящее время его необходимо включить вручную. Когда он получит большее распространение в сообществе, мы включим его по умолчанию.

Плагины Google Maps и WebView уже выиграли от улучшений в Platform Views.

Если хотите использовать Platform Views, чтобы размещать собственные UI-элементы в iOS и Android, прочитайте подробнее про нативные Android и iOS views в приложении Flutter.

Комментарий

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

Навигатор 2.0

Если вы раньше использовали навигацию в своих приложениях Flutter, возможно, вы заметили, что основная структура данных, стек страниц, по которым перемещается пользователь, скрыта от вас. Вместо этого, чтобы управлять ею, вы вызываете Navigator.pop() или Navigator.push().

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



Два экрана можно реализовать так:

class ColorListScreen extends StatelessWidget { final List<Color> colors; final void Function(Color color) onTapped; ColorListScreen({this.colors, this.onTapped});  @override Widget build(BuildContext context) => Scaffold(       appBar: AppBar(title: Text('Colors')),       body: Column(         children: [           // you can see and decide on every color in this list           for (final color in colors)             Expanded(               child: GestureDetector(                 child: Container(color: color),                 onTap: () => onTapped(color),               ),             )         ],       ),     );} class ColorScreen extends StatelessWidget { final Color color; const ColorScreen({this.color});  @override Widget build(BuildContext context) => Scaffold(       appBar: AppBar(title: Text('Color')),       body: Container(color: color),     );}

Использование простейшего стиля Navigator 1.0 позволяет вам перемещаться между этими двумя экранами. Это выглядит довольно легко:

class _ColorAppState extends State<ColorApp> { List<Color> _colors = [Colors.red, Colors.green, Colors.blue];  @override Widget build(BuildContext context) => MaterialApp(       title: 'Color App',       home: Builder(         builder: (context) => ColorListScreen(           colors: _colors,           // the Navigator manages the list of pages itself; you can only push and pop           onTapped: (color) => Navigator.push(             context,             MaterialPageRoute(builder: (context) => ColorScreen(color: color)),           ),         ),       ),     );}

Вызов Navigator.push() это всё что нужно, чтобы поместить другую страницу поверх первой, создав стек из двух страниц. Однако, в отличие от списка контейнеров, созданного в методе сборки ColorListScreen, этот стек скрыт от вас. А поскольку он скрыт, им трудно управлять в других сценариях, таких как обработка диплинков initial route, предоставленным, например, нативным встраиванием, или URL-адресом из интернета или намерением из Android. Также чрезвычайно сложно управлять вложенной маршрутизацией между различными структурами одной и той же страницы.

Navigator 2.0 решает эти и другие проблемы, делая стек страниц видимым. Вот обновленный пример перехода между одним и тем же ColorListScreen и ColorScreen:

class _ColorAppState extends State<ColorApp> { Color _selectedColor; List<Color> _colors = [Colors.red, Colors.green, Colors.blue];  @override Widget build(BuildContext context) => MaterialApp(       title: 'Color App',       home: Navigator(           // you can see and decide on every page in this list         pages: [           MaterialPage(             child: ColorListScreen(               colors: _colors,               onTapped: (color) => setState(() => _selectedColor = color),             ),           ),           if (_selectedColor != null) MaterialPage(child: ColorScreen(color: _selectedColor)),         ],         onPopPage: (route, result) {           if (!route.didPop(result)) return false;           setState(() => _selectedColor = null);           return true;         },       ),     );}

Приложение явно создаёт Navigator и предоставляет ему список страниц, представляющий полный стек. Мы создаём пустой _selectedColor, чтобы указать, что цвет еще не выбран, поэтому изначально мы не показываем ColorScreen. Когда пользователь выбирает цвет, мы вызываем setState() как обычно, чтобы указать Flutter, что вы хотите снова вызвать метод build(), который теперь создаёт стек с ColorScreen наверху.

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

Если Navigator 2.0 выглядит как остальная часть Flutter, это нарочно: он декларативен, в отличие от императивного Navigator 1.0. Идея заключалась в том, чтобы объединить модели навигации и остальной части Flutter, одновременно исправляя множество багов и добавляя фичи. Фактически, этот небольшой пример лишь поверхностно описывает то, что есть в Navigator 2.0. Для подробностей я настоятельно рекомендую статью о декларативной навигации и маршрутизации во Flutter.

Вы можете продолжать использовать Navigator 1.0: он будет работать так же, как и раньше. В ближайшее время мы не будем его удалять. Однако мы думаем, что если вы попробуете Navigator 2.0, он вам понравится.

Комментарий

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

С другой стороны, сообщество ждало от нового навигатора гораздо большего. Реализовать вложенную навигацию всё ещё крайне нетривиальная задача для Flutter. И Navigator 2.0 не привнёс никаких улучшений на этом поприще. Известный разработчик Remi Rousselet даже заявил в Twitter, что напишет свой навигатор. Будет любопытно посмотреть, что у него получится. А пока рекомендую опробовать наше собственное решение для реализации вложенной навигации мы разработали его в Surf.

Предварительная версия: Восстановление состояния для Android

Новая функция, с которой вы можете поэкспериментировать в этом выпуске, это поддержка восстановления состояния на Android. Это одна из наших самых желанных функций, получившая 217 отзывов!

Для тех, кто не знаком с необходимостью восстановления состояния: мобильные ОС могут убивать приложения, которые находятся в фоновом режиме, чтобы освободить ресурсы для приоритетных приложений. Когда это происходит, ОС уведомляет приложение, которое она собирается убить: приложение быстро сохраняет состояние пользовательского интерфейса, чтобы восстановить его, когда пользователь вернётся к приложению.

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

Вот очень простой пример восстановления состояния дефолтного приложения Flutter Counter:

class CounterState extends State<RestorableCounter> with RestorationMixin {  @override  String get restorationId => widget.restorationId;  RestorableInt _counter = RestorableInt(0);  @override  void restoreState(RestorationBucket oldBucket) => registerForRestoration(_counter, 'count');  void _incrementCounter() => setState(() => _counter.value++);  @override  Widget build(BuildContext context) => Scaffold(      body: Center(child: Text('${_counter.value}')),      floatingActionButton: FloatingActionButton(onPressed: _incrementCounter),    );}

Вкратце, каждый виджет получает сегмент хранилища, который регистрируется в RestorationMixin с использованием уникального идентификатора. Используя тип RestorableProperty (например, RestorableInt, как здесь) для хранения UI-специфичных данных и регистрируя эти данные с помощью функции восстановления состояния, данные автоматически сохраняются до того, как Android завершает работу приложения, и восстанавливаются, когда оно возвращается к жизни. И это всё. Все данные, которые хранятся в типе Restoration*, например RestorableInt, RestorableString и RestorableTextEditingController (у нас их несколько), будут восстановлены. И если мы не охватыватили все типы, которые вы хотели бы восстановить, вы можете создать свой собственный, расширив RestorableProperty.

Для автоматического тестирования восстановления состояния мы добавили в WidgetTester новый API restartAndRestore. А для тестирования вручную проще всего:

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

Android убьет и восстановит ваше приложение, и вы увидите, всё ли работает так, как вы ожидаете.



Эта версия восстановления состояния предварительная: предстоит ещё кое-что доделать. Например, восстановление состояния фича не только для Android, приложения для iOS тоже смогут от этого выиграть. Кроме того, мы заняты обновлением собственных виджетов, чтобы сохранять их состояние во время восстановления. Мы сделали поддержку классов Scrollable, таких как ListView и SingleChildScrollView (для запоминания позиции прокрутки пользователя) и TextFields (для восстановления введённого текста), и планируем распространить её на другие виджеты.

Правда, мы еще не добавили ключевую функцию поддержку навигации (1.0 или 2.0), поэтому и называем эту версию предварительной. То есть приложение не откроется на том же месте, где пользователь находился. Эта функция скоро появится в бета-версии и в следующей стабильной версии Flutter.

Комментарий

С одной стороны прорыв. Flutter-приложение всё меньше отличается от нативного в плане UX. С другой реализация довольно тяжеловесная, особенно если вы хотите сохранять не только состояние отдельных виджетов (например, текстовых полей они будут сохраняться по-умолчанию), но и любого State вашего кастомного виджета. Все сохраняемые свойства вам предстоит оборачивать в специальные Restorable-контейнеры, вручную регистрировать их в RestorationMixin.

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

Предварительная версия: плавная прокрутка для непревзойдённых частот ввода и отображения

Работая с нашими внутренними партнёрами из Google, команда Flutter значительно улучшила производительность прокрутки, когда частота ввода и отображения не совпадают. Например, вход Pixel 4 работает с частотой 120 Гц, а дисплей работает с частотой 90 Гц. Это несоответствие может привести к снижению производительности при прокрутке. С новым флагом resamplingEnabled вы можете решить эту проблему:

void main() {  GestureBinding.instance.resamplingEnabled = true;  run(MyApp());}

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

Новый унифицированный инструмент разработчика Dart

Как всегда, обновление Flutter касается не только движка и фреймворка, но и инструментов. Flutter 1.22 включает новую версию Dart (2.10), а также новый инструмент командной строки dart, который также может оказаться полезным.

Исторически у Dart было много небольших инструментов для разработчиков (таких как dartfmt для форматирования и dartanalyzer для анализа кода). В Dart 2.10 есть унифицированный инструмент разработки dart, очень похожий на инструмент flutter.



Начиная с Flutter 1.22 SDK, в папке <flutter-sdk>/bin (которая, вероятно, у вас есть в yourPATH) содержатся команды flutter и dart. Для получения дополнительной информации см. Сообщение в блоге Dart 2.10.

Инструмент анализа размера приложения

Инструменты, выпущенные как часть Flutter 1.22, включают новую утилиту анализа размера сборки. Этот инструмент помогает диагностировать, не раздувается ли размер вашего приложения с течением времени.

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

• flutter build apk
  
• flutter build appbundle
  
• flutter build ios
  
• flutter build linux
  
• flutter build macos
  
• flutter build windows
  

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


Пример разбивки релизного APK Flutter Gallery

Эта сводка полезна, чтобы быстро проанализировать размер сборки и понять, из-за чего она слишком большая. Кроме того, собранные данные также доступны в виде файла JSON, который можно посмотреть в Dart DevTools, что позволяет дополнительно исследовать содержимое приложения, выявлять проблемы с размером и видеть изменения между двумя разными файлами JSON, следуя инструкциям на flutter.dev. После загрузки файла JSON у вас будет интерфейс, в котором отображается древовидная карта размера вашего приложения.


Пример разбивки APK в Dart DevTools

Документации по инструменту анализа размера приложения на сайте flutter.dev

Комментарий

То, что давно умеет Android Studio сама по себе, теперь можно анализировать и через Dev Tools. Реализовано это даже более гибко. Теперь вы можете деплоить отчёты в Json прям на CI и мониторить изменения размера сборки в динамике.

Предварительная версия: обновленная страница Network в DevTools

Еще одна предварительная функция DevTools в этом выпуске: теперь во вкладке Network отображается body запроса.



Чтобы включить эту функцию, убедитесь, что вы находитесь на dev-канале Flutter через flutter channel dev и flutter channel upgrade.

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



Документацию по вкладке Network ищите в разделе Использование Network View на flutter.dev.

Вкладка Hosted DevTools Inspector в IntelliJ

Уже некоторое время мы поддерживаем две копии некоторых наших инструментов Flutter: например, панель Inspector в IntelliJ и вкладку Inspector в Dart DevTools. Это замедляет нашу работу: нам нужно поддерживать две кодовые базы. Кроме того, некоторые функции еще не вошли в плагин IntelliJ например, Layout Explorer. Чтобы решить эти проблемы, мы включили возможность размещения вкладки Inspector из Dart DevTools непосредственно внутри IntelliJ.



Чтобы включить эту опцию, перейдите в Preferences > Languages & Frameworks > Flutter > Enable embedded DevTools inspector.

Комментарий

Ещё одно маленькое, но очень важное изменение. В одном из выпусков Flutter Dev Podcast мы даже посвятили несколько минут обсуждению разницы в инструментах разработчика в Android Studio и VS Code.

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

Улучшенный вывод логов в Visual Studio Code

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



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

Как всегда, здесь слишком много списка изменений инструментов, но я рекомендую изучить следующие анонсы:

• Dart DevTools 0.9.0
  
• Dart DevTools 0.9.1
  
• Dart DevTools 0.9.3
  
• Выпуск плагина Flutter IntelliJ M48.1
  
• Выпуск плагина Flutter IntelliJ M49
  
• Выпуск плагина Flutter IntelliJ M50
  
• Расширения VS Code v3.14.0
  
• Расширения VS Code v3.15.0
  

В центре внимания клиентов: EasyA

EasyA это приложение по подписке: школьники занимаются с блестящим репетиторам через обмен мгновенными сообщениями. Приложение написано на Flutter. Недавно Apple отметила его как приложение дня.

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

Фил Квок, соучредитель EasyA

Критические изменения

Как всегда, мы стараемся свести количество критических изменений к минимуму. Вот список из версии Flutter 1.22:

• 56413 Запретить viewport.showOnScreen прокручивать область просмотра, если указанный Rect уже отображается.
  
• 62395 [gen_l10n] Генерация синтетических пакетов по умолчанию.
  
• 62588 Build routes even less.
  

Резюме

Стабильная версия Flutter 1.22, возможно, вышла очень быстро после релиза 1.20, но в ней так много хорошего, что здесь мы не смогли упомянуть всё. Надеемся, что этот релиз поможет вам создавать потрясающие приложения для iOS и Android, и нам не терпится увидеть, что появится в сторах! Спасибо за вашу поддержку: мы создаём Flutter для вас.

Привет! На связи IceRock Development, команда из Новосибирска.

Хотим поделиться полезным опытом. Вот уже 2 года мы занимаемся разработкой на Kotlin Multiplatform. В 2018 году начали реализовывать свои проекты и сразу сделали несколько открытий. В том числе выяснили, что мультиплатформенная технология значительно экономит силы и время.

Мы еще раз убедились в ее эффективности на KotlinConf 2019, которая проходила в Копенгагене. Это самое масштабное событие в мире программистов на Kotlin. Они собираются, чтобы провести воркшопы, обменяться опытом и просто приятно провести время в кругу единомышленников.

Да, многолюдненько. Потому что и сообщество программистов объединяет несколько десятков стран. Фото с официального сайта JetBrains

JetBrains, организаторы конференции и создатели языка Kotlin, предложили нам проект. На конференции представляли новую версию языка. Она позволяет писать код в том числе под смарт-часы Apple. Чтобы продемонстрировать эту возможность, мы должны были создать приложение под три платформы: iOS, Android и WatchOS.

Квест во имя Kotlin: что получилось сделать для конференции

Во время подготовки к KotlinConf мы вместе с JetBrains работали над Kotlin Locator/Finder. Это игра-квест, где нужно было побегать по Bella Center. К слову, это второй по величине конференц-центр в Скандинавии, который специально арендовали для KotlinConf 2019 в Копенгагене! Здесь собрались 1700 разработчиков со всего мира.

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

Чтобы пройти игру, нужно найти 6 маячков в разных местах.

Таким получился интерфейс Kotlin Locator/Finder на iOS для смартфона

JetBrains создали сервер-приложение с несколькими запросами на базе Kotlin Spinner Game. Нам позвонили, рассказали про идею. Арт-лид стал колдовать над дизайном, а технический директор со специалистом занялись начинкой приложения.

Мы согласовали с сервером протокол, нарисовали карту и создали архитектуру приложения. Начали разработку на iOS-платформе под смартфон. Первым пунктом в техзадании были смарт-часы. Но версия Kotlin, позволяющая кодить для них, вышла позже. Поэтому приложение для часов сделали после смартфона.

Так выглядит интерфейс Kotlin Locator/Finder приложения для смарт-часов

Все протестировали. В самом конце подключился Android-программист, реализовал только UI для Android. И вуаля! приложение готово.

Делимся наработками:

• код приложения;
• версия приложения для Android;
• версия приложения для iOS.

В процессе у нас получилось:

• первый раз использовать Kotlin/Native на WatchOS с версией компилятора 1.3.60 всё прошло отлично!
  
• отладить взаимодействие из общего kotlin кода с iBeacon-метками. Мы работали с библиотекой Reedyuk/blue-falcon. Библиотеку в итоге форкнули себе и доработали.
  
  Часть изменений зареквестили автору оригинала: поиск устройств, отображение устройств. Он принял обратную связь и поблагодарил.
  

Итог: можно сказать, удалось все, что запланировали. Заодно потестили новую верисю Kotlin Multiplatform и убедились, что на ней действительно можно писать приложение под часы.

Само приложение скачали несколько сотен раз в Play Market и в App Store. Для локального мероприятия очень даже себе показатель. До финала квеста дошли 20 человек. Победителей JetBrains отметили призами.

Только посмотрите на эти лица! Да, слегка смущенно выглядят ребята

Еще бы! Потому что на них смотрят самые крутые Kotlin-разработчики мира!

Сэкономили время и затраты на команду: что нам дала мультиплатформенная технология

Над приложением фулл-тайм работал барабанная дробь! только iOS-разработчик. Остальные: дизайнер, Android-программист и тестировщик трудились на неполную ставку. И сделали полностью нативное приложение!

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

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

Основную часть багов нашли при разработке и отладке iOS-приложения. Поэтому создавали приложения для часов и Android практически без них.

Код Kotlin Multiplatform очень похож на Swift. У приложения Kotlin Locator/Finder на iOS и Android общая бизнес-логика: за поведение на обеих платформах отвечает один кусок кода. Это дает одинаковую детализацию и стабильность работы. Соответственно, и комфорт для пользователя.

Приложение на iOS

Приложение на Android

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

Что может дать Kotlin Multiplatform любому бизнесу

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

Резюмируем кратко:

Быстрый выход на рынок. Все этапы разработки, проверки и тестирования проходят почти в 1,5 раза быстрее, чем при создании нативных приложений отдельно на iOS и Android. Хотя все зависит от сложности UI. Так что ускорить разработку в среднем можно на 2050%.

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

Если проект сложнее, одному спецу нужно написать общий код и бизнес-логику. Разработчику другой платформы не придется делать двойную работу. Останется подключить приложение к общей библиотеке и добавить UI.

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

Совместимость с другими языками программирования. Если у вас есть приложение, в которое вы хотите интегрировать Kotlin Multiplatform, его не придется полностью переписывать. Язык похож на Swift и совместим с Java.

Сейчас мы в IceRock Development ведем большинство проектов с помощью этой технологии. 2019 год мы в компании объявили годом Kotlin Multiplatform.

Стараемся внести свой вклад и в развитие международного Kotlin-сообщества. Подскажем пару полезностей:

• https://moko.icerock.dev наши опенсорс библиотеки для быстрого старта при использовании Kotlin Multiplatform;
• https://libs.kmp.icerock.dev сайт с библиотеками для Kotlin Multiplatform;
• https://kmp.icerock.dev сайт с библиотеками и ссылками на проекты;
• https://t.me/kotlinmpp телеграм-канал, где 800+ программистов обсуждают нюансы использования технологии.

Если есть вопросы, напишите нам на mpp@icerock.dev. Рады любой обратной связи!