Мобильная платформа 1С для приложений

В этой статье я расскажу об очень интересном направлении 1С, а именно о мобильной платформе для разработки приложений.

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

  1. высокая распространённость данной платформы у конечных пользователей по всему миру;
  2. простота и удобство публикации, отладки и монетизации своих разработок.

В результате основная площадка получения ПО для Android «ломится» от выбора ПО, начиная от простых поделок типа «Hello, World» и заканчивая профессиональными программными комплексами, такими как WPS Office.

Фирма 1С так же не осталась в стороне от данной тенденции и предоставила разработчикам механизмы создания, отладки и публикации продуктов на платформе Android и iOS. На самом деле, в этом направлении 1С не стала изобретать велосипед, а портировала платформу на вышеуказанные платформы, но есть нюансы и отличия от основного ПО. Об ограничениях, отличиях от обычной платформы я вкратце расскажу ниже.

Картинки, список объектов и ограничения использования взял с портала ИТС, так как все равно лучше ИТС-а картинки не нарисую и списки тоже, так что, просьба — сильно не пинать.  

Что такое платформа для мобильных устройств в 1С

Как написано на сайте ИТС — платформа для мобильных устройств содержит компоненты для отладки и сборки мобильных приложений, работающих на устройствах с операционными системами Android, iOS или Windows. Попробую пояснить это определение на примере из своей практики.

Для создания, модификации, отладки программист 1С использует свой рабочий компьютер и свою «офисную» платформу. Отличие от обычной  разработки начинается с формирования основных настроек конфигурации, а именно «Назначение использования»:

Рис. 1 Варианты назначения использования конфигурации

Как видим, у нас имеется 2 варианта разработки, один из которых – Приложение для мобильной платформы. Это как раз наш вариант. Если данный пункт выбран, станут доступны еще некоторые настройки, например:

Рис. 2 Использование функционала мобильной платформы

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

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

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

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

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

Опишу вкратце все 3 варианта. Описание краткое, без учета нюансов работы вариантов.

Мобильный клиент

Не буду переписывать статью ИТС, поэтому скажу своими словами – этот вариант – практически полный аналог Web-клиента, с той лишь разницей, что в нем доступен функционал платформы, без ограничений Web-браузера.

Архитектуру мобильного клиента можно представить следующим образом (рис. 3).

Рис. 3 Архитектура мобильного клиента

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

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

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

Архитектуру мобильного клиента с автономным режимом можно представить следующим образом (рис. 4).

Рис. 4 Архитектура мобильного клиента с автономным режимом

Мобильная платформа 1С

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

Основная черта этого варианта – на мобильном устройстве содержится своя собственная база данных (в принципе тот же файл 1Cv8.1CD), и имеет собственную конфигурацию.

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

Архитектуру мобильной платформы можно представить следующим образом (рис. 5).

Рис. 5 Архитектура мобильной платформы

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

При разработке мобильного приложения поддерживаются следующие объекты конфигурации и механизмы системы:

● Подсистемы;

● Константы;

● Справочники;

● Документы;

● Журналы документов;

● Регистры накопления, кроме разделения итогов и режима агрегатов;

● Регистры сведений;

● Обработки;

● Перечисления;

● Права доступа (с ограничениями), роли;

● Пользователи информационной базы (с ограничениями);

● Функциональные опции;

● Параметры сеанса;

● Планы обмена за исключением планов обмена с установленным признаком РИБ)

● Управляемые блокировки;

● Подписки на события;

● Запросы;

● Динамический список (с ограничениями);

● Использование Web-сервисов без возможности создания Web-сервиса в мобильном прикладном решении;

● Общие картинки;

● Общие команды и группы команд;

● Общие макеты;

● Общие модули;

● Общие формы;

● Система компоновки данных, включая диалоги настройки;

● Условное оформление;

● Механизм XDTO без возможности создания пакетов XDTO;

● Полнотекстовый поиск;

● Языки;

● Фоновые задания;

● Механизмы отладки прикладных решений.

Не поддерживаются механизмы и объекты конфигурации:

● Переключение интерфейсов и режим совместимости интерфейсов

● Механизмы бухгалтерского учета;

● Механизмы периодических расчетов;

● Механизмы бизнес-процессов и задач;

● Механизм общих реквизитов;

● Ограничения доступа к данным;

● Хранилища настроек;

● Работа с внешними источниками данных;

● Механизм автоматизированного тестирования;

● Механизм перетаскивания;

● Стандартные функции;

● Некоторые элементы управляемых форм;

● Расширенное редактирование в элементах формы;

● Пользовательская настройка форм;

● Сохранение и восстановление данных форм в настройках;

● Информационная панель, история работы пользователя и оповещения (метод ПоказатьОповещениеПользователя());

● Отображение состояния длительных процессов (метод Состояние());

● Справочная система в мобильной платформе;

● Механизм регламентных заданий.

На этих двух списках хотел бы остановиться подробнее.

Когда я начал погружаться в это направление кодинга, у меня возникли закономерные вопросы и возмущения: «Как так нет рег. заданий? Я же хочу каждые 30 мин производить обмен с основной конфигурацией, а доп. обработку с запуском по периоду добавить в МП не смогу»; «Почему нет объектов бизнес-процессов, я, например, хочу ставить задачи Торговому представителю» и так далее.

На самом деле фирма 1С создала универсальную платформу под разные ОС: Android, iOS, ориентируясь на ограничения этих ОС, что и привело к таким ограничениям, причем они разняться не только от ОС к ОС, но и по версиям одной и той же ОС. Кроме того, часть объектов в МП просто не нужны. Вы же не будете, например, в МП реализовывать полноценный бух. учет или будете? 😉  МП нужна для, как я уже указал выше: «призванная получать первичные данные, производить минимальную обработку, и передавать данные в основную конфигурацию».

Вот такая вкратце эта самая мобильная платформа.

Ну а теперь перейду от теории к практике и расскажу, с какими проектами я сталкивался, как их решал и что в результате получилось и не получилось тоже.

  1. Первым моим заданием, с которого я начал знакомство с МП, считаю задание по созданию РМК, реализованного на мобильной кассе LiteBox http://www.it46.ru/catalog/kassy/komplekty_kassy/litebox_mobilnaya_kassa/

5 лет назад было принято решение о реализации данного оборудования конечным заказчикам. Это оборудование было довольно удобно для небольших точек продаж, имело весь функционал, который необходим (полноценная касса по закону 54-ФЗ, работа с ЕГАИС из коробки), имела на борту свое ПО для работы. Осталось дело за малым – создать свой эксклюзивный софт.

Конфигурация была написана довольно быстро, но, как всегда, не обошлось без «подводных камней». Основная проблема была в том, что МП не умела работать с асинхронными вызовами (Intent), и, соответственно, не могла передавать команды печати чеков фискальному ядру устройства. В результате пришлось дописывать прослойку на Android Studio, которая получала Intent (намеренье) от МП, передавала команду фискальному ядру, получала и передавала ответ в МП.

  • Создание на МП полнофункциональной конфигурации для Торгового представителя (дальше в тексте — ТП). На момент создания данной конфигурации использовалась система «Моби-С» https://mobi-c.ru/, но, так как штат ТП должен был сильно разрастись, и, соответственно, необходимо было покупать много доп. лицензий, было принято решение о написании собственного ПО. Этот проект был, так сказать, тренажером для опробования вариантов обмена МП с основной конфигурацией, которых, к слову, достаточно много.
  • Довольно интересная задача – написать помощник для ТП, которая, к сожалению, не была выполнена полноценно, как я не старался. Вкратце суть задачи: ТП приезжает на точку продаж, нажимает кнопку «Запись» в ПО, в результате ПО фиксирует дату/время, координаты положения ТП и записывает разговор как обычный диктофон. После окончания записи ПО так же фиксирует дату/время и координаты.

Данный проект не был завершен полностью, что связано с особенностями системы Android – на части планшетов и телефонов ОС Android переводит МП в «сон», если окно приложения неактивно. В результате, если ТП запустил ПО и перешел в другое приложение, запись звука прекращается. Можно было написать демона, который был бы резидентным и активным, но разработка ПО на Java не производилась.

  • Начну с предыстории. В торговом комплексе приобрели ТСД и мобильный принтер для того, чтобы сотрудники комплекса могли оперативно проверять цены на товары, и, при необходимости, не отходя от полки перепечатывать ценники. Но по незнанию приобрели ТСД, который имел на борту Windows CE. Кто в курсе, тот знает, насколько это устаревшая ОС. В результате и ТСД и принтер долгое время пылился на складе, так как никак не удавалось найти подходящее ПО, единственное ПО, которое более или мене подходило – это Cleverence, и rdp так же не подходило как механизм взаимодействия.

В результате была написана конфигурация, которая выполняла все функции ТСД, в рамках задачи, конечно, и проведена работа с оборудованием – мобильным принтером, которая работала онлайн через Web-сервисы. Изначально из основной конфигурации выгружались остатки и цены номенклатуры по подписке в файл csv, загрузкой в облако, и получением данных на стороне МП – то есть оффлайн.

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

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

Comments

So empty here ... leave a comment!

Добавить комментарий

Sidebar