Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.16.1030
В мобильный клиент будет добавлена возможность автономной работы, чтобы сделать его использование более комфортным для пользователя. Раньше при работе с мобильным клиентом в случае пропадания связи с сервером останавливалась работа приложения, и если пользователь выходил из приложения до восстановления связи, могла произойти потеря данных. В случае медленного канала связи запросы к информационной базе могли выполняться долго, что негативно сказывалось на удобстве работы. Возможность автономной работы мобильного клиента призвана решить эти проблемы.
Мобильный клиент с автономным режимом может:
Работать напрямую с основной инфобазой при хорошем соединении
Работать офлайн когда нет связи с инфобазой
Предоставлять возможность выбора (онлайн или офлайн) в случае плохой связи
Задачу №1 решает сейчас мобильный клиент. Адаптация конфигурации для работы через мобильный клиент может быть проведена достаточно быстро.
Задачу №2 решает мобильная платформа. Но этот подход требует создания отдельного мобильного приложения, что может быть довольно трудоемкой задачей.
Мобильный клиент с автономным режимом совмещает в себе две этих технологии. Помимо обычного мобильного клиента он содержит локальный сервер с файловой базой данных. В рамках адаптации конфигурации под мобильный клиент с автономным режимом часть функциональности конфигурации может быть перенесена на мобильное устройство. Это, конечно, потребует некоторых трудозатрат, но это может оказаться проще, чем создавать с нуля приложение на мобильной платформе. В мобильном клиенте с автономным режимом можно реализовывать только ту автономную функциональность, которую критично иметь в офлайне, и реализовывать ее не всю сразу, а постепенно, по мере необходимости и доступности ресурсов (разработчиков). Мы ожидаем, что на практике затраты на решение задачи работы мобильного клиента при плохой связи / отсутствии связи при помощи мобильного клиента с автономным режимом будут существенно меньше по сравнению с разработкой приложения на мобильной платформе. При этом у мобильного клиента с автономным режимом будет возможность работы и офлайн (с доступом только к реализованной для офлайна функциональности), и онлайн (с полной функциональностью).
Переход в автономный режим осуществляется автоматически при исчезновении WiFi и мобильного интернета; пользователь может также включить его вручную в случае неустойчивой связи.
В рамках адаптации конфигурации под мобильный клиент с автономным режимом можно указать, какие данные конфигурации будут необходимы в автономном режиме:
Состав автономного режима можно задавать вплоть до реквизитов объектов. Например, в каком-то справочнике в определенном реквизите может находиться большой объем данных, который нецелесообразно скачивать на мобильное устройство.
В составе автономного режима также указывается приоритет открытия форм. В соответствии с приоритетом при открытии формы данные в нее будут грузиться с основного либо с автономного сервера.
Для обработки ситуации потери связи с основным сервером на клиенте появилось событие ПриИзмененииДоступностиОсновногоСервера.
С помощью метода ОсновнойСерверДоступен можно в любой момент проверить, есть ли соединение с основным сервером.
При наличии соединения возможны межсерверные вызовы; мобильный сервер вызывает основной сервер, аналогично как это бы сделал мобильный клиент. Через контекст ОсновнойСервер доступны все серверные модули, которые можно вызывать из клиента.
Добавлена инструкция препроцессору МобильноеПриложениеСервер. С помощью конструкций вида «#Если МобильноеПриложениеСервер» можно выполнять код на автономном сервере мобильного клиента.
На основании состава автономного режима создается мобильное приложение с соответствующей структурой локальной базы. Это мобильное приложение может работать в одном из трех режимов (выбираемых пользователем для конфигурации в целом):
Автономный (офлайн): приложение работает только с локальным сервером. Работа идет только с локально доступными объектами, остальные объекты недоступны. Стандартные команды интерфейса автоматически подстраиваются под офлайн режим (соответствующие пункты меню становятся недоступны).
Плохое соединение: приоритеты, заданные разработчиком в составе автономного режима, игнорируются, и все объекты, доступные локально, работают с локальным сервером. Например, в приведенном выше примере справочник Контрагенты откроется локально, даже если есть связь.
Рассмотрим ситуацию, когда мы открыли форму с основного сервера, и соединение с сервером после этого пропало. Эта форма станет недоступной до восстановления связи, но можно работать с другими формами, доступными локально. А если аналог открытой на основном сервере формы доступен локально – эту форму можно переоткрыть с локального сервера и продолжить с ней работать.
Обратная ситуация возникает, когда мы работаем с локальной формой, и соединение с сервером восстанавливается. Нам хочется открыть форму с сервера, потому что на ней доступно больше реквизитов. Для этого мы сделали механизм переоткрытия форм.
Переоткрыть форму можно программно вызовом метода Переоткрыть в обработчике события формы ПриИзмененииДоступностиОсновногоСервера. У уже открытой формы вызывается обработчик ПередПереоткрытием, у новой открываемой формы вызывается разработчик ПриПереоткрытии. В обработчиках этих событий можно проинициализировать вновь открываемую форму с учетом данных, введенных (но не сохраненных) на закрываемой форме. Перенести данные можно вручную кодом или автоматически методом ЗаполнитьПриПереоткрытии. Метод ЗаполнитьПриПереоткрытии вызывается автоматически после ПриПереоткрытии если параметр СтандартнаяОбработка = Истина. У метода ЗаполнитьПриПереоткрытии есть ограничения; если реквизиты имеют сложные типы (например, табличный документ или диаграмма) – скопировать их не получится (потому что, в частности, состояние табличного документа на клиенте доступно не полностью). В этом случае метод не скопирует ничего и сгенерирует исключение.
Процесс обмена данными между основным и локальным серверами в текущей реализации целиком возлагается на разработчика, адаптирующего конфигурацию под мобильный клиент с автономным режимом. С помощью планов обмена разработчик может вести учет изменений данных, и синхронизировать изменения, например, с помощью фоновых заданий. Это аналогично разработке приложения на мобильной платформе с обменом данными с приложением 1С на сервере.
Демо работы мобильного клиента с автономным режимом:
