Разработка мобильного приложения 1С: от среды до публикации
Содержание
Чтобы написать мобильное приложение 1С, нужны три вещи: мобильная платформа 1С:Предприятие (отдельный комплект разработки), Конфигуратор или 1C:EDT для верстки конфигурации и веб-сервер, через который телефон обменивается данными с центральной базой. Настольная платформа 8.3 для этого не подходит — у мобильной свой, урезанный набор объектов.
Типичная задача выглядит так: торговому представителю или кладовщику нужно на телефоне принимать заявки , сканировать штрихкоды и отправлять данные в учётную базу, в том числе там, где связь пропадает. Дальше — как это собрать, какую архитектуру выбрать и как довести приложение до магазина.
Что такое мобильная платформа и какую модель выбрать
На платформе 1С мобильное приложение можно сделать двумя путями, и это первое решение, которое определяет весь проект.
Мобильная платформа — вы пишете отдельную мобильную конфигурацию с собственной базой прямо на устройстве. Приложение работает автономно, а с учётной системой синхронизируется по сети. Подходит, когда нужна работа без постоянного интернета.
Мобильный клиент (доступен с версии платформы 8.3.14) — это тонкий клиент для телефона, который работает с обычной конфигурацией на сервере в режиме онлайн. Фактически существующее решение — например, 1С:УНФ или 1С:Розница — открывается на мобильном без отдельной разработки, если конфигурация поддерживает мобильный клиент.
| Критерий | Мобильная платформа | Мобильный клиент |
|---|---|---|
| База | своя, на устройстве | на сервере, телефон как клиент |
| Работа без сети | да, офлайн | нет, нужен онлайн |
| Разработка | отдельная мобильная конфигурация | дорабатывается основная |
| Когда брать | выездной персонал, слабая связь | приложение-«спутник» к учётной базе |
Если цель — дать сотрудникам доступ к готовой учётной базе из офиса и связь стабильна, начните с мобильного клиента: это в разы быстрее, чем писать автономное приложение с нуля.
Среда разработки: Конфигуратор, EDT и назначение конфигурации
Мобильную платформу скачивают отдельно от основного дистрибутива — это комплект файлов под Android и iOS. Разработку ведут в привычном Конфигураторе либо в 1C:EDT.
Чтобы конфигурация стала мобильной, в её свойствах задают назначение использования — значение Мобильное устройство. После этого в дереве метаданных остаются только объекты и свойства, которые работают на телефоне, а недоступные платформа подсвечивает.
Порядок первого запуска:
- Создайте пустую конфигурацию и в её свойствах укажите назначение
Мобильное устройство. - Опубликуйте приложение на веб-сервере (Apache или IIS) — это нужно для отладки и обмена.
- Установите на телефон мобильное приложение разработчика из Google Play или App Store.
- В приложении разработчика введите адрес публикации и подключитесь.
Набор объектов у мобильной платформы заметно у́же настольной: часть механизмов, регламентные задания и тяжёлые серверные операции недоступны либо ограничены. Это стоит проверить на старте, а не после того, как половина логики написана.
О чём договориться до начала разработки:
- Целевые ОС. Мобильная платформа собирает приложения под Android и iOS. Заранее определите минимальную версию ОС, которую поддерживаете, — от неё зависит, какие функции устройства доступны.
- Версия платформы. Берите версию мобильной платформы не ниже той, где появились нужные вам возможности (например, мобильный клиент — с 8.3.14). Разработку центральной базы и мобильного приложения держите на согласованных версиях.
- Парк устройств. Если приложение для своих сотрудников — зафиксируйте модели телефонов. Разброс «от старого Android до свежего iPhone» усложняет тестирование в разы.
Мобильная ОС в любой момент может выгрузить фоновый процесс ради экономии батареи. Не стройте логику на том, что приложение всегда «живёт» в фоне и что-то досчитывает, — синхронизацию и длительные операции запускайте, когда приложение активно.
Интерфейс и навигация мобильного приложения
Формы в мобильном приложении — управляемые, как и в настольной 1С, но платформа сама адаптирует их под узкий экран и сенсорное управление. Отдельную разметку «под Android» и «под iOS» вручную рисовать не нужно.
На что опереться при проектировании:
- 🧭 Панель разделов — верхнеуровневая навигация приложения. Не выносите в неё больше 5–7 пунктов: на телефоне длинное меню неудобно.
- 📝 Формы списка и элемента — основа почти любого экрана. Списки держите короткими, с отбором, а не «всё сразу».
- 🔀 Функциональные опции — ими скрывают и показывают реквизиты и команды, чтобы один и тот же интерфейс подходил разным ролям (кладовщик, курьер, менеджер).
- 👆 Крупные элементы управления и минимум полей на экране: ввод с телефона медленный, каждое лишнее поле снижает скорость работы.
Проектируйте интерфейс от сценария, а не от структуры базы. Сначала опишите, что сотрудник делает за смену — «открыл заявку → отсканировал товар → подтвердил» — и под эти шаги стройте экраны.
Обмен данными с центральной базой: HTTP-сервисы, веб-сервисы, OData
Автономное приложение бесполезно без обмена с учётной системой. На платформе 1С для этого есть три основных механизма, и выбор зависит от того, кто инициатор обмена.
| Механизм | Что это | Когда применять |
|---|---|---|
| HTTP-сервис | свой REST-интерфейс: вы задаёте URL и методы GET/POST | гибкий обмен, свои форматы JSON |
| Веб-сервис (SOAP) | строгий контракт с описанием | интеграция со сторонними системами по SOAP |
| OData (стандартный интерфейс) | автоматический REST поверх метаданных | быстрый доступ к справочникам и документам без написания кода |
HTTP-сервисы — рабочая лошадка для мобильной разработки. В Конфигураторе центральной базы вы создаёте HTTP-сервис, задаёте шаблоны URL и методы, пишете обработчики, а затем публикуете базу на веб-сервере. Мобильное приложение обращается к этим адресам и получает или отправляет JSON.
OData включается публикацией стандартного интерфейса и даёт доступ к данным по предсказуемым адресам без написания серверного кода. Например, список номенклатуры в формате JSON приложение запрашивает так:
http://server/base/odata/standard.odata/Catalog_Номенклатура?$format=json
Не публикуйте OData «на весь мир». Открывайте только нужные объекты через состав стандартного интерфейса и закрывайте доступ правами, иначе наружу уедет вся база.
Для обмена справочниками большого объёма (номенклатура, контрагенты) в автономной модели применяют планы обмена: они переносят только изменения, а не всю таблицу каждый раз.
Безопасность обмена. Телефон ходит в базу через интернет, поэтому публикацию держите на https, а не на открытом http: пароли и данные нельзя гонять в открытом виде. Каждому приложению заведите отдельную учётную запись с минимальными правами — ровно под те объекты, с которыми оно работает. Логин и пароль не «зашивайте» в код приложения намертво: пользователь должен вводить их при первом подключении, а приложение хранит их в защищённом хранилище устройства.
Автономная работа и локальное хранилище
Главное преимущество мобильной платформы — приложение работает без сети. Данные лежат в локальной базе прямо на устройстве, а синхронизация идёт отдельно, когда связь появляется.
Как это обычно устроено:
- При первом запуске приложение загружает с сервера начальный набор данных — справочники, остатки, задания.
- Сотрудник работает офлайн: создаёт документы, они сохраняются в локальную базу устройства.
- Как только появляется интернет, приложение отправляет накопленные изменения на сервер и забирает встречные.
Важные ограничения, которые влияют на сценарий:
- Нумерацию и контроль остатков в офлайне нельзя полностью доверить телефону — финальную проверку делайте на сервере при приёме данных.
- Конфликты (двое изменили один объект) нужно разрешать по правилу, заданному заранее: обычно «выигрывает сервер» либо «последняя запись».
- Держите на устройстве только нужные данные. Выгружать весь справочник номенклатуры из тысяч позиций на телефон курьера не стоит — берите срез под его зону.
Перед тем как раскатывать приложение на всех, прогоните сценарий «неделя без синхронизации»: что будет, если сотрудник накопил сотни документов и только потом вышел в сеть. Это типичная точка, где обмен начинает тормозить.
Камера, сканер, геолокация и push-уведомления
Ради этого мобильное приложение обычно и пишут — доступ к железу телефона, которого нет у настольной 1С. Мобильная платформа умеет работать с основными возможностями устройства:
- 📷 Камера — сделать фото и приложить его к документу (приёмка с фотофиксацией, отчёт о визите).
- 🔳 Сканирование штрихкодов и QR — встроенными средствами через камеру, без отдельного «железного» сканера.
- 📍 Геолокация — определить координаты устройства: отметка места визита, контроль маршрута, геозоны.
- 🔔 Push-уведомления — через сервис push-уведомлений 1С (его нужно подключить отдельно); так приложение сообщает о новом задании, даже когда закрыто.
- 📇 Доступ к телефонным функциям — звонок и доступ к контактам прямо из карточки клиента.
Любой доступ к железу требует разрешения пользователя (камера, геолокация). Запрашивайте право в момент, когда функция реально нужна, и объясняйте зачем — иначе сотрудник откажет, и сценарий сломается.
Точные имена объектов и методов работы с оборудованием смотрите в синтакс-помощнике Конфигуратора для мобильной платформы: там набор отличается от настольной версии, и часть функций появляется только в свежих релизах.
Тестирование, отладка и сборка приложения
Главная ошибка новичка — сразу собирать .apk. На этапе разработки сборка не нужна.
Тестирование без сборки. Мобильное приложение разработчика (бесплатно в Google Play и App Store) подключается к опубликованной на веб-сервере базе по адресу и запускает вашу конфигурацию прямо на телефоне. Отладку можно вести из Конфигуратора по подключению — точки останова работают так же, как на десктопе.
Сборка готового приложения. Когда конфигурация готова, итоговый файл собирают через конфигурацию «Сборщик мобильных приложений» от 1С. Она формирует установочный пакет:
.apkили.aab— для Android;.ipa— для iOS (требует учётной записи и сертификатов Apple).
Для сборки понадобятся компоненты Android SDK и ключи подписи. iOS без сертификатов разработчика Apple и Mac для финальной подписи не собрать — это ограничение самой экосистемы, а не 1С.
Публикация. Готовый пакет либо выкладывают в Google Play Console и App Store Connect, либо, для внутреннего приложения, раздают .apk напрямую — установкой из файла в обход магазина.
Разделяйте два вида обновлений. Изменения в данных и часть доработок конфигурации автономное приложение получает через обмен — пересобирать и переустанавливать его не нужно. А вот обновление самой сборки (новая версия платформы, смена набора разрешений, новые возможности устройства) требует новой публикации в магазине или повторной установки .apk. Планируйте выпуск заранее: заставить сотни пользователей вручную переустановить приложение — отдельная задача.
Магазины приложений проверяют сборки вручную и могут отклонить приложение из-за политик (например, по разрешениям или описанию). Закладывайте на первую публикацию запас в несколько дней.
Частые вопросы
Нужен ли программист 1С, или справится обычный разработчик мобильных приложений?
Можно ли переделать настольную конфигурацию в мобильную без переписывания?
Обязательно ли выкладывать приложение в Google Play и App Store?
.apk можно раздать сотрудникам напрямую и установить из файла. Для iOS распространение вне App Store возможно только по программам корпоративного или ad hoc распространения Apple, это сложнее.