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

в самой конфигурации могут быть процедуры которы пытаются соединиться с чем то при запуске, в модуле приложения проверьте процедуру "ПередНачаломРаботыСистемы"

и судя по скрину так и есть: конфигурация наличие обновлений для себя проверяет

(7) Да причём тут созданные объекты. Я про то, что в свойствах конфы, если стоит "Приложение для мобильной платформы", активным становится меню "Состав автономной конфигурации". И вот там нужно галочками проставить ваши объекты и выбрать приоритет основной сервер или автономный сервер. Просто у вас нигде не сказано, что это сделано.

По сути МК с автономным это два в одном (МП и МК в одной конфе/базе) и надо самому прописывать что делать при потере связи.
Метаданные дублируются - пока есть связь то обычный МК работает и МП на своих метаданных.
Связи нет - все МК пропадает и только что в МП синхронизировал осталось доступно.

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

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

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

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


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

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

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

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

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

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

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

Обычный: объекты работают с приоритетом, заданным разработчиком в составе автономного режима.

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

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

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

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

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

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

(20) То есть, автономная конфа предположительно залетает успешно. Хм... Может, МК как-то определяет, что мобильная база пуста...
(21) Из документации это прямо следует. Никакого "автоматического кэширования" нет. При переходе в автономный режим мобильный клиент остается "наедине" только с теми данными, которые загружены по плану обмена.

(25) А если попробовать вручную перевести в автономный режим?

Не очень понял, где это, но типа где-то можно :)

а ссылку можно чтоб конфу скачать?

В общем, нашел все, что нужно:
- Мобильный клиент с автономным режимом - адаптация конфигураций:
https://www.youtube.com/watch?v=jPSvu4S90EA
- Все можно посмотреть в демо-конфигурации от 1с в комплекте с платформами от 8.3.16 и выше
- Например ( у кого есть доступ): https://releases.1c.ru/version_file?nick=Platform83&ver=8.3.17.1549&path=Platform\8_3_17_1549\demodt_8_3_17_1549.zip

Будем адаптировать конфигурацию по автономный режим

herfis, спасибо про наводку про планы обмена :) Не обратил внимания

(35) Это вам спасибо за найденные материалы.

(34) Доброго дня. Спасибо за инфу, очень помогли. Сделал самописную конфу мобильно-автономным)). Методом тыка из Демо конфигурации были определены нужные объекты для переноса, таким образом успешно сделал автономку на мобильным.
Теперь о проблеме, есть другая конфа на основе БСП. Там эти объекты не приживаются, конфа даже не умеет читать директиву "#Если МобильныйАвтономныйСервер Тогда", соответственно при открытии на мобильном клиенте открывается с ошибкой и не может создать автономную конфигурацию.
Напишите мне пожалуйста, я думаю у вас опыта побольше... Спасибо

Добрый день ! Спасибо за инфо.
Кто нибудь интересовался вопросом можно ли напрямую обратиться из основного сервера к автономному ? наоборот то можно - для этого есть метод "ОсновнойСервер".
А вот обратно не нашел - только нашел способ с клиента вызывать общий модуль с приоритетом "Автономный сервер", тогда можно вернуть данные из автономного сервера на основной, но это не слишком то удобно ...

Еще большая проблема это модули объектов - которые при включении в состав автономной конфигурации какого либо объекта пытаются компилироваться и не могут, понятное дело т.к. там есть ссылки на общие модули и объекты не определенные для мобильного. Общие модули мы опять же не можем включить т.к. в них есть запрещенные объекты н-р журнал регистрации, почти везде, который вызывает ошибку.
Печально, по хорошему для мобильного варианта должны быть свои модули объекта/менеджера объекта или как то все же можно это обойти без использования оберток (#Если МобильныйКлиент Тогда) почти везде ?

Друзья. Вопрос на да/нет

Если в конфе установлен режим совместимости 8.3.14. Будет САБЖ работать? (можно лайк/диз)