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

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

Казалось бы, задача на пять минут: поймали подключение нужного Bluetooth-устройства и вызвали системную функцию включения hotspot. Но с недавних пор эту лавочку в Android прикрыли. Обычному стороннему приложению прямого доступа к управлению tethering уже не дают, даже если пользователь сам этого хочет.

В итоге получилось небольшое приложение BlueSpot на C#/.NET, которое делает ровно одну вещь: при подключении к выбранному Bluetooth-устройству включает системную Wi‑Fi-точку и присылает уведомление. Root не требуется, но без небольшого легального извращения в виде Shizuku не обошлось.

Тут должна быть картинка

Привет, Хабр! Когда-то я пять лет проработал в отделе тестирования, а последние шесть занимаюсь разработкой под iOS и Android. На одном из первых проектов в мобилке я на Java под Android создал пирамиду тестирования: больше тысячи unit-тестов, больше ста интеграционных и с десяток UI и End‑to‑End. На текущей работе сделал то же самое с нуля, но уже под iOS на Swift.

Но не все сценарии можно покрыть автотестами. Многое все еще тестируется вручную. Например, на текущем проекте мне нужно проверять работу звонков. И для этого не подходят симуляторы/эмуляторы, так как часть функций звонков в них недоступна. Единственная возможность проверить - это взять два физических телефона и протыкать все руками. Обычно я так и делаю при разработке. А потом готовые фичи передают ручным тестировщикам, которые это проверяют на своих телефонах. 

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

Начал разбираться и узнал, что есть множество мировых ферм устройств: BrowserStack, Sauce Labs, LambdaTest, AWS Device Farm, Firebase Test Lab и другие. Но все они зарубежные. С текущими перебоями интернета в РФ — ненадежный вариант. Оказалось, что в России, кроме приватных ферм у корпораций, есть MWS SunQ. Можно развернуть STF и Appium самому — но это больше задача для DevOps. И ограничена теми устройствами, что есть у фирмы. У нас их штук десять — для полноценного тестирования мало. Поэтому я решил разобраться с MWS SunQ.

Попросил Claude написать таймер одним HTML-файлом — а телефон его не будит: вкладка спит, будильник не звонит. Сделал Kapsula: приложение для Android и iOS, которое запускает такой файл как проект с настоящими будильниками ОС через мост из пяти методов. Внутри — iframe без same-origin, postMessage-RPC, три грабли Android-уведомлений, звук на iOS, правило состояния для ИИ-кода и промпт вместо SDK. Без сервера, без аккаунта, без аналитики.

Большинство лаунчеров для Android повторяют одну и ту же концепцию сетки иконок. Чтобы открыть приложение, нужно листать бесконечные рабочие столы и тянуться пальцем до нужной иконки.

Я решил сделать SwipeLauncher — открытый лаунчер с круговым меню, где любое действие или вложенное меню открывается одним свайпом из любой точки экрана.

В этой статье я расскажу, как проект прошел путь от простого прототипа на 4 стороны света до динамической сетки на Jetpack Compose, с какими подводными камнями Android пришлось столкнуться и как устроена математика свайпов под капотом.

28 стилей одной кнопки на старте – и как мы дошли до дизайн-системы, которая живет без нас: с паспортами компонентов, распределенной разработкой и генерацией кода нейронкой.

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

Я мог бы закончить историю на этом, но идея мобильной разработки не давала мне покоя: получается, имея под рукой планшет с большим экраном, вы можете организовать полноценный рабочий процесс. Правда, инструменты для сборки, тестирования и работы с SDK обычно выпускают только для ПК. А можно ли скомпилировать код прямо на смартфоне? Можно — например, в ALT Mobile или «Авроре ОС», если установить дополнительные пакеты.

В статье я подробно расскажу, как развернуть облачную среду разработки, привязать ее к планшету и написать собственный плагин для автоматизации сборки под «Аврору ОС».

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

На телефонах с Android за доступность для людей с особенностями зрения отвечает TalkBack — функция озвучивания экрана, которая зачитывает текст, роль и состояние всех размеченных элементов на экране и позволяет с ними взаимодействовать. Если разметка сломается, приложением будет пользоваться сильно сложнее или вообще невозможно.

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

Сейчас ситуация стала интереснее. Устройства наконец начали расходиться по разным веткам. Для игр и тренажёров остались большие VR-шлемы. Для виртуальных рабочих столов появились лёгкие очки-дисплеи. А рядом вырос новый класс - внешне почти обычные очки с камерой, микрофонами, динамиками, ИИ и небольшим экраном перед глазами.

Rokid Glasses RV101 относятся как раз к последнему классу. Мне они интересны не столько как готовый гаджет с переводчиком, телесуфлёром и камерой, сколько как маленький носимый компьютер, на котором разрешают запускать свой код.

Книга «Асинхронный Kotlin» Яны Седовой посвящена теме, которая часто вызывает проблемы у начинающих Android‑разработчиков, — корутинам и Flow. Книга строится по маршруту от простого определения к рабочему мессенджеру на Jetpack Compose, Room и Retrofit, закрывая пробелы в знаниях, которые обычно оставляют ИТ‑курсы и лекции в ВУЗах. Для студента, стажера или начинающего разработчика (джуна) это полезный русскоязычный учебник, где асинхронность на Kotlin разобрана системно и последовательно, без необходимости собирать воедино материал из самых разных статей на Хабре.

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

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

Этим летом мы переделали ранжирование кандидатов. Теперь место кандидата в поисковой выдаче зависит от ответа на вопрос, который рекрутёр и так задаёт себе про каждого. «Показал бы я этого кандидата клиенту?» На этот вопрос отвечает языковая модель (LLM). Она встроена в платформу как судья, перечитывает найденные поиском резюме, и каждый вердикт обязана доказывать дословными цитатами из них.

Доля действительно подходящих кандидатов в первой десятке поисковой выдачи выросла с 43,7 до 66,3 процента. Замерено на эталонном наборе, который мы заморозили до начала работ. Как устроен замер, расскажу ниже.

Кроме прироста точности эта переделка дала четыре истории, где проверка на эталонном наборе перечеркнула то, что казалось очевидным. Тендер на роль судьи, который мы устроили между четырьмя LLM, выигрывала недорогая и быстрая из них, пока мы не проверили, настоящие ли цитаты из резюме она приводит. Экономия на глубине рассуждений прошла все проверки качества и провалилась на проверке цитат. Перебор 1330 вариантов взвешивания оценок судьи доказал, что веса не нужны. А RRF, стандартный приём слияния семантического и полнотекстового поиска, первую же проверку на эталонном наборе провалил, он ухудшил и полноту, и точность. Обо всём по порядку.

Привет!

Представьте, что вы с удовольствием пишите один код на все платформы на Kotlin Multiplatform, и вдруг приходит задача «синкать данные раз в час, только по вайфаю и когда телефон на зарядке».

Под Android вы берёте WorkManager и за пятнадцать минут закрываете тикет. Потом яблочный смежник открывает документацию по BGTaskScheduler и обнаруживает, что модель там вообще другая и работает всё по-другому: нет очереди задач, есть окна, которые система выдаёт по своему усмотрению и т. д.

В итоге в проекте появляется expect fun scheduleSync() с разными реализациями, которые ведут себя по-разному, и никто в команде через год не сможет сказать, что именно произойдёт на iOS, если приложение свернули посреди загрузки.

Так как я андроидер с альтернативным мышлением, мне нравится API WorkManager'а. Я захотел его скопировать под KMP, породив так называемый Kotlin Multiplatform Work Manager или же Jabbit (job + rabbit, да, я знаю) — планировщик фоновых задач для KMP.

Таргеты: Android, iOS, js и wasmJs. Как будет время и желание, появится ещё и декстоп.

Привет, Хабр! Я Евгений Шувагин, последний год работаю над компонентом Face-Shot в Т-Банке.

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

Каждое утро мне падает сводка по приложению. Сегодня в ней было: 27 сканов за сутки, из них 10 — с вердиктом “нет данных”. Тридцать семь процентов людей навели камеру на штрихкод и не получили ничего. Разбираю, откуда берётся эта дыра при базе в 112 тысяч товаров, почему OCR-фоллбэк отсекает 39 процентов пользовательских вкладов и где проходит граница между “принять с риском” и “отклонить и потерять данные”.

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

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

Пытаюсь лучше понять работу Kotlin Coroutines. Беру небольшую тему про Kotlin Coroutines и пытаюсь разобраться и написать шпаргалку (максимально кратко и лаконично). Сегодня поговорим про Каналы (Channel) и паттерн Actor.

В предыдущих частях мы выяснили, что обычные suspend-функции возвращают результат только один раз. Но что делать, если у нас есть непрерывный поток данных, который асинхронно генерируется в одной корутине, а обрабатываться должен в другой (или даже в нескольких)? Нам нужна потокобезопасная «труба». В мире корутин этой трубой является Channel.

Представьте обычный feed на LazyColumn: новости, карточки, между ними рекламный баннер. Баннер загрузился, пользователь пролистал его вниз, затем вернулся обратно, и мерцание реклама грузится заново.

Ещё раз вниз. Ещё раз вверх. Ещё одно мерцание и загрузка.

На первый взгляд причина кажется очевидной: item покидает экран, rememberBannerAdState теряет состояние, Compose создаёт всё заново. Значит, достаточно сохранить BannerAdState за пределами item и проблема исчезнет.

Я тоже так подумал.

Не исчезла.
Мерцания остались.

С этого момента простой баг (?) интеграции Yandex Ads превратился для меня в небольшое расследование: пришлось разобраться, что на самом деле происходит с item внутри LazyColumn, как SubcomposeLayout переиспользует composition, почему это ещё не означает переиспользование AndroidView и какой lifecycle поверх всего этого построил Compose API Yandex Ads.

В итоге вопрос «почему баннер моргает?» оказался гораздо интереснее самого workaround.

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

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

В новом выпуске 136 уровней вложенности XCUITest и Android Runtime под капотом, как Tinder сократил холодные старты на 47% и новые условия распространения приложений в Евросоюзе, от Event-Driven UI к State-Driven UI, что нового в Dart, как сделать MCP удобными и действительно полезными, уменьшение трения в приложениях и многое другое. Заходите!

Человек уже решил записать еду. Но вместо ввода приложение предлагает поиск, штрихкод, фото, AI, рецепт, избранное — и ещё несколько дверей. Я сравнил девять трекеров и проверил на моём обеде, где появляется лишнее состояние.

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

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