Куперс

1. ТЗ проекта мобильного приложения

2. XDTO-пакеты и объекты XDTO в разработке мобильного приложения

3. Настройка обмена данными

4. Передача приложения с помощью Android файла apk

5. Тестирование мобильных приложений

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

Моя статья для Вас, если:

— Вы пишете на 1С, и в основном вся работа выполняется на типовых конфигурациях

— Вы хорошо знаете процесс создания конфигурации для ПК и стоит задача написать мобильное приложение (далее МП) или возможно внести исправления/доработки в существующее приложение.

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

Мы коротко рассмотрим весь процесс создания МП от составления технического задания (ТЗ) до компиляции готового к установке Android файла apk.

Еще уточню, мы не будем очень сильно углубляться в детали, иначе бы статья превратилась в полное пошаговое руководство по созданию МП или даже в небольшой роман))) Также не будет рассматриваться компиляция под iOS и публикация в AppStore или PlayMarket.

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

Итак, погнали!

1. ТЗ проекта мобильного приложения

Здесь, кажется, не о чем говорить. Общаемся с заказчиком, пишем все за ним. Обсуждаем хотелки, критерии интерфейса, в общем все, как и в версии для ПК. Но! Хочу выделить различия составления ТЗ для МП и для ПК.

Обычно заказчик хочет видеть на экране мобильного устройства те же объекты, что и в ПК версии. Поясню, бывают случаи, когда разрабатывается, например, МП для сбора каких-либо данных, и в ЦБ эти данные обрабатываются просто как коллекция. Но когда мы говорим об отображении объектов из ЦБ на МП, нужно понимать, что перетащив/скопировав объект один в один, как есть, мы совершаем акт насилия над МП))) Все дело в том, что, во-первых, не стоит перегружать базу данных МП лишними реквизитами, так как это может привести к увеличению размера базы на устройстве и к существенному увеличению времени получения и обработки данных при обмене с ЦБ. Но и это еще не все причины! Экран МП может вместить в себе намного меньше элементов, нежели экран ПК. Поэтому, если мы перенесем даже простой справочник с десятком реквизитов, он уже будет смотреться на МП очень загроможденным. И еще, стоит учитывать, что даже если объект достаточно прост, то на его оформление нужно будет потратить минимум вдвое больше времени нежели при создании аналогичного объекта на ПК.

Также при составлении ТЗ стоит уточнить у заказчика, на каких устройствах планируется использовать мобильное приложение. И если мы говорим о качественной разработке, нужно будет провести тестирование на таком же устройстве или, как минимум, в эмуляторе этой модели. Если же в планах заказчика нет конкретного оборудования и даже нет примерного понимания размера экрана, обязательно оговариваем диапазон тестируемых экранов, например, от 5 до 10 дюймов. И, конечно же, не забываем заложить в ТЗ часы на такое тестирование.

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

Итак, подводим итог по ТЗ:

— уточняем размер устройств;
— заставляем заказчика назвать минимум реквизитов для переноса объектов из ПК на МП;
— при тестировании учитываем ориентацию и размер экрана. Проверяем удобство расположения элементов на форме.

2. XDTO-пакеты и объекты XDTO в разработке мобильного приложения

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

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

Далее я вижу такие варианты развития событий:

1. Использовать XDTO-пакеты.

Этот способ несколько более сложен, чем другие, потому как нужно вникнуть в такой объект метаданных. Хотя это очень даже удобный инструмент, когда, например, есть разработанный сторонний продукт и ему нужно обмениваться данными с 1С. Разработчик этого ПО создает xsd-схему, Вы импортируете ее в свою конфигурацию и легко получаете из xml файлов обмена данными объектов xdto. С ними намного удобней работать, чем, например, парсить, иногда огромных размеров xml.

Итак, что же нам делать с этими объектами?! xdto-пакет должен быть создан в конфигурации ЦБ и описывать структуру объекта мобильного приложения. И когда мы получим объект из МП, при чтении xdto, ЦБ будет точно знать, что у нас за объект. Важно! Порядок реквизитов в xdto и МП должен совпадать. Точно так же, если структура метаданных объектов совпадает (имя и названия реквизитов) и Вы передаете сериализованные объекты без какой-либо обработки из Цб в МП, в любом случае порядок реквизитов должен быть идентичным, иначе получите неинформативную ошибку на МП при десериализации.

2. Передавать структуру или таблицу значений вместо объектов XDTO.

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

Также сериализация подходит, если мы решаем, что объект МП будет иметь весь набор реквизитов ЦБ, то есть они будут идентичны.

Сериализация удобна еще и тем, что мы можем превратить в xml строку любой объект, который может быть сериализован (а таких много). Посмотреть эту особенность можно в синтаксис помощнике. Ищем интересующий нас объект и смотрим раздел «Доступность:», если там есть слово «Сериализуется», тогда все ок!

3. База посредник. Это еще один вариант, который также часто используется. Когда между МП и ЦБ есть еще база-посредник, которая выполняет функцию буфера. В таком случае структура МП и буферной базы идентичны и чаще всего обмениваются они между собой посредством сериализации. Буфер же может быть построен на базе БСП и обмениваться с ЦБ, используя правила обмена – «привет, КД»))).

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

Почему столько заморочек при обмене?

В ином случае мы сможем передавать из МП только примитивные типы данных (Число, Булево, Строка). А вышеописанные методы позволяют преобразовать объекты в строку и после передачи получить из нее обратно свои объекты в том же виде.

После того, как выбран метод обмена, можно приступать к созданию объектов метаданных конфигурации МП. При этом важно не забывать просматривать доступность используемых Вами объектов на мобильном приложении. Пока мобильное приложение в разработке, никто не запрещает тестить в тонком клиенте, запуская отладку и пользоваться всеми прелестями десктопного приложения. Но! Не все таким образом можно отладить и протестировать. Если используется функционал только МП, как, например, работа с геоданными, телефонией, камерой устройства, с нативным или сторонним ПО Android, — то тут удастся протестить только на реальном устройстве или на эмуляторе (например, Genymotion).

Итак, конфигурация МП написана, все что можно потестили на ПК, что дальше?

3. Настройка обмена данными

Как определить объем передаваемых данных?

Я вижу такие варианты:

1) Использовать план обмена. Конечно же, его придется создать. Тогда можно будет использовать свои правила регистрации, скажем, в подписке на события. Таким образом сможем учитывать любые задуманные отборы, чтоб на МП попало минимальное количество объектов;

2) Постоянно передавать все данные. В основном так можно делать, когда объем передаваемых данных минимален.

Вот, например: на МП передаются данные для отчетов, которые не нужно фильтровать (ДДС для руководителей) или прочая отчетность, которая нуждается только в отборе по периоду.

Или еще пример: по необходимости бухгалтер отправляет руководителю документы на подпись. У руководителя имеется МП написанное нами. Бухгалтер открывает документ который нужно завизировать, жмет кнопку «Отправить на подпись» и руководитель получает push-уведомление о том, что нужно подписать документ. Переходит в МП и получает конкретно один документ, который ожидает подписи (например, такие доки будут храниться в регистре сведений со статусом «Ожидает подписи»).

Данные мы отобрали, как же их передавать с ЦБ на МП и обратно?

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

4. Передача приложения с помощью Android файла apk

Компиляция

Передать клиенту готовый результат для 1С-ника, обычно означает передать конфигурацию (cf-ник). Но это не так в случае с МП.

Что же мы должны передать клиенту?

Клиенту мы передаем конфигурацию ЦБ с новыми объектами, конечно же, вынесенными в отдельную подсистему (планы обмена, подписки на события, xdto-пакеты, http-сервисы и пр.).

Ииии))), конечно же, готовое к установке мобильное приложение! Для Android устройств это файл с расширением .apk

Как же его получить?

Это прям-таки отдельная история)))

Чтобы получить приложение apk, его нужно скомпилировать! Для этого нам нужна отдельная конфигурация которая называется «Мобильный сборщик приложений» (можно найти на сайте 1С:ИТС).

Если Вы хоть немного ориентируетесь в разработке мобильного приложения под android на java, то это существенно облегчит понимание происходящего далее.

Для того чтобы воспользоваться такой конфигурацией, нам понадобиться еще кучка стороннего софта, который используется обычно именно для компиляции приложений написанных на java. Поэтому, большинство ошибок которые будут появляться в процессе компиляции придется гуглить на форумах явистов (причем чаще всего на англ. языке).
Может это и немного пугает, что начал я с описания ошибок, но все же!
Все ошибки начинаются со строки «FAILURE: Buildfailedwithanexception.» и далее идет расшифровка.

Приведу несколько примеров ошибок и их решения:

1) Youhavenotacceptedthelicenseagreementsofthefollowing SDK components:
.
— в таком случае, скорее всего, не установлено нужное апи версии 27 (устанавливается в Androidstudio), потому как лицензия принимается именно при его установке;

2) Couldnotfindplay-services-basement.aar (com.google.android.gms:play-services-basement:15.0.1).

— эта ошибка уже поглубже будет. Она хорошо гуглится, но!

Куда вносить правки?

Тут уже надо править файлы проекта, которые используются для компиляции. Находятся они в каталоге мобильной платформы \8.3.12.67_mobile\Android\ в архивах с именами prjandroid…

В данном случае мы правим файл build.gradle
Как я узнал, вы спросите?

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

Обязательно после исправлений в файлах проекта нужно заново подгружать платформу в мобильный сборщик, так как он использует именно загруженные файлы, а не путь к каталогу (для удобства стоило бы этот момент поправить).

Бывают и другие ошибки, но способ их решения всегда сводится к гуглу и нахождению аналогичных ошибок у ява-разработчиков.

И последний важный момент про компиляцию. Если вы однажды собрали apk и отдали клиенту, он неделю его проверял и просит внести правку в виде запятой в названии формы; Вам все равно придется компилировать apk заново!

Обычно в такой ситуации думаешь: «Да ладно, внесу правку, сохраню схему конфигурации, ну, перегружу все это дело в сборщик… ииии останется только скомпилировать…». Но не тут то было! Хотя да, зачастую этих действий достаточно, но через раз бывает и так, что мы ничего не меняя в сборщике, повторно пытаемся собрать приложение и даже луна находится в той фазе, которая была во время предыдущей сборки))) но в итоге получаем какую-то новую ошибку! Да так бывает. И дело тут в том, что при компиляции дополнительно скачиваются библиотеки гугла, гредла и изменения в их коде приводит к тому, что и нам нужно править файлы проекта. Вот так! Так что не забываем закладывать часы и на это.

Использование платформы в поставке

Как же избежать мучений с компиляцией?

А такой способ есть! Можно использовать скомпилированное приложение apk в поставке (файл с названием типа 1cem-arm.apk). Отдаем его клиенту и публикуем конфигурацию мобильной платформы у себя или у клиента на одном ПК с ЦБ (так как там все равно будет крутиться веб-сервер для публикации http-сервиса). Далее пользователь просто вписывает адрес базы в МП, и установка конфигурации проходит автоматически.

По необходимости можно обновлять конфигурацию из контекстного меню не переустанавливая само приложение. И даже есть вариант автоматической проверки обновлений (настраивается в том же контекстном меню), что очень удобно. Если у нас более 5 устройств, устанавливать новую конфу каждому или объяснять, что пришло обновление, мол, обновите – это долго и мучительно. А так — поправили конфу, обновили публикацию (установив флаг «Обновлять мобильное приложение при обновлении конфигурации базы данных») и все! При следующем запуске программы мобильного приложения все получат обновление принудительно.

5. Тестирование мобильных приложений

Описанным выше вариантом (использование платформы в поставке) очень удобно тестировать приложение. Ставим себе платформу и обновляемся без повторных компиляций и установок apk.

Но как сработают точки останова?

Для этого в конфигураторе нужно настроить отладку по протоколу HTTP (и, конечно же, перезапустить конфигуратор). Таким образом можно отладить не только http-сервис, но и само МП. Для этого нужно указать параметры отладчика именно на устройстве или эмуляторе android.

Отмечу также, что если ранее Вы не разрабатывали под мобильную платформу, Вам придется установить немного стороннего софта. Естественно компоненты java для компиляции и, например, web-сервер (рекомендую apache версии 2.2), который будет полезен для отладки на Вашем устройстве.

Также важный момент: лучше брать версии софта выпущенные теми датами, когда и был выпуск вашей версии мобильной платформы. Иначе могут быть ошибки, связанные с несоответствием версий (например sdk и gradle). Так что рекомендую сразу копаться в архивах)))

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

Специалист компании ООО «Кодерлайн»

Вадим Хоменко.