После выпуска Flutter 2.0 я заметил, что ажиотаж зашел слишком далеко. Не поймите меня неправильно, я большой поклонник Flutter и всегда буду его защищать.
Я использую Flutter в своей повседневной работе над созданием приложений для iOS и Android. Каждый день я вижу преимущества и недостатки Flutter, поскольку приложение, над которым я работаю, ранее было изначально написано на Kotlin и Swift со всеми возможными преимуществами: сканирование / распознавание страниц, идентификация PIN-кода / биометрические приложения, уведомления, статистика Firebase, наряду с очень продвинутым пользовательским потоком. Вот почему я чувствую, что могу сказать несколько слов о нашей нынешней ситуации (Flutterers).
Во время Flutter Engage в этом году одним из основных моментов, отмеченных на конференции, была возможность создать свое приложение для одной из шести платформ: iOS, Android, Mac, Windows, Linux и веб. Отличные новости! Но…
Да, вы можете развернуть свое приложение на 6 платформах, но, честно говоря, я не планирую этого делать. В основном потому, что ВЫ ДОЛЖНЫ использовать разные шаблоны проектирования в зависимости от платформы. Я не могу представить развертывание своих приложений на другой платформе. Это было бы сильно не к месту - нижние модальные окна, панели приложений, простые, но понятные списки? Это не то, чего ожидают пользователи от больших устройств. Обычно то, что работает на мобильных устройствах, не работает на компьютерах и наоборот.
Наш дорогой друг Филип Грасек рассказал о мифическом дизайнере-разработчике в своем выступлении на Flutter Engage. Я полностью согласен с ним в этом вопросе. Большему количеству разработчиков следует знать, что они делают, вместо того, чтобы слепо следовать своим спринт-доскам.
Scrum Sprint - это повторяемый фиксированный временной интервал, в течение которого создается «Готовый» продукт максимально возможной ценности.
Возвращаясь к Flutter:
Перестаньте думать, что вы создадите одно приложение и развернете его повсюду.
Скорее начните думать о том, насколько модульным я могу писать ваши приложения, чтобы повторно использовать их в будущих проектах. Вот вам пример. В моей компании мы создаем приложения, ориентированные на пользовательские данные. Это требует создания индивидуальных и продвинутых опросов, и мы не хотим писать новые виджеты каждый раз, когда нам нужно добавлять новые вопросы. Наш подход - модуль записи, который содержит всевозможную логику опроса - позволяет нам использовать его во многих проектах без необходимости переписывать каждый раз с нуля.
Приведя этот пример, я имею в виду, что когда вы создаете приложение, подумайте о том, на чем ориентировано ваше приложение или весь бизнес. Какая бизнес-логика стоит за этим?
В компьютерном программном обеспечении бизнес-логика или логика предметной области - это часть программы, которая кодирует реальные бизнес-правила, определяющие, как данные могут быть созданы, сохранены и изменены. - Википедия
Когда вы проясните логику домена, вы можете инкапсулировать ее в модули, которые вы можете использовать в своих приложениях Flutter.
Но, зачем мне вся эта суета?
Отличный вопрос!
Вы можете создать несколько приложений Flutter с разным пользовательским потоком, но сосредоточившись на одной и той же бизнес-логике.
Группирование ваших приложений Flutter в (мобильные, настольные и, возможно, веб-приложения - при необходимости) позволяет вам сосредоточиться на оптимальном пользовательском опыте для каждой конкретной платформы.
Почему я считаю, что вам следует писать несколько приложений?
Flutter - отличный инструмент, который может использовать каждый и создавать свои приложения, но это относительно новая технология, и она в основном используется небольшими компаниями или отдельными разработчиками. Я вижу, что это может измениться в ближайшем будущем, учитывая, как команда Flutter задает вопросы сообществу.
Я профессионально работал над несколькими приложениями корпоративного уровня. По моему опыту, в каждой части системы должен быть четкий рабочий процесс. Backend, front-end, dev-ops и т. Д. Но ради этого аргумента представьте, что ваше одно приложение, построенное для каждой платформы, становится популярным. В связи с большим спросом вам необходимо нанять команду разработчиков. Объединить все платформы в одно приложение просто невозможно. Можете ли вы представить, как 10+ программистов (в небольшой компании) работают над одной и той же кодовой базой, но одновременно на разных платформах? Это кошмар для менеджмента. Одна команда разработчиков работает над функцией рабочего стола, которая противоречит тому, над чем работает мобильная команда.
Во-вторых, размер приложения становится все больше и больше, а пакеты иногда не нужны для каждой платформы. Теперь, во время выпуска Flutter 2.0, у меня впервые возникла проблема с цепными зависимостями, потому что не все пакеты обновлены для поддержки нулевой безопасности или имеют взаимоисключающие зависимости.
Итак, наконец, почему Flutter не является кроссплатформенным фреймворком?
Прочитав эту статью, вы поймете, почему я считаю Flutter не традиционным кроссплатформенным фреймворком. Просто потому, что это инструмент, предоставляющий нам все необходимое для создания приложений для каждой платформы. Но мое скромное мнение таково, что это не должно быть одно приложение, больше похоже на группу приложений, управляемых одной и той же бизнес-логикой.
Другое дело, что когда мы пишем приложение Flutter, мы не пересекаем какие-либо платформы
Так было бы, если бы мы писали его в Xamarin или любом другом инструменте, который переводит его код в собственные элементы… но мы этого не делаем. У нас есть чистый холст, на котором мы все раскрашиваем сами.Если бы мне пришлось сравнивать Flutter с чем-то другим, это был бы игровой движок, вроде Unity. Мы не пишем специально игры для Windows или Mac. Мы пишем в Unity, а затем экспортируем его на конкретную платформу. Написание в Unity стало самостоятельным делом. Мы не называем каждую картину кросс-домашним холстом
Перевод статьи