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

Поэтому приватность и безопасность данных сейчас сложно переоценить. В большинстве IT-компаний это понимают и работают над собственными инструментами защиты (Apple, например, на каждой презентации делает особый акцент). Страны, в свою очередь, регулируют всё это специальными законами.

Основными из них являются Европейский General Data Protection Regulation (GDPR) и, принятый в Калифорнии, California Consumer Privacy Act (CCPA). Сегодня подробно разберёмся, что это за законы, чего требуют и как внедрить их поддержку в свой сервис, сайт или мобильное приложение.

Это первая статья из цикла про приватность на iOS, где поговорим не только про законы, но и про изменения в политике App Store, AppTracking Transparency и IDFA.

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

А скорый релиз Windows 11 с возможностью устанавливать любые APK-файлы прямо намекает, что пора озаботиться поддержкой десктопных режимов в своих мобильных приложениях. Один из шагов к этому — добавить полноценную поддержку клавиатуры, чем сегодня и займёмся.

Под катом разберём навигацию по RecyclerView, привязку горячих клавиш к toolbar menu, добавим кастомные сочетания и покажем пользователям, как ими пользоваться.

С релизом Android 12 приложения, где новая версия операционки будет указана в targetSdkVersion, получат запрет на запуск foreground-сервисов в бэкграунде. В качестве альтернативы Google предлагает WorkManager, который с появлением expedited jobs станет предпочтительным вариантом для запуска высокоприоритетных фоновых задач. 

О нём и пойдёт речь в статье — под катом обсудим новые возможности инструмента, подключим его к приложению и реализуем миграцию с foreground-сервиса.

Алоха, Хабр! Тестирование рекламных интеграций — довольно трудоёмкий процесс, который сложно автоматизировать, так как мы работаем со сторонними SDK и практически не можем их контролировать. Но для сокращения времени мы разработали и внедрили рекламную дебаг-панель, о плюсах и минусах которой расскажу в этой статье.

По мере развития приложения стоит проводить её аудит для выявления неявных деградаций в производительности. Недавно я проводил аудит раздела комментариев iFunny и написал собственный профайлер. Он не заменит имеющиеся на рынке инструменты Android Profile из Android Studio, Battery Historian и Systrace, но обладает рядом плюсов:

1. Негативное влияние профилировщика на производительность приложения сводится к минимуму.
2. Документация итераций оптимизации работы приложения.
3. Гибкость в сборе метрик.

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

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

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

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

Под катом список инструментов с описаниями, задачи тестирования и некоторые внутренние гайдлайны.

Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус — повышение безопасности.

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

Такой провокационный вопрос задал реддитор nenemen в сабреддите Java:

«Я думаю о том, чтобы свой следующий проект сделать на Kotlin + Spring Boot, но мощь всенародной любви к Kotlin и одновременно ненависти к Java заставляют всё это походить на какой-то культ. Поэтому хотел бы услышать аргументы «против».

Мы в FunCorp в своё время сделали именно такой выбор в пользу Kotlin. И сегодня соотношение Java/Kotlin у нас составляет примерно 20 на 80, продолжая уменьшаться при каждом удобном случае. Поэтому ответы на этот вопрос меня заинтересовали, и я стал листать секцию комментариев. Там наткнулся на реплику реддитора rzwitserloot, которая мне показалась настолько взвешенной, многосторонней и рациональной, что я захотел поделиться ей с нашей командой, а заодно и читателями Хабра.

Далее перевод его аргументов.

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

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

Так как это статья про конкретное практическое применение, то и термины буду использовать из нашего домена:

• просмотр(n) = попытка;
• смайл(s) = победа;
• смайлрейт(w, от worth) = количество смайлов/количество просмотров;
• контент = то, у чего есть эти самые просмотры и смайлы.

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

В Android 12 появится важное изменение, улучшающее безопасность платформы целиком и всех приложений, предназначенных для работы с этой версией ОС. Активити, сервисы и бродкаст ресиверы (broadcast receivers), в которых указаны интент-фильтры (intent-filters), должны явно обозначать, будут ли они доступны для других приложений или компонентов системы.

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

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

Задание полностью отличалось от того, чем мы привыкли заниматься, разрабатывая мобильные приложения — нужно было научить машинку на основе Raspberry Pi 4.0 с камерой объезжать препятствия, искать врага определённого цвета и идти на таран. Кто показал в среднем лучший результат — тот и выиграл.

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

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

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

В такие моменты всегда вспоминаю, как познакомился с data-driven подходом. Для себя больше люблю называть это доказательной разработкой (по аналогии с доказательной медициной) и расскажу на примере. Сейчас этот подход кажется обычным и естественным, но когда-то стал для меня настоящим откровением. И, судя по вопросам кандидатов на собеседованиях, все еще может быть полезен, хотя обсуждается уже давно.

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

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

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

Буквально через два уровня абстракций я оказался в коде, датированном 2016-2017 годами, то есть занялся software archeology. В какой-то момент меня возмутило, что вместо интерфейса репозитория в конструктор класса сервиса была передана реализация. Ещё одним уровнем абстракции ниже оказалось, что это всё-таки был интерфейс, но назывался он просто ContentRepository, а не ContentRepositoryInterface, как написал бы любой адепт ООП и принципов SOLID. Это уже не лезло ни в какие ворота, и я потребовал у архитектора оснований (кстати, рекомендую его статью о том, как мы вдвое ускорили построение лент подписок). Он в свою очередь невозмутимо показал пункт внутренних правил оформления кода, где была проставлена ссылка на статью 2013 года («А» — археология, как и было сказано).

Под катом — перевод этого материала.

Data-science развивается очень быстро, в том числе благодаря росту объема доступных данных для анализа или построения моделей. Но для создания сложных моделей командам аналитиков нужно работать совместно и эффективно управлять большими датасетами. И вот здесь может помочь, например, DVC — open-source система контроля версий для проектов машинного обучения.

Нашел не так много информации по ней в рунете, поэтому под катом на примере простого ML-проекта расскажу, как работать с инструментом для хранения и обновления датасета.

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

Ежедневно наши пользователи загружают десятки тысяч единиц контента. На таком объёме данных приходится применять ухищрения, чтобы сохранить приемлемое время ответа. Под катом расскажу, что именно мы делали, а в конце статьи поделюсь кодом на GitHub для ознакомления.

В эту тему пришлось детально погрузиться во время работы над обеспечением стандартных механизмов верификации устройств для разных мобильных платформ. Задача сводилась к разработке полноценной реализацию проверки JWS-токенов по протоколу SafetyNet на серверной стороне.

После многочасовых поисков и скрупулёзного изучения официальной документации Google решил поделиться полученным опытом. Потому что, кроме официальной документации, я нашел только отрывочные описания частных примеров реализации на разных ЯП. И ни намека на комплексное объяснение особенностей проверки по SafetyNet на сервере.

Статья будет полезна разработчикам, которые хотят подробнее разобраться с технологией верификации устройств по протоколу SafetyNet Attestation. Для изучения описательной части не обязательно знать какой-либо язык программирования. Я сознательно убрал примеры кода, чтобы сфокусироваться именно на алгоритмах проверки. Сам пример реализации на PHP сформулирован в виде подключаемой через composer библиотеки и будет описан ниже.

А в конце статьи — ссылка на разработанную мной библиотеку на PHP, которая обеспечивает полный цикл верификации JWS.

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

Единственное, о чем мы пожалели — что не применили это решение раньше.

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

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