Всем привет! На связи Юрий Шабалин и Веселина Зацепина, эксперты по безопасности мобильных приложений в компании Стингрей. С каждым годом мобильные приложения становятся всё более сложными и взаимосвязанными, предлагая пользователям бесшовный опыт взаимодействия. Одной из ключевых частей этого опыта являются ссылки, которые могут направить пользователя прямо на определённый экран приложения или на конкретный контент. Однако многие (как и мы до того, как написать эту статью) путают такие термины, как Deep Links, Web Links и App Links, что может привести к ошибкам в реализации и уязвимостям.

Цель этой статьи — разобраться в различиях между этим похожим функционалом, понять, какие атаки могут быть на них направлены и как ведёт себя Android, если несколько приложений пытаются зарегистрировать одни и те же ссылки. Сразу оговорюсь, что это статья не совсем похожа на наши обычные материалы — она призвана скорее рассказать, что мы узнали в процессе внутреннего исследования и консолидировать эту информацию в небольших "заметках на полях".

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

Небольшой туториал на тему «Как уменьшить количество Android-модулей в проекте при помощи оберток над Android-классами»

На решение, которое будет описано ниже, меня натолкнула статья Оптимизация Gradle: избавляемся от Android-модулей. В ней приведен синтетический бенчмарк, из которого видно, что количество gradle-модулей с Android-плагином негативно влияет на скорость конфигурации проекта, а также на количество необходимой памяти. Мы, как инженеры, должны воспользоваться каждой возможностью ускорить сборку проекта. Однако в статье приведено несколько недостатков описанного подхода, и на момент написания статьи они были критичными и не давали возможности использовать его в нашем проекте. 

Итак, теперь сначала..

Приветствую тебя, уважаемый читатель! Меня зовут Пятаков Никита, я Android-инженер в команде MT&S Авито. Здесь я делюсь опытом реализации двух версий шапки на главном экране приложения Avito. Эта статья будет особенно полезна разработчикам, которые хотят познакомиться с CoordinatorLayout и научиться делать похожие задачки с нетривиальным взаимодействием view между собой. 

Если вы пришли за ответом на вопрос в заголовке - то не хочу расстраивать вас, я и сам не знаю.

15 ноября этого (2024) года я опубликовал своё приложение в Play Market. Казалось бы, вот оно - начало пути к "миллиардам пользователей", как говорит Гугл при публикации игры, большим онлайнам и заработку. Но в я отдаю себе отчёт, что моя игра нишевая, и никогда сверх-популярной не станет. Однако, даже несмотря на это, я пытаюсь привлечь людей всеми способами.

Сейчас передо мной стоит один важный вопрос: я не наблюдаю свой проект в поисковой выдаче Play Market, и имею довольно слабое представление, что нужно сделать, чтобы он там вообще появился.

Изучаем конкурентов. Моими прямыми конкурентами можно назвать два проекта - Rival Regions - проект, администрация которого не ведёт соцсети и не обновляет сам проект примерно никак, и eRepublik, про который я вам ничего сказать не смогу. Во всех трёх играх, включая мою Wild Politics, игроки взаимодействуют друг с другом чтобы создать лучшее государство игры, однако если в WP и RR государства могут быть какими угодно по названию и территориям, то, насколько мне известно, eR позволяет существовать только странам, подобным реальным.

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

Выше неё - весьма известная Rebel Inc., и целых три симулятора президента одного и того же издателя. Видимо, людям нравится играть за лидеров и только за них.

Привет, друзья!

Я Илья Попов, действующий senior android разработчик, ментор начинающих андроид-разработчиков и автор телеграм-канала Android Dev Notes.

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

Раз наша цель – работа в андроид-разработке, то первое, что нужно сделать – изучить рынок вакансий и понять, а что от вас вообще нужно работодателям?

Идём на основные сайты для поиска работы (hh, superjob, career.habr, geekjob, getmatch и тд) и анализируем пару десятков вакансий джуниоров и то, какие требования в них фигурируют чаще всего. Составляем себе список навыков, библиотек, фреймворков, инструментов для освоения.

Следующее, с чем надо определиться: к какому из пунктов приступать первым? Здесь два варианта:

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

– просим помощи в составлении программы у компетентного разработчика, который занимается обучением начинающих

Эта программа не будет высечена на камне – нам может потребоваться её изменять, а часто придётся импровизировать и отходить от неё. Но мы теперь не плывём в океане наудачу – у нас есть маяк. А дальше дело за малым – поднимаем якорь, надуваем паруса и вступаем на тернистый, но интересный путь разработчика!

Другие статьи из серии:
1. Почему MVx архитектуры всегда получаются плохо
2. Как поправить 3 проблемы MVx архитектур
3. Кроссплатформенная архитектура ядра приложения. Простая. Линейная. Масштабируемая
4. Т-функция: подключаем логику к UI как к БД

Описание проблемы

Задача

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

Я смотрю на это всё и вижу: вот экраны, эти данные на них — статические, а вот эти динамические, значит их надо откуда-то взять; вот тут интерактивные компоненты: при взаимодействии с ними надо что-то сделать. Иногда просто открыть другой экран или виджет, иногда выполнить логику. Исходя из этого я проектирую то, как будет выглядеть логика фичи. Описываю ее в компонентах архитектуры, разбиваю на задачи, узнаю где и как взаимодействовать с сервером, и прочее.

Скрытые кейсы

Но потом я обнаруживаю, что далеко не все переходы такие простые, как нарисовано на дизайне, например, как в случае с авторизацией. Не все явно присутствуют, как, например, переходы назад. А в некоторых случаях не хватает всевозможных экранов ожидания, экранов “пустых” состояний и экранов ошибок.

Знакомо?

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

Фотограф: Laura Cleffmann: https://www.pexels.com/ru-ru/photo/20001993/

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

Привет, меня зовут Сергей и я SDET-специалист в IT-компании SimbirSoft. В своей практике мне приходится тестировать как веб-, так и мобильные приложения на Android. Особенность тестирования мобилок в том, что шаги автотеста нужно максимально приблизить к действиям пользователя. О чем это я? Да все о том же — на смартфонах не кликают, а тапают; не закрывают по крестику модалки, а свайпают. Это как на флоте, эти все словечки понятны только тем, кто драил гальюн или бакланил из камбуза хлеб. 

В этой статье рассмотрим несколько методов скроллов класса TouchAction инструмента Appium, которые позволяют скроллить до нужного элемента или проверить свайп модального окна. И несмотря на то, что в новой версии Appium используются методы executeScript(), класс TouchAction все еще актуален. Поэтому я рекомендую к прочтению эту статью, в первую очередь, тем, кто использует в своих проектах Appium.

Привет! Меня зовут Денис Веренцов, я Android-инженер из команды Emcee, это технопродукт Авито. В статье я расскажу, как можно развернуть облачную инфраструктуру для запуска нативных автотестов Android-приложений на основе разработанного нами решения.

Статья будет полезна тем, кто хочет организовать инфраструктуру для запуска тестов, но не обладает подходящим для этого «железом». Материал также будет интересен тем, у кого есть желание попробовать технологию Emcee в деле.

Разработали для Стройпарка мобильное приложение. На его примере рассказываем о трендах, которые будут актуальны для e-commerce в 2025 году и в особенности — для строительных и отделочных материалов и DIY-рынка.

Увидев однажды пост про свое приложение, решил написать небольшую статью, описав все возможности разработки. Думаю, многим будет интересно..

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

Слова usecase и interactor попали в обиход Android‑разработчиков из книги про «чистую» архитектуру. Книгу эту почти никто не читал внимательно, плюс изложенные там свойства «чистой» архитектуры сформулированы неточно (многие до сих пор уверены, что «чистая» архитектура — это про то, как на слои абстракций логику делить). Чтобы в них разобраться, нужно прочитать еще пару книг из 90-х, мало кто этим занимается.

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

Призываю читателя не использовать эти абстракции в принципе. Всегда на собеседованиях спрашиваю, есть ли в проекте юзкейсы. Если есть, это в 99% значит, что проект будет комком грязи. НО — если уж эти абстракции везде используются и про них спрашивают на собеседованиях, я хочу предложить своё видение того, как можно их использовать.

Всем привет! Меня зовут Женя Мельцайкин, я старший инженер-программист в компании Контур. Большую часть времени в Контуре я работал и работаю Android-программистом, но статья будет не про Android и даже не про мобильную разработку. А про команду мобильной разработки и про наш процесс разработки! Давайте же начнем разбираться, причем тут мобильные разработчики, автоматизация и бэкенд.

Архитектура, с которой мы работаем изо дня в день, оставляет желать лучшего. Иначе как объяснить тот хаос и стресс, который каждый из нас испытывает, приходя на новое место работы? В большинстве случаев самым сложным слоем является UI, и эта сложность зачастую обусловлена не разнообразием элементов интерфейса, а неправильным подходом к архитектуре этого слоя. Отсюда можно сделать вывод, что нельзя дробить приложение в привычной форме: на UI, domain и data. Необходимо добавить еще один дочерний слой — ui/viewModel, и на этом слое, одном из самых важных, я хочу акцентировать ваше внимание.

Меня зовут Илья и мы начинаем!