Фото Доменико Лоя на Unsplash

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

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

Да, вы можете развернуть свое приложение на 6 платформах, но, честно говоря, я не планирую этого делать. В основном потому, что ВЫ ДОЛЖНЫ использовать разные шаблоны проектирования в зависимости от платформы. Я не могу представить развертывание своих приложений на другой платформе.

На первый взгляд кажется, что он выступает за создание отдельных приложений для каждой платформы (например, Android, iOS, Mac, Windows и т. Д.). Идея о том, что вам нужно написать отдельное приложение для каждой платформы, используя собственный инструментарий пользовательского интерфейса платформы, широко распространена в сообществе разработчиков. «Нативные максималисты виджетов», как я их называю, полагают, что использование кроссплатформенных библиотек пользовательского интерфейса приведет к неполноценному, «неродному» опыту и, следовательно, будет отклонено пользователем. Как правило, приверженцев этой философии устраивает совместное использование «бизнес-логики», но пользовательский интерфейс должен использовать собственные виджеты пользовательского интерфейса. Большая часть этой догмы основана на датированных наблюдениях за неуклюжими кроссплатформенными настольными приложениями середины и конца девяностых годов - многие из них были разработаны новичками, использующими ранние воплощения Swing.

С тех пор кросс-платформенные наборы инструментов созрели, и платформы сошлись на некоторых общих шаблонах проектирования пользовательского интерфейса. Это особенно актуально для мобильных устройств, где многие популярные нативные приложения выглядят практически одинаково на Android и iOS. Разработчики мобильных приложений осознали, что гораздо важнее создать красивый, последовательный дизайн, чем пытаться «выглядеть нативно». Да, между iOS и Android есть различия, но различия являются исключением, а не правилом. На мой взгляд, было бы излишним поддерживать две отдельные кодовые базы для 2% пользовательского интерфейса, где они расходятся. Лучше предоставить абстракции, позволяющие удовлетворить эту 2% -ную дельту специфичными для платформы способами.

Если вы прочтете статью дальше, то увидите, что автор на самом деле не максималист по нативным виджетам. Т.е. Он не утверждает, что вы должны создавать отдельные приложения для iOS и Android, используя их собственные SDK. Он даже не утверждает, что нужно писать отдельные приложения для iOS и Android.

Обычно то, что работает на мобильных устройствах, не работает на компьютерах и наоборот.

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

Стратегии ориентации на несколько форм-факторов

Полное раскрытие информации: я работаю на Codename One.

Двумя лучшими кроссплатформенными инструментами для разработки мобильных приложений являются Codename One и Flutter. Они очень похоже подходят к проблеме кроссплатформенной разработки. Оба обеспечивают 100% повторное использование кода на разных платформах. Оба предоставляют богатый набор компонентов пользовательского интерфейса и абстракций API для базовых возможностей устройства, и оба могут быть развернуты на iOS и Android (и других платформах) как собственные приложения. Приложения Codename One разрабатываются на Java и / или Kotlin. Flutter в Dart.

И Codename One, и Flutter также позволяют развернуть приложение как настольное приложение. Однако, если вы не настроите пользовательский интерфейс для большего размера экрана и шаблонов использования рабочего стола, результат, вероятно, будет не очень хорошим. Даже использование мобильных приложений на планшете кажется вынужденным, если вы не настроили пользовательский интерфейс для большего размера экрана. Есть четыре стратегии, которые я использую при создании многофакторного приложения (т. Е. Приложения, которое работает на мобильных устройствах и настольных компьютерах):

1. Отзывчивый пользовательский интерфейс

Здесь логика приложения практически одинакова для обоих форм-факторов, но диспетчер компоновки и стили учитывают «форм-фактор». Например. На планшете / компьютере они используют разные стили, и менеджеры по расположению по-разному позиционируют элементы. (Например, вместо кнопки гамбургера, которая открывает боковое меню, выдвигающееся поверх формы, всегда отображается боковое меню).

2. Абстракция на уровне компонентов

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

3. Альтернативные взгляды

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

4. Отдельный поток управления

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

5. Отдельные приложения.

Если вы уже реализуете свое приложение с отдельным потоком управления, то создание отдельных приложений - это всего лишь один небольшой дополнительный шаг. Как правило, вы по-прежнему разделяете всю свою бизнес-логику между приложениями. Вы просто предоставите альтернативные точки входа для разных приложений. С Codename One это может быть достигнуто либо путем перемещения всего кода в общую библиотеку (cn1lib), либо путем простого предоставления альтернативного файла конфигурации (codenameone_settings.properties), который определяет другой основной класс. Большинство целей сборки используют Proguard или аналогичный для удаления неиспользуемого кода, поэтому совместное использование кода не влияет на размер приложения.

Лучший выбор?

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

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

По-прежнему предпочитаю кроссплатформенный инструмент разработки

Предположим, ваша команда решает реализовать отдельные приложения для каждого форм-фактора (мобильные, планшетные и настольные). Давайте даже сделаем шаг вперед и предположим, что вы решили реализовать отдельные приложения для каждой платформы (Android Mobile, Android Tablet, iPhone, iPad, Mac, Windows, Linux). Тогда есть ли какие-то преимущества от использования кроссплатформенного инструментария, такого как Codename One или Flutter? Поскольку вы создаете отдельные приложения, не лучше ли использовать только собственные API?

Если у вас нет неограниченного количества времени, разработчиков и денег, тогда ответ - «нет». Вам будет намного хуже, если вы решите использовать отдельные собственные SDK для каждой платформы. Даже если вам удастся написать несколько общих модулей, которые вы могли использовать в проектах, сложность, связанная с поддержкой отдельных баз кода, ошеломляет. Все в 7 раз сложнее. Каждая ошибка исправляется 7 раз, и тестирование становится до смешного сложным. Кроме того, чтобы быть в курсе последних событий на всех этих платформах и API, требуется самоотверженность. Скорее всего, вам потребуется привлечь отдельные команды для каждой платформы - и очень мало работы можно разделить между командами.

Использование такой технологии, как Flutter, - даже если вы создаете 7 отдельных приложений, было бы намного проще. Совместное использование кода между проектами намного проще, и каждый разработчик может работать над каждым проектом, не сталкиваясь с барьерами для входа, налагаемыми особенностями каждого нативного API.

Резюме

Тот факт, что вы можете развернуть свое приложение на 8 различных платформах, не означает, что вам следует это делать. Развертывание на нескольких платформах в одном форм-факторе (например, на телефонах) - надежный подход с проверенным послужным списком: бесчисленные популярные приложения в магазинах приложений для iOS и Android в настоящее время разрабатываются с помощью кроссплатформенных инструментов, таких как Codename One и Flutter. Однако развертывание в нескольких форм-факторах (например, телефоне и настольном компьютере) сложнее, поскольку то, что работает в одном форм-факторе, может не работать в другом. Возможно, вам будет удобнее создавать отдельные проекты для каждого форм-фактора и разделять между ними бизнес-логику. Это не означает, что вам следует отказаться от инструмента кросс-платформенной разработки. Использование такого инструмента по-прежнему является преимуществом, поскольку снижает общую сложность проекта и упрощает совместное использование кода и разработчиков между проектами.

Первоначально опубликовано на https://sjhannah.com 6 апреля 2021 г.