Заметки из Зазеркалья

29.05.2019

Мобильный клиент с автономным режимом

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Планируется в версии 8.3.16

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

Мобильный клиент с автономным режимом может:

  1. Работать напрямую с основной инфобазой при хорошем соединении

  2. Работать офлайн когда нет связи с инфобазой

  3. Предоставлять возможность выбора (онлайн или офлайн) в случае плохой связи

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

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

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

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

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

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

В составе автономного режима также указывается приоритет открытия форм. В соответствии с приоритетом при открытии формы данные в нее будут грузиться с основного либо с автономного сервера.

Для обработки ситуации потери связи с основным сервером на клиенте появилось событие ПриИзмененииДоступностиОсновногоСервера.

С помощью метода ОсновнойСерверДоступен можно в любой момент проверить, есть ли соединение с основным сервером.

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

Добавлена инструкция препроцессору МобильноеПриложениеСервер. С помощью конструкций вида «#Если МобильноеПриложениеСервер» можно выполнять код на автономном сервере мобильного клиента.

На основании состава автономного режима создается мобильное приложение с соответствующей структурой локальной базы. Это мобильное приложение может работать в одном из трех режимов (выбираемых пользователем для конфигурации в целом):

  1. Обычный: объекты работают с приоритетом, заданным разработчиком в составе автономного режима.
  2. Автономный (офлайн): приложение работает только с локальным сервером. Работа идет только с локально доступными объектами, остальные объекты недоступны. Стандартные команды интерфейса автоматически подстраиваются под офлайн режим (соответствующие пункты меню становятся недоступны).

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

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

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

Переоткрыть форму можно программно вызовом метода Переоткрыть в обработчике события формы ПриИзмененииДоступностиОсновногоСервера. У уже открытой формы вызывается обработчик ПередПереоткрытием, у новой открываемой формы вызывается разработчик ПриПереоткрытии. В обработчиках этих событий можно проинициализировать вновь открываемую форму с учетом данных, введенных (но не сохраненных) на закрываемой форме. Перенести данные можно вручную кодом или автоматически методом ЗаполнитьПриПереоткрытии. Метод ЗаполнитьПриПереоткрытии вызывается автоматически после ПриПереоткрытии если параметр СтандартнаяОбработка = Истина. У метода ЗаполнитьПриПереоткрытии есть ограничения; если реквизиты имеют сложные типы (например, табличный документ или диаграмма) – скопировать их не получится (потому что, в частности, состояние табличного документа на клиенте доступно не полностью). В этом случае метод не скопирует ничего и сгенерирует исключение.

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

Демо работы мобильного клиента с автономным режимом:



Теги: мобильный клиент  мобильная платформа 

Рассказать друзьям: