Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё Зона инфо

Что такое in-app purchases и зачем это нужно

Конечно же все знакомы с концепцией приложений-маркетплейсов: это e-commerce приложения, в которых можно покупать разнообразные товары. Они есть у большинства пользователей смартфонов. Для совершения подобных покупок через приложение можно интегрировать SDK, использовать WebView, да хотя бы просто перенаправлять пользователя в web-версию и продолжать флоу оплаты там.

Казалось бы, что покупка тапочек бабушке на дачу, что покупка подписки в Down Dog — разница не велика, но есть одно но: нельзя реализовать покупку контента в мобильных приложениях теми же методами, что и покупку товаров. Если попытаетесь это сделать — не пройдёте проверки Google Play и App store. Покупка контента должна быть реализована исключительно с помощью сторов, а если конкретнее — с помощью in-app purchases или IAP.

Есть вероятность, что в скором времени сторы допустят альтернативные способы реализации in-app purchases. Например, компания Paddle, вдохновившись решением суда по делу Epic vs Apple, анонсировала работу над аналогом App Store IAP. Для Android тоже ведётся работа по разрешению альтернативных биллинговых систем. Пока такая возможность есть только для ограниченного списка стран, при этом наряду с альтернативной биллинговой системой всё равно должна быть реализована оригинальная.

Примеры IAP продуктов

Чтобы было понятнее, какой контент подпадает под IAP, собрала примеры таких продуктов:

  • Покупка игровых уровней или бонусов
  • Подписки на музыкальные или видео стриминговые сервисы
  • Разблокировка дополнительного функционала в приложении

И ещё парочка топов с приложениями IAP: первый и второй. В категорию IAP входят практически все возможные варианты монетизации контента. Однако есть одно исключение.

Reader Apps

Если некоторое время провести на форумах, посвящённых IAP, то можно обнаружить, что участники этих форумов почему-то не очень любят Netflix (раз, два, три). И дело здесь вовсе не в попсовых сериалах, а в том, что в Review Guidelines от Apple есть одно исключение, для которого не требуется реализация IAP — это так называемые Reader Apps. По сути это лазейка для приложений, у которых есть ещё и веб-версии. Reader Apps могут не реализовывать покупку контента через приложение вовсе, либо могут переводить пользователя на свой сайт для совершения покупок.

Image

Политика оплат от Google

В Payments policy от Google есть примерно такое же исключение для Consumption-only (reader) apps. Однако наличие веб-версии не является достаточным аргументом для попадания в категорию Reader Apps. Существуют чёткие признаки, которым удовлетворяют далеко не все приложения (в отличие от Netflix).

Комиссия сторов

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

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

Если владелец приложения получил до 1 миллиона долларов в течение 12 месяцев, комиссия составляет 15%. Как только он превышает отметку в 1 миллион, комиссия увеличивается до 30%.

Чтобы точно рассчитать комиссию с учётом смен подписок, промо-периодов и тому подобного, можно воспользоваться статьёй How to determine Apple and Google Stores commission rates for in-app purchases.

Типы in-app purchases

К огромному счастью, типы IAP между платформами не различаются (iOS и Android). Всего их четыре:

  1. Покупка постоянного доступа (или только доступа на ограниченный период времени)
  2. Покупка дополнительного контента
  3. Покупка виртуальных товаров
  4. Подписка

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

IAP в РФ сегодня

С марта 2022 года в России начали действовать санкции, касающиеся платёжных систем: Visa и Mastercard приостановили работу в России, российские банки были отключены от Swift. Конечно же эти изменения повлияли на возможности пользователей из РФ оплачивать подписки в приложениях.

В связи с этим Google Play ограничил возможности выпуска и обновления платных приложений в РФ.

App Store напрямую не запрещал разработчикам выпускать подобные приложения, однако нужно понимать, что, хотя и существуют обходные способы оплаты (раз и два), они не всегда просты и доступны. Проще говоря, пользователям из России нужно постараться, чтобы оплатить контент.

Поэтому, если ваше приложение рассчитано на российский рынок, есть смысл присмотреться к аналогам App Store и Google Play. Например, в RuStore появилась возможность монетизации контента.

Наш опыт реализации IAP

Теперь, когда мы знаем что такое in-app purchases и почему это нужно, — поговорим о нашем опыте внедрения IAP (к слову, это был первый опыт команды). Попутно рассмотрим проблемы, с которыми мы столкнулись, и возможные способы их решения.

Постановка задачи

Мы реализовывали нативное мобильное приложение (МП) с контентом в виде курсов на зарубежный рынок. У приложения была также и веб-версия (фронт на веб и общий бэк имплементировал другой подрядчик). Заказчик хотел реализовать:

  1. Покупку курсов через приложение
  2. Подписку на курс

Ну и дежурное и до боли любимое — релиз через два месяца, пацаны, погнали!

Регуляторка IAP

Одна из первых вещей, которая бросается в глаза при поиске информации по IAP: сторы, особенно App Store, очень внимательно ревьюят приложения с такой функциональностью, и почти никому не удаётся пройти ревью с первого раза.

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

У сторов есть определённые требования к реализации in-app purchases. Если сформулировать их кратко: нельзя вводить пользователей в заблуждение относительно каких-либо услуг, подписки или контента, который вы предлагаете в своем приложении. Если подробнее — в требованиях для Google Play есть даже примеры как делать НЕ надо, у App Store требования собраны в формате рекомендаций.

Многие требования понятны и легко реализуемы. Я остановлюсь на некоторых, но не буду перечислять все:

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Пример как можно и нельзя

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

Paywall

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

Что это такое? По сути, это платёжная стена, блокирующая доступ в приложение, пока пользователь не оплатит подписку. Существую как Soft paywall — стены, которые юзер может пропустить и продолжить пользоваться приложением, так и Hard paywall — стены, которые пользователь пропустить не может.

Советую ознакомиться с отличной статьёй по реализации Paywalls.

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

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Осложнялось всё тем, что в нашем приложении была неавторизованная зона, в которой также был доступен определённый бесплатный контент. Но в случае реализации Hard paywall, после регистрации пользователь терял бы доступ к этому бесплатному контенту неавторизованной зоны.

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

Дополнительно:  Как поставить кассовый аппарат усынови меня в дом

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

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

Restore purchases

Другой вопрос, который нас долго мучил: нужна ли в приложении кнопка Restore purchases?

Restore purchases, или восстановление покупок — требование из гайдлайнов App Store.

## Реализация кнопки восстановления покупок: опыт разработчиков

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

Мы долго ломали над этой задачкой голову, перечитывали гайдлайны, форумы. Везде инфа делилась 50/50: где-то было написано, что без этой функции приложение точно реджектнут, где-то, что если предусмотрены альтернативные способы восстановления, — пропустят.

## Важные моменты

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

**Ооочень граничный кейс:** пользователь запустил транзакцию, но по каким-то причинам не прошла валидация чека. Если пользователь остаётся с тем же устройством, приложение в бэкграунде будет запрашивать повторную валидацию. Если же пользователь меняет устройство, повторная валидация автоматически не запустится: в данном случае как раз кнопка Restore purchases поможет её запустить.

### Обращение в поддержку

Собрав несколько таких неоднозначных вопросов мы, как наивные простачки, пошли писать в поддержки сторов. Поддержка iOS с виду обещала быть полезной: два бесплатных обращения от аккаунта разработчика, следующие — по несколько долларов, ответ в течение трёх суток!

Ответили нам через полторы недели следующим письмом:

![Изображение ответа](https://habrastorage.org/getpro/habr/upload_files/22a/2c8/d56/22a2c8d56489c5d0a181b493cfc4d08f.png)

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

![Изображение ответа](https://habrastorage.org/getpro/habr/upload_files/9a5/3d3/1f0/9a53d31f0eabcc1dc29315c3b9e0c6d3.png)

Таким образом, попытки подстелить соломку оказались тщетны. Нам предлагалось идти сразу в бой.

### Наши решения

Кейс с Paywall мы решили достаточно просто: добавили на экран кнопку Log out. Так мы закрыли оба требования:

![Кнопка Log out](https://habrastorage.org/getpro/habr/upload_files/f89/9c7/387/f899c7387a26c8fd62238737d2909760.png)

По Restore purchases мы решили поступить немного иначе: реализовали кнопку, но скрыли её в первой сборке, чтобы проверить, пропустят нас ревьюеры или нет.

Спойлер: сборка iOS прошла ревью почти с первого раза! Что значит почти: в первый раз нас развернули за неработающую ссылку на Privacy Policy — досадный баг. Но в остальном замечаний к сборке у ревьюеров не было.

На самом деле нам не до конца известен процесс ревью, так что есть вероятность, что ревьюеры увидели необходимые методы для Restore purchases в коде, и на основании этого пропустили сборку, не обратив внимание, на то, что в UI кнопка скрыта.

### Юридические блокеры

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

Google Play

Настройка Payment profile в Google Play Console в общей сложности заняла месяц и три дня. Это был итерационный процесс: стор запрашивал документы, юристы заказчика их отправляли, затем ждали ревью и запроса следующей порции.

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

После того, как мы разблокировались с Payment profile, мы смогли создать продукты в сторе. Но чтобы созданные продукты приходили в приложение, нужен был ещё доступ для релиза тестовых сборок в internal testing. Для этого требовалось внести ещё кучу информации в стор и тоже ждать ревью — это заняло ещё 26 дней.

App Store

Тут вообще интересная ситуация: в общей сложности блочились мы меньше. Но Paid Applications Agreement мы не могли принять не из-за юридических проблем, а из-за бага Apple: кнопка принятия соглашения на экране была задизейблена и мы ждали две недели, пока баг поправят!

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Заключение

Какие же выводы можно сделать из первой части нашего невероятного увлекательного и не менее стрессового приключения?

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

В следующей статье разберём сложности в технической реализации IAP.

P. S. Там публикуем кейсы, лучшие практики, новости и вакансии Surf, а также проводим прямые эфиры.

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

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

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

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

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

Применение принципа «общей кнопки» подразумевает использование брендированной кнопки в центре композиции (ближе к линии горизонта), размещённой на светлом однородном фоне на главных экранах в интерфейсе.

Принцип «общей кнопки» применим как для продуктов QIWI Кошелька, так и для других сервисов QIWI.

Как применять принцип «общей кнопки» на главных экранах

Пример расположения «общей кнопки» на лендинге на главной странице навторизованной зоны qiwi.com.

«Общая кнопка» на главной странице терминала.

2. Кнопка включает в себя главное функциональное действие на экране.

3. Кнопка несет самую большую пользу для компании, продукта, пользователей, бизнеса.

4. Кнопка располагается по центру. В видимой части экрана. По высоте ближе к «уровню горизонта».

5. «Общая кнопка» должна быть самым крупным кликабельным элементом на экране.

6. Кнопка всегда оранжевая со скругленными краями 100% — в стиле Brand button с тенью и градиентом.

7. Перед названием кнопки рекомендуем размещать иконку, усиливающую заметность кнопки.

Организация: Банк ВТБ (ПАО)

Номинация: Прорыв года в розничном финансовом бизнесе

Название проекта: Чат-бот ВТБ

Описание проекта Чат-бот — современный канал поддержки для розничных клиентов ВТБ. Бот мультифункционален: он не только отвечает на вопросы по продуктам и услугам банка, но и помогает совершать ежедневные банковские операции прямо в чате. Отсюда и имя: Помощник ВТБ. Чат в онлайн-сервисах ВТБ — это канал для связи с банком в приложении, на сайте и в мессенджерах. Это не обособленный продукт, а универсальное решение, которое спроектировано таким образом, чтобы использовать его в различных каналах обслуживания и для разных категорий клиентов: массовых и привилегированных. Чат позволяет общаться с оператором и чат-ботом. Бот консультирует клиентов по широкому кругу вопросов: от обновления приложения и условий по вкладам и счетам до персональной информации, например, о списании денег или дате очередного платежа по кредиту. Помощник ВТБ владеет знаниями обо всех продуктах банка и помогает их оформлять. В этом году чат-бот стал еще умнее и функциональнее. Благодаря запуску 110 новых фич канал превратился в полноценный мессенджер с привычными пользователю функциями. Чат-бот стал быстрее за счет переработки ядра, переезда на новую технологическую платформу и оптимизации сценариев. Кроме того, чат-бот существует в мессенджерах: в этом году к консультациям в Telegram, WhatsApp и Viber мы добавили поддержку клиентов во ВКонтакте. Теперь мы еще ближе к нашей аудитории. Наши усилия по оптимизации продукта приносят отличный результат: средняя оценка чат-бота пользователями – 4,9 из 5. И менее 3% из оценивших клиентов ставят отрицательную оценку. Благодаря чат-боту снижается нагрузка на операторов контактного центра. За последний год доля чата в общей массе обращений в контактный центр выросла с 42% до 45%. То есть почти половину всех запросов в банк обрабатывает чат-бот. Цели и задачи Цель чат-бота ВТБ — улучшать клиентский опыт. Для достижения целей мы:

Дополнительно:  «Откройте для себя простой способ бесплатной загрузки Instagram на телефон Android Honor на русском языке и изучите пять эффективных способов без усилий установить службы Google на любой китайский смартфон Android, включая Huawei Honor, Xiaomi и Meizu»

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

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

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

С ростом аудитории и функциональности сервисов появляются пользователи, которым по различным причинам необходимо использовать несколько учётных записей для абсолютно разных целей: личных, рабочих или учебных. Чтобы они могли быстро и удобно переключаться между ними, разработчики добавляют в свои приложения функцию мультиаккаунта — с функцией переключения, multi push и т. д.

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

Что может пойти не так?

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

Приложения должны уметь вовремя реагировать на внешние события (например, на push-уведомления), анализировать, с каким из аккаунтов связано это событие, и при необходимости переключаться. Для этого необходима возможность совершать действия и обрабатывать сетевые запросы для всех авторизованных аккаунтов, а не только для активного. Все модули приложения должны хранить набор данных для каждого аккаунта и уметь перестраиваться под переключение на каждый из них. Звучит непросто!

Разберём каждую задачу в отдельности.

Отправка запросов от лица нескольких пользователей одновременно

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

Получается, что при разделении авторизованной и анонимной зоны в запросах передаётся разный набор параметров. В неавторизованной зоне обычно используется анонимный идентификатор устройства, такой как IDFA на iOS. Подобный механизм можно назвать авторизацией запроса — это проставление в параметры или заголовки запроса информации, используемой в авторизации.

Зачастую запрос авторизуется в коде в месте использования. Узнали, согласны? При внедрении мультиаккаунта, когда в приложении может быть несколько активных профилей одновременно, такой подход чреват путаницей: запрос может быть отправлен не от того аккаунта! Если не обеспечено централизованное хранение сессий, подобные ситуации практически неизбежны. Всё из-за того, что в приложении получается слишком много мест, где что-то может пойти не так: можно сохранить не те токены, перепутать пользователя в момент записи сессии, и наступить на те же грабли при формировании каждого сетевого запроса, которых в кодовой базе может быть сотни.

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

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

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

UML-диаграмма отправки запросов от лица нескольких пользователей представлена на рисунке.

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

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

Например, у нас учтён следующий интерфейс для отправки запроса от конкретного пользователя:

Хранение сессий и метаданных

По стандарту OAuth 2.0, для отправки запросов в авторизованной зоне, как правило, используется секретный токен доступа, который клиенты получают при авторизации. Он служит «подтверждением» возможности действия пользователя в своём аккаунте и отправляется с каждым соответствующим запросом.

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

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

Оптимальным местом для хранения сессий в iOS может стать Keychain, так как он отвечает всем требованиям, а самое главное — требованиям по безопасности, предоставляя максимальную защищённость современных устройств Apple.

Таким образом, мы получаем:

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

Недостатки у использования Keychain, к сожалению, тоже есть — это:

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

Как интегрировать мультиаккаунт в уже работающий сервис и не поломать всё

Нюансы переключения между учётными записями

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

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

Дополнительно:  Перезапуск Yandex Station Light и как сбросить Алису к заводским настройкам

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

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

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

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

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

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

Управление push-уведомлениями

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

Чтобы на устройства приходили уведомления, необходимо сообщить серверу его идентификатор. При рассылке push’ей только с одной учётной записи всё просто: запрос на сервер вы подписываете токеном текущего пользователя, и тогда бекенд понимает, для какой именно учётной записи нужно присылать уведомления. Меняется активная учётная запись — устройство снова подписывается на уведомления.

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

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

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

Если уведомления в приложении будут приходить от нескольких учётных записей, то пользователю необходимо визуально различать, для какого аккаунта приходит push. Для этого отлично подойдёт уникальный никнейм, который пользователь может выбирать для каждой своей учётной записи. Однако, тут может возникнуть проблема с никнеймами по умолчанию — например, цифровыми ID, — но это лишь позволит мотивировать пользователя сменить его на более понятный и выделяющийся.

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

Грабли, боли и тестирование

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

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

Чтобы задать вопрос, необходима авторизация

У меня возникла проблема при работе с приложением. Куда я могу обратиться?

Как узнать входит ли мой адрес в зону доставки?

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

Для чего нужна авторизация?

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

Приложение не работает. Что-то пошло не так. Что делать?

Как можно оплатить заказ, оформляя его через приложение?

При заказе доставки или самовывоза вы можете оплатить заказ как с привязанной карты или Google Play, так и картой или наличными на кассе или курьеру. При выборе заказа «В зале» доступна только онлайн-оплата с привязанной карты.

Почему в приложении не всё меню?

Для типов заказов «Доставка» и «Самовывоз» отображаются товары, доступные для доставки. Полное меню доступно при выборе типа заказа «В зале».

В приложении есть «Самовывоз» и есть заказ «В зале». Чем они отличаются?

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

Я сделал заказ. Как его отменить?

Заказ был оплачен, но потом отменён. Когда вернутся деньги?

Что такое «Локатор» в приложении?

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

Оцените статью
Добавить комментарий