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

WebSockets vs HTTP: Как устроена двусторонняя связь в вебе

На заре интернета, когда возможности веба ограничивались просмотром информационных статей, однонаправленного протокола HTTP, посылающего запрос серверу и получающего ответ, было вполне достаточно. А потом пришли приложения со своими push-уведомлениями, мессенджеры для общения, карты для онлайн-навигации — и здесь технологии HTTP уже стало недостаточно. Требовалось двунаправленное соединение, в котором не только клиент мог отправлять запрос, но и сервер мог динамически посылать информацию клиенту для отображения. Так и появились WebSockets.

Сегодня мы разберем, что это за технология, чем WS отличается от WSS, и почему без WebSockets современный веб был бы невыносимо медленным.
Читать далее

Читать: https://habr.com/ru/articles/979614/

@mobi_dev | Другие наши каналы

Снепшот-тестирование SwiftUI View в legacy-проекте: обходим ограничения

Снепшот-тестирование — один из немногих надёжных способов контролировать визуальную целостность SwiftUI-компонентов. Но что делать, если ваш проект ограничен Xcode 13.3 и Swift 5.6, а большинство компонентов дизайн-системы обёрнуты в UIViewRepresentable?

Меня зовут Денис Третьяков, я iOS-разработчик в ПСБ. В этой статье расскажу, как мы организовали снепшот-тестирование SwiftUI-компонентов в условиях жёстких ограничений, с какими проблемами столкнулись и как их решили.
Читать далее

Читать: https://habr.com/ru/companies/psb/articles/978374/

@mobi_dev | Другие наши каналы

Мобильная разработка за неделю #613 (15 — 21 декабря)

В новой дайджесте последствия уменьшения приложений и новый шаг в передаче зависимостей Swift, улучшение доступности в Android-приложениях и перформанс, лёгкий и быстрый DI-контейнер, Offline-First приложения, ускорение загрузки экрана, больше рекламы в App Store и многое другое. Заходите!
Читать далее

Читать: https://habr.com/ru/articles/979034/

@mobi_dev | Другие наши каналы

«Liquid Glass» на iOS 16: шейдеры — легко, а скриншоты — боль

Шейдеры - легко, скриншоты - боль. Написал свой Liquid Glass для iOS 14-26, потому что Apple сделала API только для новых систем. GPU справляется за 2ms, а CPU тратит 90% времени на легальное получение пикселей экрана. Почему так и как с этим жить - под катом.
Читать далее

Читать: https://habr.com/ru/articles/978924/

@mobi_dev | Другие наши каналы

От ощущений к цифрам: как мы внедрили метрики перформанса в андроид приложение

Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.

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

Присаживайтесь, наливайте чай/кофе — поехали.
Читать далее

Читать: https://habr.com/ru/articles/978170/

@mobi_dev | Другие наши каналы

В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic

В Rust-коде ядра Linux обнаружили опасный баг в Binder, приводивший к повреждению памяти и kernel panic. Исправление уже включено в стабильные обновления

— Читать дальше «В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic»

GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона

GTA Vice City запустили прямо в браузере без установки: игра работает на ПК и смартфонах, быстро загружается и требует лицензионные файлы

— Читать дальше «GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона»

Как мы перевернули подход к мобильным интерфейсам с Backend Driven UI

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

В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.

Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.

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

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

Читать: https://habr.com/ru/companies/whoosh/articles/977814/

@mobi_dev | Другие наши каналы

OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным

ChatGPT получит визуальный поиск, интерактивные ответы и встроенные приложения, из-за которых привычный поиск Google может стать ненужным

— Читать дальше «OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным»

EcoQuest: А кто это тут нагадил?

Шалом, любители кинуть бумажку мимо урны. Я честно пытался скормить написание этой статьи нескольким разным ИИ потому, что очень хочу спать. Но...
Пойти в лес за мусором...

Читать: https://habr.com/ru/articles/977916/

@mobi_dev | Другие наши каналы

Все не так с Codable

Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.

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

Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в JSONDecoder/JSONEncoder, ускорив сериализацию и десериализацию в два раза. В конце обсудим, как получить эту оптимизацию без ограничений по версии iOS и насколько можно ускорить работу с JSON в приложении.
Читать далее

Читать: https://habr.com/ru/companies/tbank/articles/977694/

@mobi_dev | Другие наши каналы

Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift

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

Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.

В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.
Читать далее

Читать: https://habr.com/ru/companies/yandex/articles/976898/

@mobi_dev | Другие наши каналы

Скандалы, интриги, продуктовые метрики: что нам дало ускорение загрузки экрана в приложении hh

Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.

Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для  мобильных разработчиков, но и для аналитиков и продактов.
Читать далее

Читать: https://habr.com/ru/companies/hh/articles/977376/

@mobi_dev | Другие наши каналы

Танцы с бубном, душевные терзания и комплекс супергероя: как мы новый редактор в «Заметках» разрабатывали

Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор.

Спойлер: в этой истории будет много боли, падений, преодолений и взлетов (без последнего у меня не осталось бы сил на статью). А еще расскажу про главную ошибку в выборе архитектурных решений, которую мы допустили и которая завела нас в тупик. Так что сможете научиться на нашем опыте!
Читать далее

Читать: https://habr.com/ru/companies/yadro/articles/974944/

@mobi_dev | Другие наши каналы

Р-ФОН: пишем, запускаем и отлаживаем для него программы на Raspberry Pi с установленной ОС «РОСА Фреш»

Это самый простой способ создания программ для Р-ФОН.

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

Уникальность телефона Р-ФОН заключается в том, что на нём можно сразу запускать программы, работающие на компьютерах с процессорами ARM и операционными системами «РОСА Фреш» и «РОСА Хром». Это существенно облегчает разработку. И написание, и запуск, и отладку, и работу в программе можно сначала обкатать на компьютере, и лишь на последнем этапе скопировать программу на телефон и протестировать уже на нём.

Естественно, для работы со специфическими для телефона компонентами, такими как GPS-приёмник и GSM-модем, требуется отдельный подход. Но для создания пользовательского интерфейса и, например, кода для работы по сети - компьютер более чем удобен.

Какой же компьютер с процессором ARM подойдёт? Неплох компьютер на процессоре Байкал-М, но он дороговат, и его ещё нужно поискать. А вот компьютер на основе Raspberry Pi можно назвать народным. Подойдёт 64-разрядный, то есть, начиная с версии Raspberry Pi 4. Мне достался Pi 400, и всё описанное ниже было опробовано именно на нём.

Ниже описан мой опыт написания простых тестовых программ для Р-ФОН, использующих различные графические инструментарии (Qt, PyQt, GTK3, GTK4, SDL2).
Читать далее

Читать: https://habr.com/ru/articles/976428/

@mobi_dev | Другие наши каналы