👣 Почему писать два нативных приложения с помощью агентов вместо одного на Flutter - плохая идея Команда Flutter выпустила материал о том, почему в эпоху ИИ единая кодовая база выигрывает у двух нативных. Главная мысль: узкое место агентской разработки - не генерация кода, а скорость проверки и поддержка. В чем проблема нативных приложений: Представьте: ИИ за день переписывает приложение на Swift и Kotlin. На старте все отлично - синтаксис, экраны, запросы к API. Через два года выясняется, что поддерживать это очень сложно. Причина в том, что код на проде - это не просто экраны. Это история решений команды: почему сделали так, а не иначе, что сломалось и как починили, какие требования нужно соблюдать, какие редкие случаи уже исправили. В одной кодовой базе команда спорит и пишет код один раз. В двух - каждое требование нужно отдельно поднять, решить и поддерживать дважды. Вторая проблема - агенты расходятся в решениях: Популярная идея: пусть один агент пишет на Swift, второй агент на Kotlin. Но каждая генерация LLM вероятностна. Даже с одинаковыми промптами два агента в разных языковых парадигмах принимают разные решения. Обе реализации проходят тесты в первый день. Через недели на Android падает конверсия на 3% - потому что тайминг ретраев ведет себя иначе при плохой сети. Инженеры тратят дни, копаясь в двух стеках. Flutter убирает дрейф в источнике: одна state machine, один слой сериализации, один источник бизнес-логики. Почему Flutter лучше подходит для ИИ: Генерация кода перестала быть узким местом, узким местом стала проверка. 73% разработчиков чувствуют себя продуктивнее с ИИ, но 46% не доверяют ему при критичном дебаге без ручной проверки. Качество вывода агента ограничено скоростью цикла обратной связи. Flutter изначально строился для мгновенной обратной связи человеку и эта же архитектура работает на агента: Stateful Hot Reload вносит изменения в работающую Dart VM с сохранением состояния, headless widget-тесты идут в герметичной среде, а дерево Widget и RenderObject инспектируется через Dart VM Service и DevTools по MCP - детерминированно, а не по скриншотам. Окружение агента важнее промпта: Если агента не направлять, он знает Flutter только до момента, когда его обучали: тянется к устаревшим API, неверно понимает сторонние пакеты, останавливается, не проверив результат. Уговорами в промпте это надежно не лечится - нужно правильное окружение. Внутренний эксперимент Project One Shot это показал: общие указания вроде «избегай утечек памяти» не работали. Агент справился, только когда получил четкое окружение - анализ кода через AST и MCP, навыки под конкретный пакет и обязательную проверку тестами: сначала воспроизвести баг падающим тестом, потом написать минимальный фикс, потом прогнать тесты и линтеры утечек. Чтобы такое окружение было у каждой команды, Flutter выпустил три вещи: официальные плагины для агентов с MCP-сервером и набором навыков, агентов Antigravity для проверки доступности и Agent Skills CLI - инструмент, с которым авторы пакетов могут поставлять свои навыки прямо внутри пакета. Куда все движется: Приложения эволюционируют от статичных экранов к динамическим интерфейсам под намерение пользователя. Google и партнеры развивают A2UI - открытый стандарт генеративных интерфейсов, на котором работает GenUI SDK для Flutter. В работе это проверено на GenLatte: ИИ-нативный сервис заказа кофе, где Gemini рисует латте-арт, а Flutter динамически собирает интерактивные интерфейсы. Flutter дает переносимый декларативный холст, который рендерит UI одинаково везде. 🔗 Читать подробнее 💡 Вывод: ИИ действительно упрощает миграцию на нативные приложения - но только в первый день. Дальше в игру вступает поддержка, и здесь две нативные базы проигрывают одной. Flutter выигрывает не потому, что генерирует код, а потому что сокращает цикл проверки и убирает дрейф между платформами. В эпоху агентской разработки это важнее, чем скорость написания первой версии. Подписаться на канал: ➡️ Flutter & Dart | Мобильный трудоголик

👣 Переиспользуемая пагинация во Flutter на Riverpod Бесконечная лента - привычная часть многих приложений. Но реализация пагинации часто превращается в повторяющийся код. Хочется один раз собрать универсальный механизм и переиспользовать его в разных экранах. В статье на примере Riverpod рассказывается, как это сделать без сторонних пакетов. В чем суть проблемы: Готовые пакеты для пагинации существуют. Но многие из них устарели, используют устаревшие классы или предполагают, что номер страницы всегда число. Это не всегда так. Например в банковском приложении транзакции могут группироваться по датам. Тогда индекс страницы - это дата или строка, а не целое число. Решение - построить собственный контроллер поверх AsyncNotifier. Он будет хранить текущий индекс, загружать первую страницу и добавлять следующую к уже полученным элементам. Как устроен контроллер: Контроллер принимает два типа: T для данных и I для индекса страницы. Ему нужны три вещи: начальный индекс, способ загрузки страницы и способ вычисления следующего индекса. abstract class PaginationController<T, I> { I get initialPage; late I currentPage = initialPage; FutureOr<List<T>> loadPage(I page); Future<void> loadNextPage(); I nextPage(I currentPage); } Затем создается механизм, который реализует этот интерфейс поверх AsyncNotifier. mixin AsyncPaginationController<T, I> on AsyncNotifier<List<T>> implements PaginationController<T, I> { @override late I currentPage = initialPage; @override FutureOr<List<T>> build() async => loadPage(initialPage); @override Future<void> loadNextPage() async { final newState = await AsyncValue.guard(() async { currentPage = nextPage(currentPage); final elements = await loadPage(currentPage); return [...?state.valueOrNull, ...elements]; }); state = newState; } } Механизм берет на себя хранение текущего индекса, загрузку первой страницы и добавление новых элементов. Конкретному экрану остается только определить начальный индекс, запрос данных и следующий индекс. Как выглядит использование: class RepositoriesViewModel extends AsyncNotifier<List<Repository>> with AsyncPaginationController<Repository, int> { @override int get initialPage => 1; @override FutureOr<List<Repository>> loadPage(int page) async { final (_, items) = await repository.fetchRepositories(page: page); return items; } @override int nextPage(int currentPage) => currentPage + 1; } Все, что требуется от экрана - задать три параметра. Как подключить в интерфейсе: Осталось отслеживать конец прокрутки. Для этого используется NotificationListener. NotificationListener( onNotification: (ScrollNotification info) { if (info is ScrollEndNotification && info.metrics.pixels >= info.metrics.maxScrollExtent) { viewModel.loadNextPage(); } return true; }, child: CustomScrollView(...), ) Когда пользователь прокручивает список до конца, вызывается загрузка следующей страницы. 🔗 Читать подробнее 💡 Вывод: Пагинация на Riverpod может быть переиспользуемой. Контроллер поверх AsyncNotifier хранит индекс, загружает страницы и добавляет новые элементы. Конкретный экран определяет только начальный индекс, запрос и следующий индекс. Такой подход дает чистую архитектуру, поддержку нечисловых индексов и легкое расширение поиском, фильтрацией и обновлением жестом. Подписаться на канал: ➡️ Flutter & Dart | Мобильный трудоголик

👣 Релиз Genkit Dart 1.0: ИИ-функции и агенты на Dart и Flutter Вышла первая стабильная версия Genkit Dart - фреймворка для разработки ИИ-функционала и ИИ-агентов на Dart. Теперь можно строить приложения с поддержкой разных моделей, инструментов и интеграций, не выходя из экосистемы Dart и Flutter. Раньше фреймворк был в статусе preview. Обратная связь от сообщества помогла доработать API и расширить набор инструментов для задач на проде. Теперь релиз готов к использованию в реальных проектах. Как установить: Добавить Genkit в проект можно одной командой: dart pub add genkit Также можно установить скиллы для ИИ-ассистентов, чтобы они знали актуальные API и практики Genkit Dart: npx skills add genkit-ai/skills Единый API для разных моделей: Genkit поддерживает Google Gemini, Anthropic Claude, OpenAI и модели, совместимые с OpenAI, через один интерфейс. Провайдеры регистрируются как плагины и их можно менять без переписывания логики приложения. final ai = Genkit(plugins: [googleAI(), anthropic()]); final prompt = 'Suggest a weekend getaway from San Francisco.'; final fromGemini = await ai.generate( model: googleAI.gemini('gemini-flash-latest'), prompt: prompt, ); final fromClaude = await ai.generate( model: anthropic.model('claude-sonnet-5-5'), prompt: prompt, ); Типобезопасность через flows: Genkit позволяет оборачивать ИИ-логику в flows - строго типизированные функции, которые легко тестировать и разворачивать как HTTP-эндпоинты. Схемы данных описываются один раз на Dart и используются и на сервере и в приложении. @Schema() abstract class $TripRequest { String get destination; int get days; } Это дает сквозную типобезопасность между бэкендом и Flutter-приложением. Где выполняется код: ИИ-логика пишется на стандартном Dart, поэтому ее можно запускать где угодно: 🔹Напрямую во Flutter: для быстрого прототипирования или сценариев, где пользователь использует свой ключ API. 🔹На Dart-сервере: для сложных flows и защиты приватных промптов. Flutter вызывает их через defineRemoteAction. 🔹Во Flutter с удаленными моделями: ИИ-логика остается в приложении, но запросы к модели идут через легкий Genkit-бэкенд, который защищает ключи API и проверяет авторизацию. Инструменты и отладка: Genkit включает локальный Developer UI для тестирования flows, экспериментов с промптами и пошаговой проверки трассировок выполнения. genkit start -- dart run server/bin/server.dart Агентские сценарии: С момента preview Genkit Dart расширился возможностями для многошаговых агентских рабочих процессов: прерывания с участием человека, middleware для генерации, управление промптами, телеметрией на проде. Инструменты позволяют моделям вызывать Dart-функции для получения данных или выполнения действий. Когда действие требует подтверждения пользователя, инструмент может приостановить генерацию, вернув .interrupt(...) вместо .response(...). Это гарантирует, что модель не обойдет проверку. Middleware подключается напрямую в цикл генерации, чтобы перехватывать вызовы модели, внедрять инструменты или изменять запросы и ответы. Можно подключать готовые возможности вроде автоматических повторов и правил подтверждения инструментов. 🔗 Читать подробнее 💡 Вывод: Genkit Dart 1.0 - это стабильный инструмент для построения ИИ-функционала и агентов на Dart. Единый API для разных моделей, сквозная типобезопасность, поддержка агентских сценариев и телеметрии на проде. Раньше для подобных задач приходилось уходить в другие языки или собирать все вручную. Теперь ИИ-логика остается в знакомой экосистеме Dart и Flutter. Это упрощает разработку, тестирование и поддержку. Подписаться на канал: ➡️ Flutter & Dart | Мобильный трудоголик