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

Привет, Хабр! Меня зовут Алексей Григорьев, я iOS-разработчик в МТС, работаю над продуктом Membrana — это тариф + мобильное приложение для управления приватностью в Сети. Сейчас в iOS-приложениях на первое место постепенно выходит модульная архитектура. Она позволяет создавать гибкие и масштабируемые проекты, которые легко сопровождать и развивать. Особенно это актуально при увеличении кодовой базы и разрастании функциональности, когда поддержка монолита усложняется.

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

В этом материале я расскажу про ключевые моменты модульной архитектуры в iOS-приложениях, инструментах для ее внедрения и применения в наших проектах.

Привет, Flutter-разработчики! 👋 В этом выпуске вас ждут горячие новости, свежие пакеты и интересные видео.

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

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

В 2022 году, с выпуском Android 11, Google удалила этот доступ для разработчиков приложений. Согласно новой политике видимости пакетов, приложения должны видеть другие приложения только в том случае, если те необходимы для их базовой функциональности. Кроме того, разработчики должны явным образом объявлять эти приложения в обязательном для всех приложений Android файле конфигурации AndroidManifest.xml.

В крайних случаях, например, для диспетчеров файлов, браузеров и антивирусов Google предоставляет исключение в виде разрешения QUERY_ALL_PACKAGES, которое позволяет видеть все установленные приложения.

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

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

GrapheneOS — это операционная система с открытым исходным кодом (FOSS), основанная на проекте Android Open Source Project (AOSP), которая в первую очередь сосредоточена на улучшении конфиденциальности и безопасности. Хотя мы все хотели бы иметь наилучшую безопасность и конфиденциальность, к сожалению, такие улучшения редко приходят без потерь в удобстве и простоте использования. В этой статье мы рассмотрим, как максимально использовать улучшения Graphene и как эти меры влияют на пользовательский опыт, предлагая практические решения.

Эта статья является попыткой объединить информацию и знания о мобильной безопасности и конфиденциальности в рамках проекта GrapheneOS.

Long story short: он собрал рабочий, визуально приятный и очень надежный сервис по планированию питания не будучи экспертом в создании продукта. Просто положился на нейронки. Хорошая новость в том, что вы тоже так можете. Плохая… Давайте посмотрим, будет ли плохая.

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

Вопрос в другом. Может ли человек с опытом разработки собрать годный сервис за 2,76 доллара? Кстати, откуда они взялись, эти несчастные почти три бакса? Нет, мы не купили ему пирожных. Все проще – это расходы на API от Anthropica. За эти деньги получился сервис, который не просто собирает меню на каждый день, но еще иллюстрирует все позиции не хуже вашей бабуленьки.  Кроме денег понадобился Cursor с моделью Claude 3.7 Sonnet и немного терпения. 

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

По итогам четвёртого квартала 2024 года только в VK Видео количество суточных просмотров выросло до 2,7 миллиарда, а месячная аудитория — до 72,2 миллиона человек. Часть этих просмотров приходится на Android-устройства.

Меня зовут Егор Баженов. Я Android-разработчик в команде VK Видео. В этой статье расскажу о специфике работы видеоплееров в Android-сервисах с большой нагрузкой, возможных ошибках и способах их исправления.

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

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

В декабре 2023 я впервые задумался о похудении. Тогда при росте 194 см я весил 116 кг. Раньше я только играл в мини-футбол, вообще не следил за едой и даже не заглядывал в спортзал.

Начал нормально питаться, поменял привычки, добавил силовые тренировки, к сентябрю 2024 скинул около 30 кг. Это был рекорд по минимальному весу.

Сейчас, через полгода, вешу 89 кг. Оказалось, что нарастить мышцы намного труднее, чем избавиться от жира. Надеюсь, что эти +3 кг в основном мышцы. Почему так: теперь могу подтянуться 11 раз вместо 9, и на фото видны изменения — делаю такие сравнения каждые пару месяцев.

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: BBVA, Duolingo, Google Photos, Wise, Дзен.

Мы привыкли учиться от простого к сложному, от аксиом к теоремам, от базовых понятий — к сложным концепциям, от «Hello, world!» — к многомодульным приложениям. Но библиотеке Kotlin Coroutines в этом смысле не повезло. И документация, и немногочисленные (особенно на русском языке) учебные материалы с первых страниц оглушают читателя потоком понятий, которые объясняются друг через друга. Приблизительно так: Job — это часть контекста, а контекст — это контейнер, содержащий Job. Раскрутить этот клубок бывает непросто.

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

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

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

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

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

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

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

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

«Работать нужно не 12 часов, а головой» — так сказал Стив Джобс, и мы, ведущие сотрудники Surf, с этим согласны. Мы запустили подкаст «Не 12 часов» и решили рассказать о нём и вам.

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

Я люблю историю развития компьютерной индустрии. На днях мне попался к чтению цикл статей «Удивительный и забытый Palm», в которых рассказывалось, как Palm, Inc. удалось создать класс устройств на новой мобильной ОС — Palm OS, которые сначала захватили 80% рынка карманных компьютеров, а после ушли в забвение из-за принятия некоторых неверных решений и скорого прихода iOS/Android.

Однако тот цикл был посвящён в первую очередь самим устройствам и операционной системе. Меня же особо привлекла ссылка на «Zen of Palm» — брошюру, содержащую философию и руководство компании Palm по разработке приложений для устройств на Palm OS.

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

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

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

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

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

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

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

История развития асинхронного программирования в языке Swift. Можно относиться к этому как к расследованию нераскрытого дела.

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