Руководства

# Документация по мобильному приложению

Version 0.1

Version Control Table

Date Version Description
10.2023 0.1 Innitial guide

# Инициализация

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

# Иннициализация Firebase

  • Инициализируются основные сервисы Firebase: Push, отлавливание ошибок и прочие.
  • Получение Firebase токена, который будет использоваться на протяжении работы приложения.

# Запуск первого экрана

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

# Последовательность запросов

  • Отправляем запрос на куки
  • Отправляем запрос для получения токенов
  • Отправляем запрос для получения первого экрана
  • Когда истекает access токен, мы делаем запрос для обновления токенов

# Последовательность запросов при пин-коде

Если у пользователя есть пинкод, то последовательность такая:

  • Отправляем запрос на куки
  • Отправляем запрос для получения экрана проверки пин-кода
  • Если введен правильный пин-код, отправляем запрос для получения токенов
  • Отправляем запрос для получения первого экрана (первый экрана зависит от процесса, в релизном процессе должен быть экран home)
  • Когда истекает access токен, мы делаем запрос для обновления токенов

# Показ и управление экранами

  • Основная логика отображения экранов основана на mainController и функции changePage.
  • Функция changePage отвечает за запрос нового экрана, разбиение экрана на виджеты и перенаправление на нужный экран.
  • Процесс работы changePage:

# 1. Запрос экрана

  • Запрашивается экран с передачей необходимых параметров.

# 2. Парсинг экшенов

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

# 3. Валидация на экране

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

# 4. Выполнение запроса

  • Если предыдущий этап валидации прошел успешно, то отправляется запрос.

# 5. Парсинг запросов

Для обработки и парсинга запросов используются две функции:

# Config-parser

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

# Build widget

Эта функция берет полученную от config-parser "матрешку" и разбивает её на отдельные виджеты или компоненты. Она определяет, какой именно экран и связанные с ним элементы следует отобразить на устройстве пользователя.

# Процесс работы

  1. Принятый JSON с сервера сначала обрабатывается функцией config-parser. Эта функция "читает" данные, проходя по ним рекурсивно, и формирует из них удобную для работы структуру.
  2. После этого, build widget начинает анализировать полученную структуру, определяя какой экран и связанные с ним элементы (ноды) следует отобразить.
  3. Основываясь на определенной ноде и экране, происходит переход в нужную ветку обработки. Например, если был определен экран ввода мобильного номера и соответствующая нода идентификации, то система перенаправляет пользователя именно на этот экран, где уже непосредственно происходит взаимодействие с пользователем.

# 6. Отображение элементов на экране

Для удобства работы с элементами, предоставляемыми сервером, используется централизованный словарь (glossary):

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

  • Обращение к элементу: Для отображения конкретного элемента на экране, система обращается к словарю по имени этого элемента. Например, чтобы отобразить кнопку, производится запрос к словарю с ключом button.

# Процесс работы:

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

# Запросы

# Отправка запросов

MakeRequest: Отправляет запросы на сервер для получения данных следующего экрана.

# Токены

В приложении используются два типа токенов:

  • Access Token: Используется для доступа к ресурсам. Имеет ограниченное время жизни и может истечь. В настоящий момент время жизни составляет 3 минуты, но это значение может измениться в будущем.
  • Refresh Token: Используется для обновления Access Token. В настоящий момент время жизни составляет 30 минуты, но это значение может измениться в будущем.

# Работа с токенами

  • Обновление Access Token: При каждом запросе к системе, мы проверяем срок действия Access Token. Если он истек, система автоматически производит его обновление.

  • Обработка Refresh Token:

    • Если запрос отправлен без Refresh Token, система автоматически запрашивает новый и подставляет его в запрос.
    • Если Refresh Token истек, запрос прерывается, и пользователю показывается экран ошибки.

# Перехватчик запросов

  • Любой запрос, отправляемый на сервер будет перехвачен.
  • Этот механизм проверяет каждый запрос на наличие и актуальность токенов.
  • Если Access Token истек, он обновляется с помощью Refresh Token.
  • Если Refresh Token отсутствует, система запрашивает новый.
  • Если жизнь Refresh Token истекла, запрос прекращается, и показывается экран ошибки.

# Перехватчик ошибок

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

Примеры обработки ошибок

  • Если истек токен: показ экрана "Сессия истекла, обновите сессию".
  • Отсутствие сервиса (например, генерации OTP): "Сервис недоступен, повторите позже".
  • Сложные ошибки или следующий экран с ошибкой: предложение "Вернуться на первый экран" или "Обновить экран".

# Управление экранами ошибок и загрузки. ConnectController

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

У нас есть специализированный контроллер, который определяет, какой экран показать в зависимости от текущего контекста:

  • Основной экран: Это стандартный экран, на котором пользователь проводит большую часть времени.

  • Экран ошибок: Показывается поверх основного экрана, если произошла ошибка, например, проблема с интернет-соединением.

# Отображение экрана ошибок и загрузки

  • Функционал показа ошибок: Если произошла какая-то ошибка, например, отключение интернета, то в реальном времени пользователю показывается экран с ошибкой поверх основного экрана.

  • Экран загрузки (Loading screen): Когда пользователь переходит с одного экрана на другой, поверх текущего экрана показывается затемненный экран с индикатором загрузки.

# Метод changeload

Для управления отображением экранов ошибок и загрузки в приложении используется функция changeload:

  • В зависимости от переданных параметров, функция либо показывает экран загрузки (loading screen), либо экран ошибки.

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

# Виды ошибок

  • Ошибка с генерацией новых экранов: При такой ошибке показывается соответствующий экран.

  • Ошибка с токеном: Например, если токен истек, показывается экран с сообщением о проблеме с токеном.

  • Неопределенные ошибки: В случае возникновения неизвестных ошибок, показывается стандартный экран ошибки.

# Экран поддержки BPMMain

Описание:
BPM Main - это экран поддержки, который служит основой для других экранов в приложении. Его главные функции:

1. Считывание свайпов

  • Встроенная функциональность для распознавания жестов пользователя (свайп влево или вправо).
  • После определения свайпа система решает, куда будет направлен пользователь (вперед или назад).

2. Показ экранов ошибок или загрузки

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

Примечание: BPM Main экран работает как "подложка" для других экранов. То есть, если пользователь находится на экране идентификации и происходит ошибка, BPM Main отображает экран ошибки прямо поверх экрана идентификации. Если ошибок нет, BPM Main остается невидимым для пользователя.

# Рекурсивная обработка ответов от Back-end

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

При работе с Back-end сервисом может возникнуть ситуация, когда в ответ на запрос ожидается экран, но Back-end вместо экрана возвращает токены.

# Решение

Для обработки данной ситуации была разработана рекурсивная функция. Её основная задача - обеспечить корректное получение экрана, даже если в ответ на запрос приходят токены.

# Алгоритм работы функции

  1. Отправить запрос на Back-end.
  2. Проверить ответ: содержит ли он экран или токены.
  3. Если ответ содержит экран:
    • Сохранить имя экрана.
    • Сохранить запрос.
    • Отдать результат.
  4. Если ответ содержит токены:
    • Сохранить копию запроса.
    • Сохранить токены.
    • Отправить сохраненный запрос с новым токеном.

Этот процесс будет повторяться до тех пор, пока в ответ не придет экран.

# Пример использования

При нажатии на кнопку в пользовательском интерфейсе инициируется запрос на Back-end для получения нового экрана. Если в ответ приходят токены, функция автоматически повторяет запрос до получения экрана.