Мобильная платформа 1С: варианты мобильных приложений, ограничения и первый проект

Мобильная платформа 1С — это вариант платформы, который запускает на Android или iOS отдельную конфигурацию с собственной локальной базой. Приложение работает без связи, а данные синхронизирует с основной базой обменом, обычно через HTTP-сервис. Кроме неё есть ещё мобильный клиент (онлайн-доступ к основной базе) и мобильный клиент с автономным режимом. Выбор между ними — первое и главное решение в проекте.

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

Три варианта мобильного приложения на 1С

Мобильный клиент — по сути тонкий клиент для смартфона. Подходит, когда связь стабильная и нужна та же функциональность, что в офисе: согласования, просмотр отчётов, ввод заказов. Отдельную конфигурацию писать не нужно, но формы стоит адаптировать под маленький экран.

Автономный режим — гибрид: часть данных и логики доступна без связи, затем синхронизируется. Требует поддержки со стороны конфигурации.

Мобильная платформа — самостоятельное приложение. Его выбирают, когда сотрудник работает там, где связи нет или она плохая: склад, выездная торговля, инвентаризация, мерчендайзинг. Это самый трудоёмкий вариант: нужно спроектировать конфигурацию, интерфейс и обмен.

На проектах я начинаю с вопроса «есть ли связь там, где работает пользователь». Если да, почти всегда достаточно мобильного клиента. Если нет — мобильная платформа.

Ограничения мобильной платформы

Мобильная конфигурация поддерживает основной набор объектов: константы, справочники, документы, журналы, регистры сведений и накопления, перечисления, обработки, общие модули и формы, планы обмена (кроме РИБ), запросы, СКД, фоновые задания. Но многое из «офисной» платформы недоступно. По документации платформы, среди неподдерживаемого:

• бухгалтерские и расчётные механизмы (планы счетов, планы видов расчёта, регистры бухгалтерии и расчёта);
• бизнес-процессы и задачи;
• общие реквизиты и ограничение доступа к данным на уровне записей;
• внешние источники данных;
• регламентные задания;
• пользовательская настройка форм и часть элементов управляемых форм;
• создание собственных веб-сервисов и пакетов XDTO внутри мобильного приложения.

Список меняется от версии к версии платформы, поэтому перед проектированием сверяйтесь с документацией именно вашей версии. Практический вывод: в мобильное приложение не переносят типовую конфигурацию, а проектируют компактную модель данных под конкретную задачу — «что нужно сотруднику в поле».

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

Порядок разработки

Разработка ведётся в обычном конфигураторе на компьютере.

1. Создайте конфигурацию и в её свойствах установите назначение использования «Приложение для мобильной платформы». После этого конфигуратор начнёт контролировать, что вы используете только поддерживаемые объекты.
2. Отметьте используемые разрешения — камера, геопозиция, сеть и т. д. Из них формируются разрешения в манифесте приложения при сборке.
3. Спроектируйте начальную страницу. На мобильном устройстве доступна одна колонка, поэтому рабочее место строится из одной-двух общих форм с крупными элементами.
4. Опубликуйте конфигурацию для отладки. В конфигураторе есть команда публикации мобильного приложения на веб-сервере: конфигурация выкладывается на веб-сервер в виде XML-описания.
5. Установите на устройство мобильную платформу для разработчика и загрузите в неё приложение по адресу публикации. После изменений достаточно обновить публикацию и перезагрузить приложение на устройстве.

Отлаживать лучше на реальном устройстве: эмулятор Android работает медленнее и не всегда корректно ведёт себя с камерой и сканером. Для итоговой поставки приложение собирается в установочный пакет сборщиком мобильных приложений — он объединяет мобильную платформу и вашу конфигурацию.

Интерфейс под маленький экран

• Минимум полей на форме: только то, что пользователь заполняет в поле. Остальное — на сервере.
• Табличные части: группы колонок, чтобы строка помещалась в ширину экрана; ввод строки в отдельной форме.
• Крупные кнопки основных действий, без глубоких меню.
• Сканирование штрихкода как основной способ ввода номенклатуры вместо выбора из списка.

Обмен с основной базой

Самая важная часть проекта. Обычная схема: в основной базе — HTTP-сервис, мобильное приложение обращается к нему через HTTPСоединение, данные идут в JSON. Внутри мобильной конфигурации регистрация изменений ведётся планом обмена, чтобы отправлять только изменённое.

Пример выгрузки документов из мобильного приложения:

// Отправляет данные документов в основную базу. Возвращает Истина при успехе.
Функция ОтправитьДокументы(ДанныеДокументов) Экспорт

	ЗаписьJSON = Новый ЗаписьJSON;
	ЗаписьJSON.УстановитьСтроку();
	ЗаписатьJSON(ЗаписьJSON, ДанныеДокументов);
	ТелоЗапроса = ЗаписьJSON.Закрыть();

	Соединение = Новый HTTPСоединение(АдресСервера(), , ИмяПользователяОбмена(),
		ПарольОбмена(), , 30, Новый ЗащищенноеСоединениеOpenSSL);

	Запрос = Новый HTTPЗапрос("/base/hs/mobile/documents");
	Запрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	Запрос.УстановитьТелоИзСтроки(ТелоЗапроса, КодировкаТекста.UTF8,
		ИспользованиеByteOrderMark.НеИспользовать);

	Попытка
		Ответ = Соединение.ОтправитьДляОбработки(Запрос);
	Исключение
		// Связи нет — данные останутся зарегистрированными и уйдут при следующем обмене.
		Возврат Ложь;
	КонецПопытки;

	Возврат Ответ.КодСостояния = 200;

КонецФункции

АдресСервера, ИмяПользователяОбмена, ПарольОбмена — ваши функции, читающие настройки приложения. Главное правило: снимать регистрацию изменений только после успешного ответа сервера. Тогда потеря связи на середине обмена ничего не ломает — данные уйдут при следующей попытке.

Со стороны основной базы HTTP-сервис принимает JSON, создаёт или обновляет документы и возвращает ответ с результатом по каждому объекту. Такую интеграцию удобно проектировать вместе с остальными внешними подключениями — это та же задача интеграции 1С через API.

Частая альтернатива для справочных данных (остатки, цены) — периодическая выгрузка снимка из основной базы, который мобильное приложение загружает целиком. Это проще, чем инкрементальный обмен, если объём небольшой.

Подводные камни из практики

• Работа в фоне. Операционная система может приостановить приложение, когда оно неактивно. Долгие операции, которые должны идти при свёрнутом приложении, на мобильной платформе ненадёжны.
• Специфическое оборудование. Мобильные кассы, принтеры и сканеры часто требуют своих драйверов или внешних компонент. Проверяйте совместимость до начала разработки, а не после.
• Версии платформы. Версия мобильной платформы и сборщика должна соответствовать требованиям магазинов приложений и версий Android. Закладывайте время на обновление сборки.
• Объём данных. Локальная база на телефоне не для миллионов записей. Передавайте на устройство только то, что нужно конкретному сотруднику.
• Конфликты. Если один документ меняется и на устройстве, и в основной базе, заранее решите, чья версия главная.

Итог

• Мобильная платформа 1С запускает отдельную конфигурацию с локальной базой и подходит для работы без связи.
• Если связь есть, проще и дешевле мобильный клиент к основной базе.
• Мобильная конфигурация ограничена по объектам: проектируйте компактную модель под задачу, а не переносите типовую.
• Обмен обычно строят на HTTP-сервисе основной базы, JSON и плане обмена на стороне приложения.
• Отлаживайте на реальном устройстве и заранее проверяйте совместимость с оборудованием.

Если нужно оценить, какой вариант подойдёт под вашу задачу, это обсуждается на этапе проектирования разработки конфигурации 1С.