Android *

DOOM стал культовым шутером от первого лица, который изменил лицо игровой индустрии. С момента своего появления он не только покорил миллионы игроков по всему миру, но и оставил неизгладимый след в истории видеоигр. Теперь, вдохновленный существующими проектами на GitHub, я решил взять на себя смелую задачу — портировать эту легендарную игру на платформу Android Wear. Давайте погрузимся в процесс и реализуем этот захватывающий проект!

Привет, меня зовут Владимир Феофилактов, я занимаюсь Android‑разработкой мобильного приложения СберБизнес. Я хотел бы поделиться с вами историей поиска ответа на вечный вопрос: «когда и как чистить граф зависимостей?».

У нас было приложение‑монолит с главным ComponentManager, где строился весь граф зависимостей. Файл был немаленький. Также во всех фрагментах необходимо было вручную создавать DI‑компонент и следить за его чисткой, а разработчики то и дело забывали про это или чистили неправильно.

Потом началась кампания по выносу фичёвого кода в отдельные модули. С каждым новым модулем всё чаще выстреливала циклическая зависимость, и приходилось писать обвязку (прокси‑класс). Главный ComponentManager оставался связующим звеном между фичёвыми модулями, через которое происходил переброс зависимостей, так что он всё ещё был большим и сложным. Иногда рефакторинг, связанный с перемещением кода из одного модуля в другой, вызывал многочасовую борьбу за нахождение пути решения проблемы «почему сборка никак не соберётся?». Иногда, чтобы доставить зависимость из одного модуля в другой, нужно было строить сложные конструкции, как при игре в «Твистер».

Вся эта увлекательная и мучительная игра продолжалась довольно долго, пока на помощь, как бы странно это ни звучало, не пришёл новомодный Compose. Тогда мы только начинали его осваивать, и я решил сделать небольшой pet‑проект, состоящий из двух экранов, с применением Compose для его изучения. Естественно, в этот проект подключил всё самое современное из библиотек, включая Dagger 2. Как обычно, немного повозившись с настройкой DI, в голове всплыла вся та боль, которую мы испытываем в нашем проекте.

Продолжая серию статей, общения между процессами и между двумя приложениями, в заключительной части разберем примеры в пределах одной Wi-Fi‑сети.

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

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

Из данных по распространению мобильных телефонов можно сделать вывод, что даже в слаборазвитых странах проникновение приближается к 70%. Большая часть новых пользователей это малообразованные люди. Для работы с ними мы должны использовать самые простые инструменты взаимодействия. Азиатские рынки представляют особый интерес для разработчиков мобильных приложений благодаря их огромному потенциалу роста.

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

Всем привет! Я Александр Власюк, старший Android-инженер в Авито, разрабатываю Авито Кошелек и веду телеграм-канал «​​Записки инженера». В этой статье вспоминаем, как лейауты работают в Compose, обсуждаем изменение лейаута отдельного компонента, смотрим, как создавать кастомные Layout и LazyLayout и учимся откладывать композицию. И всё это на примерах, в том числе из дизайн-системы Авито.

Меня зовут Александр Чекунков, я — Android‑разработчик в СБЕРе. Занимаюсь разработкой CSI‑опросов в мобильном приложении «СберБанк Онлайн».

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

Но для того чтобы получить максимальную пользу от unit‑тестов, важно писать их правильно. В этой статье мы обсудим best practices, применяемые командой СБЕРа для написания тестов, и рассмотрим подходы для повышения их эффективности.

Речь пойдет о новом механизме хранения и манипулирования данными в SimpleUI, который так тесно связан с UI-механизмами платформы что по сути является частью UI/UX. Это многогранный артефакт – это и «визуальная форма данных» (списки, поля ввода, поиск) и резидентное в памяти хранение и примитивное локальное хранение. В целом можно сказать, что «вы наполняете датасет данными, а платформа делает все остальное». Причем в результате выигрыш во всем – в скорости разработки, в прозрачности решения и производительности на любых объемах данных. Кроме того, это удобная работа со ссылочными объектами, что делаем Симпл более удобным для работы с данными внешних систем, а датасеты в свою очередь становятся основным механизмом хранения данных внешних систем (даже для онлайн-решений).

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

Привет! Я Егор Ерусланов, Qt-разработчик.

В Android-приложение 2ГИС мы добавили новый режим PiP (Picture-in-Picture, или «картинка в картинке»). С PiP наши пользователи смогут следить за маршрутом в маленьком плавающем окне на основном экране. Например, когда нужно быстро прочитать сообщение или включить подкаст и при этом сохранять фокус на навигации. Режим PiP — это не просто «приятная мелочь», а функциональность, которая подстраивается под новые требования пользователей навигатора. 

В этом посте поделюсь, как решал несколько трудностей, которые встретились при разработке этой функции.

На первый взгляд кажется, что в современном мире за 1 000 рублей не представляется возможным купить интересное и полезное устройство. Уже практически 3 года я занимаюсь тем, что рассказываю о том, как я покупаю за копейки различные гаджеты и стараюсь дать им новую жизнь. Однако всё это время я обходил один интереснейший класс устройств — Android-часы, причём не на WearOS, а на самом обычном чистом андроиде с полноценными смартфонными чипсетами. Недавно я сэкономил на «шавухе» и купил себе на вторичке смарт-часы ZGPax S8 за тысячу рублей — и в сегодняшней статье я расскажу, почему это один из лучших бюджетных девайсов для настоящего гика!

В Android-разработке могут возникать сценарии, когда нам нужно собрать один aar из нескольких модулей. 

Однажды нам в Сравни потребовалось создать SDK для наших партнёров — на основе уже существующего проекта. Сделать это хотелось без радикальных изменений в проекте и излишнего раскрытия деталей его устройства.

Задача понятная, но нетривиальная в реализации. Google до сих пор не предоставляет полноценного инструмента для создания fat-aar; к opensource-решениям также много вопросов. 

Выход из ситуации: вникнуть в нюансы того, как работает gradle, и на базе общедоступных средств сделать свой инструмент для создания многомодульной библиотеки. С автоматизированной сборкой модулей и публикацией артефакта. 

О том, как мы к этому подступились и к чему пришли, рассказываем под катом.

Всем привет, меня зовут Вадим Мезенцев, я Android‑разработчик в команде Яндекс Go. Сегодня я хочу рассказать историю о том, как мы искали подход к профилированию нашего приложения, с какими проблемами столкнулись и как в итоге реализовали библиотеку для измерения производительности.

Наша команда часто сталкивалась с проблемами при поиске «узких мест» в производительности приложения. Мы пробовали различные инструменты профилирования, но все они требовали слишком много времени на сбор метрик, анализ и фильтрацию нужных данных. Чтобы решить эту проблему, мы разработали собственное решение, которое сочетает скорость анализа и простоту поиска проблем. Мы создали библиотеку Demeter, которую легко интегрировать в отладочную версию Android‑приложения. Она позволяет получать отчёты о производительности во время использования приложения и переходов между экранами. Такую сборку можно передать команде тестирования, а затем проанализировать отчёты и изучить изменения.

Установка Chrome OS на обычный ПК с поддержкой Android Приложений, различия ChromeOS Flex и версии для Chromebook, Сравнение их, подробная установка каждой из них.

Идея приложения состоит в демонстрации IoT - интеграция различных устройств, и передача данных по разным протоколам в Edge или Cloud. Допустим, наш автономный механизм работает без подключения к интернету, а нам необходимо сделать замеры поведения движений во времени. Мы подключаемся с помощью смартфона по Bluetooth LE к контроллеру механизма и в течении определенного времени делаем запись. При этом наш смартфон успешно подключается к облачному MQTT-брокеру и передает данные в IoT платформу. Платформа производит аналитику и предоставляет нам результат. А мы в это время на основании полученных данных можем внести требуемые значения характеристик механизма в контроллер по BLE.

В статье Machine learning на ESP32 мы начали разработку проекта распознавания жестов для ESP32. В данной статье продолжим реализацию подключение и отправку данных по BLE и MQTT с помощью Android-устройства. Хотя ESP 32 может напрямую подключаться к Wi-Fi и MQTT, как, например, показано в статье Платформа с web-камерой на ESP32, мы все же реализуем передачу данных по BLE, руководствуясь выше изложенными соображениями.

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

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

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

Мобильные браузеры долгие годы оставались в тени «взрослых» десктопных версий. Все бы хорошо, но возможностей у первых гораздо меньше. Основной недостаток — нет расширений. Как говорится, бери что дают, за малым исключением (подробнее — ниже). Но сейчас Microsoft начинает менять правила игры. Ее браузер для Android получил настоящие расширения, такие же, как на ПК. Сегодня об этом и поговорим, а еще посмотрим, что это может значить для рынка мобильных браузеров.

Представьте ситуацию: май месяц, экзамены уже на носу, все вокруг готовятся к ЕГЭ... А что, если добавить к этому разработку приложения, победу в конкурсе и публикацию в RuStore? Звучит как безумие? Возможно. Но именно так мы провели последний год перед поступлением. И вот наша история!

В этой статье мне хотелось бы разобрать вопрос, которым часто задаются начинающие и молодые разработчики мобильных приложений под Android. Многие мобильные разработчики слышали о таких широко известных инструментах внедрения зависимостей (DI), как Koin и Dagger. Они решают одну задачу — управление зависимостями, но делают это по-разному. Но в чём же их принципиальная разница, в чём их отличия, их плюсы и минусы, и какой из этих инструментов выбрать при разработке нового проекта (и в зависимости от его сложности и требований)? Обо всём об этом постараюсь кратко изложить далее и дам рекомендации по выбору для новых проектов.