Разработка мобильных приложений *

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

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

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

Привет, Хабр! Меня зовут Никита, я занимаюсь iOS-разработкой в Яндекс Диске. Как вы знаете, прошлой осенью зарелизился Swift 6, а вместе c ним появились и строгие проверки для защиты от датарейсов, связанные со Swift Concurrency.

В этой статье я постараюсь разобраться с основными изменениями в каждом пропозале и поделюсь своими заметками, тем, что мне показалось самым важным или интересным. В конце статьи бонус — Playground с тестами для каждого пропозала, чтобы можно было поиграть с кодом, детальнее разобраться с изменениями и понять, как они влияют на код, написанный на Swift 5.

Про «смерть» Flutter говорят каждый год, иногда по нескольку раз. Сейчас разговоры об этом получили новый виток — во многом после сокращений в Google и появления форка Flock, который якобы заменит основную ветку.

Разбираем страхи, связанные с фреймворком, и отвечаем на основные вопросы по Flutter и Flock с экспертами. За помощь в написании статьи спасибо ведущим Flutter-инженерам Евгению Сатурову, Михаилу «Fox» Матюнину, Сергею Кольцову и Евгению Коту.

Привет, меня зовут Вера, я Android‑разработчик в Яндекс Диске. Мы в Диске сейчас активно работаем над переездом на Compose с использованием дизайн‑системы. Про стабильность в Compose есть немало статей, однако ошибки продолжают cовершаться, поэтому решила поделиться своим опытом в формате ликбез‑статьи.

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

С февраля 2024 года Apple блокирует не только российские финтех-приложения и аккаунты разработчиков, но и закрывает доступ для разработки корпоративных сервисов. Это всё новый пакет санкций, который должен ударить по мобильной разработке и доходам бизнеса.

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

Всем привет! Меня зовут Женя, я руководитель отдела разработки «Аккаунт» в мобильном приложении для продавцов платформы Ozon Seller. Поделюсь нашим опытом работы над улучшением скорости сборки Android-проекта.

Скорость сборки проекта напрямую влияет на time to market продукта и (внезапно) удовольствие от процесса разработки. Если каких-то 50 лет назад время компиляции могло доходить до нескольких дней, и это считалось нормальным, то сейчас даже лишняя пара минут сборки проекта в Android Studio может заставить понервничать. Чтобы сберечь здоровье себе и CI, скорости сборки проекта нужно уделять внимание. Нетерпеливые читатели могут сразу посмотреть итоговую таблицу с результатами в конце статьи.

Привет, меня зовут Михаил Шевченко. В Авито я проектирую и разрабатываю backend low-code платформы Bricks. В этой статье рассказываю о том, почему в Авито было принято решение развивать собственные low-code-решения и Backend-Driven UI, объясняю их устройство и делюсь достигнутыми результатами.

Всем привет! Меня зовут Сергей, и я работаю разработчиком мобильных приложений. Также мы с ребятами развиваем международное комьюнити Coffee&Code, а сам я частый гость на встречах в Санкт-Петербурге.

Хочу поговорить о теме, которая волнует многих разработчиков: использование старых технологий в iOS-разработке, таких как Objective-C. Тут возникает очень насущный вопрос, являются ли он легаси?

Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»

Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.

В техническом блоке МТС около 3 тысяч человек занимаются подключением интернета и обслуживанием абонентов. В какой-то момент, чтобы выполнить свою работу, им нужно было зайти и заполнить данные в шести разных системах. Любое уточнение информации шло через диспетчерский центр, а перенос времени визита к абоненту или поиск новых заявок осуществлялись по звонку руководителю. И это все при разъездном характере работы, когда каждая минута на счету, а к абоненту опоздать никак нельзя!

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

Когда я впервые решил создать свой open-source проект, мне казалось, что главное – это хорошая идея и рабочий код. Я взялся за разработку библиотеки для сетевых клиентов и UI-компонентов, вложил в неё два года работы и, наконец, выложил на GitHub. Но вместо успеха меня ждал холодный душ – библиотека получила всего 10 звёздочек.

Тогда я осознал ключевую проблему open-source: одна только идея не работает. Если проект плохо оформлен – его никто не найдёт. Документация и описание –  не менее важны, чем сам код. В следующем проекте я учёл ошибки. Когда правильно оформил проект, он начал находить аудиторию, получать звёзды и фидбек от разработчиков.

Open-source – это не только код, но и способность донести свою работу до других. И эта история дала мне важный урок: если хочешь, чтобы твой проект заметили, помоги людям его понять. А ещё я понял, как важно участвовать в комьюнити и контрибьютить.

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

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

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

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

Идея сделать игру под Android на Go была неоднозначной, но интересной. Я легко мог представить Go не только в привычной для него сервисной нише, но и в прикладной — его кросс-платформенность и близость к системному уровню в сочетании с простотой пришлись бы там очень кстати. И вот мы здесь — игру мечты я пока не создал, но пару игр попроще сделать удалось.

В этой статье я хочу рассказать об инструментах, появившихся по ходу работы. Сами инструменты я объединил в библиотеку Youngine и опубликовал на GitHub. Там же я опубликовал небольшой пример проекта.

Сегодня мы можем позволить себе веб-страницы, весящие больше, чем оригинальный DOOM, и объём вычислений для их рендера, которого хватило бы для взлома Энигмы. В век технологического изобилия уже не так ценишь байты и флопсы. Единственный по-настоящему ценный ресурс — это люди, и современные разработчики готовы биться за этот ресурс, как Джон Кармак бился за каждый такт процессора.

30 мая прошла конференция X5 Future Night, где более сорока спикеров рассказывали о передовых технологиях ритейла, помогающих привлечь и удержать покупателя, максимизировать его удовлетворение и свою выгоду. Запись всей конференции можно посмотреть на досуге, а в этой статье хотим подсветить несколько технологий, которыми X5 Tech особенно гордится.

Дело было в Питере ― я шел по брусчатке и оступился. Чтобы сохранить лицо, я пожертвовал руками. Ну и как теперь жить и работать? ― спросите вы. Рассказываю. Спойлер: больничный я не брал.

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

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

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

Меня зовут Андрей Данилов, под Android начал разрабатывать в далеком 2012 году. Успел поработать примерно везде — в крошечном стартапе, маленькой продуктовой компании, аутсорсах и крупных компаниях, таких как Авито, Ситимобил, Яндекс. Успел выступить примерно на десятке митапов и конференций. Сейчас член Программного комитета конференции Apps conf X. В данный момент руковожу парой команд в Т-Банке.

Довольно много времени прошло с 2007 года, когда Android стал доступен для разработчиков. С тех пор прошло почти 18 лет, за это время изменилось примерно все — железо стало мощнее, интернет быстрее, IDE умнее, а проекты сложнее. Предлагаю оглянуться назад и посмотреть что же именно изменилось с тех пор для разработчиков.

В 2023 году Huawei заявили об окончательном уходе от Android и переходе на собственную HarmonyOS Next. Для разработчиков это значит, что не получится создавать нативные приложения силами одной команды. Бизнес ждут новые расходы или снижение охвата аудитории.

Меня зовут Сергей, я техлид Android-разработки в Surf. В статье расскажем, чего ожидать владельцам приложений в России, стоит ли готовиться к очередной разработке на новой ОС и как это сделать.

Привет, жители Хабра! Это Даша Волкова из МТС Диджитал. Huawei готовится к решительному шагу — полному отказу от Android в своей экосистеме. Работа в этом направлении шла несколько лет, и сейчас, похоже, все готово к последнему рывку. Компания собирается перевести свои устройства на собственную операционную систему HarmonyOS Next. Написана она с нуля, в ней нет ни единой строки кода Android (во всяком случае, так говорят китайские разработчики). Решение затронет как новые гаджеты, так и уже выпущенные устройства. Подробности — под катом.