rososmotr/sdk-android: РОСОСМОТР

Общий принцип использования в host-приложении
Доступные методы
Инициализация SDK в приложении
Завершение работы с SDK в приложении
Смена авторизованного пользователя
Контроль отправки и получения данных
Список доступных осмотров
Данные для построения детального экрана осмотра
Взаимодействие с осмотром
Информация о текущем пользователе
Обращение в поддержку с отправкой отладочной информации

Общий принцип использования в host-приложении

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

host-n-sdk

Основные договорённости и принципы решения:

SDK кэширует данные в локальной БД. Получает данные от сервера, сохраняет, добавляет к ним то, что пользователь отредактировал или осмотрел.
SDK выдаёт данные host-приложению и строит свои экраны всегда по локальной БД. Даже при наличии интернета, запросы к серверу НЕ синхронные.
SDK спроектирована с глубой привязкой к Rx.
Методы обращения к данным, доступные host-приложению, никогда не получает в ответ сами данные, – это всегда Observable<...>.
Host-приложение должно проектироваться таким образом, чтобы обрабатывать изменения данных, на которые подписывается. Не единожды, а до тех пор, пока подписка не будет отменена. К примеру, метод viewapp.list() вернёт подписку на изменения списка осмотров. Изменения будут эмититься каждый раз, когда данные будут меняться.

Доступные методы

Здесь и далее нотация даётся в псевдо-формате. Точнее смотрите в коде подключаемой SDK и в примерах использования.

interface Viewapp {
   static fun init(token, userId, serverUri, apikey): Viewapp
   fun close(): Completable
   
   val sync: Sync
   val inspections: Inspections
   val user: User
   
   fun sendSupportRequest(message): Completable
}

interface Sync {
   fun forceSync()
   fun sendingProgress(): Observable<SendingStatus>
   fun receivingProgress(): Observable<ReceivingStatus>
}

interface Inspections {
   fun list(): Observable<InspectionsBundleModel>
   fun inspection(inspectionId): Observable<InspectionDetailsModel>
   
   fun startStageFlow(stage): Completable
   
   fun sendToReview(inspection): Completable
}

interface User {
   fun me(): Observable<UserModel>
}

Инициализация SDK в приложении

Для инициализации инстанса SDK используется метод init():

interface Viewapp {
   static fun init(token, userId, serverUri, apikey): Viewapp
}

token – (string) токен открытой сессии текущего пользователя, например "904822.ffb34b6110abca4df25f63fd9ba333fc";
userId – (int) идентификатор текущего пользователя из БД viewapp, например 904822;
serverUri – (string) адрес сервера для обмена данными, который будет использоваться как префик для всех запросов, например "https://web.rososmotr.ru". Адрес должен быть без завершающего слэша.
apikey – (string) ключ копии SDK, по которому определяется принадлежность к компании (должен быть выдан вам Рососмотром), например "sdk.cmp15";

Метод принимает токен, идентификатор авторизованного пользователя и вспомогательные параметры для связи с серверами. Возвращает объект SDK для последующего использования в host-приложении.

Идентификатор пользователя определяет локальную БД, поэтому важно, чтобы userId был задан корректно.

Получить токен и идентификатор пользователя необходимо через серверное взаимодействие методом /sdk/sdk_login.

Прервать сессию пользователя в дельнейшем можно методом /sdk/sdk_logout.

Завершение работы с SDK в приложении

Чтобы завершить работу SDK, необходимо вызвать метод close():

interface Viewapp {
   fun close(): Completable
}

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

Смена авторизованного пользователя

Чтобы поменять авторизованного в host-приложении пользователя, необходимо сначала вызывать close(), затем вызывать init() с новыми параметрами.

Контроль отправки и получения данных

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

Аналогично отправке, для получения изменений, SDK требуется синхронизироваться с сервером в ответ на push-уведомления или по другим событиям. Например, после отправки осмотр на проверку или после подписания.

Чтобы отслеживать процесс получения и отправки данных, host-приложению необходимо подписаться на события sendingProgress() и receivingProgress().

Принудительно запустить обмен данными с сервером можно методом forceSync(). Отследить ход синхронизации можно через всё ту же подписку на sendingProgress() и receivingProgress(). Метод принудительной синхронизации сработает только на экранах, которые в навигации работают до экранов по flow просмотра / выполнения этапов осмотра. И только при условии, что в этот же момент не выполняется синхронизация, запущенная ранее (запущенная через force или автоматически).

interface Viewapp {
   val sync: Sync
}

interface Sync {
   fun forceSync()
   
   fun sendingProgress(): Observable<SendingStatus>
   
   fun receivingProgress(): Observable<ReceivingStatus>
}

// SendingStatus
{
   "hasAnyToSend": true,
   "inProgress": true,
   "shortMessage": "отправка файлов",
   "description": "не удаляйте приложение, пока выполняется отправка данных",
   "error": ***Error
}

hasAnyToSend – (bool) флаг: есть ли данные на отправку или всё полностью отправлено;
inProgress – (bool) флаг: выполняется ли отправка прямо сейчас или нет связи, нечего отправлять;
shortMessage – (string) подсказка о текущем этапе отправки, например "отправка файлов", имеет смысл только при inProgress == true;
description – (string) расширенная версия подсказки или предостережение, имеет смысл только при inProgress == true,
error – один из вариантов ошибок, которые НЕ прерывают работу SDK (см. ниже).

// ReceivingStatus
{
   "inProgress": true,
   "shortMessage": "загрузка списка осмотров",
   "error": ***Error
}

inProgress – (bool) флаг: выполняется ли получение данных прямо сейчас или нет необходимости или нет связи;
shortMessage – (string) подсказка о текущем этапе получения данных, например "загрузка списка осмотров", имеет смысл только при inProgress == true;
error – один из вариантов ошибок, которые НЕ прерывают работу SDK (см. ниже).

Подписку на sendingProgress() и receivingProgress() предлагается использовать для визуализции прогресса синхронизации. Чаще всего, это необходимо на вспомогтельных экранах с лоадерами.

Работособность SDK и доступные пользователю операции жёстко зависят от синхронизации только при первом старте, когда локальная БД не заполнена никакими осмотрами, и после действий, совершенных на уровне сервер-to-сервер.

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

К примеру, вы программно создали новый осмотр для своего клиента, и теперь нужно, чтобы осмотр максимально быстро появился в host-приложении. В таком случае подходит вызов forceSync() с последующим показом экрана загрузки. На экране нужно отображать сообщения из SendingStatus и ReceivingStatus, ориентируясь на совокупность флагов в обеих подписках и поле error.

Важно учитывать, что sendingProgress() и receivingProgress() могут продуцировать ошибки, но есть ошибки связи, от которых цикл Observable и работа SDK не зависят, а есть Exception, которые нужно обрабатывать как обычно (например, через onError или try ... catch ... в зависимости от стека host-приложения).

Перечень специальных ошибок модуля sync:

class TokenMismatchError

class NoConnectionError

class NetworkTimeoutError

class CommonSyncError

TokenMismatchError – указанный в init() токен неправильный или сессия закончилась, необходима переавторизация;
NoConnectionError – нет связи с сервером или другая общая ошибка сети;
NetworkTimeoutError – связь с сервером есть, осуществляется попытка выполнить запросы, но не хватает времени для получения ответа;
CommonSyncError – общая проблема при синхронизации с сервером: начиная от временного падения серверов, заканчивая ошибкой в данных.

Host-приложение может продолжать работу с SDK, несмотря на возникшие ошибки, но в определённых сценариях пользователю следует сообщить о том, что есть проблемы.

TokenMismatchError означает, что нужно получить новый токен и выполнить программное переподключение SDK (подробнее в Смене авторизованного пользователя).

NoConnectionError – такая ошибка, на исправление которой пользователь может непосредственно сам повлиять. Рекомендуется сообщать о проблемах с подключением каким-либо способом, не блокирующим интерфейс.

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

В текущей версии SDK нет типизации этапов отправки / получения данных и нет количественных показателей: процентов, общего количества и т.п. В следующих версиях SDK это будет добавлено.

Список доступных осмотров

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

В нативном приложении список осмотров отображается на экране с карточками:

inspections

Для построения списка карточек требуется сокращённая информация. Подписка на изменение данных доступна через метод inspections.list():

interface Viewapp {
   val inspections: Inspections
}

interface Inspections {
   fun list(): Observable<InspectionsBundleModel>
}

// InspectionsBundleModel
{
   "isFirstLoadFinished": true,
   "items": List<InspectionInListModel>
}

isFirstLoadFinished – (bool) флаг: завершилась ли первичная загрузка данных или следует дождаться окончания синхронизации данных;
items – (List) массив сокращённых сведений об осмотрах.

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

class DBReadException : Exception()

Сетевые ошибки не относятся к данному методу, так как они возможны только в модуле sync.

Важно понять, как именно использовать данный метод после init().

Подписку на list() необходимо комбинировать с подпиской на receivingProgress(). Дело в том, что после первой инициализации, когда локальная БД пустая, требуется некоторое время на скачивание данных об осмотрах. Если init() делается заранее (мы рекомендуем именно такое поведение), тогда высока вероятность, что к моменту отображения осмотров в интерфейсе данные уже будут загружены.

Если нет, тогда сразу после подписки на list(), придёт пакет, в котором isFirstLoadFinished == false, а подписка на receivingProgress() в это же время выдаст флаг inProgress == true. Приложение должно будет показать пользователю лоадером или иным образом, что данные ещё не готовы для использования.

Конечно, дальше может случиться ошибка связи или загрузка завершится успешно (то есть, флаг inProgress == false и флаг isFirstLoadFinished == true), но список окажется пустым. Эти ситуации должны быть отработаны host-приложением.

Концепция загрузки данных на стороне SDK сводится к нескольким тезисам:

До первой загрузки данных не известно, есть ли осмотры у пользователя или список действительно пуст на стороне сервера.
После первой загрузки, список выдаётся из локальной БД независимо от синхронизации с сервером.
Данные об осмотрах на конкретном устройстве и на сервере НЕ ОБЯЗАТЕЛЬНО одинаковые. Актуальность на устройстве довольно условная, но таков дизайн системы. Цель такого решения — обеспечить независимость от неустойчивой связи.
Для работы с актульными данными, необходимо контролировать события из sendingProgress() и receivingProgress(), а так же флаг isFirstLoadFinished.

Структура данных InspectionInListModel:

// InspectionInListModel
{
   "id": 142369,
   "objectName": "Полное наименование объекта",
   "serviceName": "Наименование схемы осмотра",
   "image": "https://",
   "status": {
      "alias": "contract",
      "name": "Заявление принято",
      "message": "Проверка фотографий прошла успешно",
      "date": "2021-10-12 18:53:17"
   }
}

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

Данные для построения детального экрана осмотра

Детальный экран – основной экран осмотра, на котором собрана общая информация. На нём же пользователю даётся возможность выполнить какое-либо связанное с осмотром действие: выполнить этап съёмки, заполнить поля формы, отправить осмотр на проверку и т.д.

В нативном приложении детальный экран осмотра выглядит примерно так:

inspection details

Получить подписку на данные для детального экрана можно методом inspections.inspection():

interface Viewapp {
   val inspections: Inspections
}

interface Inspections {
   fun inspection(inspectionId): Observable<InspectionDetailsModel>
}

Структура продуцируемых данных:

// InspectionDetailsModel
{
   "id": 142369,
   "objectName": "KASKO Lexus UX I",
   "serviceName": "Automobile loss settlement",
    
   "status": {
      "alias": "draft",
      "name": "The inspection is incomplete",
      "message": "You have not completed the inspection...",
      "date": "2021-03-23 21:37:42"
   },
   "statusList": [
      {
         "alias": "draft",
         "ord": 1,
         "short": "осмотр не завершён",
         "description": "Вы не завершили осмотр или...",
         "datetime": "2019-06-03 06:04:16",
         "isPassed": false,
         "isCurrent": true
      },
      {
         "alias": "expertise",
         "ord": 3,
         "short": "экспертиза",
         "description": "Сделанные вами фотографии переданы на проверку",
         "datetime": null,
         "isPassed": false,
         "isCurrent": false
      }
   ],
    
   "isChecklist": false,

   "stages": List<InspectionStageModel>,

   "allowedActions": [
      "sendToReview",
      "makeAgreement"
   ],

   "extraButtons": [
      {
         "isDoc": true,
         "icon": "https://web.rososmotr.ru/img/extra_buttons/pdf.png",
         "text": "Акт об осмотре",
         "subText": "PDF",
         "size": "0,73 Мб",
         "url": "https://web.rososmotr.ru/pdf/inspection_test_4222b902d.pdf",
         "ord": 1
      }
   ]
}

поля status и statusList связаны между собой:
status – текущий статус осмотра по данным из локальной БД;
statusList – список статусов, через которые осмотр проходил или будет проходить — помогает добавить наглядности для пользователя.
- statusList.isPassed – (bool) флаг: считается ли данный статус пройденным для текущего осмотра;
- statusList.isCurrent – (bool) флаг: является ли данный статус текущим статусом осмотра.

Один и тот же статус может многократно повторяться в осмотре, так как предусмотрен возврат на доработку и повторная экспертиза (можно много раз).

extraButtons – массив дополнительных материалов или действий — в него, в том числе, выдаётся ссылка на документ до и после подписания (файл НЕ кэшируется SDK и должен быть загружен host-приложением, при необходимости).

Структура и примеры заполнения модели InspectionStageModel:

// InspectionStageModel
{
   "type": "formGroup",
   "key": "person",
   "ord": 1,
   "icon": "https://",
   "title": "Policyholder",
   "subTitle": "Form",
   "state": "done"
}

{
   "type": "singleShooting",
   "key": "1725",
   "ord": 3,
   "icon": "https://",
   "title": "Car",
   "subTitle": "Shooting",
   "state": "alarm"
}

{
   "type": "multiShooting",
   "key": "1903",
   "ord": 4,
   "icon": "https://",
   "title": "Equipment",
   "subTitle": "Repeat shooting",
   "state": "todo"
}

поле с изображением icon в текущей версии SDK выдаёт ссылку на файл в интернете, либо пустую строку, когда изображения нет (кэшировать картинку в текущий момент host-приложению необходимо самостоятельно);
state – состояние готовности этапа, может иметь один из вариантов заполнения:
- "todo" – этап ещё не заполнялся, пользователь начнёт делать его впервые;
- "alarm" – пользователь начинал выполнять этап, но не завершил; или эксперты вернули этап на доработку;
- "done" – минимально необходимые, но достаточные операции по этапу выполнены.

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

Вместо данных по подписке на inspections.inspection() может вылететь ошибка. Перечень возможных ошибок, которые host-приложению крайне желательно уметь перехватывать и обрабатывать, так как это необратимые ошибки — после них прерывается эмит для Observable (перечень не ограничивается следующими типами):

class WrongInspectionIdException : Exception()

class DBReadException : Exception()

WrongInspectionIdException – осмотр с указанным идентификатором не найден в локальной БД;
DBReadException – необратимые проблемы при чтении локальной БД, требуется перезапуск всей цепочки действий или перезапуск приложения.

Сетевые ошибки не относятся к данному методу, так как они возможны только в модуле sync.

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

Полные данные по осмотру в его актуальном состоянии на сервере, включая ссылки на материалы осмотра, можно получить через серверный запрос к методу /inspection/inspection_v4. Бизнес-логика – принимаемые компанией решения по осмотру пользователя – должна строиться на этих данных.

Взаимодействие с осмотром

Через SDK над осмотром доступно 2 вида действий:

Выполнение этапа осмотра.
Отправка осмотра на проверку.

Отдельно предусмотрено действие подписания итогового документа по осмотру, но это действие в текущий момент host-приложение должно обеспечить самостоятельно.

1. Просмотр / выполнение этапа осмотра

Этап осмотра – это просмотр / редактирование полей формы или выполнение съёмки по шагам, или просмотр готовых материалов по ним же.

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

inspection stages

Чтобы перенаправить пользователя к просмотру или выполнению очередного этапа осмотра, необходимо использовать метод startStageFlow():

interface Viewapp {
   val inspections: Inspections
}

interface Inspections {
   fun startStageFlow(stage): Completable
}

stage – (InspectionStageModel) объект, полученный через inspections.inspection(), описывающий нужный этап.

Метод вызовет цепочку экранов, полностью выполняемых SDK. Результатом будет либо возврат к детальному экрану осмотра, либо добавление новых материалов и затем возврат к детальному экрану осмотра, либо необратимая ошибка.

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

Если используется кнопка “Продолжить”, тогда host-приложение должно самостоятельно определить, в какой следующий этап направить пользователя. Или же, вообще, следующим действием должно стать подписание итогового документа или перевод осмотра на проверку.

Логика выбора следующего действия такая:

Найти первый попавшийся незавершённый этап с типом, определяющим съёмку. Удобнее искать первый stage, для которого type != "formGroup" AND state IN ("alarm", "todo"). То есть, этап не является группой формы и по статусу он требует доработки или ещё не выполнялся.
Когда закончились этапы съёмки, пробуем взять первый попавшийся незавершённый stage с формой. Это type == "formGroup" AND state IN ("alarm", "todo").
Если выполнены все этапы (и по съёмке, и по заполнению полей формы), тогда смотрим, можно ли отправить осмотр на проверку. Возможность и своевременность такого действия определяется по наличию элемента sendToReview в массиве allowedActions.
Наконец, финальным действием считаем выполнение подписания итогового документа. Требуется ли выполнить подписание – определяется по наличию элемента makeAgreement в массиве allowedActions.

Правильный порядок выполнения этапов особенно важен для осмотров, выполняемых в формате чек-листов. У таких осмотров isChecklist == true. Однако, незвисимо от флага isChecklist, рекомендованный порядок обхода этапов НЕ меняется.

При выполнении действия может вылететь ошибка, которую host-приложение должно уметь перехватывать и обрабатывать (перечень не ограничивается следующими типами):

class WrongStageException : Exception()

class DBReadException : Exception()

class DBWriteException : Exception()

class FileIOException : Exception()

class PermissionException : Exception()

WrongStageException – передан неправильный объект этапа или данных по осмотру уже нет в локальной БД, желательно перезайти через список осмотров;
DBReadException и DBWriteException – ошибка работы с локальной БД, желательно перезайти через инициализацию;
FileIOException – проблемы при работе с файловой системой (обычно: нет свободного места);
PermissionException – пользователь не выдал необходимые права или забрал их, желательно подсказать пользователю, что нужны все запрошенные права.

Сетевые ошибки не относятся к данному методу, так как они возможны только в модуле sync.

После выполнения всей цепочки действий, приложение получит управление назад через Completable. До этого момента host-приложению необходимо приостановить обновление экранов по Observable от списка осмотров и/или от запроса детальных данных по осмотру.

Чаще всего, после завершения flow этапа, пользователь должен оказаться на детальном экране того же осмотра. Экран необходимо обновить по актуальным данным.

Вслед за возвратом управления host-приложению, если пользователь вносил изменения или данные осмотра обновились как-то иначе, SDK проэмитит обновление данных по подписке на Observable от метода inspections.inspection().

2. Отправка осмотра на проверку

После того, как все этапы будут выполнены, SDK выдаст доступное действие "sendToReview" в поле allowedActions детальных данных.

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

Чтобы отправить осмотр на проверку (мы называем это “перевести в экспертизу”), необходимо использовать метод sendToReview():

interface Viewapp {
   val inspections: Inspections
}

interface Inspections {
   fun sendToReview(inspection): Completable
}

inspection – (InspectionDetailsModel) модель данных осмотра.

class WrongInspectionException : Exception()

class WrongStateException : Exception()

class DBReadException : Exception()

class DBWriteException : Exception()

WrongInspectionException – передан неправильный объект осмотра или данных по осмотру уже нет в локальной БД, или нельзя подписывать осмотр в его текущем состоянии;
WrongStateException – попытка отправить осмотр на проверку раньше, чем это возможно (у осмотра в его актуальном состоянии нет "sendToReview" в поле allowedActions);
DBReadException и DBWriteException – ошибка работы с локальной БД, желательно перезайти через инициализацию.

Сетевые ошибки не относятся к данному методу, так как они возможны только в модуле sync.

Отправлять на проверку таким способом можно только те осмотры, в выдаче детальных данных для которых в массиве allowedActions есть действие "sendToReview".

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

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

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

3. Подписание итогового документа по осмотру

Подписание должно обеспечиваться host-приложением. SDK в текущей версии не умеет проводить подписание.

Запускать процесс подписания можно только для тех осмотров, в выдаче детальных данных для которых в массиве allowedActions есть действие "makeAgreement".

После завершения подписания, необходимо сообщить Рососмотру о свершившемся факте. Для этого требуется последовательно:

Вызвать метод /sdk/sdk_force_sign_v1 через серверное взаимодействие, и обозначить тем самым, что осмотр подписан пользователем.
Принудительно запустить сеанс синхронизации данных для текущего инстанса SDK.
Обновить экран осмотра после завершения синхронизации.

Информация о текущем пользователе

Данные о пользователе текущей сессии доступны через метод user.me():

interface Viewapp {
   val user: User
}

interface User {
   fun me(): Observable<UserModel>
}

Содержимое ответа (другие поля не гарантируются и не должны использоваться в коде host-приложения):

// UserModel
{
   "id": 17901,
   "lastName": "Иванов",
   "firstName": "Иван",
   "middleName": "Иванович",
   "phone": "+71234567890",
   "role": "agent",
   "language": "ru"
}

class FirstLoadException : Exception()

class DBReadException : Exception()

FirstLoadException – данные запрошены раньше, чем SDK успела синхронизироваться хотя бы раз;
DBReadException – ошибка работы с локальной БД, желательно перезайти через инициализацию.

Сетевые ошибки не относятся к данному методу, так как они возможны только в модуле sync.

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

Остальную информацию о пользователе можно получить запросом /user/user_v2 через взаимодействие между серверами.

Обращение в поддержку с отправкой отладочной информации

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

interface Viewapp {
   fun sendSupportRequest(message): Completable
}

message – (string) поясняющее сообщение от пользователя, например "Не вижу назначенный на меня осмотр №А435".

Метод может вызвать любой вид ошибок, включая сетевые!

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

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

Полученные от пользователей обращения доступны программно здесь: /support.

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

Оглавление

Общий принцип использования в host-приложении

Доступные методы

Инициализация SDK в приложении

Завершение работы с SDK в приложении

Смена авторизованного пользователя

Контроль отправки и получения данных

Список доступных осмотров

Данные для построения детального экрана осмотра

Взаимодействие с осмотром

1. Просмотр / выполнение этапа осмотра

2. Отправка осмотра на проверку

3. Подписание итогового документа по осмотру

Информация о текущем пользователе

Обращение в поддержку с отправкой отладочной информации

Описание

Конвейеры