Мобильная разработка
Photo
Ученые научили крыс бегать и стрелять внутри DOOM
Ученые обновили эксперимент с DOOM II: теперь крысы не только бегают по уровню, но и стреляют, управляя персонажем без имплантов и нейроинтерфейсов
— Читать дальше «Ученые научили крыс бегать и стрелять внутри DOOM»
Ученые обновили эксперимент с DOOM II: теперь крысы не только бегают по уровню, но и стреляют, управляя персонажем без имплантов и нейроинтерфейсов
— Читать дальше «Ученые научили крыс бегать и стрелять внутри DOOM»
❤1
Мобильная разработка
Photo
Р-ФОН: пишем, запускаем и отлаживаем для него программы на 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 | Другие наши каналы
Это самый простой способ создания программ для Р-ФОН.
Традиционно программы для мобильных телефонов собираются в специализированных средах разработки, включающих эмуляторы.
Уникальность телефона Р-ФОН заключается в том, что на нём можно сразу запускать программы, работающие на компьютерах с процессорами 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 | Другие наши каналы
🙉4🤷2🌚1
Танцы с бубном, душевные терзания и комплекс супергероя: как мы новый редактор в «Заметках» разрабатывали
Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор.
Спойлер: в этой истории будет много боли, падений, преодолений и взлетов (без последнего у меня не осталось бы сил на статью). А еще расскажу про главную ошибку в выборе архитектурных решений, которую мы допустили и которая завела нас в тупик. Так что сможете научиться на нашем опыте!
Читать далее
Читать: https://habr.com/ru/companies/yadro/articles/974944/
@mobi_dev | Другие наши каналы
Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор.
Спойлер: в этой истории будет много боли, падений, преодолений и взлетов (без последнего у меня не осталось бы сил на статью). А еще расскажу про главную ошибку в выборе архитектурных решений, которую мы допустили и которая завела нас в тупик. Так что сможете научиться на нашем опыте!
Читать далее
Читать: https://habr.com/ru/companies/yadro/articles/974944/
@mobi_dev | Другие наши каналы
Скандалы, интриги, продуктовые метрики: что нам дало ускорение загрузки экрана в приложении hh
Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.
Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для мобильных разработчиков, но и для аналитиков и продактов.
Читать далее
Читать: https://habr.com/ru/companies/hh/articles/977376/
@mobi_dev | Другие наши каналы
Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.
Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для мобильных разработчиков, но и для аналитиков и продактов.
Читать далее
Читать: https://habr.com/ru/companies/hh/articles/977376/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
Опенсорс-библиотека 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 | Другие наши каналы
Когда 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 | Другие наши каналы
Все не так с Codable
Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.
Особое внимание должно уделяться производительности кода в стандартной библиотеке языка, так как этот код используется почти во всех приложениях, которые написаны на этом языке.
Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в
Читать далее
Читать: https://habr.com/ru/companies/tbank/articles/977694/
@mobi_dev | Другие наши каналы
Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.
Особое внимание должно уделяться производительности кода в стандартной библиотеке языка, так как этот код используется почти во всех приложениях, которые написаны на этом языке.
Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в
JSONDecoder/JSONEncoder, ускорив сериализацию и десериализацию в два раза. В конце обсудим, как получить эту оптимизацию без ограничений по версии iOS и насколько можно ускорить работу с JSON в приложении.Читать далее
Читать: https://habr.com/ru/companies/tbank/articles/977694/
@mobi_dev | Другие наши каналы
EcoQuest: А кто это тут нагадил?
Шалом, любители кинуть бумажку мимо урны. Я честно пытался скормить написание этой статьи нескольким разным ИИ потому, что очень хочу спать. Но...
Пойти в лес за мусором...
Читать: https://habr.com/ru/articles/977916/
@mobi_dev | Другие наши каналы
Шалом, любители кинуть бумажку мимо урны. Я честно пытался скормить написание этой статьи нескольким разным ИИ потому, что очень хочу спать. Но...
Пойти в лес за мусором...
Читать: https://habr.com/ru/articles/977916/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным
ChatGPT получит визуальный поиск, интерактивные ответы и встроенные приложения, из-за которых привычный поиск Google может стать ненужным
— Читать дальше «OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным»
ChatGPT получит визуальный поиск, интерактивные ответы и встроенные приложения, из-за которых привычный поиск Google может стать ненужным
— Читать дальше «OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным»
🤔1
Мобильная разработка
Photo
Как мы перевернули подход к мобильным интерфейсам с 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 | Другие наши каналы
После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении.
В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.
Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.
Такой подход работал, статусная модель была простой: несколько базовых состояний и переходы между ними. Но с ростом бизнеса логика усложнилась. Появились региональные особенности работы в разных городах, ролевые ограничения, условные переходы, зависящие от контекста.
Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.
Читать про формирование UI через бэкенд
Читать: https://habr.com/ru/companies/whoosh/articles/977814/
@mobi_dev | Другие наши каналы
🔥21❤7💯4🦄2⚡1👍1
Мобильная разработка
Photo
GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона
GTA Vice City запустили прямо в браузере без установки: игра работает на ПК и смартфонах, быстро загружается и требует лицензионные файлы
— Читать дальше «GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона»
GTA Vice City запустили прямо в браузере без установки: игра работает на ПК и смартфонах, быстро загружается и требует лицензионные файлы
— Читать дальше «GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона»
🔥5
Мобильная разработка
Photo
В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic
В Rust-коде ядра Linux обнаружили опасный баг в Binder, приводивший к повреждению памяти и kernel panic. Исправление уже включено в стабильные обновления
— Читать дальше «В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic»
В Rust-коде ядра Linux обнаружили опасный баг в Binder, приводивший к повреждению памяти и kernel panic. Исправление уже включено в стабильные обновления
— Читать дальше «В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic»
❤4
От ощущений к цифрам: как мы внедрили метрики перформанса в андроид приложение
Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.
В этой статье разберём, почему перформанс на мобильных устройствах это не ощущения, а фактор, который влияет на конверсию и GMV. Покажу, какие метрики имеет смысл собирать на клиенте, как их мониторить, и приведу примеры кода для Android.
Присаживайтесь, наливайте чай/кофе — поехали.
Читать далее
Читать: https://habr.com/ru/articles/978170/
@mobi_dev | Другие наши каналы
Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.
В этой статье разберём, почему перформанс на мобильных устройствах это не ощущения, а фактор, который влияет на конверсию и GMV. Покажу, какие метрики имеет смысл собирать на клиенте, как их мониторить, и приведу примеры кода для Android.
Присаживайтесь, наливайте чай/кофе — поехали.
Читать далее
Читать: https://habr.com/ru/articles/978170/
@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 | Другие наши каналы
Шейдеры - легко, скриншоты - боль. Написал свой Liquid Glass для iOS 14-26, потому что Apple сделала API только для новых систем. GPU справляется за 2ms, а CPU тратит 90% времени на легальное получение пикселей экрана. Почему так и как с этим жить - под катом.
Читать далее
Читать: https://habr.com/ru/articles/978924/
@mobi_dev | Другие наши каналы
Мобильная разработка за неделю #613 (15 — 21 декабря)
В новой дайджесте последствия уменьшения приложений и новый шаг в передаче зависимостей Swift, улучшение доступности в Android-приложениях и перформанс, лёгкий и быстрый DI-контейнер, Offline-First приложения, ускорение загрузки экрана, больше рекламы в App Store и многое другое. Заходите!
Читать далее
Читать: https://habr.com/ru/articles/979034/
@mobi_dev | Другие наши каналы
В новой дайджесте последствия уменьшения приложений и новый шаг в передаче зависимостей Swift, улучшение доступности в Android-приложениях и перформанс, лёгкий и быстрый DI-контейнер, Offline-First приложения, ускорение загрузки экрана, больше рекламы в App Store и многое другое. Заходите!
Читать далее
Читать: https://habr.com/ru/articles/979034/
@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 | Другие наши каналы
Снепшот-тестирование — один из немногих надёжных способов контролировать визуальную целостность SwiftUI-компонентов. Но что делать, если ваш проект ограничен Xcode 13.3 и Swift 5.6, а большинство компонентов дизайн-системы обёрнуты в UIViewRepresentable?
Меня зовут Денис Третьяков, я iOS-разработчик в ПСБ. В этой статье расскажу, как мы организовали снепшот-тестирование SwiftUI-компонентов в условиях жёстких ограничений, с какими проблемами столкнулись и как их решили.
Читать далее
Читать: https://habr.com/ru/companies/psb/articles/978374/
@mobi_dev | Другие наши каналы