Аврора — это отечественная мобильная ОС, развиваемая компанией «Открытая мобильная платформа». Она построена на базе Linux и унаследовала часть решений от Sailfish OS, но за последние годы превратилась в самостоятельную, зрелую платформу. Пятая версия, вышедшая в 2024 году, ориентирована не только на корпоративный сектор, но и на массового пользователя. В ней — переработанный интерфейс, поддержка планшетов, 64-битная архитектура, повышенная устойчивость и растущая экосистема приложений.

И вот в эту экосистему мы решили встроить наш Flutter Mobile SDK. В этой статье мы — тимлид Mobile SDK в 2ГИС Александр Максимовский и Flutter-разработчик @Sameri11 Михаил Новосельцев — расскажем про технические детали адаптации.

Меня зовут Александр Максимовский, и я тимлид команды Mobile SDK в 2ГИС. Мы разрабатываем SDK — набор инструментов, который позволяет другим разработчикам внедрять наши технологии (карту, справочник, построение маршрутов и навигатор) в свои мобильные приложения. Благодаря нам можно быстро и удобно интегрировать функциональность 2ГИС, не тратя время на реализацию сложных решений с нуля. Мы сделали решение, которое позволяет из Flutter-приложения напрямую вызывать C++ код. Под капотом:

▪️ FFI для прямого взаимодействия с C++ кодом ядром;

▪️ Кодогенерируемое API почти полностью аналогично iOS и Android Mobile SDK;

▪️ TextureWidget вместо PlatformView для рендеринга карты;

▪️ Единые виджеты для отображения карты как для Android, так и для iOS.

Если вы работаете с Flutter, интегрируете карты или маршруты или просто любите разбираться в архитектуре SDK — эта статья для вас. Под катом детально рассказываю про основу продукта — кодогенератор для генерации платформенного Dart-кода на основе C++ интерфейсов.

В 2ГИС мы знаем: лучшие продукты создаются вместе с пользователями. Уже почти 7 лет наше комьюнити помогает нам дополнять и актуализировать справочник. Мы называем этих людей спецагентами — они уточняют информацию, пишут отзывы, добавляют фотографии и делают 2ГИС удобнее для миллионов пользователей. 

И мы захотели вовлечь ещё больше людей в развитие продукта. Так появился новый краудсорсинговый инструмент — Telegram-бот, который мотивирует пользователей добавлять фото к местам и организациям. Запуск показал, как правильно выстроенный краудсорс может решать бизнес-задачи, масштабироваться и вовлекать пользователей. Этот кейс будет полезен продакт-менеджерам и маркетологам, которые ищут новые способы роста и взаимодействия с аудиторией.

Привет, меня зовут Андякина Ольга, я QA‑инженер в компании 2ГИС, тестирую сервис по бронированию отелей Отелло. В этой статье расскажу про плюсы и минусы разных подходов к генерации данных и поделюсь хорошими практиками подготовки данных на примере пакета библиотек d42 и нашего проекта. В первую очередь, наш опыт будет полезен тем, кто занимается автоматизацией тестирования фронтенда.

Автоматизированное тестирование сложно представить без использования тестовых данных. Например, при интеграционном тестировании нужно записывать данные в базу и валидировать полученные данные, в нагрузочном — выполнять запрос с уникальными параметрами. Также данные могут потребоваться при фронтенд‑ и e2e‑тестировании, чтобы наполнить блок текстом или ввести ФИО в форму. Есть различные подходы к получению тестовых данных для автотестов, и генерация данных — один из самых удобных и гибких подходов.

Однажды инженер Василий проснулся и понял, что больше не может ждать эти бесконечные пайплайны.

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

Картина была такая: от старта пайплайна до непосредственного запуска тестов в сервисе проходило в среднем 7,5 минут. Допустим, за рабочий день каждый член команды (разработчик/тестировщик) запускает 3 пайплайна, а людей в команде — 14. Тогда на сборку образа уходит 5 часов 15 минут. 

Василию не подходит.

Локаторы — важная часть автоматизации тестирования. Они позволяют находить элементы на странице для взаимодействия с ними в тестах. Но что делать, если стандартные методы, такие как CSS-селекторы и XPath, становятся громоздкими, ломаются при изменении структуры страницы или не поддерживают уникальные особенности элементов? Решение — кастомные локаторы.

Меня зовут Лёша, и я занимаюсь тестированием в 2ГИС. Моя команда работает над сервисом по бронированию отелей Отелло. В этой статье я расскажу, как использовать кастомные локаторы, чтобы тесты оставались стабильными и поддерживаемыми даже при изменениях в приложении. В примерах я использую Python, но не стоит пугаться, если вы не знакомы с этим языком, каких-то сложных операций мы сегодня выполнять не будем.

Привет, меня зовут Кристина Климовских, я — Python Developer в команде DataMining. Главная задача моей команды — поддерживать бесперебойный флоу добычи данных для обогащения и актуализации справочника 2ГИС.

Ежедневно наши парсеры собирают разношёрстные данные из более 700 источников — это поставщики адресов магазинов, отзывов к заведениям, расписания общественного транспорта, ссылок на запись в салоны красоты и всё остальное, что можно впоследствии найти в 2ГИС. Поддерживать этот «зоопарк» парсеров нам помогают тесты — в каждом из проектов добычи мы стараемся покрывать новый функционал тестами и использовать их при раскатке в CI.

Однажды в одном из проектов флоу тестирования начал сильно тормозить разработку и докатку новый фичей до боя. Хочу рассказать о проблемах, с которыми мы столкнулись, но двигаясь в обратном направлении — от того, к чему пришли, к тому, что было.

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

Представим, что у нас есть приложение на React, в котором можно читать и писать отзывы. Пользователь открыл список отзывов, пролистал его, нажал кнопку «Написать отзыв». Форма написания отзыва открывается в попапе. Пользователь начинает вводить текст, свой email. Вдруг валидация почты срабатывает с ошибкой, которую разработчики забыли обработать. Результат — белый экран. React просто не смог ничего отрендерить из-за этой ошибки в каком-то попапе.

Первая же мысль — не надо было всё уничтожать, список же был не при делах. Чтобы обработать ошибку в render-фазе в React, необходимо использовать Error Boundaries. Почему именно так нужно обрабатывать ошибки — расскажу под катом.

Неделю с небольшим назад прошел онлайн-митап, который будет интересен как опытным iOS- и Android-разработчикам, так и тем, кто только выбирает путь. Два хардкорных доклада и дискуссия о состоянии рынка — под катом в виде записей с таймкодами и презентациями.

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

В конце мая мы успели сходить на CodeFest, где выступили с докладами и подготовили стенд с пазлом в 1440 деталей и конструктором постеров.