Разработка мобильного приложения на платформе 1С: от конфигурации до публикации
Содержание
Мобильное приложение на 1С собирают из обычной конфигурации: платформа «1С:Предприятие» запускает её на Android и iOS через отдельную мобильную платформу. Сделать такое приложение можно двумя путями — автономное приложение с локальной базой прямо на телефоне или мобильный клиент, который работает онлайн с серверной базой.
Разработка идёт в том же Конфигураторе, что и обычная конфигурация, но с ограничениями: только управляемые формы, урезанный набор объектов, своя встроенная СУБД на устройстве. Ниже — весь путь: от выбора режима и подготовки конфигурации до публикации на веб-сервере, тестирования на реальном телефоне, сборки APK и выпуска в магазины.
Автономное приложение или мобильный клиент: что выбрать
С этого вопроса начинается любой проект. От ответа зависит архитектура, объём работы и способ распространения.
Автономное приложение хранит данные в локальной базе на телефоне и работает без связи. С основной базой 1С оно синхронизируется планами обмена — периодически, когда есть интернет. Подходит для выездных сотрудников: заявки, осмотры, инвентаризация в зоне без сети.
Мобильный клиент — это «тонкий клиент» для телефона: он держит постоянную связь с серверной базой и показывает её данные онлайн, как веб-клиент. Своей базы на устройстве нет. Подходит, когда связь стабильна, а данные должны быть всегда актуальными. Работает на платформе не ниже 8.3.14.
Для внутреннего использования мобильный клиент почти ничего не требует собирать. 1С публикует в магазинах универсальное приложение «1С:Предприятие. Мобильный клиент» — устанавливаете его на телефон и подключаете к своей опубликованной базе. Отдельный APK нужен, только если хотите приложение под своим именем и иконкой.
Что подготовить перед разработкой
Мобильная платформа — это отдельный дистрибутив, он не входит в обычную поставку «1С:Предприятия». Его скачивают из личного кабинета и устанавливают дополнительно к основной платформе.
Главный шаг, без которого ничего не запустится, — назначение использования. В Конфигураторе откройте свойства корневого узла конфигурации и в поле Назначение использования добавьте значение Мобильное устройство. Если приложение только мобильное — оставьте одно это значение; если конфигурация кросс-платформенная, укажите и Персональный компьютер, и Мобильное устройство.
Сразу держите в голове ограничения мобильной платформы — они жёстче, чем у десктопа:
- 🧩 только управляемые формы, обычные формы не поддерживаются;
- 🗄️ своя встроенная СУБД на устройстве — она проще серверной, часть конструкций языка запросов недоступна в автономном режиме;
- 🚫 нет COM, внешних компонент в привычном виде, многих объектов работы с файловой системой;
- 📦 размер и состав конфигурации стоит держать компактным — телефон не сервер.
Поэтому мобильную конфигурацию обычно делают отдельной, а не пытаются целиком затащить на телефон большую учётную систему.
Публикация конфигурации на веб-сервере
Телефон не подключается к мобильной конфигурации напрямую — он скачивает её с веб-сервера. Поэтому следующий шаг после подготовки конфигурации — публикация.
Нужен работающий веб-сервер: на Windows это обычно IIS, кросс-платформенно — Apache. Публикация выполняется из Конфигуратора: меню Администрирование → Публикация на веб-сервере. В окне публикации указывается имя публикации, каталог и веб-сервер, а для мобильной разработки включается соответствующий вариант — публикация мобильного клиента или автономного мобильного приложения.
Разница по режимам:
- для мобильного клиента публикуется ваша информационная база с включённой опцией мобильного клиента — телефон подключается к ней онлайн;
- для автономного приложения публикуется сама мобильная конфигурация — тестовое или собранное приложение скачивает её и разворачивает локальную базу на устройстве.
Веб-сервер должен быть доступен с телефона по сети. Если разработка идёт на локальной машине, телефон и компьютер должны быть в одной сети, а в адресе публикации используйте реальный IP компьютера, а не localhost.
После успешной публикации у вас появится адрес вида http://ip-адрес/имя_публикации — именно его вы дадите тестовому приложению на телефоне.
Интерфейс и функции устройства
Интерфейс мобильного приложения строится на управляемых формах, но проектировать его нужно под маленький экран и палец, а не под мышь. Крупные элементы, минимум колонок в списках, вынос частых действий на видное место.
Формы адаптируются автоматически, но ширину и порядок элементов стоит проверять на реальном разрешении. Рабочий стол и панель разделов на телефоне выглядят иначе, чем на компьютере, — продумайте, что вынести на главный экран.
Отдельная ценность мобильного приложения — доступ к функциям телефона. Платформа даёт встроенные средства:
- 📷 камера и работа с изображениями — через объект
СредстваМультимедиа(снимок, выбор из галереи); - 📍 геопозиция — через
СредстваГеопозиционирования(координаты, адрес); - ☎️ звонки и SMS — через средства телефонии;
- 🔔 push-уведомления и локальные оповещения;
- 🧾 сканирование штрихкодов и QR камерой.
Сканирование штрихкодов — отдельный сильный сценарий: приёмка товара, инвентаризация, проверка маркировки прямо с телефона вместо стационарного ТСД.
Push-уведомления требуют регистрации приложения в службе отправки уведомлений. Для автономного приложения заранее заложите в проект, по каким событиям и через какой сервис будете их слать, — встроить это постфактум сложнее.
Данные и синхронизация с основной базой
Для мобильного клиента вопрос синхронизации не стоит: он и так работает с серверной базой онлайн. Всё, что ниже, — про автономное приложение.
Автономное приложение держит локальную базу на телефоне и обменивается данными с центральной базой 1С. Классическая схема — планы обмена: мобильное приложение и основная база настроены как узлы, обмен идёт сообщениями в формате XML.
Транспорт сообщений в мобильном приложении — веб-сервисы или HTTP-сервисы основной базы. Телефон при наличии связи отправляет свои изменения и забирает чужие. Обмен запускают по расписанию, по кнопке или по событию (например, при появлении интернета).
Проектируйте приложение как offline-first:
- Все операции должны проходить локально, без ожидания сервера.
- Конфликты изменений (один документ правили и на телефоне, и в базе) нужно продумать заранее — кто главный, как разрешать.
- На телефон выгружайте только нужные данные: справочники и документы конкретного сотрудника, а не всю базу.
Полная выгрузка большой базы на телефон — частая ошибка на старте. Локальная СУБД телефона не рассчитана на миллионы записей: ограничивайте состав данных отбором по сотруднику, периоду, организации.
Отдельно продумайте поведение при обрыве связи во время обмена. Планы обмена регистрируют изменения по узлам, поэтому неотправленные данные не теряются — они уйдут при следующей успешной синхронизации. Но если сообщение частично дошло, важно, чтобы повторная отправка не задвоила документы: проверьте идемпотентность обработки на стороне приёма.
Тестирование и отладка на телефоне
Собирать APK ради каждой проверки не нужно. Для разработки есть тестовое приложение мобильной платформы — универсальная оболочка, которую один раз ставят на устройство. Она загружает вашу опубликованную конфигурацию и запускает её.
Порядок проверки на реальном устройстве:
- Установите на телефон тестовое приложение мобильной платформы (APK для Android).
- В нём добавьте приложение, указав адрес публикации с веб-сервера (можно вводом URL или сканированием QR-кода, если публикация его показывает).
- Приложение скачает конфигурацию и развернёт базу — дальше работаете как в готовом приложении.
Для поиска ошибок доступна отладка по сети. В Конфигураторе включается режим отладки, в настройках мобильного приложения указывается адрес и порт отладчика, и тогда точки останова и пошаговое выполнение работают прямо во время запуска на телефоне. Это сильно быстрее, чем гадать по логам.
Проверяйте на нескольких устройствах и версиях ОС: поведение на разных экранах, камерах и версиях Android отличается. Отдельно протестируйте работу без сети и повторную синхронизацию после её появления.
Сборка APK и выпуск в магазины
Когда приложение готово, его собирают в установочный файл: APK (и AAB) для Android, IPA для iOS. Делает это сборщик мобильных приложений — веб-сервис от 1С. Вы заводите приложение, указываете конфигурацию (автономную или мобильный клиент), название, иконку, версию и ключи подписи, а на выходе получаете готовый дистрибутив.
Для подписи нужны:
- 🤖 Android — хранилище ключей (keystore): алиас и пароли. Один раз созданный ключ храните бережно — потерять его значит не иметь возможности обновлять то же приложение в магазине;
- 🍏 iOS — учётная запись Apple Developer, сертификаты и профили подготовки (provisioning profile). Без них собрать и подписать приложение для iPhone нельзя.
Куда публиковать готовое приложение:
| Магазин | Для кого | Стоимость (ориентировочно) |
|---|---|---|
| RuStore | Россия, Android | бесплатно |
| Google Play | Android, мир | разовый взнос разработчика, ~2000 ₽ |
| App Store | iOS | годовая подписка Apple Developer, ~8–9 тыс. ₽/год |
Числа примерные и зависят от курса и условий магазина — уточняйте на момент регистрации.
Для внутреннего корпоративного приложения магазин не обязателен. Android-приложение можно раздавать прямым APK (на устройстве включается установка из неизвестных источников) или через систему управления устройствами (MDM). Это быстрее и без модерации, но и без автоматических обновлений из магазина.
Если нужен просто доступ сотрудников к базе, а не продукт для продажи, не тратьте время на сборку и магазины: поставьте готовый «1С:Предприятие. Мобильный клиент» из магазина и опубликуйте базу с включённым мобильным клиентом. Своя сборка нужна ради бренда, автономной работы и публичного распространения.
Типичные ошибки при разработке мобильного приложения
Эти промахи всплывают не на старте, а ближе к публикации — когда переделывать дороже.
- 🔀 Разные версии мобильной платформы и конфигурации. Если приложение собрано на одной версии платформы, а устройство работает на другой, оно может не запуститься или падать. Держите версии совместимыми и проверяйте это при каждом обновлении.
- 🌐 Забыли про модуль расширения веб-сервера. Публикация с IIS или Apache требует установленного модуля веб-сервера от 1С. Без него каталог публикации создаётся, но телефон конфигурацию не получает.
- 📝 Потеряли ключ подписи Android. Keystore, которым подписан релиз в магазине, уникален. Потеряли файл или пароль — обновить то же приложение новым билдом уже не выйдет, придётся публиковать заново под другим именем. Храните ключ в надёжном месте с бэкапом.
- 🍏 Просрочили сертификаты iOS. Сертификаты и профили подготовки Apple имеют срок действия. Истёк — приложение перестаёт устанавливаться и собираться. Следите за датами и обновляйте заранее.
- 📱 Тестировали только на эмуляторе. Камера, геопозиция, push и производительность на реальном телефоне ведут себя иначе. Финальную проверку делайте на устройствах, которыми пользуются сотрудники.