С выходом версии платформы 1С 8.3.16 разработчикам стал доступен принципиально новый инструмент — Мобильный клиент с автономным режимом (МКАР). В отличие от классического мобильного приложения, эта технология позволяет использовать основную конфигурацию базы данных без необходимости создания отдельной «мобильной» конфигурации. В этой статье мы подробно разберем, как работает эта технология, как решить проблему конфликтов нумерации и как организовать обмен данными между мобильным устройством и центральным сервером.
Проанализируем основную разницу в архитектурных подходах. При разработке обычного мобильного приложения программист вынужден создавать отдельное дерево метаданных, описывать обмены через веб-сервисы и поддерживать две разные конфигурации. Мобильный клиент с автономным режимом работает иначе: он является «продолжением» основной базы. Если мобильное устройство находится в сети, оно работает как обычный тонкий клиент. При потере связи система переключается на локальную базу данных (SQLite), которая создается на устройстве автоматически.
Рассмотрим, как подготовить объекты конфигурации для работы в таком режиме. В свойствах каждого справочника или документа в основной конфигурации теперь можно найти признак Использовать в автономном режиме. Если этот флаг установлен, платформа включит описание этого объекта в локальную схему базы данных на мобильном телефоне.
Один из главных вопросов при внедрении автономного режима — что произойдет, если несколько менеджеров в офлайн-режиме создадут документы с одинаковыми номерами? Разберем механизм предотвращения таких конфликтов. Для обеспечения уникальности 1С рекомендует использовать префиксы мобильных рабочих мест.
Выясним, как это работает на практике. Каждому экземпляру мобильного клиента при первой регистрации в центральной базе присваивается уникальный идентификатор (номер рабочего места). Этот идентификатор должен быть включен в префикс создаваемых объектов. Посмотрим на пример логики, которую следует реализовать в модуле объекта или через подписки на события:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ЭтоАвтономноеРабочееМесто() Тогда
// Устанавливаем префикс, полученный при регистрации устройства
Префикс = ПолучитьПрефиксАвтономногоРабочегоМеста();
Номер = Префикс + Объект.Номер;
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует, что при последующей синхронизации документы от разных пользователей не «столкнутся» по номерам, а будут успешно загружены в центральную базу как уникальные записи.
Многие разработчики ошибочно полагают, что автономный режим работает полностью автоматически («из коробки»). Однако, проанализировав документацию и опыт коллег, мы видим, что логика обмена данными во многом ложится на плечи разработчика. Рассмотрим основные инструменты, которые предоставляет платформа:
ПланОбмена. В нем будут фиксироваться изменения данных, которые должны уйти на мобильные устройства.ПередПолучениемДанныхАвтономнымРабочимМестом. В этом обработчике можно программно ограничить состав выгрузки.Проанализируем пример настройки фильтрации. Допустим, нам нужно, чтобы менеджер видел только свои заказы:
Процедура ПередПолучениемДанныхАвтономнымРабочимМестом(Отказ, Данные, ПараметрыОбмена)
// Устанавливаем отбор по ответственному для текущего пользователя
Данные.Справочники.ЗаказыКлиентов.Отбор.Ответственный.Значение = ПараметрыОбмена.ТекущийПользователь;
Данные.Справочники.ЗаказыКлиентов.Отбор.Ответственный.Использование = Истина;
КонецПроцедуры
Посмотрим, как платформа адаптирует формы «на лету». Одно из преимуществ МКАР заключается в том, что разработчику не нужно рисовать формы с нуля для мобильного разрешения. Платформа старается перестроить управляемую форму так, чтобы она была удобна для сенсорного ввода. Однако для сложных форм мы рекомендуем создавать отдельные варианты интерфейса, используя проверку #Если МобильныйКлиент.
Важно помнить, что в автономном режиме недоступны некоторые функции, требующие прямого обращения к серверу (например, сложные запросы с использованием временных таблиц в некоторых контекстах или вызовы серверных процедур, не входящих в состав автономного сервера). Разберем ситуацию: если пользователь нажимает кнопку, которая должна вызвать серверный метод «тяжелого» расчета, в офлайн-режиме это приведет к ошибке, если разработчик заранее не предусмотрел локальную реализацию этого алгоритма.
Рассмотрим важные аспекты производительности. Поскольку в качестве локального хранилища используется SQLite, существуют ограничения на объем данных. Попытка выгрузить на телефон справочник номенклатуры на 500 000 позиций с остатками по всем складам приведет к значительному замедлению работы интерфейса и быстрому заполнению памяти устройства.
Основные советы по оптимизации:
Таким образом, использование мобильного клиента с автономным режимом значительно упрощает жизнь разработчику за счет единой конфигурации, но требует тщательного проектирования схем обмена и механизмов контроля уникальности данных. Мы надеемся, что этот разбор поможет вам избежать типовых ошибок при внедрении этой перспективной технологии.