Из Java во Flutter: MVP для 1С и 5 привычек, которые пришлось бросить

Java-программист пишет на Flutter уже в первый день: Dart похож на Java. Но из-за этого сходства MVP получается тормозящим и запутанным, потому что привычки Android SDK здесь не работают. Помогают композиция вместо наследования, неизменяемые модели и один подход к состоянию. Для B2B к ним добавляется ранняя связка с 1С.

Почему возникает ловушка «Dart — это почти Java» 🪤

Первый вечер с Flutter. Открываю пустой проект и вижу знакомое: классы, дженерики, async и await. Руки сами набирают привычное: абстрактный BaseScreen с методами initData и dispose, рядом синглтон-сервис, рядом менеджер запросов. К ночи экран списка заказов открывается, данные приходят из тестового API.

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

Dart читается как Java, поэтому мозг пропускает проверку: синтаксис знаком, значит знакома и модель выполнения. Но Flutter не использует нативные View. Он сам рисует интерфейс и заново собирает дерево виджетов при каждом изменении состояния. Мой базовый экран пересобирал страницу целиком, а фильтр лежал в объекте, который фреймворк пересоздаёт вместе с виджетом.

Теперь ставка. Задача была типовая для малого бизнеса: менеджеры оптовой компании принимают заказы по телефону и в Telegram, потом переносят их в 1С руками. MVP должен был показать, приживётся ли заказ прямо в приложении: каталог, корзина, статус отгрузки. Если выйти на пилот с дёргающимся списком, менеджеры вернутся к звонкам на склад. Пилот закроют как «не прижилось», бюджет спишут, а вопрос, нужно ли бизнесу приложение, останется без ответа. Переписывать придётся всё, что успело вырасти на этом экране: состояние, запросы, модели.

Как исправить: пять привычек Android SDK, которые пришлось бросить 🔧

Симптомы были разными, причина одна: Flutter-код, написанный с привычками из Android. После пяти замен список перестал дёргаться.

От наследования экранов к композиции виджетов

В Android я строила цепочку: BaseActivity, поверх неё BaseListActivity. Во Flutter экран собирается из маленьких виджетов. Общее поведение уходит в отдельный виджет-обёртку. Индикатор загрузки и заглушка для пустого списка становятся самостоятельными виджетами, которые вставляются куда нужно. Наследование глубже одного уровня здесь почти не встречается.

От POJO с сеттерами к неизменяемым моделям

Заказ из 1С приходит в JSON. В Java я сделала бы класс с полями и сеттерами. Во Flutter поля модели объявляют как final, а изменения делают через метод copyWith, который возвращает новую копию. Инструменты состояния сравнивают старое значение с новым и перерисовывают экран, только если оно изменилось. Шаблонный код для таких моделей пишут генераторы, например пакеты freezed и json_serializable.

От пулов потоков к Future и Stream

Java приучает следить, чтобы тяжёлая работа не блокировала основной поток. Dart исполняет код в одном потоке с циклом событий. Сетевой запрос возвращает Future, достаточно поставить await, и интерфейс не замирает. Отдельные потоки, в Dart их называют изолятами, нужны для тяжёлых вычислений, например для разбора огромного каталога. Запускать изолят ради обычного запроса к 1С — джавовская привычка, которая только усложняет код.

От тяжёлого onCreate к лёгкому build

Метод build вызывается при каждой перестройке, поэтому запросы, сортировки и форматирование в нём недопустимы. Список заказов у меня дёргался именно из-за сортировки внутри build. Я перенесла её в слой состояния, вынесла строку списка в отдельный виджет и подключила ListView.builder, чтобы строились только видимые строки.

От трёх архитектур сразу к одному подходу к состоянию

Из Java я принесла любовь к слоям и внедрению зависимостей и в первый вечер подключила сразу Provider, Bloc и get_it. Для MVP на несколько экранов это лишний код. Сейчас беру один инструмент, Riverpod или Bloc, и держу его на весь проект. Оба нормальные. Смешивать их нельзя: через месяц никто не найдёт, где живёт состояние корзины.

Что делать, если ошибка повторяется: приложение снова тормозит 🔁

Привычки возвращаются. Через месяц после исправлений список заказов снова дёрнулся: в строку добавили подсчёт суммы прямо в build. Ловить такие вещи глазами долго, поэтому я сверяюсь с инструментами.

1. ✓Запустите приложение в режиме profile на реальном смартфоне. В debug-режиме и на эмуляторе Flutter работает медленнее, и замеры врут.
2. ✓Откройте Flutter DevTools и включите отслеживание перестроек виджетов. Виджет, который перестраивается без причины, виден сразу.
3. ✓Проверьте списки: нужен ListView.builder, картинки должны кэшироваться, тяжёлые расчёты должны идти вне build.
4. ✓Нарисуйте карту состояния: какие данные где живут. У каждого куска данных должен быть один владелец.
5. ✓Добавьте код-ревью, если разработчик в проекте один. Второй взгляд быстрее находит «джавовские» места, чем линтер.

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

Как предотвратить проблемы ещё до пилота 🛡️

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

Перед пилотом проверьте ещё несколько вещей.

• ✓Есть ли сеть там, где работают пользователи. На складе и в выездах связь пропадает, поэтому нужен локальный кэш и очередь неотправленных заказов.
• ✓Доходят ли push-уведомления. Google-сервисы на части устройств в России недоступны, так что запасной канал, например RuStore Push, лучше заложить сразу.
• ✓Где лежат персональные данные клиентов. Если приложение их собирает, действует 152-ФЗ: запись данных граждан РФ должна идти в базы на территории России.
• ✓Как приложение ведёт себя на самом слабом смартфоне из тех, что есть у сотрудников.
• ✓Записан ли в README выбранный подход к состоянию, чтобы новый разработчик не принёс второй.

Как выбрать: Flutter, нативная разработка или 1С:Мобильная платформа

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

Если сотрудникам нужны формы поверх данных 1С, часто хватает 1С:Мобильной платформы: разработка идёт в привычной среде. Если нужен быстрый интерфейс и запуск сразу на iOS и Android, берём Flutter. Бывает и гибрид: клиентская часть на Flutter, а данные и логика остаются в 1С.

Сколько стоит MVP на Flutter и как мы его делаем 💼

Разработка мобильных приложений у нас начинается от 500 000 ₽. Итоговая цена зависит от числа сценариев и объёма обмена с 1С: приложение с заказами и остатками стоит иначе, чем приложение с одной формой заявки. Точную цифру называем после разбора задачи.

Отличие нашего подхода в том, что мы внедряем 1С и пишем мобильные клиенты сами. HTTP-сервис в конфигурации и приложение на Flutter делает одна команда, поэтому вопрос «кто виноват, что остатки не совпадают» не возникает между двумя подрядчиками. Начинаем с одного сценария, например с оформления заказа, выпускаем его на пилот и добавляем экраны по результатам. Бизнес видит работающий продукт до того, как потратит основной бюджет. Если приложением будут пользоваться клиенты компании, у нас есть отдельный формат: B2B-приложение с 1С.

❓ Частые вопросы

Можно ли Java-разработчику сразу писать коммерческое MVP на Flutter?

Можно, если сначала пройти замены привычек: композиция вместо наследования, неизменяемые модели, Future вместо потоков и один подход к состоянию. Синтаксис Dart знаком, а вот модель выполнения другая. Первый экран стоит проверить на реальном смартфоне в режиме profile, а не на эмуляторе, и только потом наращивать функции.

Как подключить Flutter-приложение к 1С?

Чаще всего в конфигурации 1С публикуют HTTP-сервис или стандартный интерфейс OData, а приложение обращается к нему по HTTP и получает JSON. Заранее продумайте, какие данные нужны экрану: остатки, цены, статусы. Данные нужно отдавать порциями: весь справочник за один запрос телефон не переварит.

Сколько стоит мобильное MVP для бизнеса, который работает на 1С?

Разработка мобильных приложений у нас начинается от 500 000 ₽. Итог зависит от числа сценариев и объёма обмена с 1С: заказы и остатки стоят иначе, чем одна форма заявки. Точную цену называем после разбора задачи, когда понятно, какие данные приложению нужны из 1С.

Что выбрать для приложения менеджеров: Flutter или 1С:Мобильную платформу?

Если нужны внутренние формы поверх данных 1С без сложного дизайна, хватит 1С:Мобильной платформы. Если важны скорость интерфейса, свой дизайн и запуск сразу на iOS и Android, берут Flutter. Часто оптимален гибрид: интерфейс на Flutter, а данные и логика остаются в 1С.

Нужно ли хранить данные клиентов приложения в России?

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