Разработка мобильных приложений *

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

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

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

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

Фаза загрузки в моём тесте bufferbloat не нагружала линию: speed.cloudflare.com отвечал на запрос гигабайта кодом 403 и одним байтом, а код этого не замечал. Как это исказило вердикты, как ошибка всплыла при скорости 0.0000008 Мбит/с и почему генератор нагрузки обязан измерять собственную нагрузку.

У меня есть коллекция музыки, которой нет ни в одном стриминге: FLAC, японские альбомы, редкие релизы. Слушать её хотелось так же удобно, как Spotify, с телефона и компьютера, с текстами и итогами года. Готовые решения закрывали задачу по кусочкам, поэтому я написал своё: Nami — плеер для Android, Windows и Linux и собственный сервер на Rust. Внутри: синхронизация между устройствами через одну SQL‑таблицу вместо девяти, караоке‑тексты с выравниванием по словам нейросетью прямо на телефоне, фуригана и ромадзи для японских песен, bit‑perfect‑вывод на USB‑ЦАП и сервер, который занимает 69 МБ памяти.

Мой телесуфлёр для Android называется Суфлёр. Он распознаёт речь на телефоне и прокручивает текст по голосу поверх Instagram, TikTok или системной камеры. Во время записи видео Android отдаёт микрофон камере, и Суфлёр получает звук параллельно с ней через службу специальных возможностей. Такое исключение описано в разделе 5.4.5 Android CDD. Место в сценарии Суфлёр находит, выравнивая восемь последних распознанных слов по всему тексту. Ещё в статье есть правила, которые понадобились трекеру для английского языка.

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

Когда говорят об автоматизации закупок, обычно вспоминают электронные торговые площадки, аналитику, интеграции, API, автоматическую обработку документов и, конечно, искусственный интеллект. Но до всего этого существует гораздо более простая задача: как среди большого потока закупок найти несколько процедур, которые действительно подходят конкретной компании?

На первый взгляд это обычная задача поиска по структурированной базе. У закупки есть название, заказчик, регион, начальная цена, сроки подачи заявок, классификаторы и другие параметры. Кажется, что достаточно проиндексировать данные, добавить несколько фильтров и показать пользователю результаты. На практике оказалось, что основная сложность начинается именно после этого.

Мы работаем с государственными и коммерческими закупками больше 11 лет, поэтому при проектировании системы поиска могли отталкиваться не только от структуры данных, но и от того, как подрядчики действительно выбирают новые контракты. И довольно быстро выяснилось: профессиональный тендерный специалист и собственник небольшой компании смотрят на одну и ту же закупку совершенно по-разному.

В новом выпуске почему игры лагают и как я всё‑таки опубликовать игру в Google Play из России, iPhone Duo для iOS-разработчика и кросс-компиляция под Android, Flutter Web с WebAssembly Week, ИИ-агент для мобильного тестирования в hh.ru, биологическая лаборатория Anthropic, новые премиальные Googlebook на Android и многое другое. Заходите!

Два месяца, восемь раундов проверки Apple: два реджекта App Review и два реджекта нотаризации для альтернативного маркетплейса. Что выяснилось: контент на нотаризации действительно не смотрят - механика, зарубленная в App Store по Guideline 1.2, прошла четыре раза. Но формальные гайдлайны применяются: нас отклонили по 2.1 (ключ ATT без промпта) и по 4.8 (ревьюер открыл нашу веб-страницу входа и потребовал Sign in with Apple). Плюс цифры по срокам из App Store Connect: первая нотаризация шла неделю, последняя - 3 часа 46 минут.

Перевод статьи о QA-трансформации в крупном брокере: от ручных проверок к умному workflow. История о том, как тестирование было перестроено вокруг LLM: реальный стек, примеры пропущенных требований и разбор того, где ИИ ошибается. И да, человек всё ещё очень нужен.

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

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

Привет!

15 июля истёк срок, который ФАС дала Apple на предустановку RuStore и MAX. Требования не выполнены, дело возбуждено, потолок штрафа доходит до 4 млрд рублей. Ну, вроде очередной эпизод в переписке ведомства с корпорацией, таких за последние годы набралось много.

Но через пару дней я ко всей этой истории и понял, что смотрю на верхушку истории, которая тянется с 2022 года, а целиком я её не видел ни разу. Захотелось разложить всё в разрезе: что за эти четыре года случилось с мобильной разработкой в России. С продажами устройств, с доставкой приложений до живых людей, со стеком, с тем, где сейчас работа.

Скажу сразу: любимой платформы у меня тут нет, болеть ни за кого не собираюсь.

Всё началось с обычной задачи: собрать нитку маршрута на несколько дней, прикинуть набор высоты по дням, понять, где на пути вода, и отдать группе трек, который откроется у всех.

Как силами двух разработчиков создать мессенджер под шесть платформ на Compose Multiplatform и Go. Рассказываем об оптимизации бандла до 10 МБ, разработке собственного SFU на pion/webrtc и синхронизации сообщений на слабых сетях.

Спидтест показывает 200 мегабит, а в PUBG Mobile 180 мс — и оба числа правда. Пропускная способность и задержка измеряют разные вещи, и про вторую спидтест не говорит ничего.

Я собирал для своего iOS-приложения панель задержек: пинговать не «интернет вообще», а те серверы, которыми человек реально пользуется в своей стране, и сортировать их от худшего. Семь раундов измерений против лежащего рядом MacBook дали пять дефектов подряд — и вытащили баг, который жил в приложении с версии 1.0: два параллельных пинга забирали ответы друг у друга, потому что ICMP-сокет отдаёт и чужие echo reply тоже.

iPhone Duo сломал часть допущений, зашитых в iOS-приложения с 2007 года: экранов теперь два, safe area асимметрична, «только портрет» больше не значит что думаете. Разбираю по докладам Apple, что реально меняется в вашем Swift-коде — size classes, reserved regions, arrangements, hinge и камера.

Всем привет!

В конце августа мы провели по ИИ в безопасной разработке и решили собрать в этом материалы основные тезисы наших экспертов. Тема - горячая, важная, поэтому добро пожаловать в комментарии!

Итак, начинаем разбираться, как ИИ меняет безопасную разработку вместе с Антоном Прокофьевым, директором центра разработки решений по контролю безопасности ПО ГК «Солар»; Дмитрием Евдокимовым, основателем и генеральным директором Luntry; Дмитрием Частухиным, основателем и техническим директором Hexway.

Где ИИ уже снимает рутинную нагрузку с AppSec? Почему сгенерированный код все равно требует проверки и зачем контролировать ИИ-приложения уже во время исполнения?

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

Сразу оговорюсь: это не статья про архитектуру, паттерны проектирования, ECS, оптимизацию кода или правильную организацию проекта.

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

На разработку ушло 16 выходных дней и примерно 250$

Решил я значит разработать свое приложение, начитавшись материалов про ИИ и вайбкодинг, захотелось попробовать самому. Так как я являюсь UX/UI дизайнером, который занимается разработкой дизайна для приложений, я поставил себе несколько целей, которые должны были закрыться в процессе разработки аппы...

Возвращаюсь со своим еженедельным дайджестом для мобильных разработчиков. В этом выпуске адаптация приложений под iPhone Duo и Shared Transition как требования дизайнеров, прозрачный Яндекс.Навигатор и нативная разработка в Shopify, фронтенд без готового бэкенда, путь к Chaos As A Service, ошибка после оформления подписки, которая приводит к оттоку и многое другое. Заходите!

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

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

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