Мобильный клиент с автономным режимом — это мощная технология, объединяющая преимущества онлайн-доступа к серверу и возможности офлайн-работы мобильного приложения. Однако её настройка значительно сложнее, чем запуск обычного мобильного клиента. Разберем пошагово, как обеспечить стабильную работу приложения при отсутствии интернета и почему простого "включения галочек" в свойствах конфигурации недостаточно.
Прежде всего, проанализируем, что происходит внутри системы. Мобильный клиент с автономным режимом фактически несет в себе «две сущности»: стандартный клиент, работающий напрямую с основной базой, и локальный сервер с базой данных SQLite. Когда связь пропадает, приложение переключается на этот локальный сервер. Чтобы это произошло, на мобильном устройстве (включая такие специфические устройства, как ТСД Zebra) уже должна быть развернута база данных с актуальными метаданными и накопленными данными. Если при запуске вы видите бесконечное «обновление конфигурации», это означает, что клиент пытается инициализировать локальную базу, но процесс прерывается или настроен некорректно.
Первым делом необходимо определить, какие именно объекты будут доступны пользователю без интернета. В свойствах корневого объекта конфигурации найдем пункт Состав автономной конфигурации. Рассмотрим, что там нужно настроить:
Важнейший момент, который часто упускают разработчики: автономный режим не работает без настроенного плана обмена. В отличие от обычного мобильного клиента, данные здесь не «кэшируются» автоматически. Вы должны явно указать системе, как передавать данные между основным сервером и мобильным устройством.
Проанализируем требования к плану обмена:
ПриОтправкеДанныхПодчиненному, чтобы на телефон попадали только те данные, которые относятся к конкретному пользователю.Поскольку в автономном режиме код выполняется на локальном мобильном сервере, многие стандартные функции (например, работа с журналом регистрации или COM-объектами) будут вызывать ошибки. Чтобы этого избежать, используем специальные директивы препроцессора. Рассмотрим пример кода в модуле объекта:
#Если МобильноеПриложениеСервер Тогда
// Этот код выполнится только на мобильном устройстве в офлайне
ЛокальнаяЛогикаПроверки();
#Иначе
// Этот код выполнится на основном сервере
ПолнаяПроверкаНаСервере();
#КонецЕсли
Важно: Если вы включаете общий модуль в состав автономной конфигурации, он должен быть скомпилирован без ошибок для мобильной платформы. Если в модуле есть обращения к объектам, не входящим в автономный состав, обязательно оборачивайте такие вызовы в #Если Не МобильноеПриложениеСервер Тогда ... #КонецЕсли.
Чтобы приложение «бесшовно» переходило в офлайн, необходимо запрограммировать поведение форм при потере связи. Для этого используется событие ПриИзмененииДоступностиОсновногоСервера. Выясним, как это реализовать на практике:
&НаКлиенте
Процедура ПриИзмененииДоступностиОсновногоСервера(Доступен)
Если Не Доступен Тогда
// Сервер стал недоступен, пробуем переоткрыть форму в автономном режиме
Попытка
ЭтаФорма.Переоткрыть();
Исключение
Сообщить("Работа переведена в автономный режим. Некоторые функции ограничены.");
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Для сохранения данных, которые пользователь начал вводить в онлайн-режиме, но не успел записать до обрыва связи, используйте метод ЗаполнитьПриПереоткрытии() в обработчике ПриПереоткрытии на стороне автономной формы.
Частая причина неудач при запуске автономного режима — использование старых версий платформы или неправильного режима совместимости. Разберем основные требования:
Если при каждом входе в Android-приложение вы видите индикатор обновления, проверьте следующее:
maxAllowedContentLength и таймауты выполнения скриптов).Подводя итог, можно сказать, что автономный режим — это полноценный проект по адаптации конфигурации. Вам потребуется не только расставить флаги в метаданных, но и пересмотреть логику серверного кода, настроить правила обмена данными и протестировать поведение интерфейса при программном переоткрытии форм.