«Жизнь вне декстопа» или мобильная разработка на 1С

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

Поэтому я хотел бы рассказать, что из себя представляет мобильная разработка, чем она отличается от привычной нам, какие у нее есть ограничения, какие существуют собственные объекты, эксклюзивные для мобильной разработки. В конце я хотел бы привести примеры из реальной жизни – те задачи, которые были поставлены передо мной. Часть из них удалось решить средствами 1С, часть – внешними средствами. На текущий момент, возможно, ситуация уже была бы немного другой.

Резюмируя эту вводную часть, хочу сказать, что мобильная разработка – это действительно очень интересная тема, которая, как я считаю, понравится многим. Это познавательно: вы узнаете не только, как разрабатывать мобильные приложения, но и все сопутствующие элементы – аппаратную часть, операционные системы, такие как Android, iOS и так далее. Это направление действительно перспективное.

Исторические предпосылки мобильной разработки в 1С

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

До смартфонов существовали КПК. Это, по сути, были мобильные устройства с теми же аппаратными компонентами: процессором, жестким диском в определенном виде, оперативной памятью. Они работали под управлением операционных систем Symbian, WinSE, Windows Mobile. Таким образом, мобильная разработка началась не с момента изобретения смартфона и его вхождения в повседневную жизнь, а значительно раньше.

Три подхода к мобильной разработке в 1С

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

Мобильное приложение

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

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

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

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

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

Второй вариант – это мобильный клиент. Если проводить аналогию, по сути, это то же самое, что веб-клиент либо тонкий клиент. У нас устанавливается небольшая программа, которая по HTTP-сервисам IaaS либо Apache обращается к центральной базе, получает оттуда данные и по сути является интерфейсной частью. Конечный пользователь либо вводит данные, либо получает итоговую информацию в виде отчетов, графиков и так далее.

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

Из минусов: основной минус – работа только онлайн. Отключился интернет – мобильный клиент перестал работать. Также он работает только с управляемыми формами. Здесь у меня был показательный проект: у заказчика основная база была на УТ 8.3.10, и он настаивал на том, чтобы все было реализовано на мобильном клиенте. В результате все формы элементов, которые использовались на мобильных устройствах, приходилось дописывать на управляемых формах. Это существенный минус. Еще один минус заключается в том, что, так же как и тонкий клиент и веб-клиент, используется лицензия.

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

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

Если говорить о плюсах и минусах, этот вариант сочетает возможности первых двух.

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

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

Второй момент: на момент публикации таких проблем уже практически нет, но ранее существовала серьезная сложность при переходе на расширения. Мобильный клиент не получал изменения расширений и использовал типовой код.

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

Специфические объекты и возможности мобильной платформы

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

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

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

Третья группа – работа с мультимедиа и сканирование штрих-кодов. В мобильных устройствах изначально присутствуют микрофон, динамики и камера. Мы записываем и воспроизводим звук, видео, делаем фотографии. Мобильная платформа 1С умеет работать со всеми этими мультимедийными ресурсами. Реализация происходит через операционную систему, но эта логика скрыта от программиста и конечного пользователя.

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

Область применения мобильных решений

Теперь об области применения. Ранее были разобраны отличия, объекты и возможности мобильной платформы. Здесь важно выделить два ключевых момента, при которых имеет смысл выбирать мобильное приложение.

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

Второй момент – оперативное получение уже сформированных данных из центральной базы. Если обратиться к изображению, видно, что это отчет, построенный на СКД. В мобильную платформу СКД была добавлена практически сразу, и отчеты на ней создаются точно так же, как и в десктопном варианте.

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

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

Возникает логичный вопрос: как поставить задачи сотруднику, если мобильное устройство разрабатывается для сотрудника склада или торгового представителя, и ему необходимо получать задания. Эта задача решается другими способами.

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

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

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

Синхронизация и интерфейс в мобильных приложениях

После рассмотрения объектов метаданных стоит отдельно остановиться на синхронизации. Синхронизация необходима в любом случае. Все варианты синхронизации, которые используются в обычных решениях, применимы и в мобильной платформе.

В моих проектах использовались HTTP-веб-запросы, FTP-запросы, облачные хранилища, обмен через файлы и другие способы. Даже если посмотреть на ограничения, например, xDTO-пакеты формально неактивны, и кажется, что их нельзя использовать.

Однако если открыть любое мобильное решение от «1С» или сторонних разработчиков, xDTO там присутствуют, но не в виде отдельных объектов, а в виде макетов.

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

Все данные консолидированы в основном меню или в обработке. Крайний правый экран на изображении, по сути, является рабочим местом, из которого можно вызвать любой объект. Если какие-то данные не добавлены в это рабочее место, доступ к ним осуществляется через меню.

Практические кейсы

Если говорить о задачах в рамках крупных проектов, с которыми мне приходилось работать, первая задача заключалась в разработке мобильного приложения на платформе 1С для мобильной кассы MSPOS-K. Возможно, кто-то уже работал с этим устройством. Это касса формата «все в одном»: планшет, касса и, как правило, банковский терминал.

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

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

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

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

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

Такая проблема возникала на всех планшетах Samsung, и с ней пришлось долго разбираться. Причина заключается в том, что в Android, так же как и в iOS, при сворачивании приложения оно переходит в спящий режим. Когда приложение засыпает, все основные потоки останавливаются, и запись прекращается.

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

В рамках этой же задачи возникла еще одна проблема. Все мультимедиафайлы сохранялись в базу данных. Файл базы данных мобильного приложения – это тот же самый файл .1sd со всеми его ограничениями: ограничением на размер файла, размер таблицы и блокировкой всей таблицы, если с ней уже работает пользователь. Это ограничение доставило существенные сложности.

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

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

Работа с мобильным оборудованием

Отдельно стоит сказать о работе с мобильным оборудованием. В настоящее время существует большое количество мобильных устройств: принтеры этикеток, мобильные кассы, внешние сканеры, мобильные терминалы, банковские терминалы и ТСД.

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

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

На текущий момент эта проблема во многом решена. Фирма «1С» выпустила 1С-подключаемое оборудование для мобильных приложений. В рамках этого решения были стандартизированы программные компоненты. Если говорить про Android, это соответствующие библиотеки, аналогичные DLL в Windows. Благодаря этому работа с мобильным оборудованием стала значительно проще.

Выводы

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

Многих новичков отпугивает мысль о том, что придется писать по-новому, изучать другой синтаксис – это не так. Код пишется в том же синтаксисе, к которому вы привыкли. Появляются новые объекты и ограничения, но изучать все с нуля не требуется. Разработка мобильного приложения выполняется на компьютере, так же как и разработка десктопных решений. Приложение просто выполняется на мобильном устройстве.

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

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

И напоследок: есть ли жизнь вне десктопа? Да, есть, и она действительно очень интересная.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT