В повседневной работе мы привыкли к Column, Row, ListView. Они закрывают большинство задач по построению интерфейсов. Но иногда требуется настоящая таблица: строки, столбцы, сортировка, постраничная навигация. И здесь у Flutter есть несколько специализированных инструментов, о которых многие забывают.
DataTable - для небольших объемов:
Если у вас предсказуемый, небольшой набор данных - идеальный вариант. DataTable строится на основе DataRow и DataCell, все объявляется декларативно. Подходит для экранов настроек, административных панелей, любых мест, где таблица не превышает десятка строк. Сортировка подключается через onSort, постраничное отображение контента - через PaginatedDataTable, которая оборачивает обычную DataTable и добавляет навигацию.
Table - полный контроль:
Если нужно управлять каждой ячейкой, задавать разную ширину колонок, рисовать границы, вставлять сложные виджеты - используйте Table. Здесь вы сами определяете каждую строку как TableRow, а внутри - список ячеек с любыми виджетами. Можно задавать ширину колонок: фиксированную (FixedColumnWidth), пропорциональную (FlexColumnWidth) или по содержимому (IntrinsicColumnWidth).
Что важно знать:
DataTable и Table - не самые популярные виджеты во Flutter, но в своих нишах они незаменимы. DataTable удобен для небольших, четко структурированных данных с сортировкой и пагинацией. Table - для кастомных макетов, где нужно полное управление шириной и содержимым ячеек. Если объемы большие или содержимое часто меняется, стоит присмотреться к другим подходам.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2🔥1
Команда Flutter опубликовала размышления о том, как искусственный интеллект влияет на развитие экосистемы. Это не дорожная карта, а скорее честный взгляд на текущую ситуацию. Потому что в 2026 году невозможно делать инструменты для разработки, не обращая внимания на ИИ.
Цифры, которые объясняют все:
Согласно опросам, 84% разработчиков в целом используют ИИ-инструменты в своей работе. Среди Flutter-разработчиков этот показатель чуть ниже - 79%, но все равно впечатляет. Однако есть проблема: 46% не доверяют точности ИИ при решении критических задач. Это тратит лишнее время на проверку сгенерированного кода.
Главные принципы:
Команда декларирует несколько ключевых правил, которым следует при развитии ИИ-направления:
Команда Flutter не пытается предсказать будущее ИИ, а экспериментирует на виду, честно говоря о своих намерениях. ИИ не станет обязательной частью экосистемы, но для тех, кто хочет его использовать, инструменты будут. И при этом никто не заставляет отказываться от традиционной разработки - это тоже полностью валидный путь. Главное - чтобы у разработчика был выбор.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🙏1👀1
В каждом проекте рано или поздно появляются серые, поблекшие импорты. Они висят, ни на что не влияют, но глаза мозолят. Ревьюеры тратят время на проверку, нужны ли они вообще. А кодовая база обрастает балластом, который никто не замечает, но всем мешает.
Одна команда, которая все решает:
В корне проекта достаточно выполнить:
dart pub get && dart fix --apply
Анализатор Dart пробежится по всем файлам, найдет неиспользуемые импорты и удалит их. Без лишних вопросов, без ручного перебора каждого файла.
Если хочется сначала посмотреть, что именно будет удалено, можно выполнить dart fix --dry-run. Покажет список изменений, но ничего не тронет.
Почему об этом вообще стоит думать:
Неиспользуемые импорты не ломают код, но они делают его грязным. Ревьюеры тратят время на проверку того, что на самом деле не используется. Линтеры и форматтеры работают хуже, когда списки импортов захламлены. А сам проект со временем становится тяжелее и менее понятным.
dart fix решает эту проблему мгновенно. Инструмент официальный, встроенный в экосистему Dart, так что никаких сторонних зависимостей тащить не нужно.
Что важно помнить:
Перед массовой чисткой лучше сделать коммит - мало ли что. Сгенерированные файлы (.g.dart) dart fix трогать не должен, они все равно перезапишутся при следующей сборке. И всегда после чистки стоит прогнать dart analyze && flutter test, чтобы убедиться, что ничего не сломалось.
dart fix --apply - это не магия, а просто правильный инструмент. Он не делает код быстрее и не добавляет новых фич. Зато он убирает мусор, который отвлекает, запутывает и создает иллюзию сложности. Если в вашем проекте есть неиспользуемые импорты - команда решит проблему за секунду. Если их нет - вы либо уже все почистили, либо просто не замечаете.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Команда Flutter объявила о заморозке изменений в библиотеках Material и Cupertino внутри основного SDK. Это первый шаг к самому масштабному архитектурному изменению в истории фреймворка - полному отделению дизайн-систем от ядра. Теперь Material и Cupertino станут обычными пакетами на
pub.dev.Какую проблему решает это изменение:
Сейчас Material и Cupertino жестко привязаны к Flutter и обновляются только с релизами SDK. Это создает несколько проблем:
После разделения библиотеки Material и Cupertino будут обычными пакетами на
pub.dev со своим версионированием и циклом обновлений.Что будет происходить дальше:
С 7 апреля все изменения в Material и Cupertino внутри Flutter заморожены. Дальнейшая разработка продолжится в репозитории flutter/packages, где появятся новые пакеты - material_ui и cupertino_ui. После выхода стабильного релиза Flutter 3.44 новые пакеты станут доступны, и разработчикам нужно будет постепенно переходить на них.
Старые библиотеки Material и Cupertino в SDK будут объявлены устаревшими в следующем релизе после 3.44 и удалены спустя какое-то время.
Flutter перестает быть фреймворком со встроенными Material и Cupertino и становится платформой, где дизайн-системы живут своей жизнью. Это не просто техническое изменение, а смена подхода: ядро SDK становится легче и стабильнее, а дизайн-системы - независимыми, с собственными циклами обновлений. Разработчики получают свободу выбора: можно использовать Material, Cupertino или свою собственную дизайн-систему. Баги теперь будут фикситься быстрее - не нужно ждать квартального релиза Flutter.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2👀1
Загружая новую сборку iOS-приложения, всегда приходится заходить в App Store Connect для нажатия на «Нет» в окне «Информация о соответствии экспортным требованиям».
Если ваше приложение не использует шифрование, то можно очень просто избавиться от ручного подтверждения при каждой загрузке сборки в TestFlight.
Для этого необходимо открыть файл Info.plist в папке /ios/Runner и добавить следующие строки:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
Что это дает:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3🔥2
Производительность Flutter-приложения напрямую зависит от того, как написан код. Лишние перестройки UI, тяжелые операции в основном потоке, неправильная работа со списками и изображениями - все это ведет к фризам, падению FPS и раздраженным пользователям. В этом посте обсудим наиболее распространенные ошибки, которые превращают быстрый фреймворк в тормознутое приложение.
Лишние перестройки UI:
Самая частая проблема - setState, который пересобирает все дерево виджетов целиком. Даже если изменился один текст, Flutter заново вызывает build() для всех дочерних элементов. В маленьком проекте это незаметно. Когда же внутри есть списки, картинки и сложные layout'ы, каждое нажатие кнопки начинает тормозить интерфейс. Решение - использовать ValueListenableBuilder, StreamBuilder или аналоги, которые обновляют только нужную часть.
Отсутствие const:
Многие забывают про const. Без него каждый rebuild создает новые объекты виджетов, даже если они идентичны предыдущим. Это увеличивает нагрузку на сборщик мусора и процессор. В больших списках или сложных UI это дает заметный прирост производительности - достаточно просто добавить const там, где это возможно.
Логика внутри build():
build() может вызываться десятки раз в секунду - при анимациях, скролле, обновлениях. Если внутри выполнять сортировку, фильтрацию или парсинг, это напрямую убивает производительность. Даже простая операция sort() на среднем списке может занимать миллисекунды, а для 60 FPS на каждый кадр есть всего 16 мс. Вся логика должна быть вынесена в initState или бизнес-слой.
ListView без builder:
Когда вы используете ListView(children: [...]), Flutter создает все элементы списка сразу, даже если пользователь видит только первые 5–10. При 100+ элементах это приводит к лишним аллокациям, перегрузке памяти и долгому первому рендеру. ListView.builder создает элементы лениво - только те, что видны на экране. Это значительно снижает нагрузку.
Отсутствие ключей:
Без key Flutter не может корректно сопоставить старые и новые элементы при обновлении списка. В результате он пересоздает виджеты вместо их обновления, что приводит к лишним rebuildам и визуальным багам - например, прыгающим элементам. ValueKey или ObjectKey решают эту проблему.
Большинство проблем с производительностью возникают не из-за сложности задачи, а из-за мелких решений, которые легко упустить в процессе разработки. Лишний rebuild, тяжелая операция в основном потоке, список без builder - каждое из этих решений кажется безобидным, пока приложение не начинает тормозить. Хорошая новость в том, что большинство описанных проблем решаются относительно просто. Главное - не откладывать это на потом.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥2❤1🙏1
В повседневной разработке часто встречаются задачи, которые можно решить красиво и без лишнего кода. Вместо того чтобы городить велосипеды, достаточно знать несколько встроенных инструментов Flutter.
LayoutBuilder - адаптивный интерфейс без хардкода:
Проблема: нужно показывать разную верстку в зависимости от ширины экрана. Многие начинают писать проверки через MediaQuery или пытаются угадать размеры устройства. Но это неправильно - важно не само устройство, а реальное место, которое виджет занимает на экране.
LayoutBuilder дает доступ к ограничениям родителя прямо во время построения. Вы можете посмотреть максимальную ширину и решить, показывать горизонтальное меню или вертикальное, две колонки или одну. Все адаптируется под текущий контейнер, а не под экран в целом.
LayoutBuilder(
builder: (context, constraints) {
if (constraints.maxWidth > 600) {
return Row(children: [sidebar, content]);
}
return Column(children: [sidebar, content]);
},
)
AnimatedSwitcher - плавные переходы между виджетами:
Смена одного виджета на другой обычно выглядит резко. Текст изменился - моргнул, иконка сменилась - тоже моргнула. AnimatedSwitcher добавляет анимацию при замене дочернего элемента. Старый виджет плавно исчезает, новый - появляется. Вы можете настроить тип перехода: затухание, сдвиг, масштаб.
Важный момент: анимация сработает только если у виджетов разные key. Иначе AnimatedSwitcher решит, что ничего не изменилось.
AnimatedSwitcher(
duration: Duration(milliseconds: 300),
child: Text(counter.toString(), key: ValueKey(counter)),
)
Все эти виджеты решают повседневные задачи: адаптивную верстку, плавную смену контента, простые анимации и оптимизацию перерисовок. Они есть в стандартной библиотеке, не требуют подключения сторонних пакетов и при этом заметно упрощают код. Если вы до сих пор писали свои велосипеды для таких случаев - попробуйте заменить их на встроенные решения.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🙏1
При разработке Flutter-приложений паттерн BLoC часто становится всемогущим объектом, впитывающим всю бизнес-логику. Внутри хендлеров оказываются и запросы к сервисам, и валидация и эмиттеры состояния. Проект разрастается, файлы раздуваются, тестирование становится невозможным. Сегодня обсудим как можно вынести бизнес-логику в отдельные классы - use-cases.
Как это работает:
Вместо того чтобы вызывать сервисы прямо внутри хендлеров BLoC, вся логика конкретного сценария (например загрузки товаров) выносится в отдельный класс. Use-case зависит от абстракций репозиториев и сервисов, но ничего не знает про UI. Он вызывает нужные зависимости, обрабатывает ошибки, выполняет side-эффекты и только после этого отправляет событие в BLoC. Сам BLoC превращается в тонкую прослойку: принимает события, обновляет состояние и больше ничего не делает.
Как это работает на практике:
Огромный BLoC-файл, отвечающий за получение данных, кэширование, фильтрацию и обновление UI, превращается в узкое место проекта. Конструктор забит зависимостями, тестирование почти невозможно. После рефакторинга BLoC сокращается до 20-30 строк, не зависит от сервисов и становится просто набором функций для обновления состояния. Все пользовательские сценарии выносятся в отдельные use-cases.
В результате время разработки нового функционала сокращается, количество багов снижается, тесты становятся надежнее.
Почему это работает:
Use-case оркестрирует несколько сервисов и репозиториев, объединяет данные, обрабатывает ошибки, логирует и только после этого отправляет событие в BLoC. BLoC остается только стейт-менеджером и не выполняет ничего, кроме преобразования событий в состояние. Такой подход соответствует принципам чистой архитектуры: доменный слой не зависит от реализации, что повышает гибкость и тестируемость.
Разделение бизнес-логики и UI - необходимость для масштабируемых приложений. Use-cases помогают структурировать код, упрощают тестирование и делают BLoC максимально простым. Этот подход не привязан к BLoC и может использоваться с любым другим стейт-менеджером.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤1👍1
Команда Flutter объявила о миграции трех основных своих сайтов (dart.dev, flutter.dev и docs.flutter.dev) на Jaspr - open-source фреймворк для создания веб-сайтов на Dart. Раньше сайты были собраны из разных технологий: документация работала на Eleventy (Node.js), а основной сайт - на Wagtail (Python + Django). Теперь все на Dart.
Почему они решили это сделать:
Старая архитектура была фрагментированной. Чтобы вносить правки или поддерживать сайты, нужно было знать
Node.js, Python и Dart одновременно. Это создавало барьер для контрибьюторов и усложняло поддержку. Кроме того, добавление интерактивных элементов (например, викторин в туториалах) требовало сложных, разовых решений.Что изменилось:
Теперь все три сайта используют единый стек на Dart. Основные изменения:
Почему так лучше:
Миграция на Jaspr - пример того, как сообщество и официальная команда совместно улучшают экосистему. Единый стек на Dart упрощает поддержку, снижает порог входа для контрибьюторов и открывает возможности для более интерактивной документации. Если вы когда-нибудь хотели попробовать веб-разработку на Dart - теперь есть отличный повод.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
Команда объявила о своем участии в десятках конференций по всему миру в 2026 году. Цель - не просто показать доклады, а лично пообщаться с разработчиками, увидеть демо вживую и собрать обратную связь. Это хорошая возможность для всех, кто давно хотел задать вопрос команде или поделиться своим мнением.
Где и когда:
В апреле стартует Google Cloud Next в Лас-Вегасе. В мае - Flutterconf в Испании, Google I/O в Саннивейле и Flutter Flow Developers Conference в Сан-Франциско. Летом команда будет в Праге, Варшаве, Берлине, Бангалоре и Орландо. Осенью - в Стокгольме, Канкуне, Берлине, Токио и других городах. Полный список обновляется на странице событий Flutter.dev.
Если вы не можете приехать - не проблема:
Многие из перечисленных конференций транслируются онлайн, а их записи потом выкладывают в открытый доступ. Это означает, что вы можете посмотреть доклады команды Flutter, не выходя из дома - прямо во время трансляции или в удобное время после. Так что даже если вашего города нет в списке, вы все равно сможете узнать обо всех новинках и важных новостях.
Почему это важно:
Flutter - это огромное сообщество. Команда говорит, что самые яркие моменты ее карьеры связаны с живым общением на ивентах. Они хотят слышать не только через баг-репорты и пул-реквесты, но и лично. Это важно для развития фреймворка.
Кроме того, участие в конференциях - способ показать, что Flutter развивается, становится все более кроссплатформенным и готов к сложным, ресурсоемким задачам.
Если вы давно хотели встретиться с командой Flutter, задать вопрос или просто посмотреть на живые демо - теперь у вас есть такая возможность. Список конференций на 2026 год уже опубликован, и он довольно обширный. А если не можете приехать - ищите онлайн-трансляции и записи. Следите за обновлениями на сайте Flutter.dev.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1🗿1
Всем привет! Сегодня хочу разобрать интересную статью про судьбу Flutter после увольнений в Google. В апреле 2024 года Google уволил инженеров из команд Flutter, Dart и Python - за несколько недель до Google I/O, где традиционно анонсировали светлое будущее. Тогда было много паники и постов «Flutter умер». Прошло два года. Flutter не умер. Но и не остался прежним. Пора без истерик разобраться, что на самом деле изменилось.
Что тогда произошло:
Увольнения затронули в основном DevOps и инфраструктуру, а не разработчиков самого фреймворка. План развития продукта не изменился. Но сообщество правильно прочитало сигнал: для Google Flutter - больше не стратегический приоритет, а просто поддерживаемый продукт. Разница огромная. Стратегическому приоритету выделяют лучших инженеров, лоббируют внутри компании, вкладывают ресурсы. Поддерживаемому продукту - фиксят критические баги, но новых горизонтов не открывают.
Что случилось потом:
Flutter продолжил выпускать релизы. Impeller стал стабильным. Дорожная карта 2024 года выполнена. BMW, Alibaba и eBay все еще используют Flutter на проде. Опрос Stack Overflow 2024 показал 46% использования среди кроссплатформенных фреймворков - больше, чем у React Native (35%).
Но вот что важно: Тим Снит (многолетний руководитель разработки Flutter, лицо проекта на I/O) ушел в Apple в 2023 году. Брэндон ДеРозье (создатель Impeller) в 2025 году перешел в команду Android XR. Это не увольнения. Это добровольные уходы ключевых людей. И они сигнализируют о том, что даже внутри Google самые талантливые инженеры перестали видеть будущее за Flutter.
Почему я все еще использую Flutter:
Фреймворк работает. Для 90% задач кроссплатформенной разработки - стабильно, быстро, предсказуемо. Сообщество огромное, уже более 50 000 пакетов на
pub.dev. Релизы выходят четыре раза в год. С точки зрения инженерной реальности Flutter не стал хуже.Но соотношение затрат и выгод изменилось. Теперь нужно задавать себе другие вопросы.
Используйте Flutter там, где он подходит. Понимайте свои зависимости и риски. Не принимайте архитектурные решения по звездам на GitHub и по рекомендациям от ИИ. Релевантный показатель один: решает ли фреймворк вашу проблему сегодня и есть ли у него разумный путь поддержки на три года вперед. По этому показателю Flutter проходит проверку. Не на отлично. Не так уверенно, как в 2021 году. Но проходит. Те, кто ожидает немедленного краха, ошибаются. Те, кто утверждает, что все осталось по-прежнему, тоже ошибаются. Правда, как обычно, посередине: Flutter - рабочий инструмент, но теперь его стоит выбирать с открытыми глазами, понимая, что уровень поддержки со стороны Google может и дальше снижаться.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1👀1
Привет! Наткнулся на статью, где автор подробно рассказывает, как добавить собственную вкладку в Dart DevTools и настроить взаимодействие с запущенным Flutter-приложением. Оказывается, это не так сложно, как кажется.
С чего начать:
Первым делом создается новый пакет под расширение. Официального шаблона нет, поэтому структуру добавляют вручную. В корне пакета создается папка devtools, внутри - build и файл конфигурации
config.yaml. В конфиге указываются имя, версия, иконка для вкладки и трекер ошибок:Файл config.yaml:
name: my_dev_tools_ext
issueTracker: https://...
version: 0.0.1
materialIconCodePoint: '0xe0b1'
requiresConnection: false
Для работы расширения нужен пакет devtools_extensions. Он дает доступ к менеджерам: extensionManager (взаимодействие с DevTools), serviceManager (доступ к VM-сервису) и dtdManager (связь с Dart Tooling Daemon).
Интерфейс и тестирование:
Сами виджеты можно собирать из готовых компонентов пакета devtools_app_shared. Например DevToolsButton уже имеет стиль, подходящий для интерфейса DevTools, а через extensionManager.showNotification можно показывать уведомления.
Для отладки расширения используется симулированная среда:
flutter run -d chrome --dart-define=use_simulated_environment=true
Перед публикацией сборка создается командой build_and_copy, а проверить корректность структуры можно через validate.
Два типа расширений:
Расширения DevTools открывают интересные возможности для создания инструментов отладки, визуализации состояния и даже управления приложением в рантайме. Статья дает хороший практический старт: от создания пакета до выполнения произвольного Dart-кода на живом приложении. Если вы когда-нибудь хотели добавить свою вкладку в DevTools - это вполне реально.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2🙏1
Обычный строковый поиск работает только при точном совпадении. Одна лишняя буква, опечатка или другой падеж и результат пустой. В этой статье автор разбирает, как реализовать локальный поиск, который понимает, что пользователь имел в виду, даже если ввел с ошибкой.
Почему простое вхождение не работает:
Пользователи часто ошибаются. Вместо «Арбатская» пишут «Орбатская», вместо «Петровка» - «Питровка». Простой поиск по вхождению подстроки такие запросы игнорирует. А отправлять каждый запрос на сервер - долго и не всегда возможно.
Что такое расстояние Левенштейна:
Это число, которое показывает, сколько операций нужно, чтобы превратить одну строку в другую. Операции - вставка, удаление, замена символа. Например, «кот» -> «код»: одна замена символа, расстояние = 1. «Австрия» -> «Австралия»: нужно добавить две буквы, расстояние = 2.
Для поиска удобнее использовать нормализованное значение от 0 до 1, где 0 - полное совпадение, 1 - строки разные.
Более точный вариант - расстояние Дамерау‑Левенштейна:
Оно добавляет еще одну операцию - перестановку соседних символов. Это одна из самых частых опечаток: «годки» вместо «годик». Обычное расстояние Левенштейна даст 2, а расстояние Дамерау‑Левенштейна - 1, потому что достаточно переставить буквы.
Как это реализовать во Flutter:
Автор приводит пример поиска по адресам и станциям метро. Алгоритм:
Такой поиск имеет смысл не везде. В идеале - отдать поиск на бэкенд, если он это умеет. Если нет и приходится искать локально, расстояние Дамерау-Левенштейна может спасти ситуацию. Но не ждите чудес: алгоритм требовательный к ресурсам, а порог совпадения придется подбирать вручную.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1🔥1
Начиная с релиза Flutter 3.44, Swift Package Manager (SPM) заменяет CocoaPods как стандартный менеджер зависимостей для iOS и macOS. Это означает, что больше не нужно возиться с установкой Ruby или настройкой CocoaPods, чтобы просто запустить приложение.
Почему CocoaPods уходит:
CocoaPods официально переведен в режим поддержки без активного развития. Его реестр станет доступен только для чтения 2 декабря 2026 года. Существующие сборки продолжат работать, но новые версии пакетов добавляться уже не будут. Flutter переходит на решение, которое официально поддерживает Apple, чтобы приложения продолжали получать обновления зависимостей и имели доступ к экосистеме Swift-пакетов.
Что будет с приложениями:
Flutter CLI автоматизирует переход. При сборке или запуске iOS / macOS приложения CLI сам обновит Xcode-проект для использования SPM. Если приложение использует плагины, которые еще не перешли на SPM, Flutter выдаст предупреждение и временно использует CocoaPods для таких плагинов.
В случае критических проблем можно временно отключить SPM в
pubspec.yaml:flutter:
config:
enable-swift-package-manager: false
Но компания просит сообщать о таких проблемах, чтобы успеть их исправить до полного удаления CocoaPods.
Переход на SPM - неизбежный шаг. CocoaPods устарел, и поддержка его заканчивается. Для разработчиков приложений процесс в основном автоматический. А вот авторам плагинов предстоит работа - иначе их пакеты станут несовместимыми и потеряют позиции на pub.dev. Лучше заняться этим сейчас, а не ждать, когда CocoaPods окончательно отключат.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2❤1
Команда Flutter представила Agent Skills - специальные инструкции, которые делают ИИ-ассистентов более компетентными в разработке на Flutter и Dart. Это не просто документация, а готовые сценарии для типовых задач: локализация, адаптивная верстка, интеграционные тесты, использование новых возможностей языка.
Зачем это нужно:
ИИ-агенты хороши в общих вопросах, но для профессиональной Flutter-разработки этого мало. Нужно понимать нюансы локализации, правильно применять свежие фичи Dart, настраивать интеграционные тесты. Skills закрывают этот пробел.
Важное отличие от MCP: Model Context Protocol дает агентам инструменты (молоток и гвозди), а Skills учат, как этими инструментами пользоваться (чертеж и навыки строителя). Skills также экономят токены благодаря «прогрессивному раскрытию» - агент подгружает инструкции только тогда, когда они действительно нужны.
От теории к практике:
Ранние эксперименты показали: Skills, которые просто дают документацию, не так полезны. Документация Flutter и так открыта и современные модели неплохо умеют находить нужную информацию. Поэтому команда сделала Skills задаче-ориентированными - они учат агента выполнять конкретные действия.
Что уже доступно:
Примеры Skills из открытых репозиториев:
Agent Skills - шаг к тому, чтобы ИИ-ассистенты перестали быть просто умными поисковиками и стали реальными помощниками в конкретных задачах. Пока доступен базовый набор, но команда обещает расширять его вместе с сообществом. Agent Skills не превратят ИИ в сеньора, но избавят от необходимости каждый раз объяснять, как настроить локализацию или собрать покрытие тестами.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥2🙏1
Привет! Наткнулся на интересную статью, где разработчики из Яндекса рассказывают, как они создали свой пакет для навигации во Flutter. Проблема знакомая: проект растет, появляются табы, вложенные модули, диплинки, а стандартные решения перестают работать. В итоге они написали свое решение и поделились им со всеми.
В чем суть:
Основная идея yx_navigation в том, что состояние навигации - это не стек, а дерево узлов RouteNode. Каждый узел содержит маршрут, параметры и список дочерних узлов. Все просто: добавил узел - экран появился, убрал - исчез.
Какую проблему решает:
yx_navigation - не очередная обертка над Navigator 2.0, а решение, выросшее из реальных проблем крупного проекта. Пакет подойдет тем, кто уперся в ограничения go_router, кому надоело ждать кодогенерацию в auto_route и кто хочет управлять навигацией без привязки к UI и менять состояние даже в неактивных вкладках.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥2👍1
Вышла новая версия Flutter 3.44. На первый взгляд - очередной плановый релиз. Но на самом деле это один из самых стратегически важных апдейтов за последние годы. Два главных изменения: Swift Package Manager становится стандартом для iOS/macOS, а Material и Cupertino начинают отделяться от ядра фреймворка.
Swift Package Manager вместо CocoaPods:
Долгие годы Flutter-разработчики под iOS мучились с Ruby-окружением, pod install и конфликтами версий. С выходом 3.44 SPM включен по умолчанию даже на стабильной ветке. Flutter теперь сам генерирует Swift-пакеты для Add-to-App, диагностирует несовместимые плагины и предупреждает о конфликтах между CocoaPods и SPM. CocoaPods официально уходит в историю.
Material и Cupertino отделяются от ядра:
Второе крупное изменение - библиотеки Material и Cupertino постепенно выносятся из основного SDK в отдельные пакеты material_ui и cupertino_ui. Это значит, что дизайн-системы смогут обновляться независимо от релизного цикла Flutter (раз в три месяца). В будущем приложения смогут не включать целые UI-библиотеки, если они не используются. Это шаг к модульности и уменьшению размера приложений.
Другие изменения:
Android - HCPP и predictive back:
HCPP - это новая стратегия для платформенных вьюх (WebView, карты). Вместо того чтобы рендерить их через offscreen-буферы, Flutter теперь делегирует композицию напрямую Android OS через Vulkan. Результат: плавный скролл, правильная обработка касаний и поддержка SurfaceView.
Web - производительность и доступность:
Flutter Web получил reduced motion support, улучшения accessibility, фиксы для Firefox, оптимизации CanvasKit и Skwasm. Генерация мусора теперь унифицирована, а шрифты загружаются быстрее.
Flutter 3.44 закладывает фундамент, который изменит экосистему в ближайшие годы. Переход на SPM окончательно избавляет iOS-разработку от Ruby-зависимостей и делает сборку предсказуемее. HCPP и Impeller улучшают производительность на Android и iOS. А отделение Material и Cupertino от ядра открывает дорогу к легким, модульным приложениям, которые включают только нужные компоненты.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤2👍1
Вместе с новой версией Flutter 3.44 команда также выпустила Dart 3.12. Обновление не самое революционное, но несколько приятных изменений в языке и экосистеме все же есть.
Приватные именованные параметры:
Раньше нельзя было написать конструктор с параметром, начинающимся на underscore. Если поле приватное, приходилось городить список инициализации:
class Bird {
final String _name;
Bird({required String name}) : _name = name;
}Теперь можно короче:
class Bird {
final String _name;
Bird({required this._name});
}Снаружи параметр остается публичным - underscore автоматически отбрасывается. Мелочь, но приятная.
Первичные конструкторы (эксперимент):
Одна из самых ожидаемых фич. Позволяет объявлять класс одной строкой:
class Point(final int x, final int y);
Вместо:
class Point {
final int x;
final int y;
Point(this.x, this.y);
}Пока это экспериментальная функция, доступная с флагом --enable-experiment=primary-constructors. Если фича приживется, классы в Dart станут заметно лаконичнее.
Genkit Dart в превью:
Open-source фреймворк для создания ИИ-приложений на Dart и Flutter. С единым API для Google Gemini, Anthropic Claude и OpenAI. Можно писать логику один раз и запускать где угодно - на сервере или прямо в приложении. Плюс локальный UI для отладки промптов и трассировок.
Agentic Hot Reload:
Еще одно нововведение - горячая перезагрузка для ИИ-агентов. Через Dart MCP сервер агент сам подключается к запущенному приложению, вносит изменения и перезагружает UI. Без ручного копирования URI и настройки DTD.
Dart 3.12 - не про революцию, а про эволюцию. Язык становится удобнее, экосистема обрастает ИИ-инструментами, а горячая перезагрузка для агентов упрощает работу с нейросетями в коде. Основные конструкторы пока экспериментальны, но их появление говорит о том, что команда думает в правильном направлении.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2❤1
Flutter скрывает от разработчика ручное управление памятью. Кажется, что сборщик мусора все сделает сам. Но на практике утечки случаются регулярно. Экран закрыт, а какие-то объекты продолжают висеть в памяти. После нескольких переходов туда-сюда приложение начинает тормозить, а на слабых устройствах - вылетать. Это не баг фреймворка, это ошибки в коде, которые можно и нужно контролировать.
Откуда берутся утечки:
Чаще всего проблема в том, что объект создается, но не освобождается. Экран ушел, а контроллеры, подписки, таймеры или слушатели продолжают жить. Они держат ссылки на другие объекты, а те - на виджеты. В итоге память не отдается системе.
Контроллеры и dispose:
TextEditingController, ScrollController, AnimationController, FocusNode - все это нужно уничтожать в dispose(). Если этого не делать, каждый открытый экран будет оставлять после себя мусор. Правило простое: создал в initState - удали в dispose.
Подписки на Stream и слушатели:
StreamSubscription, addListener у ChangeNotifier и ValueNotifier - это классические источники утечек. Если подписался, но не отписался, поток будет слать события в уже мертвый экран. А заодно удерживать его в памяти. Решение: сохранять подписку и отменять ее в dispose.
BLoC и другие сущности с жизненным циклом:
Если BLoC создается прямо внутри State, нужно не забыть вызвать close(). Удобнее использовать BlocProvider, который сам управляет жизненным циклом. Главное правило: кто создал, тот и закрывает.
Таймеры:
Timer.periodic запускает повторяющиеся задачи. Если не отменить таймер при уходе с экрана, он будет продолжать тикать, вызывать setState и держать экран в памяти. Всегда сохраняйте ссылку на таймер и вызывайте cancel() в dispose.Сохраненный BuildContext:
BuildContext нельзя хранить в сервисах, синглтонах или долгоживущих объектах. Он привязан к дереву виджетов. Хранив его надолго, вы случайно удерживаете в памяти целую часть интерфейса. Лучший способ - передавать контекст только в момент вызова, не сохраняя его.
Кэши без ограничений:
Кэш - это тоже утечка, если он растет бесконтрольно. Изображения, модели, результаты запросов - все это копится в памяти, если вовремя не чистить. Простое решение: ограничить размер кэша или очищать его при выходе пользователя.
Утечки памяти во Flutter - это не магия, а следствие забытых dispose, cancel и removeListener. Они не видны сразу, но накапливаются со временем. Самый надежный способ - профилактика: иметь чек-лист для код-ревью и периодически прогонять подозрительные сценарии через DevTools. Если относиться к dispose как к обязательной части работы с экраном, большинство проблем можно поймать еще до релиза.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🔥1
Диплинки позволяют открывать приложение по ссылке - перешел по URL и сразу попал на нужный экран. Смена пароля по ссылке из письма, открытие конкретного видео или поста, переход на карточку товара по ссылке - все это работает через deeplinks. Во Flutter нет единого решения, потому что механизм завязан на платформу. Придется настраивать Android и iOS отдельно, но это не так страшно, как кажется.
Для обработки ссылок внутри Flutter удобнее всего использовать пакет app_links. Он официально поддерживается, работает на всех платформах.
Добавляем пакет в проект:
Для добавления пакета в проект можно выполнить команду в терминале:
flutter pub add app_links
Либо добавить следующую строку в блок dependencies в файле
pubspec.yaml:
app_links: ^7.1.1
Настройка для Android:
В файле android/app/src/main/AndroidManifest.xml внутри <activity> нужно добавить intent-filter. Это правило, которое говорит системе что нужно обрабатывать ссылки такого вида.
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" android:host="your-domain.com" />
</intent-filter>
Если используете кастомную схему (не http/https), укажите ее вместо https.
App Links (https):
Для автоматического открытия ссылок в приложении нужно:
Пример файла
assetlinks.json:
[
{
"relation": [
"delegate_permission/common.handle_all_urls"
],
"target": {
"namespace": "android_app",
"package_name": "com.example.yourapp",
"sha256_cert_fingerprints": [
"ваш SHA256 отпечаток"
]
}
}
]
SHA256 можно получить из Google Play Console или сгенерировать через keytool.
Настройка для iOS:
Custom scheme:
Добавьте схему в Xcode: откройте
Info.plist как исходный код и добавьте:
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>myapp</string>
</array>
</dict>
</array>
Universal Links (https):
Нужно:
applinks:your-domain.com..well-known.Пример файла apple-app-site-association:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAMID.com.example.yourapp",
"paths": ["*"]
}
]
}
}
TEAMID можно найти в Apple Developer Account.
Диплинки во Flutter настраиваются в несколько этапов: правим манифест на Android, добавляем entitlements на iOS, кладем файлы на сервер, а в коде используем app_links для получения ссылок и Navigator для переходов. app_links берет на себя всю сложность получения deeplink на обеих платформах. Вам остается только подписаться на поток и написать логику переходов.
После правильной настройки приложение будет корректно открываться по ссылкам из писем, мессенджеров или браузера. Главное не забыть протестировать все сценарии и убедиться, что файлы
assetlinks.json и apple-app-site-association доступны по правильным адресам.Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2🙏1
Во Flutter анимации - это красиво, но если ими не управлять, они могут съедать ресурсы даже тогда, когда их никто не видит. Сегодня разберем два инструмента, которые помогут анимациям не тормозить интерфейс и не работать впустую.
AnimatedBuilder - перерисовываем только то, что нужно:
По умолчанию при каждом кадре анимации перестраивается весь виджет, который содержит AnimationController. Если внутри есть тяжелые элементы, это бьет по производительности.
AnimatedBuilder решает эту проблему. Он разделяет анимируемую часть и статический контент. Статический контент передается через параметр child и не пересоздается при каждом кадре. Перерисовывается только то, что реально меняется.
AnimatedBuilder(
animation: _animationController,
child: Container(
width: 300,
height: 300,
color: Colors.blue,
child: const Center(child: Text('Привет!')),
),
builder: (context, child) {
return Transform.rotate(
angle: _controller.value * 2 * pi,
child: child,
);
},
)
TickerMode - останавливаем анимацию, когда ее не видно:
Если пользователь свернул приложение или переключился на другой экран, а анимация продолжает работать, это пустая трата ресурсов процессора и батареи.
TickerMode позволяет отключать все анимации в определенной части дерева виджетов. Достаточно обернуть нужный участок и передать enabled: false. Все AnimationController, связанные с TickerProviderStateMixin, автоматически приостановятся.
TickerMode(
enabled: _isActive,
child: MyWidget(),
)
AnimatedBuilder помогает не перерисовывать статику при каждом кадре, а TickerMode - не тратить ресурсы на анимацию, которую никто не видит. Вместе они делают приложение плавнее и экономичнее. Если вы используете анимации в своих проектах, эти два виджета должны быть в вашем арсенале.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3❤1