Flutter *

Привет, Хабр! Мне 50 лет, я инженер‑теплотехник с многолетним стажем. Работаю в компании которая занимается производством блочных тепловых пунктов. Моя повседневная работа — это проектирование разделов АТМ в AutoCAD,и программирование реле ПР200 от «Овен» в связке с панелями EKF для наших шкафов управления.

В какой‑то момент я поймал жесткий профессиональный кризис. Когда ты закрываешь объекты один за другим, а алгоритмы автоматизации превращаются в конвейер, мозг начинает выгорать. Мне наскучило писать одни и те же блоки логики и рисовать типовые экраны на панелях. Захотелось амбициозной, сложной задачи, которая заставит извилины шевелиться, и даст то самое забытое чувство: «Я смог это сделать!».

Я не профессиональный программист, но я умею ставить задачи. Объединив свой опыт в КИПиА с возможностями современных нейросетей, я в одиночку разработал универсальное для наших шкафов управления мобильное приложение на Flutter/Dart, которое может подключаться к ПР200 или любому другому Modbus устройству тремя различными способами. И после подключения на экране смартфона вы получаете своего рода мини SCADA систему для настройки, контроля и управления контроллером в шкафу.

Ниже я подробно расскажу об архитектуре этого решения, и почему ИИ — это лучший «цифровой джун» для опытного инженера.

«У меня игра на Flame, можно ли добавить в неё 3D?». Можно, и игру не придётся переписывать: корабль летает по трёхмерному двору со светом и тенями, а джойстик, HUD и вся игровая логика остаются на Flame. У двух движков одни часы, одна физика и один ввод, поэтому таран, который посчитала 3D-физика, приходит во Flame обычным onCollisionStart. Я разберу по шагам небольшую аркаду на flame_flutter3d, покажу рецепты, которые можно брать в свою игру, и неочевидные места, на которые наступил сам. В аркаду можно сыграть прямо в браузере.

Прошлый раз я писал про то, как заложил в схему БД поля под синхронизацию, которой пока нет. Синхронизации до сих пор нет, зато вышли два обновления: 0.2.0 и 0.2.1. В этой статье про три вещи, на которых пришлось подумать: переносимую папку с данными, бэкапы и импорт из Notion и Obsidian. Nookly — локальное приложение для заметок на Flutter: страницы, блоки, таблицы, канбан, поиск. Данные лежат в SQLite на устройстве, без облака.

Flutter позволяет создавать выразительные многоплатформенные приложения из единой кодовой базы. Независимо от того, разрабатываете ли вы панель управления, инструмент для своей команды или полноценное веб-приложение, Flutter Web дает вам возможность адаптировать ваше приложение для любого браузера.

С 17 по 21 августа мы проводим Неделю тестирования Flutter Web с WebAssembly ! В течение недели инженеры Dart и Flutter будут в режиме реального времени обрабатывать поступающие запросы, чтобы помочь в миграции, а наша команда по связям с разработчиками будет делиться вашими успехами в каналах сообщества.

Полгода назад я в одиночку начал делать Nookly — локальное приложение для заметок на Flutter: страницы, блочный редактор, таблицы с канбан-видом, полнотекстовый поиск. Ключевое требование с самого начала: всё работает офлайн, данные не покидают устройство. В этом посте — не про сам продукт, а про два инженерных решения, которые могут быть полезны: как спроектировать схему БД так, чтобы синхронизация потом не потребовала переписывания половины кода, и как собрать лендинг вообще без шага сборки.

Неделю назад я писал, почему видео из аниме-плеера нельзя просто вставить в <video>. Вывод был такой: нужен серверный видеопрокси, и никуда вы от него не денетесь.

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

Под катом: что именно делал сервер, почему на Android его нет, и что оказалось не переносом библиотеки с Python на Dart, а её переписыванием — вместе с багом, который жил в оригинале, стрелочной функцией в Dart, из-за которой whenComplete начинает ждать сам себя, и релизом, который подписывает не человек.

Гайдлайны Apple, Android и Flutter по-разному, но одинаково настойчиво подталкивают задавать переход прямо в коде экрана — в документации go_router это штатный пример. В результате экран отвечает и за интерфейс, и за навигацию: его трудно переиспользовать, он знает про следующие экраны, а модульный тест превращается в интеграционный.

В статье — приём, который выносит переход из кода виджета туда, где для решения есть вся информация: экран сообщает о запросе пользователя, а решение принимает роутер вкладки или приложения. Одна и та же задача (две вкладки со своими стеками и общий экран, который в каждой вкладке ведёт себя по-своему) решена трижды: на штатном Navigator, на go_router и на auto_route.

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

Если у вас в зависимостях есть SDK RuStore или VK — проверьте адрес Maven-репозитория: 30 сентября и 1 октября старые отключаются, а часть библиотек всё ещё ведёт на них. Ниже — таблица с конкретными файлами и строками, которые ещё не обновлены, и несколько историй о том, как я чинил SDK VK и RuStore под Flutter 3.47 и AGP 9 и присылал вендорам патчи.

Поехали.

Вообще говоря, я всегда делал бэкенд исключительно на PHP. Я считаю его отличным языком для бэкенда, вернее не только для бэкенда, а отличным языком. Некоторые не любят PHP за малый порог вхождения. Типа через этот малый порог вхождения входит очень много непрограммистов, которые потом пишут говнокод. Но я придерживаюсь мнения, что PHP никак не виноват в этом. Скорее наоборот. На PHP логика просыпается даже у тех, кто кроме говнокода ничего написать не может. Поэтому в любом случае это отличный язык программирования, который каждый год хоронят, но никак похоронить не могут. И в 2026 году он живее всех живых и показывает отличные результаты.

Вторым в списке для сравнения я решил поставить Дарт. Дело в том, что самое узкое место применения Дарта — это как раз-таки применение на серверах. Потому что в мобильной разработке он уже как стандарт, веб, фронтенд мало-мальцевски он тоже подтягивает. Но вот на серверах пока что его используют очень мало. Одна из причин на то, что его мало используют на серверах, — это отсутствие библиотек, таких как, например, есть у PHP. Но, тем не менее, это совсем не значит, а тем более сейчас в эпоху LLM, это совсем не значит, что Дарт негоден на серверах. Как покажет сравнение, он очень-таки годен.

Третий кандидат для сравнения — это C++. Это его фреймворк Drogon, который в каком-то там 2014 или 2015 годах взлетел как самый быстрый фреймворк для серверов на бэкенде по скорости. Если честно, я ни разу не писал бэкенд на C++, поэтому это была первая попытка. Просто хотелось посмотреть, как C++ уничтожит двух других оппонентов со своей 100x производительностью.

Чтобы человек навёл камеру на пачку гречки и получил название, вес и калории, нужна база штрихкодов российских продуктов. Я был уверен, что она где-то есть. Её нет. Что проверял живыми запросами, почему каталоги сетей не взять, как чек ОФД заменяет каталог и как в итоге устроен справочник на 258 тысяч позиций, который растёт ровно на то, что люди сканируют.

Почему миллионы начинающих пользователей боятся «нажать не туда», а видеоуроки не формируют практических навыков? Рассказываю, как создала интерактивный симулятор настольных ОС (Windows 10, 11 и Linux) с уроками и мини-играми и как это помогает безопасно осваивать компьютерную грамотность прямо со смартфона.

В первой части мы разобрали, как Dart отличает число от объекта, а во второй – как убирается молодое поколение. Там все держалось на одном приеме: живых переносим в соседнее полупространство, а всю старую половину выбрасываем целиком.

Почему в старом поколении переезд не подходит

В молодом поколении все было просто – отбрасываем мертвые объекты и забываем про них, в старом поколении все по-другому. Для старого поколения такая операция слишком дорогая. Количество живых объектов больше, чем неживых, а это значит, что нам бы пришлось копировать почти всю память с места на место. Также необходимо было бы держать вторую половину пространства запасам такого же размера как и занятую часть полупространства. Для решения этой проблемы существует mark-sweep (Пометка-очистка).

Привет, это команда ОС Аврора.

У нас есть проблема, о которой не принято говорить в блоге вендора, но без неё вся эта история не имеет смысла. Про Аврору мы регулярно слышим одно и то же: платформа хорошая, но приложений мало, а переносить на неё уже готовые приложения с Android сложно и дорого. Пет-проект — ладно. Корпоративное приложение — тоже: их у нас уже много, просто они живут внутри закрытых контуров, и вы их не видите. А вот массовое приложение, которому для существования нужна миллионная аудитория, вроде бы обречено: никто не станет переписывать миллион строк legacy-кода ради новой платформы.

Дальше разговор обычно упирается в одну и ту же фразу: у нас всё нативное. Kotlin, Swift, годы накопленного кода, и переписывать это долго и дорого. Кроссплатформа есть далеко не у всех.

Тем, у кого она есть, нам уже давно есть что ответить: Flutter под Аврору поддерживается официально, Compose Multiplatform — тоже, и такие команды переезжают без драмы. А вот всем остальным мы до недавнего времени могли предложить только сочувствие.

Теперь, в эпоху ИИ, появился инструмент мощнее любого SDK и было бы странно его не попробовать. Поэтому мы взяли чужое большое приложение, позвали внешнего эксперта, которого никак не контролируем, и договорились опубликовать результат независимо от того, каким он получится.

С появлением Flutter GPU у Dart-разработчиков впервые появился прямой доступ к Metal и Vulkan без единой строчки нативного кода. Чтобы понять, готов ли новый API к настоящим 3D-играм, я написал над ним движок на чистом Dart: сцена, PBR-освещение, каскадные и кубические карты теней, HDR-конвейер и три взаимозаменяемых графических бэкенда (Flutter GPU, WebGL2 и программный растеризатор), плюс три законченные игры, играбельные прямо в браузере. В статье разбираем границы Flutter GPU, устройство движка и самые дорогие грабли, собранные по дороге.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

Теперь можно управлять машинкой в пределах комнаты, но для выезда за её пределы, хотелось видеть, куда движется устройство на экране. Чем я и начал заниматься дальше.

По пути на презентацию я в очередной раз просматривал функции приложения и заметил небольшой баг. Ноутбука под рукой не оказалось, а исправить его нужно было срочно. Вспомнил про тестовый стенд с онлайн-IDE, развернул там нужные инструменты и прямо с планшета оперативно поправил код.

Я мог бы закончить историю на этом, но идея мобильной разработки не давала мне покоя: получается, имея под рукой планшет с большим экраном, вы можете организовать полноценный рабочий процесс. Правда, инструменты для сборки, тестирования и работы с SDK обычно выпускают только для ПК. А можно ли скомпилировать код прямо на смартфоне? Можно — например, в ALT Mobile или «Авроре ОС», если установить дополнительные пакеты.

В статье я подробно расскажу, как развернуть облачную среду разработки, привязать ее к планшету и написать собственный плагин для автоматизации сборки под «Аврору ОС».

Всем привет! Меня зовут Милена, я бэкенд‑инженер на Java в Банки.ру. Полтора года назад я вызвалась написать мобильное приложение для команды, в которой не было ни одного мобильного разработчика. За три месяца мы его выпустили, оно работало на обеих платформах, и я закрыла для себя вопрос, ради которого во все это ввязалась «понравится ли мне мобильная разработка» — спойлер: ответ оказался «нет».

Мой рассказ о том, как я взялась за незнакомую технологию в одиночку без Flutter‑разработчика рядом в супер‑сжатые сроки.

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

Продолжаю рассказывать о том, как делаю ровер с управлением по сети.

Основные условия к проекту - это возможность собрать ровер из готовых модулей, которые можно найти на известных площадках, прошить микроконтроллер простым drag-and-drop и записать OS на SD Card.

История о том, как я пытаюсь сделать ровер.