Мобильная разработка

Вот и время для заключительной статьи этого цикла. В предыдущих статьях мы рассмотрели нашу мотивацию, всю техническую информацию и поделились инсайтами при создании масштабируемого бизнес-решения в виде кроссплатформенного SDK. В этой небольшой статье хотелось уделить внимание иным аспектам, таким как адаптация процессов команды KMP и смежных команд, которые являются заказчиками, немного поговорить про подходы к тестированию и контролю качества, CI/CD и т.д.

Кратко напомним про контекст и продукт: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контекст проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В предыдущих статьях мы рассматривали технические и архитектурные аспекты при создании Kotlin Multiplatform SDK, но немаловажной частью остается работа с UI и ресурсами в таком SDK, особенно если он поставляется сразу в несколько продуктов.

Да, в Compose Multiplatform есть базовая работа с ресурсами: можно работать со строками, картинками и файлами по аналогии с Android проектами, однако что делать, когда для каждого продукта под одним и тем же ключом локализации должна срываться своя строка? В этой статье мы поделимся своим подходом и инсайтами.

Кратко напомним про контекст и продукт: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контекст проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В предыдущих статьях (раз и два) мы рассмотрели, почему выбрали Kotlin Multiplatform для нашего SDK, а также подробно разобрали базовую архитектуру проекта, включая core-модули и организацию Kit-ов. Теперь настало время погрузиться в самое интересное — архитектуру отдельной фичи и то, как мы организовали взаимодействие между модулями.

Эта статья будет особенно полезна тем, кто хочет понять, как на практике реализовать feature-first подход в KMP проекте, как правильно организовать DI, навигацию и работу с ресурсами в многомодульной архитектуре.

Кратко напомним контекст и продукты: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контектс проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В прошлой статье было много текста о том, почему мы стали смотреть в сторону кроссплатформенной разработки и почему мы в Instories выбрали именно Kotlin Multiplatform (далее — KMP) для своего решения.

Кратко напомним контекст и продукты: Instories — мобильный видеоредактор для маркетологов, SMM‑специалистов и блогеров. Контектс проекта: желание получить ряд SDK (мы называем их Kit‑ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес‑логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

Мы выбрали использовать многомодульную архитектуру, чтобы каждая фича была инкапсулирована в своем модуле и не влияла на другие фичи, а также разделили проект на несколько крупных пакетов: kits, core и feature. В данной статье мы рассмотрим первые два пакета с технической точки зрения, а также поделимся причинами и инсайтами для выбранных решений.

Я написал свою альтернативу звонкам в WhatsApp и Telegram — полноценный Android-клиент на WebRTC с поддержкой P2P-аудио и видео, STUN/TURN, сигналингом и собственным UI.

Забудьте про «корпоративные мессенджеры»: проект JOPA Call (👉 «Just One Peer App») работает напрямую, без лишних посредников.

Реализовано: peer-to-peer соединения, fallback через TURN, мини-preview окна камеры, управление потоками и адаптивное видео.

Макс и его «супераппы» могут курить в сторонке — теперь у меня есть свой звонок-клиент, который не зависит от гигантов.

Привет, Хабр! Меня зовут Георгий, и я тимлид команды платформы в компании Купер. Мы специализируемся на разработке IT-приложений для маркетинга и бизнеса, включая кроссплатформенные мобильные решения на базе React Native. В этой статье я хочу поделиться опытом работы с пуш-уведомлениями. Расскажу, с чего мы начинали, какие проблемы встретили и к чему пришли на текущий момент. Все примеры возьму из свежего проекта, исходники которого доступны на GitHub — ссылку оставлю в конце.

В современном мире мобильной разработки скорость вывода новых функций на рынок становится критическим фактором успеха. Особенно это актуально в контексте быстро развивающихся технологий, таких как AI, где промедление может стоить конкурентного преимущества. Рассказывать будем на примере нашего продукта Instories — мобильного видеоредактора для маркетологов, SMM-специалистов и блогеров.

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

Именно с такими вызовами столкнулась наша команда, когда мы начали искать способы оптимизации процесса разработки для iOS и Android платформ.

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

Как сообщил мне GPT5, технология компенсации сетевой задержки в играх, также известная как «откат сетевого кода» (rollback netcode) впервые была применена в игре «Super Street Fighter II Turbo HD Remix» (2008). Но это не так: именно такой механизм я реализовал в «Pathway to Glory» (Nokia N-Gage, 2004) и «Warhammer 20K: Squad Command (PSP, NDS, 2007)». В этой статье кратко рассказано, как данная технология работает...

Привет, друзья! 🌐

Сентябрь оказался по-настоящему горячим месяцем для Flutter-разработчиков — громкие релизы, свежие статьи на Хабре, видеоразборы с YouTube и целая россыпь полезных пакетов. На нашем канале FlutterPulse мы собрали всё самое интересное в одном месте, чтобы вы ничего не пропустили.

Привет, Хабр! Меня зовут Александр Наумов, я руковожу разработкой мобильной платформы в VK Tech и Mail. В VK занимаюсь мобилками уже более десяти лет, и в этой статье я поделюсь с вами нашей внутренней кухней: как мы ищем инженерные решения, какого класса задачи мы решаем. Хочу поделиться нашей новой разработкой, которая, как мне кажется, может быть полезна сообществу.

Привет, Хабр!

Последние пару лет часто возникает вопрос: «А может ли ИИ заменить тимлида на code review?». Вопрос созрел не на пустом месте – инструменты на базе LLM теперь умеют и подсвечивать баги, и предлагать правки к pull request. Хайп подогревают отчёты: 84% разработчиков уже используют или планируют использовать ИИ в работе. Однако доверие к таким ассистентам хромает: почти 46% инженеров активно не доверяют ответам ИИ (против 33%, кто доверяет). Получается парадокс: пользуемся – но проверяем. Давайте разберёмся, где AI-ревью реально помогает, а где лид остаётся незаменим. Спойлер: место лидов в команде пока в безопасности.

Покопаемся в исходниках Retrofit, чтобы открыть завесу тайны, как же он всё-таки работает с корутинами и почему я не ловлю краш, даже когда при вызове метода из Service не переключаю диспатчер на Dispatchers.IO.

При создании интерфейса важно проверить, как он реально выглядит. Часто это проверяют все участники процесса — от разработчиков до менеджеров. И для автоматизации и упрощения процесса визуального тестирования приложения есть специальный инструмент — golden‑тесты. Это методология тестирования, в которой текущий UI сравнивается с предварительно сгенерированным «золотым» эталоном. Если вы уже слышали про скриншот‑тесты — это примерно то же самое, но есть нюансы.

Меня зовут Даниил Липаткин, я тимлид в команде разработки курьерского приложения Яндекс Доставки. В этой статье:

— Мы познакомимся с методологией, рассмотрим её преимущества и недостатки, а также когда её стоит и не стоит применять.

— Напишем базовый Golden‑тест на примере стандартных инструментов библиотеки flutter_test.

— Рассмотрим пакет alchemist, который решает проблему платформозависимости flutter_test.

— Получим прикладные рекомендации по применению тестов и настройке IDE и CI.

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

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

Команда CleverPumpkin всегда стремится делать чуть больше ожиданий. И этот проект не стал исключением. Клиент пришёл за дизайном, но в итоге сотрудничества получил гораздо больше. Что именно — читайте в нашем кейсе.

В Android-проектах Koin остаётся одной из самых популярных DI-библиотек, особенно в MVP/MVI и Compose-приложениях. Она проста в настройке, гибкая и хорошо работает в больших кодовых базах.

Но многие команды, стремясь к модульности и тестопригодности, начинают активно использовать функции loadKoinModules() и unloadKoinModules(). И здесь разработчики часто натыкаются на странную ошибку -_-

Привет, Хабр! В прошлой статье мы поговорили о строках в Swift - об их особенностях, внутреннем устройстве и подводных камнях. И я подумал: ведь строки это по сути - коллекции. А какая главная и самая популярная коллекция в Swift? Конечно же, массивы. Их используют повсюду. Но вы когда-нибудь задумывались, как они устроены внутри? Давайте погрузимся внутрь массивов и посмотрим, что они из себя представляют.

В этом выпуске рассуждения о месте Rust в iOS и MAX в Android, погружение в JNI и опыт Shopify с React Native, архитектурный сдвиг оффлайна, быстрый старт в CI, мобильный рынок Турции, продукты для бумеров и многое другое. Заходите!

Привет! Меня зовут Никита и я Android-разработчик. Сегодня я хочу рассказать, как нам вместе с командой Nexign удалось реализовать сборку бизнес-сценариев в приложении для регистрации новых клиентов с особыми требованиями по навигации.

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

Картинка: prostooleh, freepik.com

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

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

Остаться в темноте... Это страшно даже представить, а ведь множество людей так и живут, и это для них суровая реальность...

Хорошо, если слух есть, а если его нет... Сложно представить, насколько осложняется коммуникация, когда пропадает зрительная составляющая в мире, где так много информации передаётся в визуальном, в частности текстовом, формате. По сути, человек остаётся изолированным один на один...

Ниже будет некоторый обзор темы, после чего, мы плавно придём к ОЧЕНЬ интересной (на мой взгляд) идее, думаю, что будет интересно!