Глава 28. Разработка для мобильных устройств
страницаГлава 28. Разработка для мобильных устройств
28.1. Общая информация
Система программ «1С:Предприятие» позволяет разрабатывать прикладные решения, функционирующие на мобильных устройствах (смартфоны, планшетные компьютеры). Разработанные прикладные решения могут функционировать на мобильных устройствах, которые работают под управлением операционных систем Android (http://``www.``android.``com/), iOS (http://www.apple.com/ios/) и Windows (https://``www.``microsoft.``com/``windows/). Для ОС Windows обеспечивается функционирование на устройствах с сенсорным экраном.
В зависимости от решаемой задачи, разработчик может разрабатывать приложение для мобильной платформы или приложение, функционирующее в мобильном клиенте. Между этими вариантами разработки есть существенные отличия:
● Приложение на мобильной платформе является аналогом тонкого клиента, работающего с файловой информационной базой, находящейся на том же компьютере, что и само клиентское приложение. Приложение на мобильной платформе работает с информационной базой, расположенной на мобильном устройстве. Из вышесказанного следует, что клиентская и серверная часть прикладного решения функционируют на мобильном устройстве. Наличие информационной базы на мобильном устройстве означает, что для синхронизации данных между мобильным устройством и основной системой (если таковая существует) необходимо реализовывать необходимые инструменты.
Кроме того, приложение на мобильной платформе ‑ это отдельная технология, для использования которой следует разработать полностью новое решение или существенно доработать текущее.
● Мобильный клиент является аналогом тонкого клиента для обычного компьютера, использующего для доступа к информационной базе веб-сервер. Другими словами, при работе мобильного клиента на мобильном устройстве отсутствует информационная база. В мобильном клиенте клиентский код исполняется на мобильном устройстве, а серверный код исполняется на сервере приложений. При этом, как очевидно, сервер приложений функционирует не на мобильном устройстве. Так как на мобильном устройстве отсутствует информационная база, то это означает, что мобильный клиент работает только в том случае, если между мобильным устройством и веб-сервером существует соединение. Мобильный клиент не может работать в режиме офлайн.
Для того чтобы прикладное решение работало в мобильном клиенте, необходимо не переписать его (как в случае с приложением на мобильной платформе), а адаптировать. При адаптации следует помнить о то, что мобильный клиент обладает специфическим набором особенностей и ограничений, которые следует учитывать при доработке прикладного решения. Существенной особенностью мобильного клиента является то, что он поддерживает технологию расширений конфигурации.
● Мобильный клиент с автономным режимом ‑ это мобильный клиент, для которого доступна возможность работы в автономном режиме, т. е. без подключения к информационной базе. Для того чтобы прикладное решение могло работать в автономном режиме, необходимо более существенно доработать приложение, которое может работать в мобильном клиенте. Для мобильного клиента с автономным режимом требуется выбрать набор метаданных, которые доступны в автономном режиме, реализовать формы автономного режима и способы синхронизации данных в информационной базе. С точки зрения сложности разработки, мобильный клиент с автономным режимом находится между мобильным клиентом и мобильным приложением.
Интерфейс мобильных приложений ‑ аналог интерфейса Такси. В целом, интерфейсы приложения мобильной платформы и мобильного клиента выглядят аналогично. Тем не менее, работа интерфейса в каждом из возможных вариантов обладает своей спецификой, которую следует учитывать во время разработки прикладного решения.
Также в данной главе будут использоваться следующие термины:
● Мобильная платформа ‑ определение термина см. здесь.
● Мобильная версия «1С:Предприятия». Данный термин будет использоваться в том случае, когда необходимо коротко описать все возможности, предоставляемые фирмой «1С» для разработки приложений, которые работают на мобильных устройствах. Таким образом, следующие две фразы будут эквивалентны:
● Мобильная платформа и мобильный клиент предоставляют доступ к работе с короткими сообщениями (SMS).
● Мобильная версия «1С:Предприятия» предоставляет доступ к работе с короткими сообщениями (SMS).
● Мобильное приложение ‑ будет использоваться в тех случаях, когда необходимо описать исполняемый файл, который может исполняться на мобильном устройстве. В очень близком приближении можно считать, что мобильное приложение, это apk-файл для ОС Android, ipa-файл для iOS и appx-файл для Windows.
Для разработки предоставляется инструмент разработчика: мобильная платформа разработчика или мобильный клиент разработчика (мобильная версия «1С:Предприятия» для разработчика). Эта версия обладает рядом отличий от мобильного приложения, которое распространяется через магазин приложений: ее невозможно разместить в магазине приложений, в ней установлены все возможные разрешения, которые могут потребоваться прикладному решению, она предоставляет некоторые расширенные возможности относительно мобильного приложения.
Для распространения мобильного приложения в обоих случаях необходимо использовать сборщик приложений для мобильных устройств, который является специализированным инструментом, облегчающим создание пакета, который может быть размещен в магазине приложений соответствующего поставщика мобильных операционных систем.
Данная глава посвящена особенностям разработки приложений, работающих на мобильных устройствах. При этом возможности, единые для приложения на мобильной платформе и мобильного клиента, описаны в одном разделе. В том случае, когда описываются возможности, единые для мобильной платформы и мобильного клиента, будет использоваться термин «мобильная версия «1С:Предприятия». Особенности, характерные только для одного варианта разработки будут описаны в своем разделе. Если не сказано иного, то под термином «мобильное приложение» будет пониматься любое приложение, которое может работать на мобильном устройстве (приложение мобильной платформы или мобильный клиент).
Разработчику, который занимается разработкой прикладных решений для мобильных устройств, крайне желательно понимать устройство используемых механизмов на уровне документации к той или иной мобильной операционной системе. Ресурсы для разработчика доступны в сети Интернет:
● ОС Android: https://developer.android.com/.
● ОС iOS: https://developer.apple.com/.
● ОС Windows: https://developer.microsoft.com/ru-ru/windows.
28.2. Интерфейс приложения
28.2.1. Общая информация
Интерфейс мобильной версии «1С:Предприятия» является аналогом интерфейса Такси, с возможностью переключения между окнами с помощью главного меню приложения. Навигация в приложении зависит от того, какая форма активна в данный момент:
● Форма, для которой не установлен владелец и не сохраняющая данные.
● Например: форма списка, форма обработки.
● Форма открывается командой из меню функций ‑ в левой части заголовка окна находится кнопка открытия главного меню приложения. Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства или специальной кнопки.
● Форма открывается другими командами или из встроенного языка ‑ в левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была вызвана команда открытия закрываемой формы. Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Форма с установленным владельцем.
● Например: форма выбора, форма объекта, открытая из списка.
● При последовательном открытии таких окон образуется цепочка открытых окон, в которой пользователю доступна только самая последняя открытая форма. При этом закрытие текущей формы приводит к активизации предыдущей формы цепочки, т. е. той формы, откуда была открыта закрываемая форма. Следует понимать, что возврат может произойти не в ту форму, в которой пользователь находился до того, как переключился на закрываемую форму.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Форма, для которой не установлен владелец и сохраняющая данные.
● Например: форма создания объекта, вызванная из главного меню приложения или с помощью встроенного языка.
● При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была вызвана команда открытия закрываемой формы.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Формы, блокирующие интерфейс.
● Например: форма, для которой свойство Режим открытия окна установлено в значение Блокировать окно владельца или Блокировать весь интерфейс.
● В заголовке окна находится кнопка, связанная с командой формы:
● При наличии сохраняемых данных (признак реквизита Сохраняемые данные) ‑ стандартная кнопка Отмена.
● При отсутствии сохраняемых данных ‑ стандартная кнопка Закрыть.
● Если форма содержит одну из команд Отмена, Закрыть, Нет ‑ отображается эта команда.
● Главное меню приложения недоступно для формы, блокирующей весь интерфейс. Для формы, блокирующей окно владельца, главное меню приложения доступно с помощью жеста с левой стороны устройства.
Мобильное приложение, запускаемое под управлением ОС iOS, наследует масштаб интерфейса, установленный для операционной системы. Таким образом, если в операционной системе установлен увеличенный размер элементов интерфейса, то и в мобильном приложении размер элементов интерфейса также будет увеличенным.
При запуске мобильного приложения отображается полноэкранная картинка, заданная разработчиком приложения. В определенный момент времени в нижней части экрана появляется логотип и копирайт фирмы «1С», перекрывая часть заставки:
● В портретной ориентации ‑ примерно 10% площади экрана.
● В ландшафтной ориентации ‑ примерно 15% площади экрана.
28.2.2. Глобальный командный интерфейс
Интерфейс мобильной версии «1С:Предприятия» ориентирован на то, что в один момент времени на экране отображается одна форма. Под нее освобождается максимум свободного места на экране. Поэтому, команды, которые на персональном компьютере формируют командный интерфейс основного раздела (панели навигации и действий), собраны в главное меню приложения. Главное меню приложения содержит команду возврата на начальную страницу, список разделов (команды каждого раздела отображаются в виде подменю), а также команды отображения информации о программе и перехода к списку приложений. Вызов главного меню приложения осуществляется жестом с левой стороны экрана (если доступно) или с помощью специальной кнопки ≡, расположенной в левой части заголовка окна.
Существует возможность настраивать ролевую видимость командного интерфейса (см. здесь).
28.2.3. Начальная страница
Начальная страница поддерживает отображение разного количества форм, в зависимости от используемого варианта:
● Мобильная платформа ‑ поддерживается отображение только одной формы.
● Мобильный клиент ‑ отображаются все доступные формы начальной страницы (алгоритм выбора формы и способ отображения описан далее).
● Мобильный клиент с автономным режимом ‑ аналогично мобильному клиенту, с учетом особенностей автономного режима (описано далее).
Выбор отображаемых форм выполняется по следующим правилам:
● Из списка форм, указанных в настройках рабочей области начальной страницы, исключаются формы, которые недоступны в соответствии с правами доступа.
● Затем из оставшегося списка исключаются формы, которые отключены функциональными опциями.
● Отображение форм начальной страницы:
● Мобильная платформа ‑ из оставшихся форм (в результате предыдущих шагов) выбирается первая видимая форма, при этом обход форм рабочего стола идет сверху вниз, вначале левая колонка, затем правая (если задано расположение форм начальной страницы в две колонки).
● Мобильный клиент ‑ отобранные для отображения формы располагаются в виде закладок, у которых переключатель закладок расположен сверху. При запуске прикладного решения отображаются две закладки: первая видимая форма и специальная закладка, нажатие на которую приводит к загрузке всех остальных форм начальной страницы. После загрузки всех форм, под каждую форму будет создана отдельная закладка начальной страницы.
● Мобильный клиент с автономным режимом ‑ в обычном режиме работы поведение аналогично мобильному клиенту. Если мобильный клиент находится в автономном режиме или в настройках приложения установлен флажок Рассчитывать на плохое соединение, то при выборе форм начальной страницы пропускаются формы, которых нет в автономной конфигурации. В связи с этим, чтобы работа пользователя не зависела от режима работы, рекомендуется в качестве первой формы начальной страницы выбирать такую форму, которая 1) имеет прикладной смысл и 2) доступна в автономной конфигурации.
Если при формировании начальной страницы в автономной конфигурации не обнаружено ни одной формы, то на начальной страницы отображается форма, содержимое которой зависит от режима работы:
● Автономный режим:
● Заголовок: Автономный режим.
● В форме текст: Доступны функции автономного режима.
● Установлен флажок Рассчитывать на плохое соединение:
● Заголовок: Соединение не установлено.
● В форме текст: Доступны функции автономного режима.
● После установки соединения с основным сервером:
● Заголовок: Соединение установлено.
● В форме кнопка Начало …, после нажатия на которую загружаются формы начальной страницы.
Кроме формы, на начальной странице может располагаться командный интерфейс основного раздела. Состав командного интерфейса основного раздела на мобильной версии аналогичен таковому на платформе для персонального компьютера (кроме группы См.также). Командный интерфейс основного раздела отображается в виде матрицы кнопок (каждая кнопка связана с одной командой), сгруппированной по страницам. Картинка на кнопке получается из связанной команды. Если команда не обладает настраиваемой картинкой, используется стандартная картинка для данной группы команд.
Команды выводятся так чтобы максимально заполнить рабочую область окна. Группы команд размещается на страницах так, чтобы избежать переноса между страницами, т. е. если после одной группы команд вторая не помещается полностью в оставшееся место, то она начинается с новой страницы. Если все команды не помещаются на экран, то они размещаются на нескольких страницах, которые можно пролистывать.
28.2.4. Сообщения пользователю
Отображение сообщений пользователю зависит от того, сколько не просмотренных сообщений имеется в настоящий момент. Первое не просмотренное сообщение отображается в виде диалога с текстом сообщения и кнопкой ОК. После прихода второго сообщения в диалоге дополнительно появляется кнопка Все сообщения. В кнопке Все сообщения имеется подпись с полным количеством пришедших сообщений.
По нажатию на кнопку Все сообщения открывается панель сообщений, которая содержит все непрочитанные сообщения. Если в диалоге нажата кнопка ОК или закрывается панель сообщений, то список сообщений очищается. Нажатие на сообщение приводит к активации элемента формы, если сообщение связано с таковым. Для повторного открытия списка сообщений следует повторно вызвать действие, приводящее к открытию списка.
28.3. Мобильная версия «1С:Предприятия»
28.3.1. Общая информация
Данный раздел содержит описание механизмов, которые используются одинаково как в приложении на мобильной платформе, так и в мобильном клиенте.
28.3.2. Работа с файлами
Все приложения на мобильных устройствах работают в рамках специального механизма, обеспечивающего безопасное исполнение программ («песочница», sandbox). В рамках этого механизма, приложениям предоставляется ограниченный доступ к файловой системе мобильного устройства. При разработке мобильного приложения может требоваться доступ к файловой системе, например для промежуточного хранения данных или записи документов, сформированных в системе, для последующего обмена с другими компьютерами.
Для получения доступа к таким местам файловой системы предназначены специальные функции:
● КаталогВременныхФайлов() ‑ возвращает каталог временных файлов данного приложения. При необходимости каталог может быть очищен операционной системой.
● РабочийКаталогДанныхПользователя() ‑ возвращает каталог, в котором рекомендуется хранить «долговременные» данные пользователя.
● КаталогДокументов``() ‑ каталог документов, которые предназначены для обмена с внешним (по отношению к мобильному приложению) окружением.
● КаталогБиблиотекиМобильногоУстройства() ‑ возвращает каталог библиотеки мобильного устройства. Вид библиотеки определяется параметром метода. Доступны следующие виды библиотек: аудиофайлы, видеофайлы и картинки.
Вне зависимости от реальных возможностей мобильной ОС, не рекомендуется использовать для работы любые другие каталоги файловой системы мобильного устройства из соображений безопасности, а также требований разработчиков мобильных ОС к прикладным приложениям.
Если прикладному решению необходимо сохранить файл на мобильное устройство, следует использовать интерактивный вариант метода ПолучитьФайлССервераАсинх(). Следует помнить, что в каталоги библиотек мобильного устройства (в общем случае) невозможно выполнить запись файлов обычным способом (через объекты работы с файлами). Запись возможна только с помощью методов ПолучитьФайлССервераАсинх() или ПолучитьФайлыССервераАсинх().
Если в прикладном решении требуется каким-то образом использовать файл, расположенный на мобильном устройстве, то для выбора файла можно использовать объект ДиалогВыбораФайла. При работе под управлением ОС Windows используется стандартный диалог системы «1С:Предприятие». При работе под управлением ОС Android и iOS используется специальный вариант диалога, который позволяет получить доступ к различным разделам накопителя мобильного устройства (описываются значениями системного перечисления РазделДиалогаВыбораФайла):
● Перечень недавно использованных файлов (только при работе под управлением ОС Android). Значение РазделДиалогаВыбораФайла.Недавнее.
● Объединенный список фото- и видеофайлов (галерея мобильного устройства). Значение РазделДиалогаВыбораФайла.Галерея.
● Список аудиофайлов мобильного устройства. Значение РазделДиалогаВыбораФайла.Аудио.
● Папку документов мобильного устройства (результат работы метода КаталогДокументов()). Значение РазделДиалогаВыбораФайла.Документы.
● Содержимое рабочего каталога данных пользователя (результат работы метода РабочийКаталогДанныхПользователя()). Значение РазделДиалогаВыбораФайла.Файлы.
В зависимости от выбранного режима, созданный диалог имеет ряд особенностей в поведении:
|
|
Выбор каталога |
Открытие файла |
Сохранение файла |
|
Доступные разделы |
|
Все |
Все |
|
Множественный выбор |
Нет |
Да |
Нет |
|
Создание папки |
Да |
Только
в разделе |
Только
в разделе |
|
Сортировка |
По алфавиту |
Любая |
По алфавиту |
|
Отображение |
Списком |
Любое |
Списком |
В галерее и разделе с аудиофайлами допускается создание нового файла прямо в диалоге.
Если разработчику необходимо ограничить состав используемых разделов в диалоге выбора файла, например, разрешить выбор только аудиофайла (из соответствующего раздела), то для этого предназначено свойство ДиалогВыбораФайла.Разделы. В это свойство можно поместить массив, который содержит значения системного перечисления РазделДиалогаВыбораФайла. Если массив не задан (свойство установлено в значение Неопределено) или он пустой ‑ будут показаны все доступные разделы. Разделы в диалоге отображаются в том порядке, в котором они перечислены в свойстве ДиалогВыбораФайла.Разделы. Если разработчик задал единственный раздел для отображения ‑ список разделов в диалоге не будет отображаться.
Диалог выбора файлов предоставляет возможность отбора файлов по маске имени файла и по MIME-типу. Для отбора по маске необходимо использовать свойства Фильтр и ИндексФильтра объекта ДиалогВыбораФайла. Свойство Фильтр позволяет указать список масок для фильтрации списка, а свойство ИндексФильтра предназначено для указания маски, которая будет использоваться по умолчанию. При отображении списка файлов в диалоге, те файлы, которые не соответствуют установленной маске, будут недоступны для выбора и отображаться как «неактивные». При смене фильтра будет выполнена смена отображения в диалоге. Для того, чтобы задать отбора по MIME-типу, следует использовать свойство ДиалогВыбораФайла.ТипСодержимого. Это свойство содержит массив, в котором каждый элемент представляет собой MIME-типы, которые должен отображать диалог. Диалог будет отображать только те файлы, MIME-типы которых указаны в свойстве и соответствуют маске, заданной фильтром. Если свойство ДиалогВыбораФайла.ТипСодержимого не указано (или установлено в значение Неопределено), то для отбора будут использоваться следующие MIME-типы:
● Для разделов Галерея, Документы и Файлы: типы image, video и все подтипы.
● Для раздела Аудио: тип audio и все подтипы.
Если необходимо самостоятельно указать какой-либо «MIME-тип и все подтипы», то значение для установки отбора будет выглядеть следующим образом (например типа аудиофайлов): audio``/*.
Диалог выбора файла поддерживает возможность множественного выбора. Как и для персонального компьютера, на мобильном устройстве эта возможность включается с помощью свойства ДиалогВыбораФайла.МножественныйВыбор:
● Свойство установлено в значение Ложь ‑ в диалоге можно выбрать только один объект, который и будет передан в вызывающий код.
● Свойство установлено в значение Истина ‑ в этом случае диалог допускает использование и в режиме одиночного выбора (диалог открывается в таком режиме) и в режиме множественного выбора (для перевода в этот режим необходимо использовать интерактивную команду диалога, расположенную в меню Еще).
Такое необычное поведение преследует одну цель: максимально унифицировать поведение диалога для выбора файла и сократить количество действий, которые необходимы для выполнения атомарного действия. Атомарным действием будет считать выбор одного файла. Поясним это утверждение на примере. Допустим, нам необходимо реализовать диалог добавления одного или нескольких файлов в информационную базу на мобильном устройстве. Пользователь, как правило, добавляет файлы по одному (даже если этих файлов несколько), но продвинутый пользователь может захотеть выбрать сразу несколько файлов. В этом случае необходимо установить свойство МножественныйВыбор в значение Истина. Тогда обычный пользователь, как и прежде, будет выбирать файл одним нажатием, а продвинутому пользователю будет необходимо включить множественный выбор в самом диалоге, а затем выбрать добавляемые файлы и нажать кнопку выбора. Если свойство МножественныйВыбор установлено в значение Ложь, то в этом случае интерактивно включить этот режим также невозможно.
На мобильном устройстве имя файла в библиотеке может не соответствовать тому, как этот файл отображается системными приложениями. При этом представление файла не может быть использовано для идентификации файла, передачи в качестве параметров методов работы с файлами и т. д. Представление предназначено исключительно для отображения пользователю. Для получения представления следует использовать метод Файл.ПолучитьПредставлениеФайлаБиблиотекиМобильногоУстройства().
Следующий пример иллюстрирует выбор и отображение произвольного файла на мобильном устройстве:
Диалог = Новый ДиалогВыбораФайла(РежимДиалогаВыбораФайла.Открытие); Разделы = Новый Массив; Разделы.Добавить(РазделДиалогаВыбораФайла.Галерея); Диалог.Разделы = Разделы; Диалог.МножественныйВыбор = Ложь; Результат = Ждать Диалог.ВыбратьАсинх(); Если Результат = Неопределено Тогда Для каждого Объект Из Результат Цикл Сообщить("Выбран объект: " + Объект); КонецЦикла; КонецЕсли;
В результате можно сформулировать следующие рекомендации по работе с файлами на мобильном устройстве:
1. Если путь к каталогу (или файлу) начинается со строки content``:, то для записи в такой каталог допустимо использовать только методы ПолучитьФайлССервераАсинх() или ПолучитьФайлыССервераАсинх(). Также допустимо использовать такие пути в конструкторах следующих объектов: Файл, ДвоичныеДанные, Картинка, ЗапускПриложенияМобильногоУстройства и в качестве параметров следующих методов: ЗапуститьПриложение(), ПерейтиПоНавигационнойСсылке(), КопироватьФайлАсинх(), ПереместитьФайлАсинх(), УдалитьФайлыАсинх(), НайтиФайлыАсинх().
2. Если путь к каталогу (или файлу) не начинается со строки content``:, то для работы с такими файлами и путями можно использовать все возможности мобильной платформы по работе с файлами. Следует помнить, что мобильные операционные системы работают с разными файловыми системами. Следовательно, разделители путей и маски всех файлов отличаются на разных мобильных операционных систем.
3. Для того, чтобы получить маску всех файлов и разделитель пути к файлу универсальным способом, который учитывает используемую операционную систему и место исполнения кода, необходимо использовать специальные методы ПолучитьМаскуВсеФайлы() и ПолучитьРазделительПути(). Для унификации с кодом прикладного решения для персонального компьютера, можно использовать методы, которые возвращают указанные параметры отдельно для клиентской и серверной части прикладного решения: ПолучитьМаскуВсеФайлыКлиента()/Сервера() и ПолучитьРазделительПутиКлиента()/Сервера().
При отображении информации из библиотек мобильного устройства может потребоваться показывать не полноценные изображения, а уменьшенные копии (preview, картинка представления). В результате снижается вероятность получения ошибки нехватки памяти при работе с мобильным приложением, которое активно использует картинки или видеофайлы из библиотек мобильного устройства. Для того, что получить картинку представления для файла, расположенного в библиотеке мобильного устройства, следует использовать метод Файл.ПолучитьКартинкуПредставленияФайлаБиблиотекиМобильногоУстройства(). При использовании данного метода следует помнить, что для получения картинки представления, путь к обрабатываемому файлу должен принадлежать схеме content (начинаться со строки content``:).
28.3.3. Работа с картинками
Для мобильных устройств используется обычная картинка с вариантами, которая используется платформой для персонального компьютера. Описание формата картинки и ее манифеста см. здесь.
Для устройств на ОС iOS используются следующие картинки из набора:
● обычные экраны ‑ картинка mdpi;
● экраны Retina ‑ картинки xdpi.
Для устройств на ОС Android используются картинки, соответствующие разрешению экрана используемого устройства.
На мобильном устройстве поддерживается работа с объектами Картинка и ОбрабатываемаяКартинка. Объект типа Картинка может быть создан на основании пути к файлу, который принадлежит к схеме content``://. При работе с объектами Картинка и ОбрабатываемаяКартинка следует помнить о том, что на мобильном устройстве имеются ограничения по доступности свойств и методов объектов, а также имеются ограничения по работе методов. Данные ограничения отражены в Синтакс-помощнике.
Смотри также:
● Работа с файлами на мобильном устройстве (см. здесь).
● Обработка картинок (см. здесь).
28.3.4. Форма
28.3.4.1. Общая информация
Для тех механизмов или объектов конфигурации, которые не поддерживаются мобильной версией «1С:Предприятия», будут недоступны свойства элементов формы, связанные с этим механизмом или объектом. Например, свойство Сочетание клавиш или события, связанные с перетаскиванием.
Принципы и правила формирования формы для мобильной версии «1С:Предприятия» в основном совпадают с таковыми для тонкого клиента, однако, есть некоторые особенности, которые следует учитывать при разработке форм мобильного приложения:
● Экраны смартфонов, в основном, ориентированы на вертикальное расположение (портретная ориентация), поэтому форма существенно ограничена по своей ширине и слабо ограничена по высоте.
● Для мобильных устройств не принята прокрутка формы по горизонтали, т. к. полосы прокрутки на мобильных устройствах не отображаются постоянно, поэтому пользователь может не обратить внимания на то, что форма (отчет или таблица) показывает только фрагмент информации. В связи с этим, при формировании форм, разработчик обязан сам предпринимать усилия для того, чтобы все элементы формы помещались в ней по ширине, например, используя группы с группировкой Горизонтальная если возможно. Если таких усилий не предпринято, то форма будет ограниченно работоспособна, т. к. горизонтальная полоса прокрутки в формах на мобильной платформе не поддерживается.
28.3.4.2. Доступные элементы формы
В форме мобильного приложения можно использовать следующие элементы формы:
● Поля следующих видов:
● Поле ввода;
● Поле надписи;
● Поле переключателя;
● Поле картинки;
● Поле флажка;
● Поле индикатора;
● Поле полосы регулирования;
● Поле диаграммы;
● Поле табличного документа.
● Кнопка;
● Таблица;
● Декорация: надпись и картинка;
● Группы всех видов.
28.3.4.3. Размещение элементов формы
Группы, включая саму форму, и большая часть элементов формы, отображаются в виде списков, как это принято в мобильных интерфейсах. Элементы формы условно делятся на три типа:
1. Обязательно располагаются в строке списка. В эту группу входят следующие элементы:
● Поле ввода;
● Поле надписи;
● Поле переключателя;
● Кнопка;
● Поле диаграммы.
2. Могут располагаться в строке списка. В группу входит декорация.
3. Не могут располагаться в строке списка. В эту группу входят все остальные элементы.
Под фразой «отображение списком» понимается следующее:
● Группа имеет фон, отличающийся от цвета формы.
● Строкой списка выступает либо элемент формы, либо группа с горизонтальной группировкой элементов.
● Элементы, расположенные в группе с горизонтальной группировкой, располагаются в одной строке.
● Элементы, расположенные в группе с вертикальной группировкой, располагаются каждый на своей строке.
● Если в группе с вертикальной группировкой находятся элементы, которые не могут располагаться в строке списка, то в списке отображается разрыв.
● Если группа обладает отображаемым заголовком, то перед группой формируется отступ.
● Визуальными разделителями строк являются горизонтальные линии, отображением которых нельзя управлять.
Особенностью поведения элементов 2 типа является то, что они располагаются в строке списка, только если сгруппированы с элементами 1 типа. Сами по себе элементы 2 типа в список не оформляются.
Многие элементы формы не имеют рамок (поля ввода и кнопки, у которых цвет рамки установлен в значение Авто). В связи с этим, выравнивание полей ввода на форме (как на платформе для персонального компьютера) не имеет практического смысла. Вместо него используется алгоритм выравнивания значений в полях ввода. В зависимости от наличия и расположения заголовка у поля ввода, информация в нем выравнивается по-разному:
● Заголовок поля отсутствует или отображается не слева, то числовые значения выравниваются вправо, а остальные ‑ влево.
● Заголовок поля находится слева:
● В полях с редактированием текста ‑ текст выравнивается влево.
● Числовые значения выравниваются вправо.
● Выравнивание полей остальных типов зависит от того, есть в группе с этими полями поле для редактирования текста или нет. Если такое поле есть, то выравнивание остальных полей осуществляется аналогично выравниванию этого поля. В противном случае ‑ вправо.
Заголовок формы отображается только в заголовке окна и не дублируется на самой форме.
Как было уже сказано выше, прокрутка формы по горизонтали не применяется на мобильных устройствах. В то же время вертикальная прокрутка формы является вполне допустимой. Исходя из этих предпосылок, мобильная версия «1С:Предприятия» пытается автоматически перестроить форму таким образом, чтобы она поместилась на экране мобильного устройства. В процессе адаптации уменьшается ширина элементов формы для тех элементов, ширина которых в конфигурации задана так, что превышает фактическую ширину экрана на мобильном устройстве. Ширина для таких элементов формируется таким образом, чтобы элемент поместился (по ширине) в текущей ориентации мобильного устройства без горизонтальной прокрутки. Кроме изменения ширины, система может выполнить попытку уменьшить количество отображаемых элементов формы, чтобы улучшить визуальный вид формы. Для управления необходимостью такой перестройки предназначено свойство формы Вариант сворачивания элементов формы по важности (СворачиваниеЭлементовПоВажности). Значение Авто трактуется как Использовать.
Для того чтобы мобильной версии было проще адаптировать форму, у элементов формы (и колонок таблиц) имеется свойство Важность при отображении (ВажностьПриОтображении). Изменяя значение этого свойства, разработчик может добиться нужного вида формы на экране устройства. Значение этого свойства мобильный клиент обрабатывает следующим образом:
● Более важным элементам отводится больше места на форме.
● Если более важный элемент расположен под менее важными, и эти менее важные элементы занимают более трех строк формы, то менее важные элементы объединяются и помещаются в сворачиваемую группу. Важно понимать, что здесь и далее важна высота, а не количество элементов. Другими словами, три строки сетки формы могут занимать как три элемента высотой каждый по одной строке, так и один элемент формы, занимающий три строки высоты.
● Если первым или последним из сворачиваемых элементов является командная панель, то она не сворачивается, так как может относиться к важному элементу.
● Если более важный элемент расположен внутри иерархии групп или страниц, и при этом в разных местах иерархии над ним расположены менее важные элементы, занимающие более трех строк, в каждом уровне иерархии формируется сворачиваемая группа.
● Если имеются несколько элементов более высокой важности, то менее важные элементы, находящиеся между ними, помещаются в сворачиваемую группу, если менее важные элементы занимают более трех строк.
● Менее важные элементы, находящиеся ниже последнего более важного элемента, не сворачиваются.
● Если внутри свернутой группы также расположены элементы разной важности, то к этой группе алгоритм применяется рекурсивно.
● Заголовок свертываемой группы формируется по следующему алгоритму:
● Если свертывается уже существующая группа, то используется заголовок этой группы.
● Если в свертываемую группу попадает один элемент с заданным заголовком, то используется заголовок этого элемента.
● Если не подходит ни один из вышеперечисленных пунктов ‑ заголовок формируется соединением, через ",", всех заголовков элементов, входящих в свертываемую группу.
Если для элемента формы свойство ВажностьПриОтображении установлено в значение Авто, то фактическое значение свойства будет определяться по следующим правилам:
● Значение ОченьВысокая для элемента формы, отображающего данные основного реквизита формы (и подчиненные реквизиты).
● Значение Высокая, если элемент растягивается по вертикали и является одним из следующих элементов:
● таблица формы, отображающей динамический список;
● поле табличного документа;
● поле диаграммы любого вида и типа;
● поле форматированного документа;
● поле HTML-документа.
● Если элементом является командная панель, то:
● Значение Высокая, если источником команд для командной панели выступает собственно управляемая форма.
● Значение важности элемента, который является источником команд для командной панели.
● Значение важности самого важного элемента в той же группе, что и командная панель, при условии, что для командной панели не установлен источник команд.
● Значение Обычная для всех остальных элементов.
28.3.4.4. Особенности отображения элементов формы
28.3.4.4.1. Общие особенности
На форме не отображается отметка незаполненного как для элементов, расположенных на форме, так и для элементов, расположенных в таблице.
Заголовки полей выводятся без символов ":" в конце текста.
28.3.4.4.2. Форма
Свойство ТекущийЭлемент позволяет получить и установить текущий элемент формы. Однако установка текущего элемента формы не приводит к переходу этого элемента в режим редактирования и никак не отображается визуально. Чтобы перевести элемент формы в режим редактирования, следует воспользоваться методом НачатьРедактированиеЭлемента().
Если при открытии формы выполняются какие-либо действия, то следует учитывать тот факт, что до окончания работы всех обработчиков формы не будет выполняться обновления экрана мобильного устройства.
28.3.4.4.3. Поле ввода
Для облегчения работы с полем ввода с помощью сенсорных экранов мобильных устройств, во всех полях, кроме полей ввода текста и полей, где используется автоподбор, редактирование значения непосредственно в поле ввода не предполагается. Поле ввода ведет себя как кнопка, заголовок которой отображает представление текущего значения, а нажатие этой кнопки открывает специализированный редактор. В том случае, если в поле ввода используется автоподбор, имеется возможность очистить значение с помощью кнопки Очистить, расположенной в левой части заголовка окна.
Длинное нажатие в поле ввода приводит к появлению контекстного меню, которое состоит из стандартных команд системы и команд, которые добавлены в это меню во время разработки.
Для отображения кнопок очистки, открытия и регулирования, следует установить в значение Да соответствующее свойство поле ввода. Кроме этого, имеется дополнительная возможность по управлению видимостью кнопок очистки и открытия, которые отображаются непосредственно в поле ввода. Эта возможность предоставляется с помощью свойств АвтоОтображениеКнопкиОчистки и АвтоОтображениеКнопкиОткрытия. Данные свойства обрабатываются только в том случае, если соответствующее свойство поля ввода установлено в значение Да. Возможны следующие варианты поведения (значения свойств АвтоОтображениеКнопкиОчистки и АвтоОтображениеКнопкиОткрытия):
● Только для заполненного ‑ в этом случае кнопка будет отображаться только в том случае, если значение в поле отличается от значения по умолчанию для используемого типа или если данные, отображаемые полем ввода, имеют составной тип.
● Всегда ‑ кнопка очистки отображается всегда.
● Авто ‑ поведение зависит от свойства:
● свойство АвтоОтображениеКнопкиОчистки ‑ аналогично значению Только для заполненного;
● свойство АвтоОтображениеКнопкиОткрытия ‑ аналогично значению Всегда.
Кнопка выбора всегда не отображается, при этом событие НачалоВыбора срабатывает в момент нажатия на само поле ввода. Если для редактирования значения поля используется отдельная форма, то рядом с полем размещается специальный маркер (>), нажатие на который приведет к открытию этой формы. Расположение и внешний вид редакторов отличается на планшете и телефоне.
Многострочное поле ввода всегда работает в режиме ввода текста. Такое поле ввода не поддерживает выбор значений и автоподбор. Если поле ввода связано с данными, отличными от типа Строка, то для такого поля ввода игнорируется значение флажка МногострочныйРежим. Многострочное поле ввода может отображаться тремя различными способами:
1. Автоматическая подстройка высоты поля под высоту текста (чтобы избежать прокрутки). Подстройка происходит в том случае, когда поле занимает всю ширину формы, не указана высота поля (свойство Высота) и поле может растягиваться по вертикали (свойство РастягиватьПоВертикали).
2. Поле имеет заданную высоту и допустима вертикальная прокрутка внутри поля. Поле отображается таким образом в том случае, когда указана высота поля (свойство Высота) и поле не может растягиваться по вертикали (свойство РастягиватьПоВертикали).
3. Поле занимает максимально возможное место на форме. Поле отображается таким образом в том случае, когда указана высота поля (свойство Высота) и поле может растягиваться по вертикали (свойство РастягиватьПоВертикали).
Значение свойства Подсказка ввода не отображается в многострочном поле ввода.
Для мобильной платформы также актуальны дополнительные свойства поля ввода, которые позволят более эффективно использовать прикладное решение. Эти свойства позволяют дополнительно настроить поле ввода (только в том случае, если поле ввода отображает данные типа Строка) для выполнения некоторых специфических задач:
● Свойство АвтоИсправлениеПриВводеТекста ‑ позволяет включить автоматическое исправление вводимого текста. Поведение зависит от настроек используемой виртуальной клавиатуры. Значение Авто означает, что для многострочных полей ввода автоматическое исправление работает, а для обычных (однострочных) ‑ нет.
● Свойство ПроверкаПравописанияПриВводеТекста ‑ позволяет включить проверку правописания при вводе текста. При работе под управлением ОС Android данное свойство игнорируется, т. к. данная возможность управляется системой и зависит от других настроек.
При работе под управлением ОС Windows данное свойство и свойство АвтоИзменениеРегистраПриВводеТекста всегда включаются одновременно. При установке свойства ПроверкаПравописанияПриВводеТекста в значение Использовать, операционной системой будет автоматически включено изменение регистра вначале предложения при вводе текста. Это изменение будет выполнено вне зависимости от значения свойства АвтоИзменениеРегистраПриВводеТекста. Значение свойства АвтоИзменениеРегистраПриВводеТекста будет использоваться при работе под управлением других операционных систем.
Значение Авто означает, что для многострочных полей ввода автоматическая проверка работает, а для обычных (однострочных) ‑ нет.
● Свойство АвтоИзменениеРегистраПриВводеТекста ‑ позволяет управлять автоматическим изменением регистра символов при вводе текста. Поведение зависит от используемой операционной системы и настроек используемой виртуальной клавиатуры.
При работе под управлением ОС Windows данное свойство и свойство АвтоИзменениеРегистраПриВводеТекста всегда включаются одновременно. При установке свойства ПроверкаПравописанияПриВводеТекста в значение Использовать, операционной системой будет автоматически включено изменение регистра вначале предложения при вводе текста. Это изменение будет выполнено вне зависимости от значения свойства АвтоИзменениеРегистраПриВводеТекста. Значение свойства АвтоИзменениеРегистраПриВводеТекста будет использоваться при работе под управлением других операционных систем.
Может принимать следующие значения:
● Нет ‑ автоматическое изменение регистра символов не выполняется.
● Слова ‑ автоматически делается заглавной первая буква каждого слова.
● Предложения ‑ автоматически делается заглавной первая буква каждого предложения.
● Все символы ‑ автоматически делаются заглавными все вводимые символы.
● Авто ‑ для многострочных полей ввода аналогично значению Предложения, а для обычных (однострочных) ‑ Нет.
● Свойство СпециальныйРежимВводаТекста ‑ позволяет задать специальный вид виртуальной клавиатуры при вводе в поле ввода:
● Нет ‑ используется виртуальная клавиатура по умолчанию.
● Цифры и пунктуация ‑ используется виртуальная клавиатура для ввода цифр и символов пунктуации.
● URL ‑ используется виртуальная клавиатура для ввода URL.
● Email ‑ используется виртуальная клавиатура для ввода адреса электронной почты. На клавиатуре будет присутствовать символ @.
● Номер телефона ‑ используется виртуальная клавиатура для ввода номера телефона, которая содержит цифры и клавиши * и #.
● Цифры ‑ используется экранная клавиатура для ввода чисел.
● Авто ‑ используется аналогично значению Нет.
При работе на планшетах под управлением ОС Android, все виды виртуальных клавиатур, кроме клавиатуры вида Номер телефона, могут выглядеть одинаково, в связи с наличием большого количества свободного места на экране.
При разработке форм, предполагающих ввод различной информации (номера телефонов, адреса электронной почты и т. д.), может возникать необходимость специальным образом именовать кнопку завершения ввода на используемой виртуальной клавиатуре. Это должно помочь пользователю понять, какое действие будет выполнено после нажатия этой кнопки. Для этого существует свойство поля ввода ТекстКнопкиВводаЭкраннойКлавиатуры. Значение данного свойства обозначают текст, который будет отображаться на кнопке завершения ввода. При работе под управлением ОС Android при указании значения Продолжить будет отображаться Далее, а при указании значения Подключиться ‑ Ввод. Под управлением ОС Windows значение данного свойства будет игнорироваться. Управление текстом на кнопки ввода не поддерживается.
28.3.4.4.4. Поле флажка
Флажок может отображать только два состояния. При работе под управлением ОС iOS флажок всегда отображается в виде тумблера.
28.3.4.4.5. Поле переключателя
Поле переключателя вида Переключатель всегда выводится в отдельной вертикальной группе (количество колонок не настраивается). Поле переключателя вида Переключатель не комбинируется с другими элементами в одной строке.
Поле переключателя вида Тумблер всегда выводится в одной строке (количество колонок не настраивается).
28.3.4.4.6. Кнопка
В том случае, когда кнопка расположена в вертикальной группе, она растягивается до ширины родительской группы. Текст внутри кнопки выравнивается по левому краю кнопки, кроме случая, когда цвет рамки кнопки отличается от значения по умолчанию ‑ в этом случае текст выравнивается по центру кнопки.
28.3.4.4.7. Группа
При отображении групп управляемой формы поддерживается только отступ для групп с режимом отображения Обычное выделение и Сильное выделение.
При отображении свертываемой группы (свойство группы Поведение установлено в значение Свертываемая), имеется ряд особенностей:
● Заголовок свертываемой группы (см. здесь) отображается в виде нажимаемой строки;
● Свертываемая группа всегда отображается с вариантом отображения Картинка и его (варианта отображения) настройка игнорируется.
Группа вида Страницы позволяет реализовать несколько вариантов панели с закладками. Вид панели (и ее поведение) зависит от значения свойства Отображение закладок:
● Закладки сверху.
● Закладки отображаются в виде тумблера. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в конце текст отображается символ …. Картинки в заголовках не отображаются.
● Страницы расположены внутри группы под списком закладок.
● Активная закладка отображается инверсией заголовка.
● Закладки снизу.
● Закладки отображаются в виде панели кнопок. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в конце текст отображается символ …. Картинки в заголовках отображаются, при этом текст заголовка всегда отображается под картинкой.
● Страницы расположены внутри группы над списком закладок.
● Если на экране не хватает места для отображения заголовков всех страниц группы, то в конец списка добавляется кнопка Еще. Нажатие на эту кнопку открывает список заголовков всех страниц группы.
● Закладки слева.
● Закладки выводятся в виде списка. Нажатие на закладку приводит к открытию нового окна с содержимым закладки, которое замещает текущую форму (со списком закладок). Для возврата к списку закладок служит специальная кнопка (<), расположенная в левой верхней части заголовка страницы.
● Пролистывание.
● Закладки выводятся в виде точек под страницами. Текст и картинки не отображаются. Переключение между страницами выполняется жестом слева-направо или справа-налево в области страниц.
● Страницы расположены внутри группы над точками, описывающими количество закладок.
● В платформе для персонального компьютера данное значение интерпретируется как значение Закладки слева.
● Закладки справа.
● Не поддерживается мобильной платформой.
28.3.4.4.8. Таблица
Работа с текущей строкой
Поведение текущей строки в таблице определяется свойством таблицы Использование текущей строки (ИспользованиеТекущейСтроки):
● Значение Выбор. В этом случае свойства ТекущаяСтрока, ТекущийЭлемент, ТекущиеДанные определены только во время выполнения:
● обработчика контекстной команды;
● событий активизации строки или ячейки;
● событий редактирования строки.
В остальное время эти свойства таблицы имеют значение Неопределено. Для команды формы, которой необходимы данные текущей строки, следует явно указать такую необходимость в свойстве команды формы Использование текущей строки. Дополнительно необходимо указать таблицу, данные из которой будет использовать команда, с помощью свойства Используемая таблица.
В списке текущая строка визуально определяется кратковременно, во время нажатия на строку.
Если текущая строка устанавливается из встроенного языка, то установленное значение сохраняется до окончания выполнения метода встроенного языка верхнего уровня (вызванного системой из интерфейса, а не из другого метода встроенного языка).
Данное значение рекомендуется использовать для таблиц, логически не связанных с какими-то другими данными (в том числе и табличными).
● Значение ОтображениеВыделения. В этом случае текущая строка существует всегда, если таблица содержит хотя-бы одну строку.
В списке текущая строка визуально определяется всегда.
Данное значение рекомендуется использовать для таблиц, которые логически связанны с какими-то другими данными (в том числе и табличными).
● Значение ОтображениеВыделенияИВыбор. В этом случае текущая строка существует всегда, если таблица содержит хотя-бы одну строку.
В списке текущая строка визуально определяется всегда. Также в правой части строки имеется кнопка, которая выполняет одновременно два действия: активизацию строки и ее выбор.
● Значение Авто. Данное значение трактуется как значение Выбор и на мобильной платформе, и в мобильном клиенте.
Свойство ТекущийРодитель определено в следующих случаях:
● в иерархических списках ‑ всегда;
● при отображении дерева ‑ только в тех случаях, когда определено свойство ТекущаяСтрока.
Отображение колонок таблицы
Таблица в мобильной платформе никогда не имеет горизонтальной прокрутки. В связи с этим:
● Игнорируется фиксация колонок в таблице.
● Значение свойства ГоризонтальнаяПолосаПрокрутки игнорируется.
● Отображение колонок, которые не помещаются в видимой части таблицы, зависит от значения свойства таблицы управляемой формы Поведение при сжатии по горизонтали (ПоведениеПриСжатииПоГоризонтали) и от свойства Важность при отображении (ВажностьПриОтображении) колонок этой таблицы:
● Значение Скрывать элементы по важности ‑ в этом случае колонки, которые не помещаются на форму, будут скрываться по мере убывания значения свойства Важность при отображении у колонки. Таким образом, вначале будут скрыты колонки с самой низкой важностью (Очень низкая), затем со следующей важностью (Низкая) и т. д. Если есть несколько колонок с одинаковой важностью, то скрытие осуществляется справа налево. Другими словами, чем левее в таблице расположена колонка, тем выше у нее шансов быть отображенной на форме (при прочих равных).
● Значение Переносить элементы по важности ‑ в этом случае колонки скрываются по мере убывания важности (аналогично поведению Скрывать элементы по важности), а значения скрытых колонок отображаются в отдельной строке, мелким шрифтом, через запятую и с чередованием цветов.
● Значение Авто зависит от того, где используется конфигурация:
● на мобильной платформе: трактуется как Скрывать элементы по важности.
● на мобильном клиенте: трактуется как Переносить элементы по важности.
Различные режимы таблицы
Таблица в мобильном приложении может отображаться в трех режимах:
● основной режим;
● режим выбора нескольких строк;
● режим сортировки строк.
Основной режим аналогичен режиму отображения таблицы на платформе для персонального компьютера, за исключением отображения текущей и выбранных строк. В мобильной платформе эти строки не отображаются. Исключением служит кратковременная подсветка текущей строки таблицы при открытии формы. Таблица формы автоматически подстраивается под размер содержимого в том случае, если одновременно выполняются следующие условия:
● таблица занимается всю ширину формы;
● не задана фиксированная высота таблицы;
● таблица растягивается по вертикали;
● в объекте, который отображается таблица, содержится менее 100 строк данных. Если строк более 100 ‑ будет доступна прокрутка.
Режим выбора нескольких строк характеризуется специальной колонкой с флажками, с помощью которых и выполняется выбор. Колонка всегда отображается самой первой. В этом режиме контекстные команды таблицы доступны и действуют на все выделение сразу.
Режим сортировки строк характеризуется наличием специальной колонки с маркером, за который можно таскать строку. Эта колонка всегда отображается самой последней. В этом режиме недоступны контекстные команды таблицы.
Режим множественного выделения в таблице (свойство РежимВыделения установлено в значение Множественный) на мобильной платформе визуально никак не отображается. Признаком его существования служит специальная команда Выбор нескольких, которая доступна в командной панели, связанной с таблицей. При выборе этой команды таблица переходит в режим выбора нескольких строк.
Если установлен режим множественного выбора (свойство МножественныйВыбор установлено в значение Истина), то таблица сразу находится в режиме выбора нескольких строк, при этом команда перехода в этот режим в командной панели отсутствует.
Если в таблице доступно изменение порядка строк (например, табличная часть документа), то для активизации этого режима необходимо выполнить специальную команду Перестановка строк, которая доступна в командной панели, связанной с таблицей. В этом случае таблица переходит в режим сортировки строк, и сбрасываются выделенные строки (если они были).
Для таблицы поддерживаются только два режима ввода строк (свойство РежимВводаСтрок): в конце списка и в конце окна. Всегда используется режим выделения строки ‑ Строка (свойство РежимВыделенияСтроки). Фактическое значение свойства игнорируется.
Контекстное меню
Таблица формы поддерживает использование контекстного меню, которое открывается жестом от правой границы таблицы или длительным нажатием на строку.
Заполнение командной панели и контекстного меню имеет важные отличия от платформы для персонального компьютера. На платформе для персонального компьютера вопрос распределения команд между командной панелью и контекстным меню ‑ это вопрос дизайна формы. На мобильной платформе (в силу отсутствия текущей строки) это вопрос функциональной модели. Если команда использует свойства таблицы, связанные с текущей строкой, то такая команда должна располагаться в контекстном меню. Если такая команда размещена разработчиком в другом месте, то система может принудительно переместить ее в контекстное меню. Исключением из этого правила выступает случай, когда команда может выполнять свою работу как в связи с текущей строкой, так и без таковой. В качестве примера можно привести команду Создать динамического списка, отображающего данные иерархического справочника. Внеконтекстное использование команды предполагает создание элемента в корне справочника, а контекстное ‑ в текущей группе.
Для того чтобы указать системе, что команда оперируется данными текущей строки, предназначено свойство команды формы ИспользованиеТекущейСтроки. Для того чтобы связать команду формы с таблицей, чьи данные она должна обрабатывать, служит свойство команды ИспользуемаяТаблица. Использование данного свойства означает, что на мобильной платформе невозможно реализовать команду, оперирующую одновременно данными более одной таблицы. Для управления размещением команды существует свойство команды ОтображениеВКонтекстномМеню:
● Авто ‑ команда, которая использует данные текущей строки, всегда располагается в контекстном меню. Команда, которая не использует данные текущей строки ‑ всегда располагается в командной панели таблицы.
● ТолькоВКонтекстномМеню ‑ команда всегда расположена в контекстном меню.
● ДополнительноВКонтекстномМеню ‑ команда располагается в контекстном меню и в командной панели таблицы.
● Нет ‑ команда располагается только в командной панели таблицы.
Строка поиска
Управление расположением строки поиска также отличается от платформы для персонального компьютера. В зависимости от значения свойства таблицы ПоложениеСтрокиПоиска, возможно следующее поведение:
● Авто ‑ строка поиска доступна по нажатию кнопки командной панели (если таблица отображает динамический список и этот динамический список является основным реквизитом формы) или появляется при жесте вниз по заголовку таблицы (в остальных случаях);
● Верх, Командная панель ‑ строка поиска расположена между командной панелью таблицы и заголовком таблицы;
● Потянуть сверху ‑ строка поиска появляется при жесте вниз по заголовку таблицы;
● Заголовок формы``‑строка поиска расположена в заголовке формы;
● Низ ‑ строка поиска отсутствует;
● Нет ‑ строка поиска отсутствует.
В том случае, если у двух и более таблиц формы свойство ПоложениеСтрокиПоиска установлено в значение Заголовок формы, то фактическое поведение будет аналогично тому, как если у каждой из таких таблиц данное свойства установлено в значение Верх.
Высота таблицы на форме
При прокрутке таблицы, связанной с динамическим списком, в ее верхней и нижней частях появляются полупрозрачные кнопки. Нажатие на эти кнопки приводит к переходу в начало или конец списка (соответственно).
Для управления высотой таблицы управляемой формы предназначено свойство Вариант управления высотой (ВариантУправленияВысотой):
● В строках формы ‑ в этом случае высота таблицы задается с помощью свойства Высота таблицы управляемой формы. Если значение этого свойства равно 0, то высота таблицы будет равна 8 единицам для таблицы, отображающей динамический список и 4 единицам ‑ во всех остальных случаях.
● В строках таблицы ‑ в этом случае высота таблицы задается с помощью свойства ВысотаВСтрокахТаблицы таблицы управляемой формы. Если значение этого свойства равно 0, то высота таблицы будет равна 7 строкам для таблицы, отображающей динамический список и 3 строкам ‑ во всех остальных случаях.
● По содержимому ‑ если таблица связана с динамическим списком, то высота таблицы задается значением свойства ВысотаВСтрокахТаблицы. Если значение этого свойства равно 0, то высота таблицы определяется значением свойства ВысотаВСтрокахТаблицы.
Если таблица не связана с динамическим списком, то полностью отображаются все строки таблицы, но не менее 3 и не более 100 строк. При добавлении 101-й строки таблица сжимается до высоты, указанной в свойстве ВысотаВСтрокахТаблицы. Если это свойство установлено в значение 0, то для определения высоты используется свойство Высота. При этом содержимое таблицы начинает прокручиваться по вертикали. При удалении 101-й строки таблица растягивается по высоте до размера, достаточно для размещения 100 строк таблицы.
Значение По содержимому рекомендуется использовать для таблиц, отображающих небольшое количество строк.
● Авто ‑ аналогично значению По содержимому.
Обновление данных
Обновление данных, отображаемых таблицей, можно осуществлять в стиле, принятом на мобильных устройствах: путем попытки потянуть список вниз или вверх при достижении первой или последней (соответственно) строки отображаемых данных (pull to refresh). Для управления данной возможностью предназначено свойство таблицы Запрос обновления (ЗапросОбновления):
● Нет ‑ обновление можно выполнить только через команду командной панели таблицы;
● Любое другое значение означает, что обновление можно инициировать попыткой потянуть список в соответствующую сторону. При этом в области таблицы за пределами данных отображается анимация.
При выполнении обновления списка, таким образом, будет вызван обработчик события таблицы ОбработкаЗапросаОбновления. В том случае, если таблица адаптируется под содержимое, то обработчик таблицы ОбработкаЗапросаОбновления вызываться не будет.
Если динамический список, связанной с таблицей, не содержит отображаемых данных, то внутри таблицы отображается надпись Нет данных для отображения. Таблица, не связанная с динамическим списком, не отображает никакого текста при отсутствии данных для отображения.
Редактирование данных таблиц
Вместо редактирования данных в строке таблицы, связанной с табличной частью или таблицей значений, мобильная платформа предоставляет специальную системную форму. Эта форма содержит все отображаемые на родительской форме колонки текущей строки таблицы. В этой форме реализована группировка полей, если такая группировка реализована в настройках таблицы, но фактически воссоздается только первый уровень группировки. Более глубокие уровни группировки не воссоздаются на форме. Все поля более глубоких уровней группировки размещаются в родительской группе первого уровня.
При использовании системной формы необходимо помнить о следующих особенностях:
● Колонки, для которых установлено свойство Только просмотр, отображаются в системной форме также без возможности редактирования;
● В системной форме не отображаются поля типа картинка и надпись;
● На системную форму действует условное оформление формы;
● Вызываются все обработчики событий;
● Системная форма не редактируется в конфигураторе и ее нельзя модифицировать из встроенного языка.
После возврата из режима редактирования, редактируемая строка кратковременно подсвечивается.
28.3.4.5. Динамический список
Динамический список, используемый в мобильной платформе, имеет следующие особенности:
● Поддерживается управление настройками динамического списка с помощью встроенного языка. Для интерактивной настройки необходимо самостоятельно реализовать соответствующие формы настройки.
● Не поддерживается интерактивный вывод списка;
● Имеется возможность выполнять сортировку по нажатию на заголовок. По нескольким колонкам таким образом сортировать нельзя.
28.3.4.6. Панели формы
Панель навигации формы реализована с помощью специального меню, которое отображается в нижней части формы в виде переключателя. Нажатие кнопки переключателя приводит к открытию соответствующей формы.
Командная панель формы:
● В режиме отображения сверху:
● Командная панель находится в заголовке формы, правее текста.
● Если командная панель содержит стандартные пары команд ОК-Отмена и Да-Нет, то кнопка с отрицательным действием переносится в левую часть заголовка формы, а положительная отображается в командной панели формы. В меню Еще присутствуют все команды, кроме команды с отрицательным действием, которая была перенесена в заголовок формы.
● Если командная панель не содержит вышеуказанных пар команд, но содержит стандартную команду формы Отмена, Нет или Закрыть, то кнопка с такой командой переносится в панель в заголовке слева.
● Команда, которая размещена в левой части заголовка формы, будет отображаться специальным символом (<), но будет выполнять свою изначальную функцию.
● При отображении кнопки в командной панели формы учитывается свойство Отображение этой кнопки. Свойства команды, связанной с этой кнопкой, игнорируются при определении режима отображения кнопки.
● Если командная панель содержит кнопку по умолчанию, то она всегда отображается в заголовке первой.
● Если свободного места в правой части заголовка достаточно для отображения оставшихся команд ‑ они отображаются там. В противном случае отображается кнопка Еще и система пытается сделать так, чтобы кнопка Еще не была единственной: если команда, отображаемая в правой части заголовка еще не определена, то ей станет первая команда из списка оставшихся команд, а остальные будут расположены в меню Еще.
● В режиме отображения снизу:
● Фиксируется при прокрутке формы.
● При появлении клавиатуры не отображается.
В список стандартных команд не включаются команды непосредственного удаления (для объектов ссылочного типа), вызова справки, вывода списка, изменения формы. Стандартные команды Записать и закрыть и Провести и закрыть отображаются в командных панелях с заголовком Готово.
Для прикладных решений, работающих под управлением ОС iOS, необходимо помнить о том, что системные механизмы закрытия формы не задают пользователю вопрос о необходимости сохранения данных в том случае, когда закрывается форма с модифицированными данными.
Командная панель, связанная с таблицей, располагается сверху или снизу таблицы и по ширине не превышает ширины самой таблицы. При прокрутке таблицы командная панель всегда остается в видимой области.
28.3.5. Аппаратная или внешняя клавиатура
Мобильная версия «1С:Предприятие» поддерживает использование аппаратной (или внешней, подключаемой) клавиатуры мобильного устройства. Такая клавиатура поддерживается в полях ввода, которые отображают данные типа Число и Дата. При использовании аппаратной (или внешней) клавиатуры, поля ввода на мобильном устройстве будут выглядеть так же, как и без такой клавиатуры. Поля, отображающие другие типы данных ‑ не поддерживают аппаратную (или внешнюю клавиатуру).
В случае использования аппаратной (или внешней) клавиатуры, поддерживаются следующие возможности:
● Использовать сочетания клавиш, которые разработчик указал для элементов формы при разработке конфигурации. При этом стандартные сочетания клавиш системы «1С:Предприятие» не поддерживаются. Поведение системы зависит от того, для какого элемента формы назначено сочетание клавиш:
● Поле ввода ‑ сочетание клавиш приводит к активизации поля ввода.
● Декорация ‑ если для декорации вида надпись указано, что декорация должна отображаться в виде гиперссылки, то нажатие сочетания клавиш эквивалентно нажатию гиперссылки на экране. Гиперссылки в форматированной строке не активируются при нажатии сочетания клавиш.
● Группа страниц ‑ сочетание клавиш приводит к выбору указанной страницы.
● Для остальных элементов формы сочетания клавиш не выполняют какого-либо действия.
● Для перехода по элементам формы возможно использование клавиши Tab (для перехода вправо и вниз) и сочетания клавиш Shift +``Tab (для перехода влево и вверх). Для перемещения по элементам формы также поддерживается использование клавиш управления курсором, джойстика или другого механизма управления курсором на аппаратной (или внешней) клавиатуре.
Если клавиша Tab нажимается на последнем элементе формы или сочетание клавиш Shift +``Tab нажимается на первом элементе формы, то происходит потеря фокуса активным элементом формы. Повторное нажатие этих клавиш приводит к активизации первого (при нажатии Tab) или последнего (при нажатии Shift +``Tab) элемента текущей формы.
При работе под управлением ОС iOS и некоторых устройств под управлением ОС Android, нажатие клавиши Tab приводит к вставке символа табуляции в многострочное поле ввода.
Использование механизма управления курсором в многострочных полях ввода управляет курсором в рамках этого поля ввода, а не приводит к смене активного элемента формы. При работе под управлением ОС Android, использование механизма управления курсором приводит к смене активного элемента формы, если курсор стоит в первой или последней позиции текста в поле ввода.
Использование механизма управления курсором в горизонтальном направлении приводит к тому, что курсор в однострочном поле ввода перемещается по тексту в поле ввода, а если находится в позиции первой или последней позиции текста ‑ к смене активного элемента формы.
● Нажатие клавиши Esc или Back на аппаратной (или внешней) клавиатуре приводит к тому, что текущая форма будет закрыта, если в ней есть кнопки со стандартными командами Закрыть или Отмена.
● Нажатие клавиши Enter приводит к выполнению действия, связанного с кнопкой по умолчанию текущей формы. Если для формы не выбрано кнопки по умолчанию, то нажатие клавиши Enter не выполняет никаких действий.
28.3.6. Специальные возможности мобильного устройства
28.3.6.1. Общая информация
Под специальными возможностями мобильного устройства будут пониматься такие возможности, которые не предоставляются на персональных компьютерах с помощью штатных интерфейсов операционных систем. К таким возможностям можно отнести работу с телефонией, средства, уведомления, реклама и т. д. Какое программное обеспечение предоставляет эти возможности ‑ зависит от поставщика мобильной операционной системы и ее (операционной системы) архитектуры. Такие мобильные операционные системы как iOS и Windows предоставляют все необходимые интерфейсы «самостоятельно». Операционная система Android часть интерфейсов предоставляет «самостоятельно», а для части используется специальное программное обеспечение, которое может поставляться различными поставщиками. Можно сказать, что классический Android состоит из Android Open Source Project (AOSP, https``://``source``.``android``.``com``/) и набор мобильных сервисов, которые поставляет какая-либо компания. Поставщики мобильных сервисов:
● Компания Google. Эти сервисы часто обозначаются как Google Mobile Services (GMS). Используются чаще всего.
● Компания Huawei. Сервисы обозначаются как Huawei Mobile Services (HMS).
● Компания VK. Сервисы предоставляются магазином приложений RuStore.
Большинство мобильных устройств содержат только GMS, однако существуют устройства, которые содержат только HMS, а также устройства с одновременным наличием всех мобильных сервисов (GMS, HMS и RuStore).
Мобильная версия системы «1С:Предприятие», которая работает под управлением ОС Android, поддерживает использование мобильных сервисов как одновременно, так и в любой комбинации. Если на мобильном устройстве установлены все комплекты сервисов и мобильное приложение собрано с включением поддержки всех мобильных сервисов, то:
● При наличии RuStore ‑ он имеет приоритет перед остальными сервисами.
● При наличии GMS ‑ этот набор сервисов имеет приоритет перед HMS.
Сборщик мобильных приложений позволяет управлять поддержкой каждого из наборов мобильных сервисов, включая сборку с отключенной поддержкой всех наборов сервисов. Таким образом, возможность использовать какой-то из наборов сервисов определяется не на уровне конфигурации, а на уровне сборщика (во время сборки приложения).
При описании какой-либо специфической функциональности будут отдельно рассматриваться действия при необходимости использования каждого набора сервисов (GMS, HMS или RuStore). Если какого-либо описания нет, то это значит, что в разницы между сервисами нет или поддерживается только GMS.
28.3.6.2. Используемые функциональности
Механизм используемых функциональностей объединяет в единое целое управление следующими возможностями:
● Указание возможностей мобильной операционной системы, которыми будет пользоваться мобильное приложение. Указание функциональности автоматически определяет разрешения мобильной операционной системы, которые сборщик мобильных приложений будет устанавливать для собираемого мобильного приложения.
● Текст запроса разрешения, который будет отображаться пользователю в тот момент, когда мобильному приложению первый раз потребуется доступ к функциональности, которая «защищена» запросом на предоставление разрешения у пользователя.
● Размер собираемого мобильного приложения. Если какая-либо функциональность не включена в конфигурации, то при сборке мобильного приложения соответствующий модуль мобильной версии системы «1С:Предприятие», возможно, не будет включен в собранное приложение. Данное поведение, в частности, обуславливает еще одну особенность: если в мобильном приложении будет выполнена попытка вызова любого метода отключенного модуля ‑ это завершится безусловным вызовом исключения.
Рассмотрим более подробно взаимодействие настройки используемых функциональностей и кода на встроенном языке. Для того, чтобы определить, что та или иная функциональность разрешена для мобильного приложения, предназначен метод ПоддерживаетсяФункциональностьМобильногоПриложения(). Если метод возвращает значение Истина, то запрошенные возможности подключены в собранном приложении и теперь можно выполнить проверку, что на данном устройстве доступна возможность, связанная с используемой функциональностью. Например, если требуется проверить, что на устройстве поддерживается набор номера, предназначен метод СредстваТелефонии.ПоддерживаетсяНаборНомера() (подробнее см. здесь). Но данный метод связан с функциональностью Телефония/Набор номера. Таким образом, полная проверка возможности использовать набора номера может выглядеть следующим образом:
Если ПоддерживаетсяФункциональностьМобильногоПриложения(ФункциональностьМобильногоПриложения.НаборНомера) Тогда Если СредстваТелефонии.ПоддерживаетсяНаборНомера(Неопределено) Тогда // здесь можно использовать набор номера КонецЕсли; КонецЕсли;
Справедливости ради, следует отметить, что данный код является избыточным. Дело в том, что практически всегда разработчик прикладного решения знает, какие функциональности использует его прикладное решение. Поэтому код можно упростить до следующего:
Если СредстваТелефонии.ПоддерживаетсяНаборНомера(Неопределено) Тогда // здесь можно использовать набор номера КонецЕсли;
Но первый вариант также имеет право на жизнь. Дело в том, что при использовании метода ПоддерживаетсяФункциональностьМобильногоПриложения() в мобильном клиенте, проверяется список выбранных функциональностей не только на самом мобильном устройстве, но и на сервере. Метод вернет Истина только в том случае, если проверяемая функциональность включена и на мобильном устройстве, и на сервере. Таким образом, если при разработке конфигурации мобильного клиента для каких-то функциональностей возможна ситуация, когда функциональности могу включаться или отключаться для разных версий мобильного приложения ‑ рекомендуется заложить применение метода ПоддерживаетсяФункциональностьМобильногоПриложения() для предотвращения формирования исключений времени исполнения. В мобильном приложении такая предосторожность представляется излишней.
Далее приведена информация о том, какие возможности объектной модели встроенного языка связаны с какими используемыми функциональностями и как ведет себя система при попытке использовать не подключенную функциональность:
|
Функциональность |
При отключении |
На что влияет |
|
|
Искл |
|
|
|
Н/О |
Доступность свойства глобального контекста
|
|
|
Искл |
|
|
|
Искл |
|
|
|
Искл |
Не интерактивный вариант использования
метода |
|
|
Искл |
Возможность доступа к библиотеке музыки при использовании библиотек мультимедиа. Например, в диалоге открытия файла |
|
|
Искл |
Возможность доступа к библиотекам картинок и видео при использовании библиотек мультимедиа. Например, в диалоге открытия файла |
|
|
Искл |
|
|
|
Н/О |
Использование возможностей работы с видеоконференцией системы взаимодействия и демонстрацией экрана в мобильном клиенте |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность свойства глобального контекста
|
|
|
Н/О |
Использование возможностей обработки входящих запросов «Поделиться» для выбранных типов файлов |
|
|
Искл |
Доступность объекта |
|
|
Искл |
Доступность объектов |
|
|
Н/О |
|
|
|
Искл |
Доступность объектов |
|
|
Искл |
Доступ к файловой системе (включая работу с файлами) за пределами каталога приложения (только для ОС Android). |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность объектов и методов |
|
|
п.1 |
Фоновое использование |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность объектов и методов |
|
|
Искл |
Доступность объектов и методов |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность объектов |
|
|
Н/О |
|
|
|
Н/О |
Использование возможностей обработки входящих запросов «Поделиться» для всех типов файлов |
|
|
Искл |
Доступность объектов и методов |
|
|
Искл |
Доступность объектов и методов |
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность свойства глобального контекста
|
|
|
Н/О |
|
|
|
Искл |
Доступность свойства глобального контекста
|
|
|
Искл |
Доступность свойства глобального контекста
|
|
|
Искл |
Доступность методов |
|
|
Искл |
Доступность методов |
|
|
Н/О |
|
В таблице:
● Искл ‑ означает, что попытка использования функциональности, которая отключена в свойствах конфигурации, приведет к возникновению исключения времени исполнения.
● Н/О ‑ означает, что поведение системы не определено. В общем случае поведение мобильной версии «1С:Предприятия» определяется используемой мобильной ОС и задействованной возможностью. В каких-то случаях действие может быть выполнено, в каких-то ‑ нет, возможно появление ошибки мобильной ОС и т. д. Следует понимать, что если разработчик не включает использование какой-либо функциональности в конфигурации, то он автоматически отказывается от использования всех возможностей мобильной версии, связанных с этой функциональностью.
● п.1 ‑ аудиозапись может выполняться только в активном приложении. В свернутом приложении аудиозапись не ведется.
28.3.6.3. Работа с телефонией
Мобильная версия «1С:Предприятия» предоставляет набор возможностей, которые позволяют выполнять звонки из мобильных приложений. Звонки можно выполнять как с подтверждением пользователя, так и без такового. Также система предоставляет доступ к журналу звонков и возможность обрабатывать события, возникающие при получении или совершении телефонных звонков. Прикладное решение может определить возможности по работе с телефонией. Для этого предназначены методы ПоддерживаетсяНаборНомера(), ПоддерживаетсяЖурналЗвонков() и ПоддерживаетсяОбработкаЗвонков() объекта СредстваТелефонии. Обработка звонков возможна только на ОС Android.
Набор номера выполняется следующим образом:
Если СредстваТелефонии.ПоддерживаетсяНаборНомера() Тогда СредстваТелефонии.НабратьНомер(НомерТелефона, ВызватьСразу); КонецЕсли;
Параметр ВызватьСразу отвечает за то, как будет выполняться вызов абонента:
● Параметр равен значению Истина ‑ в этом случае при выполнении метода номер начинает набираться автоматически. На экране появляется стандартный интерфейс программы работы со звонками.
● Параметр равен значению Ложь ‑ в этом случае при выполнении метода будет открыто приложение работы со звонками, в котором будет установлен заданный номер. Пользователю останется только нажать кнопку начала вызова.
Мобильные устройства, функционирующие под управление ОС Android, предоставляют возможность доступа к журналу звонков. Имеется возможность перебрать записи журнала с установкой необходимого отбора. Для работы с журналом необходимо использовать метод ПолучитьЖурналЗвонков() объекта СредстваТелефонии.
Следующий пример демонстрирует получение списка всех пропущенных звонков на мобильном устройстве.
Если СредстваТелефонии.ПоддерживаетсяЖурналЗвонков() Тогда Журнал = СредстваТелефонии.ПолучитьЖурналЗвонков(); Отбор = Новый ОтборКомпоновкиДанных; НовыйЭлемент = Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных")); НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("ТипЗвонка"); НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно; НовыйЭлемент.ПравоеЗначение = ТипЗвонкаЖурналаЗвонков.Пропущенный; НовыйЭлемент.Использование = Истина; ЗаписиЖурнала = Журнал.НайтиЗаписи(Отбор); Для каждого Запись Из ЗаписиЖурнала Цикл // обработка списка звонков КонецЦикла; КонецЕсли;
При работе с журналом звонков следует помнить, что отбор журнала выполняется с помощью объекта ОтборКомпоновкиДанных.
Для обработки событий звонков (на устройствах под управлением ОС Android) предоставляется возможность подключения/отключения обработчика звонков. После того, как в системе регистрируется обработчик событий звонков, при наступлении того или иного события вызывается зарегистрированный обработчик, в который передается информация о звонке. Обработчик не позволяет управлять собственно звонком, для этого используется штатная программа операционной системы.
С помощью данного механизма можно реализовать, например, собственный журнал звонков мобильного приложения или реализовать напоминание о пропущенном звонке.
&НаКлиенте Процедура УправлениеОбработчикомЗвонков(ПодключитьОбработчик) Если НЕ СредстваТелефонии.ПоддерживаетсяОбработкаЗвонков() Тогда // обработка звонков не поддерживается Возврат; КонецЕсли; Обработчик = Новый ОписаниеОповещения("ОбработчикЗвонков", ЭтотОбъект, "Параметры"); Если ОбрабатыватьСобытияЗвонка Тогда СредстваТелефонии.ПодключитьОбработчикЗвонков(Обработчик); Иначе СредстваТелефонии.ОтключитьОбработчикЗвонков(); КонецЕсли; КонецПроцедуры Процедура ОбработчикЗвонков(НомерТелефона, Дата, ВариантСобытия, ТипЗвонка, ДопПараметры) Экспорт // обработка событий звонков КонецПроцедуры
28.3.6.4. Работа с сообщениями (SMS и MMS)
Мобильная версия «1С:Предприятия» предоставляет набор инструментов, позволяющих работать с сообщениями (SMS и MMS). Предоставляется возможность отправлять и получать сообщения. Доступ к списку сообщений определяется используемой мобильной операционной системой. Отправка сообщений возможна как в интерактивном, так и в полностью программном режиме (не интерактивном режиме).
Мобильная версия «1С:Предприятия» предоставляет средства для определения возможностей используемой мобильной ОС. Для этого у объекта глобального контекста СредстваТелефонии существуют методы ПоддерживаетсяОтправка``SMS``(), ПоддерживаетсяПрием``SMS``() и ПоддерживаетсяОтправка``MMS``(). В зависимости от используемой мобильной операционной системы, существуют следующие ограничения на работу с сообщениями:
● Для ОС iOS:
● Недоступна подписка на получение SMS/MMS;
● Недоступна не интерактивная отправка SMS/MMS.
● Для ОС Android:
● Недоступна не интерактивная отправка MMS.
● Для ОС Windows:
● Недоступна подписка на получение SMS/MMS;
● Недоступна не интерактивная отправка SMS/MMS.
Сообщение в «1С:Предприятии» представлено объектом SMS``Сообщение. Отправка сообщения выглядит следующим образом:
&НаКлиенте Процедура ОтправитьСМС(Кому, Текст, ПослатьИнтерактивно) СМС = Новый SMSСообщение(); СМС.Текст = Текст; СтрокаПолучатели = СтрЗаменить(Кому, ",", Символы.ПС); Для Счетчик=1 По СтрЧислоСтрок(СтрокаПолучатели) Цикл СМС.Получатели.Добавить(СокрЛП(СтрПолучитьСтроку(СтрокаПолучатели, Счетчик))); КонецЦикла; СредстваТелефонии.ПослатьSMS(СМС, ПослатьИнтерактивно); КонецПроцедуры
В качестве значения параметра Кому могут быть переданы несколько номеров телефонов, разделенных символом «,». Параметр ПослатьИнтерактивно определяет, как будет отправлено сообщение:
● Параметр установлен в значение Истина ‑ сообщение будет отправлено сразу;
● Параметр установлен в значение Ложь ‑ будет открыто приложение работы с сообщениями, которое указано в качестве приложения по умолчанию для используемой мобильной ОС. В этом приложении будет открыта форма отправки сообщения с заполненными полями. В этом случае пользователь должен самостоятельно нажать кнопку отправки сообщения в открытой форме.
Для того чтобы SMS-сообщение было преобразовано в MMS-сообщение, необходимо добавить вложения в сообщения. Это делается с помощью свойства SMS``Сообщение.Вложения. При этом в качестве значения свойства ТипСодержимого объекта MMS``Вложение следует указывать MIME-тип передаваемых данных, например, для jpeg-файла это будет image/``jpeg.
Если мобильная ОС позволяет, мобильная версия «1С:Предприятия» позволяет подписаться на оповещение о получении SMS-сообщений.
&НаКлиенте Процедура ПодключитьОбработчикПолученияСообщений() ПолучательСообщений = Новый ОписаниеОповещения("ПолучениеСообщения", ЭтотОбъект); СредстваТелефонии.ПодключитьОбработчикSMSСообщений(ПолучательСообщений); КонецПроцедуры &НаКлиенте Процедура ПолучениеСообщения(Сообщение, ДополнительныеПараметры) Экспорт Сообщить(Сообщение.Отправитель + " - " + Сообщение.Текст); КонецПроцедуры
При получении входящего сообщения, будет вызываться обработчик оповещения для обработки полученного сообщения. Сообщения, полученные с помощью установленного обработчика оповещения, также будут доступны и из системного приложения по работе с сообщениями.
Проверить возможность доступа у журналу сообщений можно с помощью метода СредстваТелефонии.ПоддерживаетсяЖурнал``SMS``(). Если используемая мобильная ОС предоставляет доступ к журналу сообщений, то становится доступной возможность получать сообщения в соответствии с наложенным отбором.
Следующий пример демонстрирует получение списка всех не прочитанных сообщений на мобильном устройстве.
Если СредстваТелефонии.ПоддерживаетсяЖурналSMS() Тогда Журнал = СредстваТелефонии.ПолучитьЖурналSMS(); Отбор = Новый ОтборКомпоновкиДанных; НовыйЭлемент = Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных")); НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Прочитано"); НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно; НовыйЭлемент.ПравоеЗначение = Ложь; НовыйЭлемент.Использование = Истина; ЗаписиЖурнала = Журнал.НайтиЗаписи(Отбор); Для каждого Запись Из ЗаписиЖурнала Цикл // обработка списка сообщений КонецЦикла; КонецЕсли;
При работе с журналом SMS следует помнить, что отбор журнала выполняется с помощью объекта ОтборКомпоновкиДанных.
При отборе по полю НомераТелефонов следует учитывать некоторые особенности:
● Допустимо указывать фрагменты номеров, только если в качестве правого значения элемента отбора используется строка, и при этом вид сравнения должен быть ВидСравненияКомпоновкиДанных.Содержит или ВидСравненияКомпоновкиДанных.НеСодержит. Пробелы, скобки и дефисы в номере не игнорируются.
● Не поддерживается указание имен из адресной книги (списка контактов).
● Если в качестве значения отбора указан массив номеров, то сообщение считается удовлетворяющей условию только в том случае, если в сообщении и отборе одинаковое количество номеров и все номера полностью совпадают друг с другом.
В результате поиска формируется список сообщений, упорядоченный так, чтобы в начале списка были самые новые сообщения.
28.3.6.5. Средства геопозиционирования
28.3.6.5.1. Общая информация
Большое количество мобильных устройств поддерживает определение координат, по которым располагается устройство. Также предоставляется возможность выполнять преобразование полученных координат в адрес и наоборот. Для доступа к этим функциям предназначен провайдер геопозиционирования. Каждый провайдер описывается именем и определенным набором параметров (возможностей). Конкретный провайдер геопозиционирования может поддерживать не все возможности.
Общая схема работы со средствами геопозиционирования выглядит следующим образом:
1. Выбирается необходимый провайдер геопозиционирования. В каждом случае следует выбирать тот провайдер, который максимально подходит для реализации поставленной задачи. В общем случае стоит выбирать провайдера, который обеспечивает минимальное энергопотребление и максимальную точность определения координат.
Пример:
// Определим провайдера, который не приводит к расходованию // средств и использует для определения координат // сеть сотовой связи ИскомыйПровайдер = Неопределено; Провайдеры = СредстваГеопозиционирования.ПолучитьПровайдеров(); Для каждого Провайдер Из Провайдеры Цикл Если НЕ Провайдер.Платный и Провайдер.ИспользуетСотовуюСеть Тогда ИскомыйПровайдер = Провайдер; Прервать; КонецЕсли; КонецЦикла; Если ИскомыйПровайдер = Неопределено Тогда Сообщить("Требуемый провайдер не обнаружен"); Иначе Сообщить("Найден провайдер: " + ИскомыйПровайдер.Имя); КонецЕсли;
В случае необходимости получить самый энергоэффективный провайдер или самый точный провайдер, можно воспользоваться методами ПолучитьСамогоЭнергоЭкономичногоПровайдера() или ПолучитьСамогоТочногоПровайдера() (соответственно).
2. Выполняется определение координат с помощью выбранного провайдера геопозиционирования. Для получения координат используются два метода. Метод ПолучитьПоследнееМестоположение() возвращает последние данные о местоположении, полученные выбранным провайдером. Среди свойств объекта ДанныеМестоположения (который возвращает метод ПолучитьПоследнееМестоположение()), есть свойство Дата, которое описывает, когда были получены данные о местоположении. Если эти данные были получены очень давно, то необходимо вызвать метод ОбновитьМестоположение() для того, чтобы провайдер геопозиционирования заново определил данные о местоположении. Один из параметров метода определяет тайм-аут на определение местоположения. В том случае, если метод завершен по тайм-ауту, фактическое определение координат в данном случае зависит от особенностей реализации конкретной версии мобильной операционной системы.
Пример:
// Если местоположение на данном устройстве ни разу не выполнялось // или выполнено более часа назад - обновить местоположение и // получить определенные координаты Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера); Если Координаты = Неопределено Или ТекущаяДата()-МестноеВремя(Координаты.Дата) > 3600 Тогда СредстваГеопозиционирования.ОбновитьМестоположение(ИмяПровайдера, 60); Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера); КонецЕсли;
3. При необходимости, выполняется подписка на изменение координат. После того, как потребность в подписке отпала ‑ можно отключить оповещение об изменении координат.
После получения данных о местоположении, имеется возможность выполнить несколько вспомогательных операций, связанных с полученным местоположением:
● Получить адрес по координатам. Для этого предназначен метод ПолучитьАдресПоМестоположению().
● Получить координаты места по адресу. Для этого предназначен метод ПолучитьМестоположениеПоАдресу().
● Показать карту, на которой отображены координаты одной или нескольких точек. Для этого предназначен метод ПоказатьНаКарте(). Данная возможность предоставляется не на всех мобильных ОС. Метод ПоддерживаетсяОтображениеКарты() позволяет определить возможность отображения на карте одной или нескольких точек. Для отображения точек на карте в каждой мобильной ОС будет использовать фирменное приложение разработчика операционной системы.
**Примечание 1. Для работы методов преобразования координат в адрес и обратно, на мобильном устройстве должен быть доступ в Интернет.
Примечание 2. Не поддерживается работа механизма геопозиционирования в фоновом режиме на устройствах под управлением ОС iOS.**
28.3.6.5.2. Получение ключа для работы с Google Maps
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для того чтобы мобильное приложение могло работать с геопозиционированием под управлением ОС Android с использованием GMS, необходимо получить специальный ключ для работы с Google Maps. Получение ключа выполняется следующим образом:
1. Войдите в консоль разработчика (Google Developers Console, https://console.developers.google.com/project).
2. Создайте проект (кнопка Создать проект).
3. Включите возможность использования сервиса Google Maps. Для этого необходимо выбрать приложение, а затем использовать команду меню Продукты и сервисы``‑ Диспетчер``API (меню доступно в левом верхнем углу страницы, рядом с надписью Google``APIs). На станице Библиотека следует ввести в поле ввода Google``Maps``Android``API. В списке ниже поля ввода выбрать пункт Google``Maps``Android``API, и на открывшейся странице нажать гиперссылку Включить (в верхней части страницы, справа от надписи Google``Maps``Android``API).
4. Получите ключ программного интерфейса (Ключ``API). Для этого необходимо выбрать в левой части страницы пункт меню Учетные данные. В разделе Учетные данные следует нажать кнопку Создать учетные данные и в выпадающем меню выбрать Ключ``API. После создания ключа нажать кнопку Закрыть в получившемся диалоге.
5. Создайте группу мобильного приложения в сборщике приложений для мобильных устройств (предварительно выполнив настройку сборщика приложений для мобильных устройств) и скопировать содержимое поля Параметр получения ключа для работы с картами``Google.
6. В переключателе Ограничение для ключа следует выбрать Приложения для``Android. Затем нажать кнопку Добавить ресурс: название пакета и контрольная сумма. Скопированные данные необходимо вставить в поле Контрольная сумма сертификата``SHA-1. Затем в конце вставленной строки выделить полный идентификатор приложения и перенести его в поле Название пакета. При этом контрольная сумма не должна заканчиваться на символ ";".
7. После окончания формирования ключа, он будет отображен в поле Ключ``API. Получившееся значение необходимо указать в поле Ключ для работы с картами``Google, находящееся в форме группы мобильного приложения. Затем необходимо сохранить группу мобильного приложения.
28.3.6.5.3. Получение ключа для работы c Map SDK (карты от Huawei)
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для того чтобы мобильное приложение могло работать с геопозиционированием под управлением ОС Android с использованием HMS, необходимо получить специальный ключ для работы с Huawei Map SDK. Получение ключа выполняется следующим образом (пропустить шаги по созданию приложения, если оно уже создано в AppGallery Connect и в сборщике мобильных приложений):
1. Зарегистрируйтесь как разработчик Huawei (документация по регистрации https://``developer.``huawei.``com/``consumer/``en/``doc/``start/``registration-``and-``verification-0000001053628148 ).
2. Выполнить вход в AppGallery Connect (https://``developer.``huawei.``com/``consumer/``en/``service/``josp/``agc/``index.``html#/).
3. Создайте проект (нажать Add``project).
4. Создайте приложение (нажать кнопку New``app). Задайте соответствующие параметры приложения:
● Платформа: Android.
● Устройство: Mobile``phone.
● Категория приложения: App``or``Game.
5. Скопировать содержимое поля Хеш``SHA256 ключа подписи из настроек поставщика для ОС Android (раздел Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС Андроид). Сборщик приложений для мобильных устройств должен быть корректно настроен к этому моменту.
6. В AppGallery Connect выбрать Мои проекты и нужный проект. В настройках проекта на закладке Основная информация выбрать раздел Данные приложения. В поле ввода Отпечаток сертификата``SHA-256 ввести значение, которое мы получили на предыдущем шаге и нажать Сохранить.
7. Перейти на закладку Управление``API. Включить Map``Kit.
8. На закладке Общая информация, в разделе Данные приложение скачать файл agconnect-``services.``json.
9. Скачанный файл загрузить в группу мобильного приложения в сборщике мобильных приложений:
● Перейти на закладку Для ОС``Android.
● Включить флажок Использовать сервисы``Huawei.
● В группе Работа с``AppGallery``Connect загрузить полученный json-файл.
10. После выполнения этих действий собранное с помощью сборщика мобильное приложение сможет использовать возможности Map SDK в своей работе.
28.3.6.5.4. Получение ключа для работы с картами RuStore
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для того чтобы мобильное приложение могло работать с геопозиционированием под управлением ОС Android с использованием RuStore, необходимо получить специальный ключ для работы с RuStore Maps SDK. Получение ключа выполняется следующим образом (пропустить шаги по созданию приложения, если оно уже создано в RuStore и в сборщике мобильных приложений):
1. Зарегистрируйтесь в RuStore как разработчик (документация по регистрации доступна по адресу https://www.rustore.ru/help/developers/developer-account).
2. Выполните вход в консоль разработчика RuStore (https://dev.rustore.ru/).
3. Создайте приложение (нажать + Добавить приложение). Задайте соответствующие параметры приложения:
● Тип приложения: Универсальный.
● Тип монетизации: Бесплатное / Платное.
● Название приложения в консоли. Оно будет видно только вам. Данное значение позже можно изменить.
4. В RuStore выбрать приложение. Затем перейти в раздел Карты и геосервисы. В карточке Создайте сервисный токен нажать + Создать токен.
5. Запомните созданный токен. Его будет необходимо указать в группе мобильного приложения (в сборщике мобильных приложений):
● Перейти на закладку Для ОС``Android.
● Включить флажок Использовать сервисы``RuStore.
● Запомненный токен введите в поле Токен для работы с географическими картами.
6. После выполнения этих действий собранное с помощью сборщика мобильное приложение сможет использовать возможности RuStore Maps SDK в своей работе.
28.3.6.6. Работа с мультимедиа
28.3.6.6.1. Аудио
Запись
Мобильные устройства могут выполнять запись аудиоинформации. Для определения возможности выполнения этой операции предназначен метод СредстваМультимедиа.ПоддерживаетсяАудиозапись().
В том случае, если мобильное устройство поддерживает эту возможность, то мобильная версия предоставляет следующие методы для записи звука:
● СредстваМультимедиа.СделатьАудиозапись() ‑ запускает интерфейс аудиозаписи. Выполнение программы на встроенном языке будет ожидать выполнения требуемого действия (окончания записи).
● СредстваМультимедиа.ВключитьАудиозапись() ‑ запускает фоновую запись звука. При этом выполнение прикладного решения продолжится, а для остановки записи предназначена специальная кнопка, отображаемая на экране. Остановить запись из встроенного языка можно с помощью вызова метода СредстваМультимедиа.ОтключитьАудиозапись(). Для оповещения прикладного решения об окончании записи служит обработчик, который передается в метод ВключитьАудиозапись().
Для управления параметрами аудиозаписи служит объект ПараметрыАудиозаписи. Этот объект позволяет задать следующие параметры:
● В каком режиме будет выполняться запись звука: моно или стерео. Задается свойством ИспользованиеКаналовАудиозаписи.
● Битрейт записи. Определяет, какой объем (в битах) займет одна секунда записи. Единица измерения: бит/секунду. Задается свойством СкоростьКодирования.
● Частота дискретизации звука. Определяет, как точно будет записываться звук или, другими словами, задает частоту, с которой выполняется оцифровка звука. Единица измерения: кГц. Задается свойством ЧастотаДискретизации.
● В каком формате будут получены записанные данные. Определяет формат получаемых данных. От значения данного свойства зависят формат данных, MIME-тип и расширение файла. Задается свойством ФорматАудиозаписи.
Параметры записи могут быть указаны как для синхронной записи звука, так и для фоновой записи. Для этого предназначены соответствующие параметры каждого метода. Для того, чтобы фоновая аудиозапись была возможна, и не останавливалась при засыпании устройства, необходимо указать функциональность Запись аудио в фоновом режиме в свойстве конфигурации Используемая функциональность мобильного приложения (см. здесь).
Воспроизведение
Мобильная версия «1С:Предприятия» предоставляет возможность воспроизводить звуковые оповещения, воспроизводить аудиофайлы и выполнять синтез речи. Возможность выполнения синтеза речи зависит от языка, на котором предполагается выполнять синтез.
Для воспроизведения звукового оповещения (короткий звуковой или вибросигнал) предназначен метод СредстваМультимедиа.ВоспроизвестиЗвуковоеОповещение(). Имеется возможность воспроизвести либо стандартный звук системы, либо звуковой файл, имя которого передается в качестве параметра Звук этого метода. Этот звуковой файл должен входить в состав мобильного приложения. Однако на мобильной платформе разработчика отсутствует возможность подключать ресурсы (к которым относятся воспроизводимые файлы). Для того чтобы указанный файл был прикреплен к мобильному приложению, следует воспользоваться возможностями сборщика приложений для мобильных устройств (см. здесь). В силу этого, проверить использование звуковых оповещений из файлов можно только в собранном приложении. Возможность использования вибрации при воспроизведении звукового оповещения управляется параметром Вибрация метода ВоспроизвестиЗвуковоеОповещение(). Если имя файла со звуковым оповещением указано без расширения, то используются следующие расширения (в зависимости от ОС) по умолчанию:
● ОС Android ‑ расширение .``mp3;
● ОС iOS ‑ расширение .``caf;
● ОС Windows ‑ расширение .``mp3.
Воспроизведение оповещения нельзя приостановить или остановить. Оно всегда воспроизводится целиком и полностью.
Вызов метода глобального контекста Сигнал() эквивалентен вызову метода СредстваМультимедиа.ВоспроизвестиЗвуковоеОповещение(ЗвуковоеОповещение.ПоУмолчанию).
Если необходимо воспроизвести некоторый звуковой файл, то следует воспользоваться методом СредстваМультимедиа.ВоспроизвестиАудио(). В качестве источника воспроизведения могут выступать объект ДанныеМультимедиа (результат работы метода СделатьАудиозапись() или ВключитьАудиозапись()), объект ДвоичныеДанные (который содержит непосредственно аудиофайл требуемого формата) или имя файла (тип Строка). Воспроизведение аудиофайла, входящего в состав мобильного приложения, не поддерживается. В том случае, если прикладное решение должно обрабатывать состояние остановки воспроизведения ‑ надо указать обработчик оповещения (в параметре ОбработчикОстановкиВоспроизведения), который будет вызываться в том случае, если воспроизведение остановлено или прервано.
Остановить воспроизведение аудиофайла можно с помощью метода СредстваМультимедиа.ОстановитьВоспроизведениеАудио(). Если аудиофайл в данный момент не воспроизводится ‑ ничего не произойдет.
С точки зрения возможности воспроизведения различных форматов аудиофайлов, рекомендуется опираться на MIME-тип файла. Воспроизведение аудиофайлов возможно в том случае, если эти файлы имеют следующие MIME-типы (в зависимости от используемой мобильной ОС):
● ОС Android ‑ audio``/3``gpp;
● ОС iOS ‑ audio``/``mp``4;
● ОС Windows ‑ audio``/``aac.
Кроме того, имеется возможность воспроизводить аудиофайлы со следующими MIME-типами:
● формат AAC ‑ audio``/``aac;
● формат MP3 ‑ audio``/``mpeg;
● формат WAVE ‑ audio``/``vnd``.``wave (для ОС Android ‑ начиная с версии 4.1 и выше).
Воспроизведение аудиофайлов, MIME-типы которых отличаются от перечисленных выше, не поддерживается.
Далее приведен простой пример, в котором на форме находятся две кнопки, нажатие на одну из которых (обработчик ВоспроизвестиАудио()) приводит к выбору проигрываемого файла и запуск его воспроизведения, а при нажатии на вторую кнопку (обработчик Остановить()) ‑ выполняется остановка ранее запущенного воспроизведения.
&НаКлиенте Процедура ВоспроизвестиАудио(Команда) Диалог = Новый ДиалогВыбораФайла(РежимДиалогаВыбораФайла.Открытие); Если Диалог.Выбрать() Тогда Данные = Диалог.ПолноеИмяФайла; СредстваМультимедиа.ВоспроизвестиАудио(Данные); Файл = Новый Файл(Диалог.ПолноеИмяФайла); Сообщить("" + Файл.ПолучитьПредставлениеФайлаБиблиотекиМобильногоУстройства() + " длительностью " + СредстваМультимедиа.ПолучитьПродолжительностьАудио(Данные) + " секунд"); КонецЕсли; КонецПроцедуры &НаКлиенте Процедура Остановить(Команда) СредстваМультимедиа.ОстановитьВоспроизведениеАудио(); КонецПроцедуры
На мобильной платформе имеется возможность использовать синтезатор речи, встроенный в операционную систему. Доступность синтезатора для конкретного языка следует проверять с помощью метода СредстваМультимедиа.ПоддерживаетсяВоспроизведениеТекста(). Если синтезатор речи доступен ‑ можно воспроизвести текст с помощью метода СредстваМультимедиа.ВоспроизвестиТекст(). При необходимости обрабатывать прерывание синтеза речи, имеется возможность установить соответствующий обработчик с помощью параметра ОбработчикОстановкиВоспроизведения. Прервать воспроизведение текста можно с помощью метода СредстваМультимедиа.ОстановитьВоспроизведениеТекста().
28.3.6.6.2. Фото и видео
Мобильные устройства обладают различными фотовозможностями: сделать фотоснимок, выполнить запись видеролика. Для различных мобильных устройств эти возможности могут быть доступны или нет. Для определения возможности выполнения той или иной операции предоставляются специальные функции: ПоддерживаетсяФотоснимок(), ПоддерживаетсяВидеозапись().
В том случае, если мобильное устройство поддерживает ту или иную возможность, можно воспользоваться методом глобального контекста, который активирует необходимое системное приложение для выполнения нужного действия: СделатьФотоснимок(), СделатьВидеозапись().
В связи с тем, что мобильные устройства могут обладать двумя камерами (передней и задней), платформа предоставляет мобильному приложению возможность работать с камерами по выбору. Для этого следует использовать системное перечисление ТипКамерыУстройства при определении возможностей мобильного устройства и при выполнении того или иного действия.
Передняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Передняя); Задняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Задняя);
Вышеприведенный программный код позволяет определить, какая из двух камер устройства поддерживает фотосъемку. С помощью этих методов можно определять наличие той или иной камеры на устройстве. При выполнении фото‑ или видеосъемки, также имеется возможность указать используемую камеру. Если тип камеры указан как ТипКамерыУстройства.Авто, то на устройствах это будет обрабатываться следующим образом:
● На устройстве имеется две камеры ‑ будет использована задняя камера;
● На устройстве имеется одна камера ‑ будет использована эта камера (в зависимости от наличия).
Кроме того, при попытке сделать фотоснимок или выполнить видеосъемку, имеется возможность указать некоторые дополнительные параметры, влияющие на результат действия.
При попытке выполнить фотосъемку имеется возможность (кроме типа камеры) дополнительно указать:
● С каким разрешением необходимо выполнить съемку. Если указано разрешение, не поддерживаемое устройством, будет выбрано ближайшее подходящее разрешение. Перечень поддерживаемых разрешений можно получить с помощью метода ПолучитьПоддерживаемыеРазрешенияКамеры() объекта СредстваМультимедиа. Для устройств, работающих под управлением ОС iOS, данный параметр игнорируется.
● С каким качеством будет получен результирующий снимок. Фактически определяет степень сжатия jpeg-файла. 100 ‑ означает максимальное качество.
● Какой снимок должен быть получен в результате: цветной или черно-белый. Для устройств, работающих под управлением ОС iOS, указание на необходимость получить черно-белый снимок, не влияет на интерфейс камеры (но сам снимок будет черно-белым).
● Начальный режим использования вспышки при открытии интерфейса камеры. Для этого служит параметр ТипПодсветки метода СделатьФотоснимок(). Имеется возможность принудительно включить, выключить вспышку или предоставить устройству определить режим работы вспышки автоматически.
● С помощью параметра Отметка можно управлять возможностью вставки в правый нижний угол фотографии даты и времени формирования снимка, а также произвольного текста. Для этого в качестве значения параметра следует передать объект ОтметкаНаФотоснимке.
Для того чтобы ускорить получение данных снимка при работе под управлением ОС Android, рекомендуется выполнять следующие действия:
● В том случае, если приложению не требуется фронтальная камера, принудительно устанавливать в качестве основной камеры заднюю камеру (параметр ТипКамеры метода СредстваМультимедиа.СделатьФотоснимок()). Если устанавливается автоматический режим определения камеры ‑ не рекомендуется в интерфейсе фотокамеры выполнять переключение на переднюю камеру устройства.
● При фотографировании желательно держать устройство горизонтально (широкой стороной вниз) и камерой слева.
● Не включать преобразование снимка в монохромный (параметр ЧерноБелый метода СредстваМультимедиа.СделатьФотоснимок()) без очевидной необходимости.
● По возможности уменьшать разрешение и качество получаемого снимка до разумных значений (параметры Разрешение и Качество метода СредстваМультимедиа.СделатьФотоснимок()). Например, установка параметра Качество в 50%, а параметра Разрешение в 50% от максимального разрешения камеры, может уменьшить время получения снимка в 1,5 раза.
При попытке выполнить видеосъемку, кроме указания типа камеры, имеется возможность указать качество получаемого ролика. Устройства, работающие под управлением ОС iOS, игнорируют этот параметр.
28.3.6.7. Сканирование штрихкодов
Мобильное устройство, обладающее камерой, позволяет выполнять функции сканирования штрихкодов. Для доступа к этой возможности платформа предоставляет специальный интерфейс.
Примечание. Для эффективного сканирования штрихкодов желательно, чтобы камера мобильного устройства обладала возможностью автоматической наводки объектива камеры на резкость (автофокусом). В противном случае сканирование штрихкодов будет затруднено.
Общая схема работы со сканером штрихкодов выглядит следующим образом:
1. Определяется возможность работы с механизмом сканирования. Для этого необходимо использовать метод ПоддерживаетсяСканированиеШтрихКодов() объекта глобального контекста СредстваМультимедиа.
2. В том случае, если сканирование поддерживается, метод ПоказатьСканированиеШтрихКодов() объекта СредстваМультимедиа открывает специальный интерфейс по сканированию штрихкодов. При выполнении операции сканирования вызывается специальный обработчик, содержащий информацию о результате сканирования.
3. Закрыть интерфейс сканирования можно или вручную, с помощью стандартной кнопки перехода к предыдущей форме интерфейса ОС Android, или из встроенного языка, с помощью метода ЗакрытьСканированиеШтрихКодов() объекта СредстваМультимедиа.
Рассмотрим пример работы с данным механизмом. Для демонстрации будет использоваться простая форма, на которой расположена кнопка открытия интерфейса сканирования и признак закрытия этого интерфейса после однократного сканирования. Сканированный штрихкод будет выводиться в виде сообщения.
Примечание. Данный пример не является законченным инструментом. Он предназначены для демонстрации работы с механизмом сканирования штрихкодов.
В форме необходимо создать реквизит ЗакрытьИнтерфейс типа Булево и разместить на форме элемент, отображающий этот реквизит. Также следует создать команду формы ОткрытьИнтерфейсСканирования, которую также следует разместить на форме. Модуль формы будет иметь следующий вид:
// Обработчик команды формы ОткрытьИнтерфейсСканирования &НаКлиенте Процедура ОткрытьИнтерфейсСканирования(Команда) ОбработчикСканирования = Новый ОписаниеОповещения("ОбработкаСканирования", ЭтотОбъект); ОбработчикЗакрытия = Новый ОписаниеОповещения("ОбработкаЗакрытияИнтерфейса", ЭтотОбъект); СредстваМультимедиа.ПоказатьСканированиеШтрихКодов("Наведите камеру на штрихкод", ОбработчикСканирования, ОбработчикЗакрытия); КонецПроцедуры &НаКлиенте Процедура ОбработкаСканирования(Штрихкод, Результат, Сообщение, ДополнительныеПараметры) Экспорт Если Результат Тогда Текст = "" + Штрихкод; Иначе Текст = "Ошибка: " + Сообщение; КонецЕсли; Если ЗакрытьИнтерфейс Тогда СредстваМультимедиа.ЗакрытьСканированиеШтрихКодов(); КонецЕсли; Сообщить(Текст); КонецПроцедуры &НаКлиенте Процедура ОбработкаЗакрытияИнтерфейса(ДополнительныеПараметры) Экспорт Сообщить("Закрывается интерфейс сканирования"); КонецПроцедуры &НаКлиенте Процедура ПриОткрытии(Отказ) Если НЕ СредстваМультимедиа.ПоддерживаетсяСканированиеШтрихКодов() Тогда ВызватьИсключение "Сканирование штрихкодов не поддерживается"; КонецЕсли; ЗакрытьИнтерфейс = Ложь; КонецПроцедуры
При открытии интерфейса сканирования в метод ПоказатьСканированиеШтрихКодов``() передается два описания оповещения. Первое оповещение срабатывает (параметр ОбработчикСканирования) в том случае, когда система успешно распознала штрихкод, второе оповещение (параметр ОбработчикЗакрытия) срабатывает в том случае, когда закрывается окно, предназначенное для сканирования штрихкода. Закрытие может быть как программное, так и интерактивное. Пример программного закрытия приведен в обработчике оповещения ОбработкаСканирования(), а интерактивное закрытие можно выполнить, нажав кнопку Назад в интерфейсе сканирования.
При открытии формы сканирования есть возможность указать, какой (или какие) тип штрихкодов будут ожидаться системой распознавания. Для этого предназначен параметр ТипШтрихКода метода ПоказатьСканированиеШтрихКодов(). Параметр может принимать разные значения:
● Неопределено или ТипШтрихКода.Все. В этом случае платформа будет пытаться определить какой из поддерживаемых типов штрихкодов в данный момент показывается камере. На это необходимо больше времени и, как следствие, больше энергии аккумулятора.
● Конкретное значение системного перечисления ТипШтрихКода (но не обобщающие значения!). В этом случае разработчик явно указывает, что планируется сканировать определенный тип штрихкода и не следует тратить время на попытку понять, какой штрихкод «видит» камера устройства. Самый эффективный способ (как по скорости, так и по энергопотреблению).
● Массив конкретных значений типа ТипШтрихКода. В этом случае разработчик предполагает, что могут сканироваться несколько типов штрих кода, но это количество меньше, чем можно указать с помощью обобщенных значений.
● Обобщающие значения:
● ТипШтрихКода.Линейный ‑ означает, что будут ожидаться любое из линейных типов штрихкодов (например, EAN, UPC и т. д.).
● ТипШтрихКода.Двухмерный ‑ означает, что будут ожидаться любое из двумерных типов штрихкодов (например, QR-код, PDF417 и т. д.).
● Скорость и эффективность в последних двух случаях будет находится в промежуточном положении между попытками сканировать любой штрихкод и конкретный тип штрихкодов.
Перечень поддерживаемых штрихкодов не зависит от используемой мобильной платформы и описывается значениями системного перечисления ТипШтрихКода.
28.3.6.8. Работа с электронной почтой
Мобильная версия «1С:Предприятия» предоставляет прикладному разработчику несколько способов работы с электронной почтой. Один способ позволяет реализовать полноценный почтовый клиент на платформе «1С:Предприятие» (объект ИнтернетПочта и связанные объекты), а другой способ позволяет реализовать только отправку почтовых сообщений с помощью приложения по работе с электронной почтой, установленное в системе по умолчанию (объект СредстваПочты).
При отправке почтовых сообщений типа ТипТекстаПочтовогоСообщения.``HTML с помощью объекта СредстваПочты (под управлением ОС Android) выполняется конвертация текста сообщения в формат Spannable. Отправляемое письмо отображается большинством почтовым клиентов.
При использовании текстов почтовых сообщений с типом ТипТекстаПочтовогоСообщения.``HTML (под управлением ОС Android) не рекомендуется использовать следующие возможности:
● каскадные таблицы стилей;
● встроенные таблицы;
● встроенные изображения;
● шрифты разных размеров.
Рекомендуется проверять отображение электронных писем на максимальном количестве устройств, чтобы минимизировать зависимость от различий реализации на разных ОС и в разных версиях почтовых программ.
Также следует помнить, что тип текстов почтовых сообщений ТипТекстаПочтовогоСообщения.РазмеченныйТекст не поддерживается объектом СредстваПочты.
28.3.6.9. Работа с контактами
Список контактов ‑ это база данных, которая хранит информацию о субъектах, с которыми общается владелец мобильного устройства. Описание контакта содержит идентификационные данные контакта, адреса, телефоны и другую информацию, необходимую для связи с субъектом. Также, на мобильном устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор информации, которые пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На мобильном устройстве всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
Каждая запись в списке контактов связана с какой-либо одной учетной записью. Мобильная операционная система может выполнять синхронизацию списка контактов с данными учетной записи (зависит от настроек ОС). Если контакт связан с локальной учетной записью, то синхронизация информации не выполняется и все данные расположены только на мобильном устройстве.
Основная информация о контакте хранится в объектах типа ДанныеКонтакта. Объекты данного типа содержат всю информацию о контакте, но не содержат связь контакта с учетной записью. В описании контакта есть несколько типов данных, которые могут содержать более одного значения. Такими данными являются номера телефонов, адреса, адреса электронной почты и другие. Для хранения таких данных предназначены массивы объектов типа ЭлементДанныхКонтакта. Для хранения списка идентификаторов в программах мгновенных сообщений предназначен массив объектов ЭлементДанныхКонтактаМгновенныеСообщения.
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта УчетнаяЗаписьКонтактов.
Связь между учетной записью контактов и собственно элементов списка контактов образует объект ДанныеКонтактаУчетнойЗаписи. Кроме информации о контакте и учетной записи, данный объект содержит также идентификатор, по которому выполняется синхронизация между списком контактов на мобильном устройстве и учетной записью. Можно сказать, что свойство ГлобальныйКлючКонтакта объекта ДанныеКонтактаУчетнойЗаписи является аналогом свойства Ссылка для прикладных объектов «1С:Предприятие».
Для идентификации контакта на мобильном устройстве существует объект ЛокальныйКлючКонтакта. Все операции с контактами (создание, изменение, удаление, поиск) выполняются с использованием данного объекта. Для выполнения операций с контактами следует использовать менеджер контактов (одноименный объект).
Следующий пример демонстрирует создание элемента списка контактов в локальной учетной записи:
&НаКлиенте Процедура СоздатьЭлементКонтакта(Имя, Отчество, Фамилия, ЭлектроннаяПочта, Телефон) ДанныеКонтакта = Новый ДанныеКонтакта; ДанныеКонтакта.Имя = Имя; ДанныеКонтакта.Отчество = Отчество; ДанныеКонтакта.Фамилия = Фамилия; ЭлементПочта = Новый ЭлементДанныхКонтакта(ТипАдресаЭлектроннойПочтыДанныхКонтакта.Рабочий, ЭлектроннаяПочта); ДанныеКонтакта.АдресаЭлектроннойПочты.Добавить(ЭлементПочта); ЭлементТелефон = Новый ЭлементДанныхКонтакта(ТипНомераТелефонаДанныхКонтакта.Рабочий, Телефон); ДанныеКонтакта.НомераТелефонов.Добавить(ЭлементТелефон); МК = Новый МенеджерКонтактов; ЛокальныеКонтакты = МК.ПолучитьЛокальнуюУчетнуюЗаписьКонтактов(); Контакт = Новый ДанныеКонтактаУчетнойЗаписи(ДанныеКонтакта, ЛокальныеКонтакты); МК.ДобавитьКонтакт(Контакт); КонецПроцедуры
При необходимости выполнить поиск контакта по какому-либо набору параметров, следует использовать метод НайтиКонтакты() менеджера контактов. Т. к. отбор контактов задается с помощью объекта ОтборКомпоновкиДанных, то существует возможность задать достаточно сложный отбор контактов. При этом надо помнить, что элементы отбора верхнего уровня складываются «по И». Перечень полей, которые могут участвовать в отборе контактов, приведен в описании метода НайтиКонтакты() в Синтакс-помощнике.
28.3.6.10. Работа с календарем
На мобильных устройствах имеется возможность просмотра календаря и заведения в нем различных событий. События характеризуются некоторым набором характеристик, таких как дата и время начала и завершения, описание, занятые лица и т. д. Также, на мобильном устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор информации, которые пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На мобильном устройстве всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
На мобильном устройстве может быть несколько календарей (с разными именами). Каждый календарь связан с какой-либо одной учетной записью. Мобильная операционная система может выполнять синхронизацию событий календарей с данными учетной записи (зависит от настроек ОС). Если события календаря связаны с локальной учетной записью, то синхронизация информации не выполняется и все данные расположены только на мобильном устройстве.
Основная информация о календаре хранится в объекте ДанныеКалендаря. События календаря описываются объектом ДанныеСобытияКалендаря. Данные объекты описывают характеристики календаря или события календаря, но не описывают, с какой учетной записью связан объект.
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта УчетнаяЗаписьКалендарей.
Связь между данными календарей и событий и учетными записями образуется объектами ДанныеКалендаряУчетнойЗаписи и ДанныеСобытияКалендаряУчетнойЗаписи. Эти объекты, кроме информации о собственно данных и информации об учетной записи, хранят информацию значения ключей, по которым выполняется синхронизация между мобильным устройство и сервисом, с которым выполняется синхронизация. Для синхронизации данных о календарях используется ГлобальныйКлючКалендаря, для синхронизации данных о событиях календарей используется ГлобальныйКлючСобытияКалендаря.
Для идентификации данных календарей и событий на мобильном устройстве существует объекты ЛокальныйКлючКалендаря и ЛокальныйКлючСобытияКалендаря. Все операции с календарями и событиями (создание, изменение, удаление, поиск) выполняются с использованием данного объекта. Для выполнения операций с календарями и событиями следует использовать менеджер календарей (одноименный объект).
При необходимости выполнить поиск календаря или события календаря по какому-либо набору параметров, следует использовать методы НайтиКалендари() или НайтиСобытия() менеджера календарей. Т. к. отбор данных задается с помощью объекта ОтборКомпоновкиДанных, то существует возможность задать достаточно сложный отбор контактов. При этом надо помнить, что элементы отбора верхнего уровня складываются «по И». Перечень полей, которые могут участвовать в отборе контактов, приведен в описании методов НайтиКалендари() и НайтиСобытия() в Синтакс-помощнике.
28.3.6.11. Ориентация экрана
Платформа предоставляет информацию о некоторых характеристиках экрана устройства, на котором выполняется клиентское приложение (персональный компьютер или мобильное устройство). Для этого служит метод ПолучитьИнформациюЭкрановКлиента(). В результате возвращается массив структур, описывающих экраны, подключенные к устройству.
Каждый элемент массива описывает один экран, подключенный к устройству. Параметры Высота и Ширина описывают, соответственно, высоту и ширину экрана в точках. При этом для мобильного устройства эти параметры зависят от ориентации устройства (если это разрешено в настройках), а платформы для персонального компьютера всегда возвращает канонические параметры подключенных экранов. Таким образом, на мобильном устройстве можно анализировать, в каком положении находится устройство и на основании этого принимать решения о трансформации интерфейса приложения. Для облегчения работы с ориентацией существует событие ПриИзмененииПараметровЭкрана, которое можно обработать в модуле управляемого приложения и в модуле управляемой формы.
В качестве примера рассмотрим изменение отображения формы, отображаемой на рабочем столе. В указанной форме есть два списка, которые отображают некоторую информацию. При портретной ориентации экрана (узкая сторона устройства ‑ нижняя) списки будут отображаться друг под другом, а при ландшафтной (широкая сторона устройства ‑ нижняя) ориентации ‑ списки расположены рядом. Для реализации такого поведения в модуле формы, расположенной на рабочем столе, следует разместить обработчик события ПриИзмененииПараметровЭкрана следующего вида:
&НаКлиенте Процедура ПриИзмененииПараметровЭкрана() МассивИнформаций = ПолучитьИнформациюЭкрановКлиента(); Если МассивИнформаций[0].Ширина > МассивИнформаций[0].Высота Тогда ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Горизонтальная; Иначе ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Вертикальная; КонецЕсли; КонецПроцедуры
28.3.6.12. Работа с уведомлениями
28.3.6.12.1. Общая информация
При работе информационной системы регулярно возникает необходимость оповестить пользователя о каком-либо событии. Событие может возникать как по расписанию, так и в случае возникновения другого события. Само событие может наступить как на мобильном устройстве, которым владеет пользователь, так и в каком-то другом месте информационной системы.
Для извещения пользователя о наступлении событий служат уведомления. Они могут создаваться локально или рассылаться с помощью push-сервисов. Локальные уведомления служат для информирования о событиях, которые происходят на устройстве пользователя. Обычно источником push-уведомлений выступает центральный узел информационной системы. С помощью push-уведомлений он информирует удаленных пользователей о том, что изменились данные, важные для пользователей. Однако это не единственный сценарий использования push-уведомлений. Push-уведомления могут рассылать специализированные сервисы, информирующие о курсах валюты, результатах спортивных состязаний, прогнозах погоды и т. д.
28.3.6.12.2. Локальные уведомления
Локальные уведомления служат для извещения о событиях, которые происходят непосредственно на мобильном устройстве. Локальные уведомления бывают моментальными и запланированными. Они используются для информирования о разных событиях и, кроме того, их отличает поведение на мобильном устройстве. Моментальные уведомления используются в том случае, когда необходимо «здесь и сейчас» оповестить пользователя о наступлении события, например завершении какого-либо процесса. Таким процессом может быть операция синхронизации с внешней системой. Запланированные уведомления позволяют в назначенное время напомнить пользователю о необходимости выполнить какую-либо операцию. Запланированное уведомление может быть однократным или периодическим. Однократное запланированное уведомление можно использовать, например, если в системе помечено, что какому-то контрагенту необходимо перезвонить в определенное время. Повторяемое запланированное уведомление можно использовать, например, в том случае, когда какая-то операция повторяется каждый день, вне зависимости от внешних событий.
Чтобы использовать локальные уведомления, следует установить разрешение Локальные уведомления (см. здесь). Сборщик приложений для мобильных устройств добавляет соответствующее разрешение для собираемого мобильного приложения. Следует учитывать, что мобильная версия «1С:Предприятия» для разработчика обладает всеми разрешениями для работы с локальными уведомлениями. Поэтому рекомендуется после окончания разработки механизма проверить его функционирование на обычной мобильной версии «1С:Предприятия». Для этого следует воспользоваться сборщиком приложений для мобильных устройств и проверить работоспособность получившегося приложения на одном или нескольких устройствах.
Для работы с локальными уведомлениями используется менеджер доставляемых уведомлений (свойство глобального контекста ДоставляемыеУведомления) и объект ДоставляемоеУведомление. Объект описывает собственно уведомление (включая параметры его отображения), а с помощью менеджера выполняется управление механизмом уведомлений.
Рассмотрим создание локальных уведомлений более подробно.
&НаКлиенте Функция СоздатьУведомление(Заголовок, Текст, Данные = 0, ДатаСрабатывания, ИнтервалПовторения = 0) Уведомление = Новый ДоставляемоеУведомление; Уведомление.Заголовок = Заголовок; Уведомление.Текст = Текст; Уведомление.Данные = Данные; Уведомление.ДатаПоявленияУниверсальноеВремя = ДатаСрабатывания; Уведомление.ИнтервалПовтора = ИнтервалПовторения; Уведомление.ЗвуковоеОповещение = ЗвуковоеОповещение.ПоУмолчанию; Возврат Уведомление; КонецФункции &НаКлиенте Процедура ЗадатьУведомление(Команда) Уведомление = СоздатьУведомление("Заголовок", "Текст", 2014, '00010101'); ДоставляемыеУведомления.ДобавитьЛокальноеУведомление(Уведомление); КонецПроцедуры
При создании уведомления следует помнить о следующих особенностях:
● Дата и время первого отображения уведомления задается в формате универсального времени (UTC). Для перевода из локального времени можно использовать функцию глобального контекста УниверсальноеВремя().
● Если свойство ДатаПоявленияУниверсальноеВремя задано пустым значением (или не задано вовсе), то уведомление будет отображено сразу. Таким уведомлением можно извещать пользователя о том, что мобильное приложение завершило какую-то длительную операцию, например, завершило операцию синхронизации данных.
● Если необходимо, чтобы уведомление появлялось регулярно, следует использовать свойство ИнтервалПовтора объекта ДоставляемоеУведомление. В результате можно реализовать простой вариант безусловного таймера, который по истечении заданного интервала времени будет формировать уведомление. Значение, описывающее интервал повторения уведомления, зависит от используемой мобильной операционной системы. Особенности указания интервала описаны в синтакс-помощнике. Система не предоставляет возможности указать дату и время окончания срабатывания уведомления. Для ОС Windows уведомление будет показано 5 раз (включая самое первое отображение).
● При необходимости, имеется возможность установить наклейку ‑ число, отображаемое в шторке уведомлений (ОС Android) или поверх иконки приложения (ОС iOS). Для этого служит свойство Наклейка. При работе под управлением ОС iOS имеется возможность устанавливать и получать значение наклейки с помощью методов УстановитьНаклейку() и ПолучитьНаклейку() менеджера доставляемых уведомлений. При работе в ОС Windows не поддерживается возможность создания наклейки на иконке приложения.
● При отображении уведомления имеется возможность воспроизвести некоторую мелодию. Для указания воспроизводимой мелодии служит свойство ЗвуковоеОповещение объекта ДоставляемоеУведомление. Если в качестве значения этого свойства установлено значение системного перечисления ЗвуковоеОповещение.ПоУмолчанию, то будет воспроизводиться мелодия, установленная для уведомлений в используемой операционной системе. Если в качестве значения свойства ЗвуковоеОповещение указано имя файла, то будет воспроизведен именно этот файл. Однако, в мобильной версии «1С:Предприятия» для разработчика, отсутствует возможность подключать ресурсы (к которым относятся воспроизводимые файлы). Для того чтобы файл с оповещением был прикреплен к мобильному приложению, следует воспользоваться возможностями сборщика приложений для мобильных устройств (см. здесь). В силу этого, проверить использование звуковых оповещений из файлов можно только на собранном мобильном приложении.
В ряде случаев может возникать необходимость удалять установленные (но еще не наступившие) уведомления. Такое может потребоваться в тех случаях, когда действие, для напоминания о котором установлено уведомление, уже выполнено. Для удаления уведомления можно использовать метод ОтменитьЛокальныеУведомления() менеджера доставляемых уведомлений. При этом следует помнить, что отменяются сразу все локальные уведомления, которые были установлены данным мобильным приложением, и время срабатывания которых еще не наступило.
После появления уведомления, нажатие на него приведет к запуску (или активизации) приложения. Однако этого может оказать недостаточно для полноценной обработки уведомления. В этом случае можно воспользоваться обработчиком уведомлений. Подключается этот обработчик с помощью метода ПодключитьОбработчикУведомлений() менеджера доставляемых уведомлений.
&НаКлиенте Процедура ПриОткрытии(Отказ) Обработчик = Новый ОписаниеОповещения("ОбработчикУведомлений", ЭтотОбъект); ДоставляемыеУведомления.ПодключитьОбработчикУведомлений(Обработчик); КонецПроцедуры &НаКлиенте Процедура ОбработчикУведомлений(Уведомление, Локальное, Показано, ДополнительныеПараметры) Экспорт // Важные и нужные действия КонецПроцедуры
В результате, после того как пользователь мобильного приложения нажмет на уведомление, будет активизировано мобильное приложение, создавшее уведомление, и в этом приложении будет вызван обработчик уведомления. В рамках этого обработчика можно реализовать необходимую обработку уведомления. Следует помнить, что объект, который передается в параметре Уведомление, содержит реальные данные только в свойствах Текст и Данные. Остальные свойства заполнены значениями по умолчанию.
Также следует отметить, что уведомление может не отображаться в шторке уведомлений. Для информирования мобильного приложения об этом факте, в процедуру обработки уведомлений передается параметр Показано. Так, если мобильное приложение запущено и активно, то локальное уведомление не будет отображено на экране, но обработчик уведомлений будет вызван, а параметр Показано будет установлен в значение Ложь. В этом случае задача привлечения внимания пользователя лежит на прикладном разработчике.
28.3.6.12.3. Push-уведомления
Общая информация
Push-уведомления (далее в этом разделе термины «уведомление» и «push-уведомление» используются равнозначно) предназначены для оповещения о событиях, которые произошли где-то в другом месте. Например, в корпоративной информационной системе изменились какие-то данные, важные для мобильных пользователей системы.
При работе с push-уведомлениями используются несколько различных систем:
1. Собственно мобильное приложение. Получает уведомления и реализует реакцию на них со стороны мобильного устройства.
2. Прикладное решение, которое занимается рассылкой уведомлений (отправитель). В роли отправителя выступает прикладное решение, созданное на платформе «1С:Предприятие».
3. Сервис доставки уведомлений. Этот сервис обеспечивает передачу уведомление от отправителя получателю (мобильному приложению). Таким сервисом может быть:
● Apple Push Notification Service (APNs, https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html, на английском языке);
● Firebase Cloud Messaging (FCM, https://firebase.google.com/docs/cloud-messaging/, на английском языке);
● Huawei Push Kit (HPK, https://``developer.``huawei.``com/``consumer/``en/``doc/``development/``HMSCore-``Guides/``service-``introduction-0000001050040060, на английском языке);
● RuStore Push-уведомления (RMS, https://www.rustore.ru/help/sdk/push-notifications, на русском языке);
● Windows Push Notification Services (WNS, https://docs.microsoft.com/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview, на английском языке).
4. Фирмой «1С» разработан специальный вспомогательный сервис для отправки уведомлений ‑ 1С:Центр уведомлений. Этот сервис предназначен для облегчения реализации отправки уведомлений из тиражных прикладных решений. Сервис позволяет использовать все сервисы отправки уведомлений, с которыми может работать мобильная версия «1С:Предприятия». Сервис позволяет изолировать получателей уведомлений одного отправителя, от других отправителей, которые работают с тем же мобильным приложением. Кроме того, сервис позволяет избежать публикации конфиденциальной информации, что может быть прямо запрещено политикой сервиса отправки уведомлений. Особенности работы с этим сервисом будут описаны далее, в соответствующих разделах. Следует понимать, что «1С:Центр уведомлений» не может работать без использования собственно сервисов отправки уведомлений. Сервис расположен по адресу https://``pushnotifications.1``c.``com.
В общем случае отправка уведомления выглядит следующим образом:
● Отправитель формирует уведомление;
● Отправитель определяет список получателей уведомления;
● Отправитель подключается к сервису уведомлений;
● Отправитель передает сервису уведомление и список получателей;
● Сервис обеспечивает доставку уведомлений на мобильные устройства;
● Мобильное приложение на устройстве обеспечивает обработку уведомлений.
Сервис доставки push-уведомлений не гарантирует доставки уведомления до мобильного устройства.
Чтобы использовать уведомления, следует установить разрешение Push-уведомления (см. здесь). Сборщик приложений для мобильных устройств добавляет соответствующую привилегию для собираемого мобильного приложения. Работа с мобильной версией «1С:Предприятия» для разработчика имеет некоторые особенности, которые будут рассмотрены ниже. В любом случае, рекомендуется после окончания разработки механизма проверить его функционирование на обычной мобильной версии «1С:Предприятия». Для этого следует воспользоваться сборщиком приложений для мобильных устройств и проверить работоспособность получившегося мобильного приложения с использованием всех сервисов доставки уведомлений.
Обработка push-уведомления мало отличается от обработки локального уведомления (см. здесь). Очевидно, что параметр Локальное будет иметь значение Ложь, если обработчик будет вызван для обработки push-уведомления.
Схема работы с сервисами рассылки уведомлений
Для понимания работы с push-уведомлениями, следует учитывать, что в процессе разработки и внедрения системы участвуют несколько различных ролей. В ряде случаев исполнители ролей могут объединяться, но само количество ролей остается неизменным:
● Разработчик мобильного приложения ‑ занимается разработкой мобильного приложения (получателя уведомлений). Реализует всю необходимую функциональность приложения для получения уведомлений.
● Разработчик отправителя уведомлений ‑ занимается разработкой информационной системы, которая занимается рассылкой уведомлений и механизма получения и хранения идентификаторов получателей уведомлений.
● Пользователь мобильного приложения ‑ использует мобильное приложение. Настройка мобильного приложения также выполняется этим пользователем, поэтому настройки мобильного приложения должны быть максимально просты и понятны даже неподготовленному пользователю.
● Внедренец отправителя ‑ занимается установкой и настройкой системы-отправителя уведомлений в сети пользователя системы.
При рассмотрении схем работы с тем или иным сервисом, описание действий будет происходить от лица носителя той или иной роли.
Схема работы содержит описание действий, которые надлежит выполнить представителю той или иной роли в момент выполнения своих действий. Порядок описания действий всегда будет одинаковый (разработчик мобильного приложения, разработчик отправителя, внедренец отправителя, пользователь мобильного приложения), однако это не означает, что физический порядок действий будет ровно таким же.
Кроме действий, описанных далее в разделе, реализация следующих этапов считается обязательной, и далее про них отдельно упоминаться не будет:
● Реализация реакции на уведомление ‑ выполняет разработчик мобильного приложения;
● Реализация отправки уведомлений ‑ выполняет разработчик отправителя.
Также считается, что мобильное приложение и отправитель «знают» о том, что они могут взаимодействовать друг с другом:
● Отправитель имеет некоторый публичный программный интерфейс (сервис обмена) для того, чтобы получить идентификатор получателя уведомления от мобильного приложения.
● Получатель (мобильное приложение) умеет использовать сервис обмена, который публикует отправитель для выполнения обоих действий.
Далее будут рассмотрены действия (по ролям), которые необходимо выполнить для работы с тем или иным сервисом отправки уведомлений. Пошаговые инструкций для выполнения конкретных шагов будут приведены далее в данном разделе.
APNs
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте компании Apple. При регистрации следует получить специальный сертификат.
● Предоставить полученный сертификат отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения сертификатов получателей уведомлений.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Загрузить в систему-отправителя сертификат мобильного приложения, которое будет получать уведомления.
● Сертификат должен быть получен у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
FCM на протоколе HTTP v1
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений в сервисе Firebase. При регистрации следует получить идентификатор проекта в сервисе (ID проекта) и закрытый ключ (в виде json-файла) для вашей учетной записи в сервисе FCM.
● Предоставить полученный идентификатор проекта и закрытый ключ отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения значений идентификатора проекта и закрытого ключа (в виде файла). Эти данные необходимы для получения маркера доступа, который, в свою очередь, используется для отправки уведомлений.
● Реализовать получение, хранение и обновление маркеров доступа.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Указать в системе-отправителе идентификатор проекта и закрытый ключ (в виде файла).
● Идентификатор проекта и закрытый ключ должны быть получены у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
HPK
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте AppGallery Connect компании Huawei. При регистрации следует получить Секрет клиента и ID клиента.
● Предоставить полученные данные приложения отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения значений Секрет клиента и ID клиента. Эти данные необходимы для получения маркера доступа, который, в свою очередь, используется для отправки уведомлений.
● Реализовать получение, хранение и обновление маркеров доступа.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Указать в системе-отправителе значения Секрет клиента и ID клиента, которое будет получать уведомления.
● Значения Секрет клиента и ID клиента для приложения должны быть получены у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
RMS
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений в консоли RuStore. Для этого на странице приложения перейдите в раздел Push-уведомления и выберите Проекты. После создания проекта необходимо создать сервисный токен. После этого следует получить строки ID проекта и Сервисный токен.
● Предоставить полученные ID проекта и Сервисный токен приложения отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения ID проекта и Сервисный токен. Эти данные необходимы для получения маркера доступа, который, в свою очередь, используется для отправки уведомлений.
● Реализовать получение, хранение и обновление маркеров доступа.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Указать в системе-отправителе ID проекта и Сервисный токен, которое будет получать уведомления.
● ID проекта и Сервисный токен приложения должны быть получены у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
WNS
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте компании Microsoft. При регистрации следует получить Секреты приложения и ИД безопасности приложения.
● Предоставить полученные Секреты приложения и ИД безопасности приложения отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения Секреты приложения и ИД безопасности приложения. Эти данные необходимы для получения маркера доступа, который, в свою очередь, используется для отправки уведомлений.
● Реализовать получение, хранение и обновление маркеров доступа.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Указать в системе-отправителе Секреты приложения и ИД безопасности приложения, которое будет получать уведомления.
● Секреты приложения и ИД безопасности приложения должны быть получены у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Сервис «1С:Центр уведомлений»
Сервис «1С:Центр уведомлений» позволяет несколько упростить процесс отправки и получения уведомлений для тиражных решений.
Разработчик мобильного приложения должен:
● Выбрать, какие сервисы будут использоваться для доставки уведомлений на мобильное устройство. Затем следует предоставить сервису «1С:Центр уведомлений» артефакты, которые необходимы для отправки уведомлений для используемых сервисов. Следует помнить, что предоставляемые артефакты могу являться конфиденциальной информацией.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения ключа сервера приложения (Ключ доступа отправителя) для текущего экземпляра системы-отправителя уведомлений. Регистрацию конкретного экземпляра отправителя на сайте сервиса «1С:Центр уведомлений» выполняет внедренец отправителя.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Выполнить регистрацию конкретного экземпляра отправителя на сайте сервиса «1С:Центр уведомлений». Получившийся ключ сервера зарегистрированного приложения (Ключ доступа отправителя) ввести в соответствующие настройки отправителя.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Работа с сервисом APNs
Для проверки работы механизма отправки уведомлений на ОС iOS, необходимо самостоятельно собрать собственную мобильную версию «1С:Предприятия» для разработчика. При сборке следует использовать специальный профиль обеспечения (provision profile), для которого разрешена возможность работать с push-уведомлениями. При создании «собственной» мобильной версии «1С:Предприятия» для разработчика необходимо указать корректный идентификатор мобильного приложения, при этом идентификаторы com``.``e``1``c``.``mobile и com``.``e``1``c``.``mobile``.``ios использоваться не могут, т. к. они зарезервированы для использования фирмой «1С».
Для установки соединения с APNs, на отправляющем компьютере должен быть доступен удостоверяющий сертификат мобильного приложения получателя уведомлений. Сертификаты для APNs бывают двух видов Apple``Development``IOS``Push``Services (сертификат разработчика) и Apple``Production``IOS``Push``Services (сертификат публичного мобильного приложения). Сертификат разработчика предназначен для разработки мобильного приложения и его отладки. Его следует использовать, если приложение установлено на устройство с помощью средств разработки. Сертификат публичного мобильного приложения следует использовать, если мобильное приложение распространяется через магазин приложений.
Мобильная версия «1С:Предприятия» предъявляет следующие требования к используемому сертификату:
● Сертификат приложения должен быть предоставлен в формате .``PEM.
● Сертификат должен содержать секцию Bag``Attributes, в которой должен присутствовать атрибут friendlyName. По значению атрибута friendlyName система различает сертификат разработчика и сертификат публичного мобильного приложения. Сертификат без атрибута friendlyName будет отвергнут мобильной версией «1С:Предприятия».
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для подготовки к рассылке уведомлений с использованием APNs, разработчик мобильного приложения должен выполнить следующие действия:
1. Необходимо войти в консоль разработчика (iOS Dev Center, https://developer.apple.com/devcenter/ios/index.action). Пользователь, от имени которого выполняется вход в консоль, должен иметь права администратора (в консоли разработчика).
2. В правой части окна веб-браузера необходимо выбрать пункт меню Certificates, Identifiers & Profiles в разделе iOS Developer Program.
3. Если у мобильного приложения, которое будет получать уведомления, отсутствует App``ID, то его необходимо создать. Порядок создания описан ниже. Если App``ID есть ‑ следует пропустить этот пункт и перейти к следующему пункту.
1. В разделе iOS``Apps выбрать пункт Identifiers.
2. Нажать кнопку + над списком iOS``AppIDs. Если у пользователя недостаточно прав ‑ кнопка создания будет недоступна.
3. В поле Name следует задать описание приложения (латинскими буквами). В разделе App``ID``Suffix выбрать пункт Explicit``App``ID. В поле Bundle``ID следует указать полный идентификатор мобильного приложения (можно получить в сборщике приложений для мобильных устройств). В разделе App``Services следует отметить пункт Push``Notifications.
4. Для перехода к следующему экрану следует нажать Continue.
5. Следует проверить все указанные параметры и нажать кнопку Submit для подтверждения создания App``ID.
6. Нажатие кнопки Done полностью завершает процесс создания App``ID.
4. Необходимо создать профиль обеспечения (provision profile) для сборки мобильного приложения, которое может получать уведомления. Данный профиль обеспечения (provision profile) в дальнейшем должен быть использован в сборщике приложений для мобильных устройств.
1. Необходимо выбрать пункт меню Provisioning profiles ‑ All в левой части экрана Certificates, Identifiers & Profiles.
2. Необходимо нажать кнопку + над списком iOS``Provisioning``Profiles.
3. Вид профиля выбирается в зависимости от того, для чего он создается. Если профиль обеспечения (provision profile) создается для разработки и отладки приложения, то в разделе Development необходимо выбрать пункт iOS``App``Development. Если профиль обеспечения (provision profile) создается для распространения приложения, то в разделе Distribution следует выбрать пункт App``Store. В зависимости от выбранного типа профиля обеспечения (provision profile), дальнейшие шаги помощника будут различаться.
1. Выбран профиль обеспечения (provision profile) для разработчика и нажата кнопка Continue.
1. Необходимо выбрать App``ID приложения, для сборки которого создается профиль обеспечения (provision profile), и нажать кнопку Continue.
2. Необходимо выбрать сертификаты тех разработчиков, которые смогут создавать приложения в Xcode с использованием данного профиля обеспечения (provision profile) и затем нажать кнопку Continue.
3. Необходимо выбрать устройства, на которых будет работать приложение, собранное с данным профилем обеспечения (provision profile) и затем нажать кнопку Continue.
4. Необходимо ввести описание создаваемого профиля (латинскими буквами) и нажать кнопку Generate.
2. Выбран профиль обеспечения (provision profile) для распространения нажата кнопка Continue.
1. Необходимо выбрать App``ID приложения, для сборки которого создается профиль обеспечения (provision profile), и нажать кнопку Continue.
2. Необходимо выбрать сертификат фирмы-поставщика прикладного решения и затем нажать кнопку Continue.
3. Необходимо ввести описание создаваемого профиля (латинскими буквами) и нажать кнопку Generate.
3. Затем следует скачать созданный профиль обеспечения (provision profile) с помощью кнопки Download для дальнейшего использования (в системе Xcode или сборщике приложений для мобильных устройств).
5. Для создания сертификата мобильного приложения вначале необходимо сформировать файл запроса сертификата. Для выполнения данной операции необходим компьютер Mac. Не закрывайте окно веб-браузера с открытой консолью разработчика во время создания запроса сертификата.
На компьютере Mac:
1. Необходимо запустить утилиту Связка ключей.
2. Выбрать команду Связка ключей``‑ Ассистент сертификации``‑ Запросить сертификат у бюро сертификации.
3. В открывшемся диалоге необходимо заполнить поля, при этом в качестве значения поля E-``mail пользователя рекомендуется указать тот адрес электронной почты, который указывался при регистрации в программе iOS``Developer``Program. В качестве значения свойства Запрос необходимо указать Сохранен на диске.
4. После нажатия кнопки Продолжить будет сформирован файл запроса сертификата *.``certSigningRequest.
6. Формируем сертификат для отправителя уведомлений. Для этого необходимо вернуться в окно веб-браузера с открытой консолью разработчика.
1. Необходимо выбрать пункт меню Certificates ‑ All в левой части экрана Certificates, Identifiers & Profiles.
2. Необходимо нажать кнопку + над списком iOS``Certificates.
3. В зависимости от потребности, необходимо указать пункт Apple``Push``Notification``service``SSL (``Sandbox) (если нужен сертификат для разработки и отладки приложения) или пункт Apple``Push``Notification``service``SSL (``Production) (если нужен сертификат для распространяемого приложения). Затем следует нажать кнопку Continue.
4. Необходимо указать App``ID используемого приложения и нажать кнопку Continue.
5. Необходимо нажать кнопку Continue. На данном экране предлагается создать файл запроса сертификата, который уже создан на предыдущем шаге.
6. Необходимо загрузить файл, сформированный на предыдущем шаге (с расширением .``certSigningRequest) и нажать кнопку Generate.
7. После окончания формирования сертификата, его следует скачать с сайта с помощью кнопки Download.
7. Последним шагом необходимо выполнить конвертацию сертификата в необходимые форматы. Для этого необходимо на компьютере Mac, где формировался файл запроса сертификата, выполнить следующие действия:
1. Для конвертации следует использовать программу Связка ключей.
2. Полученный на сайте сертификат загружается в Связку ключей.
3. Выполняется экспорт сертификата из Связки ключей в формате .``P12.
4. Выполняется конвертация получившегося сертификата из формата .``P12 в формат .``PEM. Для этого следует в консоли macOS выполнить следующую команду:
openssl pkcs12 -in pushcert.p12 -out pushcert.pem -nodes -clcerts
Получившиеся сертификаты необходимы для:
● Сертификат в формате .``P12 ‑ необходим в том случае, если рассылка уведомлений выполняется с помощью сервиса фирмы «1С». Сертификат должен использовать разработчиком получателя для регистрации приложения-получателя уведомлений в сервисе фирмы «1С».
● Сертификат в формате .``PEM ‑ необходим в том случае, если уведомления будут отправляться непосредственно через сервис APNs, и в этом случае сертификат должен быть предоставлен разработчику отправителя или внедренцу отправителя (если интерфейс программы-отправителя уведомлений предусматривает возможность указания сертификата программы-получателя уведомлений).
Работа с сервисом FCM на протоколе HTTP v1
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для подготовки к рассылке уведомлений с использованием FCM, разработчик мобильного приложения должен выполнить следующие действия:
1. Необходимо войти в консоль разработчика (Firebase Console, https://console.firebase.google.com).
2. Необходимо создать проект (кнопка Добавить проект). При создании проекта следует указать название проекта и страну размещения организации. Название проекта должно содержать только латинские символы. Не следует включать механизмы аналитики, если они не используются в приложении. После окончания создания проекта следует нажать кнопку Продолжить.
3. На странице проекта следует нажать гиперссылку Добавить``Firebase в свое приложение для``Android. После этого следует выполнить следующие действия:
1. В поле Название пакета``Android следует указать полный идентификатор приложения. С таким идентификатором приложение будет размещено в магазине Google Play. Этот же идентификатор будет использоваться для сборки мобильного приложения в сборщике мобильных приложений. После указания идентификатора приложения следует нажать кнопку Зарегистрировать приложение.
2. Загрузить предлагаемый файл google-``services.``json. Данный файл будет необходимо указать в сборщике мобильных приложений. После загрузки файла следует нажать кнопку Продолжить.
3. Следует нажать кнопку Готово.
4. В настройках проекта:
1. На закладке General находим и сохраняем значение идентификатора проекта (ID проекта).
2. На закладке Cloud Messaging включаем Firebase Cloud Messaging API (V1).
3. На закладке Service``Accounts нажимаем кнопку Generate``new``private``key и подтверждаем создание закрытого ключа.
4. Сохранить полученный файл закрытого ключа (json-файл) для вашей учетной записи службы. Рекомендуется относиться к данному файлу как к конфиденциальной информации. Получение данного ключа третьими лицами позволит им отправлять push-уведомления от вашего имени.
5. Полученные идентификатор проекта и закрытый ключ (в виде файла) следует указать в качестве параметров вызова метода ПолучитьМаркерДоступа() объекта МенеджерОтправкиДоставляемыхУведомлений. В качестве параметра метода ИдентификаторПриложения указывается значение идентификатора проекта, а в качестве значения параметра КлючПриложения указывается содержимое json-файл закрытого ключа (в виде строки). Полученный маркер доступа нужно использовать для отправки уведомлений.
Полученные идентификатор проекта и закрытый ключ (в виде файла) необходимо предоставить внедренцу приложения-отправителя для указания в настройках приложения.
Работа с сервисом HPK
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для подготовки к рассылке уведомлений с использованием HPK, разработчик мобильного приложения должен выполнить следующие действия:
1. Зарегистрируйтесь как разработчик Huawei (документация по регистрации https://``developer.``huawei.``com/``consumer/``en/``doc/``start/``registration-``and-``verification-0000001053628148 ).
2. Зайдите в AppGallery Connect (https://developer.huawei.com/consumer/en/service/josp/agc/index.html#/).
3. Создайте проект (нажать Add``project).
4. Создайте приложение (нажать кнопку New``app). Задайте соответствующие параметры приложения:
● Платформа: Android.
● Устройство: Mobile``phone.
● Категория приложения: App``or``Game.
5. Скопировать содержимое поля Хеш``SHA256 ключа подписи из настроек поставщика для ОС Android (раздел Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС Андроид). Сборщик приложений для мобильных устройств должен быть корректно настроен к этому моменту.
6. В AppGallery Connect выбрать Мои проекты и нужный проект. В левом меню в разделе Рост выбрать Push``Kit. На открывшейся странице нажимаем Включить (требуются права администратора). Выбрать нужное приложение в проекте. В настройках проекта на закладке Основная информация выбрать раздел Данные приложения. В поле ввода Отпечаток сертификата``SHA-256 ввести значение, которое мы получили на предыдущем шаге и нажать Сохранить.
7. В настройках проекта перейти на закладку Управление``API. Включить Push``Kit.
8. На закладке Общая информация, в разделе Данные приложение скачать файл agconnect-``services.``json.
9. Скачанный файл загрузить в группу мобильного приложения в сборщике мобильных приложений:
● Перейти на закладку Для ОС``Android.
● Включить флажок Использовать сервисы``Huawei.
● В группе Работа с``AppGallery``Connect загрузить полученный json-файл.
10. После выполнения этих действий собранное с помощью сборщика мобильное приложение сможет использовать push-уведомления в своей работе.
11. В AppGallery Connect, на закладке Общая информация, в разделе Данные приложение сохранить значения Секрет клиента и ID клиента из поля ID клиента``OAuth 2.0. Рекомендуется относиться к данной информации как к конфиденциальной информации.
12. Полученные значения следует указать в качестве параметров вызова метода ПолучитьМаркерДоступа() объекта МенеджерОтправкиДоставляемыхУведомлений. В качестве параметра метода ИдентификаторПриложения указывается значение Секрет клиента, а в качестве значения параметра КлючПриложения указывается значение ID клиента. Полученный маркер доступа нужно использовать для отправки уведомлений.
13. Полученные значения Секрет клиента и ID клиента необходимо предоставить внедренцу приложения-отправителя для указания в настройках приложения.
Работа с сервисом RMS
**Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Внимание! С помощью мобильной версии для разработчиков невозможно отладить работу с push-уведомлениями для RuStore. Для отладки и проверки необходимо собирать приложение и публиковать его в магазине.**
Для подготовки к рассылке уведомлений с использованием RMS, разработчик мобильного приложения должен выполнить следующие действия:
1. Зарегистрируйтесь в RuStore как разработчик (документация по регистрации доступна по адресу https://www.rustore.ru/help/developers/developer-account).
2. Выполните вход в консоль разработчика RuStore (https://dev.rustore.ru/).
3. Создайте приложение (нажать + Добавить приложение). Задайте соответствующие параметры приложения:
● Тип приложения: Универсальный.
● Тип монетизации: Бесплатное / Платное.
● Название приложения в консоли. Оно будет видно только вам. Данное значение позже можно изменить.
4. Получите (скопируйте) в сборщике мобильных приложений значение поля Хеш SHA256 ключа подписи. Для этого откройте форму Главное меню ‑ Сервис ‑ Настройка параметров поставщика ‑ Параметры для Андроид ОС.
5. В консоли разработчика RuStore выберите приложение. Перейдите в раздел Push-уведомления ‑ Проекты. Нажмите + Добавить проект. В настройках проекта введите название, идентификатор приложения и хеш сертификата SHA-256, полученный на предыдущем шаге. Нажмите Создать и + Создать, в результате создается сервисный токен.
6. В настройках приложения получаете ID проекта и Сервисный токен (полученный на предыдущем шаге). Рекомендуется относиться к данной информации как к конфиденциальной информации.
7. Полученные значения следует указать в качестве параметров вызова метода ПолучитьМаркерДоступа() объекта МенеджерОтправкиДоставляемыхУведомлений. В качестве параметра метода ИдентификаторПриложения указывается значение ID проекта, а в качестве значения параметра КлючПриложения указывается значение Сервисный токен. Полученный маркер доступа нужно использовать для отправки уведомлений.
Полученные ID проекта и Сервисный токен необходимо предоставить внедренцу приложения-отправителя для указания в настройках приложения.
Работа с сервисом WNS
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Следующие действия должен выполнить внедренец приложения-отправителя во время развертывания и настройки приложения-отправителя в компьютерной сети заказчика:
1. Необходимо войти в Центр разработки для Windows (https://``developer.``microsoft.``com/``windows).
2. Необходимо перейти в информационную панель (кнопка Информационная панель).
3. Необходимо создать новое приложение (кнопка Создать новое приложение). На открывшейся странице необходимо указать имя приложения, которое будет отображать в магазине приложений. После указания имени следует проверить доступность этого имени (гиперссылка Проверить доступность) и после этого нажать кнопку Зарезервировать имя продукта.
4. Необходимо войти в Application Registration Portal (https://apps.dev.microsoft.com).
5. Следует найти созданное приложение и открыть его страницу.
6. На странице приложения необходимо получить значения, указанные в разделах Секреты приложения и ИД безопасности пакета. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
7. Полученные значения следует указать в качестве параметров вызова метода ПолучитьМаркерДоступа() объекта МенеджерОтправкиДоставляемыхУведомлений. В качестве параметра метода ИдентификаторПриложения указывается значение из раздела Секреты приложения, а в качестве значения параметра КлючПриложения указывается значение из раздела ИД безопасности пакета. Полученный маркер доступа будет использовать для отправки уведомлений.
Полученные Секреты приложения и ИД безопасности пакета необходимо предоставить внедренцу приложения-отправителя для указания в настройках приложения.
При работе с WNS, значение свойства ИдентификаторПодписчикаДоставляемыхУведомлений.ИдентификаторПриложения содержит Push Notification Channel. Push Notification Channel является URI для получения уведомлений мобильным приложением. Отправка уведомлений выполняется через запрос POST-запрос по адресу URI. Канал привязан к конкретному приложению на конкретном устройстве. Следует помнить, что значение Push Notification Channel может изменяться с течением времени. Рекомендуется, чтобы мобильное приложение запрашивало новый идентификатор подписчика уведомлений при каждом запуске, и сообщало его своему сервису отправки уведомлений. Несмотря на вышесказанное, разработчик должен рассматривать значение свойства ИдентификаторПриложения как строку с неизвестным содержимым и не должен изменять ее содержимое в процессе работы.
Работа с сервисом «1С:Центр уведомлений»
Разработчик мобильного приложения должен:
● Зарегистрироваться в том сервисе рассылки уведомлений, который будет использоваться приложением. Если приложение использует несколько сервисов ‑ необходимо зарегистрироваться во всех. Сохранить артефакты, которые предоставляет каждый сервис рассылки уведомлений.
● Необходимо зарегистрироваться на сайте сервиса https://pushnotifications.1c.com/signup. Для регистрации необходимо иметь действующий номер подвижной беспроводной радиотелефонной связи (мобильный номер). В процессе регистрации на него будет выслан код подтверждения регистрации. В контактных данных рекомендуется указывать данные ответственного лица разработчика мобильного приложения.
● Необходимо зарегистрировать мобильное приложение, которое будет выступать получателем уведомлений. Для этого следует выбрать пункт меню Доставляемые уведомления``‑ Мобильные приложения и нажать кнопку Зарегистрировать приложение.
● Необходимо подключить созданное мобильное приложение к используемым сервисам. Для этого в списке Ваши мобильные приложения нажать ссылку Подключить к``APNS,``FCM или``WNS. На следующем экране необходимо нажать кнопку, соответствующую используемому сервису и ввести параметры работы с этим сервисом (полный идентификатор мобильного приложения требуется для всех сервисов рассылки уведомлений):
● Сервис APNS. Кнопка + Подключить к``APNS. Требуемые артефакты: сертификат мобильного приложения в формате .``P12 (и его пароль).
● Сервис WNS. Кнопка + Подключить к``WNS. Требуемые артефакты: значение Секреты приложения, полученное в магазине приложений Windows.
● Сервис FCM. Кнопка + Подключить к``FCM. Требуемые артефакты: значения ключа сервера проекта (Ключ сервера), полученное из консоли разработчика Firebase.
Разработчик отправителя должен:
● Каких-либо действий не выполняется.
Внедренец отправителя должен:
● Необходимо зарегистрироваться на сайте сервиса https://pushnotifications.1c.com/signup. Для регистрации необходимо иметь действующий номер подвижной беспроводной радиотелефонной связи (мобильный номер). В процессе регистрации на него будет выслан код подтверждения регистрации. В контактных данных рекомендуется указывать данные администратора информационной системы.
● Зарегистрировать отправителя уведомлений. Для этого следует выбрать пункт меню Доставляемые уведомления``‑ Отправители уведомлений и затем нажать кнопку Зарегистрировать отправителя. При регистрации рекомендуется указывать список IP-адресов, с которых будет допустимо рассылать уведомления с помощью данного сервиса. Если адреса не указаны ‑ рассылка уведомлений допускается с любого компьютера, который может авторизоваться в сервисе.
Важно понимать, что регистрацию отправителя выполняет не разработчик отправителя, а внедренец отправителя в тот момент, когда выполняется настройка экземпляра системы-отправителя у пользователя.
● В результате регистрации будет сформирован специальный ключ доступа. Для сохранения этого значения следует нажать кнопку Скопировать Ключ доступа или нажать кнопку Редактировать и скопировать значение из поля Ключ доступа отправителя. Получившееся значение необходимо указать в настройках конкретного экземпляра приложения-отправителя. Оно будет использоваться в качестве ключа аутентификации для отправки уведомлений (параметр ДанныеАутентификации метода Отправить() объекта МенеджерОтправкиДоставляемыхУведомлений). Рекомендуется относиться к данному ключу как к конфиденциальной информации. Получение данного ключа третьими лицами позволит им отправлять push-уведомления от вашего имени, например в случае, если при создании отправителя не указывались конкретные значения IP-адресов.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать выполнения команды для создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Рассылка уведомлений
Действия по рассылке уведомлений практически не различаются для различных сервисов. Различия наблюдаются в значениях параметров метода отправки уведомлений. Собственно отправка происходит с помощью метода Отправить() менеджера доставки отправляемых уведомлений:
● При рассылке уведомлений в качестве данных аутентификации используется (параметр ДанныеАутентификации метода Отправить()):
● Сервис APNs ‑ сертификат мобильного приложения, полученный из консоли разработчика. Рекомендуется относиться к данному ключу как к конфиденциальной информации. Для обеспечения отправки уведомлений с помощью APNs, на компьютере с системой-отправителем должны быть разрешены исходящие подключения по IP-портам 2195 и 2196.
● Сервисы FCM, HPK, RuStore и WNS ‑ значение, полученное в результате использования метода ПолучитьМаркерДоступа(). Рекомендуется относиться к данным, которые используются для полученния маркера доступа, как к конфиденциальной информации.
● Сервис «1С:Центр уведомлений» ‑ ключ программного интерфейса отправителя (Ключ доступа отправителя), который получен при регистрации отправителя на сайте сервиса. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Если для отправки уведомлений используется сервис «1С:Центр уведомлений», то параметр ИспользоватьПромежуточныйСервис должен быть установлен в значение Истина.
● Если отправка выполняется одновременно с использованием нескольких сервисов, то в качестве данных аутентификации может выступать соответствие, где ключом выступает вид сервиса (значение перечисления ТипПодписчикаДоставляемыхУведомлений), а в качестве значения ‑ те данные, которые необходимы соответствующему сервису.
Следует понимать, что невозможно одновременно (в одном вызове метода Отправить()) отправлять уведомления с использованием сервиса доставки уведомлений (APNs, FCM, WNS) и сервиса «1С:Центр уведомлений». Если у метода Отправить() значение параметра ИспользоватьПромежуточныйСервис установлено в значение Истина, то значением параметра ДанныеАутентфикации может быть только Ключ доступа отправителя, полученный у сервиса «1С:Центр уведомлений».
● Перечень получателей уведомлений описывается с помощью свойства Получатели объекта ДоставляемоеУведомление, которое выступает значением первого параметра метода Отправить() менеджера доставки отправляемых уведомлений.
При работе с сервисами FCM, HPK, RuStore и WNS следует помнить, что значение маркера доступа (которое получается с помощью метода ПолучитьМаркерДоступа()) не является постоянным значением. Его необходимо периодически получать повторно. Для определения необходимости выполнения этой процедуры у метода Отправить() существует возвращаемый параметр ИнформацияОПроблемахОтправкиДоставляемыхУведомлений. Если при отправке уведомлений возникает какая-либо проблема, то вышеуказанный параметр будет содержать список обнаруженных проблем. Если в списке проблем будет проблема типа ОшибкаДанныхАутентификации, то это означает, что необходимо заново получить маркер доступа и повторить попытку отправки уведомления.
28.3.6.12.4. Особенности обработки уведомлений мобильным приложением
Если обработчик уведомления не подключен, то уведомление сохраняется в памяти до окончания сеанса и будет передано обработчику уведомления после его подключения (в этом сеансе). Если до окончания сеанса обработчик не был подключен ‑ уведомление теряется после завершения сеанса.
Также необходимо учитывать следующие особенности работы с уведомлениями в мобильном приложении:
● Если мобильное приложение активно, то уведомление сразу доставляется в мобильное приложение, при этом наклейка и звуковое оповещение игнорируются.
● Если мобильное приложение не активно в момент получения уведомления, то уведомление отображается операционной системой. Если пользователь нажал на уведомление, то будет запущено соответствующее приложение. Если пользователь удалил уведомление ‑ приложение не будет проинформировано о существовании уведомления. В ОС iOS (версии 7 и младше) уведомление удаляется из центра уведомления либо явным действием пользователя, либо вытесняется другими уведомлениями данного приложения.
● Если мобильное приложение, в момент получения уведомления, работает в фоновом режиме и не активно, то работа с уведомлением выполняется по-разному на разных платформах:
● В ОС iOS уведомление будет передано в мобильное приложение только после того, как его выберет пользователь из панели уведомлений.
● В ОС Android уведомление сразу передается в мобильное приложение и одновременно отображается в панели уведомлений. После того, как пользователь выбрал уведомление в панели, происходит активизация приложения, но повторно уведомление в приложение не передается.
● В ОС Windows уведомление будет передано в мобильное приложение только после того, как его выберет пользователь в центре уведомлений.
● В том случае, если в мобильном приложении развернуто несколько информационных баз, то пользователю предлагается переключиться, если в данный момент он работает с другой информационной базой. Если конкретную информационную базу определить не получается ‑ выдается соответствующее диагностическое сообщение.
28.3.6.13. Работа с рекламой
28.3.6.13.1. Общая информация
Мобильная версия «1С:Предприятия» предоставляет возможность показывать рекламную информацию в мобильном приложении. При необходимости воспроизведения рекламы, прикладной разработчик может настроить отображение рекламного баннера с использованием рекламного сервиса Google AdMob (https://www.google.com/admob/) или Petal Ads (https://``ads.``huawei.``com/``usermgtportal/``home/``index.``html#/). Сервис Google AdMob доступен для использования при работе под управлением ОС Android (с использованием GMS) и iOS. Сервис Petal Ads доступен для использования только при работе под управлением ОС Android (с использованием HMS).
Реклама может быть нескольких видов:
● Баннер ‑ прямоугольное объявление, занимающее часть главного окна приложения. Может обновляться автоматически через некоторое время.
● Полноэкранный рекламный баннер ‑ полноэкранный формат объявлений, используемый для показа в момент перехода между формами приложения. Такое объявление занимает всю площадь экрана мобильного устройства.
● Видеообъявление с вознаграждением ‑ формат объявлений, предусматривающий вознаграждение за просмотр.
Данная документация рассматривает только вопросы, касающиеся технических аспектов работы мобильного приложения с рекламным сервисом.
Общая схема работы при работе с рекламой выглядит следующим образом:
1. Зарегистрировать свое приложение в сервисе. Получить идентификатор приложения из сервиса.
2. Настроить рекламные блоки в сервисе (при необходимости).
3. Реализовать программный интерфейс работы с рекламой, используя данные, полученные на предыдущих шагах.
Для управления отображением рекламной информации служит свойство глобального контекста ОтображениеРекламы. В документации, для упрощения, будет опускаться префикс метода ОтображениеРекламы.. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы. После старта мобильного приложения, система имеет следующие настройки по умолчанию:
● Реклама в мобильном приложении не используется.
● Идентификаторы каких-либо рекламных блоков не установлены.
● Рекламные блоки не загружены.
● Рекламная информация не отображается на экране.
Для того чтобы рекламная информация стала отображаться в приложении, необходимо выполнить следующие действия:
1. Использование рекламы в мобильном приложении должно быть разрешено с помощью метода УстановитьИспользование(Истина);.
2. В зависимости от используемого вида рекламного блока необходимо указать идентификатор блока:
● Баннер ‑ метод УстановитьИндентификаторРекламногоБаннера().
● Полноэкранный рекламный баннер ‑ метод УстановитьИндентификаторПолноэкраннойРекламы().
● Видеообъявление с вознаграждением ‑ метод УстановитьИдентификаторВидеообъявленияСВознаграждением().
3. Запуск отображение рекламной информации выполняется в зависимости от используемого рекламного блока:
● Баннер ‑ метод УстановитьОтображениеРекламногоБаннера(). С помощью этого метода можно указать место отображения рекламы или отключить отображение рекламы.
● Полноэкранный рекламный баннер ‑ метод ПоказатьПолноэкраннуюРекламу().
● Видеообъявление с вознаграждением ‑ метод ПоказатьВидеообъявлениеСВознаграждением().
При отображении полноэкранной рекламы или видеообъявления предоставляется возможность установить обработчик оповещения о завершении отображения.
4. При отображении рекламной информации могут наблюдаться временные задержки, вызванные загрузкой необходимого блока рекламы. Можно уменьшить эти задержки, выполняя загрузку рекламных блоков заранее:
● Баннер ‑ метод ЗагрузитьРекламныйБаннерАсинх()/НачатьЗагрузкуРекламногоБаннера().
● Полноэкранный рекламный баннер ‑ метод ЗагрузитьПолноэкраннуюРекламуАсинх()/НачатьЗагрузкуПолноэкраннойРекламы().
● Видеообъявление с вознаграждением ‑ метод ЗагрузитьВидеообъявленияеСВознаграждениеАсинх()/НачатьЗагрузкуВидеообъявленияСВознаграждением().
После окончания загрузки будут вызван соответствующий обработчик. В этом обработчике, с помощью параметра метода, можно определить статус загрузки рекламы и выполнить необходимые действия.
Предварительная загрузка рекламной информации не является обязательной. Вызов метода отображения рекламы автоматически загрузит нужный рекламный блок.
5. Ротацию собственно рекламной информации обеспечивает рекламная сеть.
Чтобы понять статус конкретного рекламного блока (по идентификатору рекламного блока) предназначен метод ПолучитьСтатусРекламы().
При установке идентификаторов рекламы, следует использовать идентификаторы, которые получены в веб-интерфейсе системы (подробнее см. здесь).
Реклама, отображаемая в мобильном приложении, должна соответствовать Правилам рекламного сервиса AdMob (https://``support.``google.``com/``admob/``answer/6128543). Особое внимание стоит уделить следующим разделам Правил:
● Правила и рекомендации для издателей AdMob;
● Правила для ресурсов с вознаграждением.
28.3.6.13.2. Настройка рекламных сервисов
Google AdMob
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для настройки рекламных блоков необходимо выполнить следующие действия:
1. Зарегистрироваться в системе Google AdMob.
2. Войти в систему от имени зарегистрированного пользователя (https://``apps.``admob.``com).
3. Если приложение собрано с использованием сборщика приложений для мобильных устройств и ранее выполнялось тестирование этого приложения (см. здесь), то ничего делать не надо. Идентификаторы рекламных блоков должны быть указаны в нужных местах прикладного решения. В мобильном приложении, собранном с помощью сборщика, должна отображать реальная рекламная информация.
4. Добавить новое приложение. Для этого следует выбрать в меню команду Приложения``‑ Добавить приложение.
5. Добавление приложение различается для приложения, уже опубликованного в магазине приложений и там не опубликованного. Данный выбор осуществляется при ответе на вопрос Вы уже разместили свое приложение в``Google``Play или``App``Store?
● Приложение опубликовано в магазине:
● На вопрос необходимо ответить Да.
● На следующей странице необходимо ввести фрагмент названия приложения и нажать кнопку Найти.
● Из списка следует выбрать требуемое приложение.
● Приложение не опубликовано в магазине:
● На вопрос необходимо ответить Нет.
● На следующей странице необходимо ввести название приложения и указать, под управлением какой операционной системы оно работает. Если мобильное приложение (для которого настраивается отображение рекламы) будет работать под управлением ОС Android и iOS, то следует создать два приложения AdMob.
● После нажатия кнопки Добавить будет создано необходимое мобильное приложение.
6. На странице Настройки приложения следует запомнить значение поля Идентификатор приложения. Это значение будет необходимо указать сборщику мобильных приложений.
7. После создания приложения следует перейти на страницу Рекламные блоки этого приложения.
8. При создании рекламного блока необходимо указать, какой рекламный блок будет создан: Баннер, Межстраничное объявление (полноэкранный рекламный баннер) или С вознаграждением (видеообъявление с вознаграждением). Для этого необходимо нажать кнопку Выбрать у нужного вида рекламного блока.
9. Затем формируется название (одноименное свойство) и указываются (при необходимости) другие параметры рекламного блока.
10. Нажатие кнопки Создать рекламный блок завершает операцию создания. Кнопка будет недоступна, если введены не все параметры, необходимые для создаваемого рекламного блока.
11. На странице Рекламный блок создан будет представлено два вида идентификаторов. Первый идентификатор ‑ это идентификатор приложения, а второй идентификатор следует запомнить для использования во встроенном языке. Этот же идентификатор потом можно найти в свойствах рекламного блока, в качестве значения поля Идентификатор рекламного блока.
Работу с рекламными блоками также можно выполнять следующим образом:
1. Войти в систему Google AdMob (https://``apps.``admob.``com).
2. В списке приложений выбрать нужное приложение.
3. Затем указать в левой части страницы пункт Рекламные блоки.
4. Теперь можно создавать и настраивать нужные рекламные блоки. В свойствах каждого рекламного блока будет доступен идентификатор этого блока, необходимый для использования во встроенном языке.
Идентификаторы, полученные при создании рекламных блоков, следует использовать в качестве параметров методов ОтображениеРекламы.УстановитьИндентификаторРекламногоБаннера()и ОтображениеРекламы.УстановитьИндентификаторПолноэкраннойРекламы().
Petal Ads
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для настройки рекламных блоков необходимо выполнить следующие действия:
1. Зарегистрируйтесь как разработчик Huawei (документация по регистрации https://``developer.``huawei.``com/``consumer/``en/``doc/``start/``registration-``and-``verification-0000001053628148 ).
2. Зайдите в AppGallery Connect (https://developer.huawei.com/consumer/en/service/josp/agc/index.html#/).
3. Создайте проект (нажать Add``project).
4. Создайте приложение (нажать кнопку New``app). Задайте соответствующие параметры приложения:
● Платформа: Android.
● Устройство: Mobile``phone.
● Категория приложения: App``or``Game.
5. Скопировать содержимое поля Хеш``SHA256 ключа подписи из настроек поставщика для ОС Android (раздел Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС Андроид). Сборщик приложений для мобильных устройств должен быть корректно настроен к этому моменту.
6. В AppGallery Connect выбрать Мои проекты и нужный проект. Выбрать нужное приложение в проекте. В настройках проекта на закладке Основная информация выбрать раздел Данные приложения. В поле ввода Отпечаток сертификата``SHA-256 ввести значение, которое мы получили на предыдущем шаге и нажать Сохранить.
7. В настройках проекта перейти на закладку Управление``API. Включить Ads``Kit.
8. На закладке Общая информация, в разделе Данные приложение скачать файл agconnect-``services.``json.
9. Скачанный файл загрузить в группу мобильного приложения в сборщике мобильных приложений:
● Перейти на закладку Для ОС``Android.
● Включить флажок Использовать сервисы``Huawei.
● В группе Работа с``AppGallery``Connect загрузить полученный json-файл.
10. После создания приложения следует перейти в HUAWEI Ads Publisher Console (https://``developer.``huawei.``com/``consumer/``en/``service/``ads/``publisher/``html/``index.``html#/``mainContent/``dashbordContent).
11. Необходимо создать новое (или выбирать существующее) приложение в разделе Управление трафиком ‑ Мои приложения.
12. Создание рекламных блоков выполняется в разделе Управление трафиком ‑ Рекламные блоки. При создании рекламного блока необходимо указать, какой рекламный блок будет создан: Баннер, Межстраничное объявление (полноэкранный рекламный баннер) или С вознаграждением (видеообъявление с вознаграждением).
Идентификаторы, полученные при создании рекламных блоков, следует использовать в качестве параметров методов ОтображениеРекламы.УстановитьИндентификаторРекламногоБаннера() и ОтображениеРекламы.УстановитьИндентификаторПолноэкраннойРекламы().
Смотри также:
● Описание создания приложения Petal Ads: https://``developer.``huawei.``com/``consumer/``en/``doc/``distribution/``monetize/``mediamanagement-0000001051201925.
● Настройки рекламных блоков: https://``developer.``huawei.``com/``consumer/``en/``doc/``distribution/``monetize/``unitmanagement-0000001051321852.
28.3.6.13.3. Тестирование работы с рекламой
Google AdMob
Общую схему тестирования отображения рекламной информации, при использовании системы Google AdMob, можно представить следующим образом:
● Для тестирования отображения рекламной информации не требуется публикации мобильного приложения в магазине приложений.
● Для тестирования необходимы только идентификаторы рекламных блоков, для создания которых (рекламных блоков) необходимо зарегистрировать разрабатываемое приложение в сервисе Google AdMob.
● После регистрации приложения в Google AdMob, необходимо создать рекламные блоки. Их идентификаторы будут использоваться в разрабатываемом мобильном приложении и при тестировании, и при реальной эксплуатации.
● Пока приложение работает на мобильной платформе разработчика, рекламные блоки отображают тестовое содержимое. После того, как приложение собрано сборщиком приложений для мобильных устройств ‑ оно начнет показывать реальную рекламную информацию.
Описание создания приложения AdMob и настройки рекламных блоков см. здесь.
28.3.6.14. Работа со встроенными покупками
28.3.6.14.1. Общая информация
Мобильная версия «1С:Предприятия» предоставляет прикладному разработчику возможность реализации различных покупок внутри мобильного приложения (in-app purchase). Предоставляется возможность работы со следующими видами покупок:
1. Постоянная покупка. Используется в всех поддерживаемых операционных системах. Приобретается однократно для учетной записи пользователя мобильного устройства. Распространяется на все мобильные устройства, работающие под одной учетной записью. Для распространения используется механизм восстановления покупок.
2. Расходуемая покупка. Используется в ОС iOS и Windows. Такая покупка может быть приобретена произвольное количество раз. Информация о приобретении такой покупки поступает на мобильное устройство только в момент запроса начала покупки. В ОС Android расходуемая покупка реализуется в прикладном решении с помощью специальных средств платформы (расходование постоянной покупки).
3. Подписка. Используется в всех поддерживаемых операционных системах. Такая покупка приобретается как постоянная покупка, действующая в течение определенного времени. Имеется возможность установить автоматическое продление покупки по истечению срока подписки. При этом со счета платежного средства, привязанного к аккаунту пользователя, будет списываться стоимость подписки. Нельзя изменить стоимость подписки в ОС Android. В ОС iOS изменение стоимости подписки приведет к отключению автоматического продления подписки. Удаление приложения, через которое осуществлялась покупка, не приводит к отключению автоматического продления подписок. Управление подписками осуществляется с помощью Apple AppStore, Google Wallet или через учетную запись Microsoft. В мобильном приложении невозможно реализовать интерфейс управления подписками.
При использовании ОС Windows, подписки будут доступны только в том случае, если на мобильном устройстве установлена ОС Windows 10, начиная с версии 1607. На сервере сборщика мобильных приложений должен быть установлен комплект SDK Windows 10 версии 14393 или старше.
Покупки в мобильном приложении осуществляются с помощью внешних сервисов:
● ОС Android:
● Google Play In-App Billing. На устройстве должна быть установлена актуальная версия GMS.
● Huawei In-App Purchases. На устройстве должна быть установлена актуальная версия HMS.
● RuStore платежи in-app. На устройстве должна быть установлена актуальная версия приложения RuStore.
● ОС iOS: Apple In-App Purchase.
● ОС Windows: Windows In-App Purchase.
При реализации покупок внутри мобильного приложения следует помнить, что предметы покупок ограничиваются владельцами магазинов приложений (компании Apple, Google, Huawei, Microsoft, RuStore).
В общем случае, покупки внутри приложений должны полностью соответствовать требованиям владельцев сервисов:
● ОС Android:
● GMS: https://support.google.com/googleplay/android-developer/topic/9857752.
● RuStore: https://www.rustore.ru/help/sdk/payments/kotlin-java/5-0-0.
● ОС iOS: https://``developer.``apple.``com/``app-``store/``review/``guidelines/ (на английском языке).
● ОС Windows: https://``docs.``microsoft.``com/``en-``us/``legal/``windows/``agreements/``store-``policies#108-``financial-``transactions (на английском языке).
В качестве примера можно привести следующие разрешенные и запрещенные виды контента:
● Разрешено продавать:
● Функциональные возможности мобильных приложений.
● Услуги, непосредственно связанные с мобильными приложениями.
● Запрещено продавать:
● Товары и услуги, используемые за пределами мобильных приложений.
28.3.6.14.2. Схема использования
Чтобы использовать покупки, следует для разрабатываемого мобильного приложения установить разрешение Встроенные покупки (см. здесь). Для обращения к истории данных служит свойство глобального контекста ВстроенныеПокупки. Через это свойство доступен менеджер встроенных покупок. Следовательно, обращение к методам программного интерфейса будут выглядеть следующим образом: ВстроенныеПокупки.ИмяВызываемогоМетода(). Для упрощения, в нижеследующем тексте имя свойства глобального контекста будет опускаться. В коде на встроенном языке, очевидно, такое упрощение не применимо.
Общая схема работы со встроенными покупками, в мобильном приложении, выглядит следующим образом:
1. Необходимо настроить работу используемых сервисов встроенных покупок (см. здесь) для взаимодействия с разрабатываемым мобильным приложением. Во время настройки сервисов может потребоваться загрузить в магазин приложений разрабатываемое мобильное приложение, для которого включена возможность использования встроенных покупок. При этом загружаемое мобильное приложение может не содержать в себе функциональность работы с покупками. Загружаемое приложение необходимо для работы механизмов сервисов покупок. Однако полный идентификатор загружаемого приложения должен быть в точности таким, каким он будет для финальной версии мобильного приложения с возможностью совершения встроенных покупок.
2. После настройки сервисов необходимо создать необходимые покупки (в каждом из сервисов) и зафиксировать идентификаторы и типы покупок.
3. В мобильном приложении необходимо проверить, доступно или нет на данном устройстве совершение покупок. Для этого следует использовать метод ПоддерживаютсяПокупки().
4. Если покупки поддерживаются, то следует обновить список совершенных и доступных покупок с помощью метода ОбновитьИнформациюОПриобретении(). Без выполнения этой операции будет невозможно в дальнейшем совершить покупку.
Операцию обновления информации о приобретении рекомендуется выполнять регулярно, т. к. список совершенных покупок может изменяться не только на текущем устройстве.
5. Для осуществления покупки предназначен метод НачатьПриобретение()/ПриобрестиАсинх(). В качестве параметра метода следует передать идентификатор покупки (как он указан в соответствующем сервисе) или объект ВстроеннаяПокупка, который можно получить с помощью метода ПолучитьСписок(). Некоторые мобильные операционные системы требуют выполнять подтверждение покупки клиентским приложением. Это подтверждение может выполняться мобильной версией автоматически, а может выполняться из встроенного языка. За автоматическое подтверждение отвечает специальный параметр методов выполнения покупки и обновления списка покупок. При выполнении подтверждения из встроенного языка следует использовать метод ПодтвердитьПокупку(). Проверку необходимости подтверждения следует выполнить с помощью метода ПоддерживаетсяПодтверждениеПокупок().
Все алгоритмы рассматриваются для ручного подтверждения покупок. Об особенностях в поведении системы будет написано отдельно.
6. Расходование покупок следует выполнять с помощью метода ИзрасходоватьПокупку(). После выполнения метода выполняется запрос к сервису работы с покупками, в котором указывается, что покупка израсходована и доступна для повторного приобретения. Чтобы определить, что покупка может быть израсходована, следует использовать метод ПоддерживаетсяРасходованиеПокупок(). Если метод возвращает значение Истина, то это означает, что имеется возможность расходовать встроенные покупки. Такая возможность доступна при работе под управлением ОС Android и Windows.
28.3.6.14.3. Работа с покупкой
При выполнении покупки какого-либо артефакта, разработчика мобильного приложения, из которого выполняется покупка, интересуют несколько моментов:
● Пользователь приобрел платный артефакт? Под «артефактом» понимается любой вид встроенной покупки (подробнее см. здесь).
● Пользователь оплатил покупку для нашего приложения и в «нашем» магазине приложений? Другими словами, не выполняется-ли попытка использовать платный артефакт без оплаты, незаконным путем?
● Пользователь сразу заплатил деньги или только уведомил систему о том, что он хочет купить артефакт?
● Что за артефакт приобретен и какие параметры у приобретения?
Прикладное решение может инициировать покупку с помощью двух методов: НачатьПриобретение() и ПриобрестиАсинх(). После выполнения действий пользователя эти методы работают несколько по-разному, но суть одна и та же: можно получить квитанцию о выполненной покупке или информацию о том, что «что-то пошло не так». Если покупка завершилась неуспешно, это может означать не только фактическую проблему при совершении покупки (нет связи, ошибка оплаты и т. д.), но и то, что пользователь отложил оплату покупки (в том магазине, где это возможно) и хочется оплатить покупку позже. Покупка завершается успешно, если:
● В обработчике оповещения о завершении покупки параметр Успешно равен значению Истина (для метода НачатьПриобретение()).
● Ожидание вернуло объект КвитанцияВстроеннойПокупки (для метода ПриобрестиАсинх()).
Покупка завершается неуспешно, если:
● В обработчике оповещения о завершении покупки параметр Успешно равен значению Ложь (для метода НачатьПриобретение()).
● Ожидание вернуло значение Неопределено (для метода ПриобрестиАсинх()).
После завершения действий пользователя, во встроенном языке необходимо выполнить следующие операции:
● Следующие действия необходимо выполнять только в том случае, если покупка завершена неуспешно:
● Обновить список совершенных и доступных покупок с помощью метода ОбновитьИнформациюОПриобретении().
● Удостовериться, что покупка действительно приобретена. Для этого следует использовать метод ПроверитьПриобретение().
● Если покупка приобретена, то следует продолжить дальнейшие шаги. Если покупка так и не выполнена ‑ дальше ничего делать не надо.
● Следует получить квитанцию этой покупки. Для получения квитанции следует использовать метод ПолучитьКвитанцииВстроенныхПокупок(). Квитанция встроенной покупки (объект типа КвитанцияВстроеннойПокупки) может быть получена в качестве параметра обработчика завершения процесса покупки или в результате выполнения обещания.
● Для проверки квитанции покупки следует использовать методы свойства глобального контекста ПроверкаВстроенныхПокупок. Квитанцию встроенной покупки можно проверить как на самом мобильном устройстве, так и на стороне приложения для персонального компьютера. Проверка выполняется полностью аналогично. Разница заключается в том, что при проверке с помощью прикладного решения для персонального компьютера используются другие каналы связи с сервисом покупок (и другое окружение проверяющей системы). Таким образом существенно уменьшается вероятность того, что пользователь пытается использовать платный артефакт без фактической оплаты.
При проверке квитанции покупки выполняются следующие действия:
● ОС Android: выполняется проверка электронной подписи квитанции выполненной покупки.
● ОС iOS: отправляется запрос на сервер компании Apple для проверки полученной квитанции. Запрос отправляется по адресу https://``buy.``itunes.``apple.``com/``verifyRecepient (https://``sandbox.``itunes.``apple.``com/``verifyRecepient во время тестирования).
● ОС Windows: выполняется проверка электронной подписи квитанции выполненной покупки. Сертификат для проверки цифровой подписи получается с сайта Microsoft (https://``go.``microsoft.``com/``fwlink/?``LinkId=246509&``cid=``CertificateID).
Для проверки на стороне персонального компьютера (при возможности) следует использовать метод ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупки(). В мобильном клиенте всегда рекомендуется использовать именно такой способ проверки. В мобильной платформе рекомендуется использовать проверку на персональном компьютере при возможности (у мобильного приложения есть серверная часть). Если проверку можно выполнить только на мобильном устройстве, то следует использовать метод ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупкиНаМобильномУстройстве().
● Последним шагом необходимо подтвердить факт покупки. Другими словами, следует оповестить магазин приложений, что пользователь получил приобретенный артефакт. Это подтверждение требуется не всегда и зависит от той мобильной операционной системы, под управлением которой работает мобильное приложение. Для проверки необходимости подтверждения покупки следует использовать метод ПоддерживаетсяПодтверждениеПокупок(). Если подтверждение покупок требуется, то для подтверждения покупки следует использовать метод ПодтвердитьПокупку().
Если покупается расходуемая покупка, которая расходуется сразу после покупки с помощью метода ИзрасходоватьПокупку(), то подтверждение покупки будет выполнено автоматически. Если расходуемая покупка будет израсходована не сразу, а по прошествии какого-либо времени, то такую покупку необходимо подтвердить сразу после покупки, как обычную покупку.
Выше был описан алгоритм работы в том случае, когда при выполнении покупки автоматическое подтверждение покупки выключено. Если автоматическое подтверждение покупки включено, то проверка квитанции покупки и подтверждение покупки будет выполняться автоматически. Автоматическая проверка квитанции встроенной покупки будет выполняться на стороне мобильного устройства (будет использоваться метод ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупкиНаМобильномУстройстве()). Аналогичное поведение будет наблюдаться и при использовании метода ОбновитьИнформациюОПриобретении():
● Автоматическое подтверждение покупок выключено: необходимо закодировать весь вышеописанный алгоритм.
● Автоматическое подтверждение покупок включено: мобильная версия будет автоматически проверять квитанцию встроенной покупки и подтверждать покупку.
Для того, чтобы мобильная версия могла выполнить автоматическое подтверждение покупок, мобильное приложение должно быть собрано с указанием параметра Ключ проверки встроенных покупок. Если данный ключ не будет указан при сборке, то в мобильном приложении будет невозможно выполнить подтверждение покупок.
Прикладной разработчик может получить доступ к данным квитанции о покупки. С помощью этих данных можно проверить уникальности идентификатора квитанции о покупке, адекватности даты покупки и т. д. Для этого можно воспользоваться объектом ДанныеКвитанцииВстроеннойПокупки. Этот объект позволяет получить доступ к данным квитанции встроенной покупки, которые присутствуют во всех поддерживаемых сервисах встроенных покупок. Если необходимо получить доступ к оригинальным (зависящим от операционной системы и используемого магазина приложений) данным квитанции, то сделать это можно с помощью реквизита ДанныеКвитанцииВстроеннойПокупки.ИсходныеДанные. Для получения данных квитанции встроенных покупок можно использовать метод ПолучитьДанныеКвитанцийВстроенныхПокупок(). Для этого метода требуются массив квитанций встроенных покупок и соответствующий набор идентификаторов покупок.
28.3.6.14.4. Настройка сервисов встроенных покупок
Общая информация
Информацию об особенностях конкретных типов покупок и поведения системы при работе с покупками следует искать в документации к соответствующей операционной системе.
Apple In-App Purchase
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
1. Войти в Member Center (https://``developer.``apple.``com/``membercenter/``index.``action) от имени разработчика.
2. Перейти в раздел Certificates, Identifiers & Profiles.
3. Перейти в раздел Identifiers.
4. Зарегистрировать iOS App ID для приложения (если оно еще не зарегистрировано в Member Center). При этом регистрируемый идентификатор должен совпадать с полным идентификатором мобильного приложения, в которое планируется встраивать работу с встроенными покупками. При создании iOS App ID следует убедиться, что разрешен сервис In-``App``Purchase.
5. Если планируется использовать мобильную платформу разработчика для работы со встроенными покупками, следует выполнить следующие действия:
1. Перейти в раздел Provisioning Profiles.
2. Создать новый профиль обеспечения (provisioning profile).
3. Указать, что этот профиль предназначен для iOS``App``Development.
4. Указать в качестве App ID именно тот iOS App ID, который создан на предыдущем шаге. Нельзя указывать на этом шаге iOS Wildcard AppID.
5. Созданный профиль обеспечения в дальнейшем будет необходимо использовать в сборщике приложений для мобильных устройств.
6. Войти в систему iTunes Connect (https://``itunesconnect.``apple.``com).
7. Перейти в раздел Соглашения, налоги и банковские операции.
8. Принять соглашение Paid``Application. При этом необходимо указать информацию о банковском счете, на который будут перечисляться заработанные средства.
9. Перейти на закладку Функции.
10. Перейти в раздел Встроенные покупки (открыт по умолчанию).
11. Новая встроенная покупка добавляется с помощью кнопки «+», расположенной справа от заголовка списка Встроенные покупки.
Google Play In-App Billing
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для создания встроенных покупок следует выполнить следующие шаги:
1. Войти в консоль разработчика Google Play (https://``play.``google.``com/``apps/``publish/).
2. Создать или найти мобильное приложение, в котором планируется реализовать работу с встроенными покупками. На данном этапе следует собрать мобильное приложение, для которого установлено разрешение Встроенные покупки, но может отсутствовать функциональность работы с покупками. Сборку необходимо выполнять с помощью сборщика приложений для мобильных устройств. Собранное приложение необходимо загрузить в магазин приложений (в статусе альфа-версии).
3. Перейти на страницу приложения.
4. На странице приложения, в разделе Службы и``API необходимо запомнить значение поля ЛИЦЕНЗИОННЫЙ КЛЮЧ ДЛЯ ЭТОГО ПРИЛОЖЕНИЯ. Это значение будет необходимо для выполнения проверки квитанции встроенной покупки на стороне прикладного решения для персонального компьютера.
5. Перейти в раздел Контент для продажи.
6. Новая встроенная покупка добавляется с помощью кнопки + Добавить продукт. Будьте внимательны при добавлении продуктов! Их невозможно удалить!
Huawei In-App Purchases
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для создания встроенных покупок следует выполнить следующие шаги:
1. Зарегистрируйтесь как разработчик Huawei (документация по регистрации https://``developer.``huawei.``com/``consumer/``en/``doc/``start/``registration-``and-``verification-0000001053628148 ).
2. Зайдите в AppGallery Connect (https://developer.huawei.com/consumer/en/service/josp/agc/index.html#/).
3. Создайте проект (нажать Add``project).
4. Создайте приложение (нажать кнопку New``app). Задайте соответствующие параметры приложения:
● Платформа: Android.
● Устройство: Mobile``phone.
● Категория приложения: App``or``Game.
5. Скопировать содержимое поля Хеш``SHA256 ключа подписи из настроек поставщика для ОС Android (раздел Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС Андроид). Сборщик приложений для мобильных устройств должен быть корректно настроен к этому моменту.
6. В AppGallery Connect выбрать Мои проекты и нужный проект. Выбрать нужное приложение в проекте. В настройках проекта на закладке Основная информация выбрать раздел Данные приложения. В поле ввода Отпечаток сертификата``SHA-256 ввести значение, которое мы получили на предыдущем шаге и нажать Сохранить.
7. В настройках проекта перейти на закладку Управление``API. Включить In-``App``Purchases.
8. На закладке Общая информация, в разделе Данные приложение скачать файл agconnect-``services.``json.
9. Скачанный файл загрузить в группу мобильного приложения в сборщике мобильных приложений:
● Перейти на закладку Для ОС``Android.
● Включить флажок Использовать сервисы``Huawei.
● В группе Работа с``AppGallery``Connect загрузить полученный json-файл.
10. В AppGallery Connect перейти в In-``App``Purchases через меню раздела Доходы. Нажать Settings. С открывшейся страницы скопировать значение Публичный ключ. Это значение будет необходимо для выполнения проверки квитанции встроенной покупки. Получившееся значение ключа необходимо указать в поле Ключ проверки встроенных покупок, находящееся в группе Использовать сервисы``Huawei в форме группы мобильного приложения.
11. Для добавления покупок следует перейти в AppGallery Connect. Выбрать нужное приложение. Перейти на закладку Управление``API. Перейти в Управление продуктами из меню в разделе Продукты.
12. Новая встроенная покупка добавляется с помощью кнопки Добавить продукты.
Смотри также:
● Документация по управлению встроенными покупками: https://``developer.``huawei.``com/``consumer/``en/``doc/``distribution/``app/``agc-``help-``create-``product-0000001099854866#section10697151616123.
RuStore платежи in-app
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для создания встроенных покупок следует выполнить следующие шаги:
1. Зарегистрируйтесь в RuStore как разработчик (документация по регистрации доступна по адресу https://www.rustore.ru/help/developers/developer-account).
2. Выполните вход в консоль разработчика RuStore (https://dev.rustore.ru/).
3. Создайте приложение (нажать + Добавить приложение). Задайте соответствующие параметры приложения:
● Тип приложения: Универсальный.
● Тип монетизации: Бесплатное / Платное.
● Название приложения в консоли. Оно будет видно только вам. Данное значение позже можно изменить.
4. Перейдите в раздел Монетизация.
5. Добавьте новую встроенную покупку с помощью кнопки + Новый товар в разделе Разовые покупки или + Новая подписка в разделе Подписки.
Смотри также:
● Документация по управлению встроенными покупками: https://www.rustore.ru/help/sdk/payments/.
Windows In-App Purchase
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для создания встроенных покупок следует выполнить следующие шаги:
1. Необходимо войти в Центр разработки для Windows (https://``developer.``microsoft.``com/``windows).
2. Необходимо перейти в информационную панель (кнопка Информационная панель).
3. Перейти на страницу необходимого приложения. На странице найти заголовок Надстройки, здесь нажать на кнопку Создание новой надстройки. Откроется новая страница Создание новой надстройки.
4. На странице представлено несколько типов покупки. Для использования с мобильной версией «1С:Предприятие» подходят следующие типы:
● Длительного пользования ‑ постоянная покупка (в терминах «1С:Предприятия»).
● Управляемый разработчиком расходуемый ‑ расходуемая покупка (в терминах «1С:Предприятия»).
● Подписка (в том числе и в терминах «1С:Предприятия»).
После выбора типа, в поле Код продукта ввести уникальный идентификатор покупки. Этот идентификатор будет использоваться для работы со встроенными покупками к коде конфигурации. Далее, нажать на кнопку Создать надстройку. Откроется страница только что созданной покупки.
5. На странице нажать на пункт Начать отправку. Откроется страница, на которой можно заполнить данные о покупке: Свойства, Цены и доступность, Возрастные категории и Описание в``Store (на разных языках).
В разделе Свойства свойствах можно указать время существования покупки (если это постоянная покупка) и тип контента, поставляемого с этой покупкой.
В разделе Цены и доступность указывается цена покупки и отмечается возможность поиска покупки в магазине или доступность покупки для приобретения.
Для начала рекомендуется установить цену в «бесплатно», что бы при тестировании покупок не взымалась плата. После тестирования цену необходимо будет выставить в желаемое значение.
В разделе Описание в``Store указывается заголовок и описание покупки на всех поддерживаемых языках, при желании можно добавить иконку для покупки.
28.3.6.14.5. Тестирование встроенных покупок
Общая информация
Данный раздел содержит рекомендации по тестированию работы со встроенными покупками. Рекомендации касаются особенностей взаимодействия мобильного приложения (мобильной платформы) и сервиса встроенных покупок.
Для ОС Android
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС Android, можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные покупки. Сами алгоритмы можно протестировать с использованием мобильной версии для разработчика. Если для встроенных покупок используется Google Play In-App Billing , то для тестирования также можно применить сборщик мобильных приложений, который содержит эмулятор системы Google Play In-App Billing. Если для встроенных покупок используется Huawei In-App Purchases или RuStore покупки in-app, то эмулятор этих системы не предоставляется.
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине приложений:
● При использовании сервисов GMS, покупки будут выполняться через реальный сервис Google Play In-App Billing, но фактического списания денежных средств выполняться не будет, если текстовый аккаунт добавлен в список «тестировщиков лицензий» в настройках аккаунта разработчика в Google Play Console (пункт меню Тестирование лицензий в разделе Настройка).
● При использовании сервисов HMS, покупки будут выполняться через реальный сервис Huawei In-App Purchases, но фактического списания денежных средств выполняться не будет, если текстовый аккаунт добавлен в список тестовых аккаунтов в персональных данных аккаунта разработчика AppGallery Connect в разделе меню Изолированная среда.
● Покупки в RuStore покупки будут выполняться через реальный сервис, но фактического списания денежных средств выполняться не будет. Такое будет работать в том случае, если аккаунт, от имени которого выполняется тестирование, добавлен в список тестовых аккаунтов в разделе меню Монетизация ‑ Тестовые платежи ‑ Тестировщики. На момент написания документации тестировщиком может быть только владелец аккаунта разработчика.
Дальше будут подробнее рассмотрены все варианты тестирования.
Смотри также:
● Документация по тестированию покупок в сервисе Google Play In-App Billing: https://``developer.``android.``com/``google/``play/``billing/``test.
● Документация по тестированию покупок в сервисе Huawei In-App Purchases: https://``developer.``huawei.``com/``consumer/``en/``doc/``development/``HMSCore-``Guides/``sandbox-``testing-0000001050035039.
● Документация по тестированию покупок в сервисе RuStore платежи in-app ‑ https://www.rustore.ru/help/developers/monetization/sandbox/.
На платформе разработчика
Мобильная версия «1С:Предприятие» для разработчика не позволяет выполнять тестирование покупок для любого сервиса покупок. Однако, в сборщике мобильных приложений реализован сервис, который эмулирует Google Play In-App Billing и позволяет выполнять тестирование покупок. При использовании эмулятора и мобильной версии для разработчика, необходимо в свойствах информационной базы, на которой будет осуществляться тестирование, следует заполнить свойства Адрес сервера покупок и Идентификатор пользователя.
Для того чтобы воспользоваться эмулятором, необходимо опубликовать на веб-сервере HTTP-сервис PurchasesTest (подробнее про публикацию на веб-сервере написано в книге). Адрес опубликованного HTTP-сервиса необходимо указать в свойстве информационной базы Адрес сервера покупок.
В сборщике следует завести пользователя, для которого выбрана роль Проверка покупок. Затем в сборщике приложений для мобильных устройств следует открыть специальный инструмент для тестирования встроенных покупок (Рабочий стол``‑ Сервис``‑ Тестирование встроенных покупок).
В поле Мобильное приложение выбирается то мобильное приложения, для которого будет выполняться тестирование встроенных покупок. Содержимое остальных таблиц связано с выбранным приложением.
В таблице Тестовые пользователи предоставляется возможность указать несколько пользователей, от имени которых будет тестироваться выполнение встроенных покупок. Указание разных идентификаторов тестовых пользователей в свойствах информационной базы на мобильном устройстве (свойство Идентификатор пользователя) позволит быстро проверять работу с покупками от имени разных пользователей, работающих с мобильным приложением.
В таблице Доступные покупки необходимо создать ровно тот список покупок (особенно в части идентификаторов и типов покупок), который в дальнейшем будет создаваться в консоли разработчика Google Play. При указании валюты покупки следует использовать буквенный код валюты из стандарта ISO 4217 (http://``www.``iso.``org/``iso/``ru/``home/``standards/``currency_``codes.``htm).
В таблице Совершенные покупки имеется возможность создать необходимую конфигурацию тестового окружения: какой пользователь, какие покупки совершил, имеется возможность отключать приобретение покупки и т. д.
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Google Play In-App Billing. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
1. Войти в консоль разработчика Google Play (https://``play.``google.``com/``apps/``publish/).
2. Перейти в раздел Настройки (в левой части экрана).
3. В разделе Аккаунты``Gmail тестировщиков указать адреса электронной почты тех прикладных разработчиков, которые будут тестировать работу со встроенными покупками. Указанные тут разработчики (или тестировщики) смогут выполнять покупки без выполнения реальной оплаты, однако, при выполнении тестовой покупки будет необходимо указывать данные реальной, платежеспособной банковской карты. С этой карты будет выполнено тестовое списание (с последующим возвратом) небольшой суммы (примерно 1 доллар США) для проверки корректности указанных данных.
4. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта.
Собранное приложение (Huawei In-App Purchases)
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Huawei In-App Purchases. При настройке следует указывать тот идентификатор мобильного приложения, который будет использоваться для разрабатываемого приложения (подробности настройки сервиса см. здесь):
1. Войти в консоль разработчика AppGallery Connect (https://``developer.``huawei.``com/``consumer/``en/``service/``josp/``agc/``index.``html ).
2. Перейти в раздел Пользователи и права.
3. Перейти в раздел Изолированная среда ‑ Тестовые аккаунты.
4. Добавить в список реально существующую учетную запись Huawei. Указанные в этом разделе разработчики (или тестировщики) смогут выполнять покупки без выполнения реальной оплаты. Изменение списка тестировщиков применяется длительное время (от 30 до 60 минут).
5. Номер сборки у тестируемого приложения должен быть больше, чем номер сборки у уже опубликованного в магазине приложения (если оно уже было опубликовано).
ВНИМАНИЕ! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке приложения в магазине RuStore. Для тестирования покупок приложение хоть раз должно быть опубликовано и пройти модерацию.
1. Выполните вход в консоль разработчика RuStore (https://dev.rustore.ru/).
2. Перейдите в раздел Монетизация ‑ Тестовые платежи (в левой части формы).
3. Добавьте тестировщиков. На момент написания документации тестировщиком может быть только владелец аккаунта разработчика.
В список следует добавлять только реально существующие учетные записи. Указанные тут пользователи смогут выполнять покупки без выполнения реальной оплаты.
Для ОС iOS
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС iOS, можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные покупки. Это тестирование выполняется с помощью мобильной платформы разработчика и сервиса Apple In-App Purchase, работающего в специальном (тестовом) режиме.
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине приложений. Покупки будут выполняться через реальный сервис Apple In-App Purchase, но фактического списания денежных средств выполняться не будет. Для тестирования используется специальная программа TestFlight.
Дальше будут подробнее рассмотрены оба тестирования.
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
После выполнения настроек необходимо собрать мобильную платформу разработчика, указав при ее сборке идентификатор мобильного приложения, который использовался при настройке сервиса. Подробнее о создании мобильной платформы разработчика см. здесь.
Затем необходимо указать аккаунты пользователей, которые смогу тестировать встроенные покупки в «песочнице» (sandbox). Для этого необходимо выполнить следующее:
1. Войти в систему iTunes Connect (https://``itunesconnect.``apple.``com).
2. Перейти в раздел Пользователи и роли.
3. Перейти на закладку Тестировщики``Sandbox.
4. На данной странице следует добавить электронную почту тех пользователей, которые будут выполнять роль тестировщиков.
5. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта с использованием платформы разработчика.
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
Затем выполнить следующие операции:
1. Войти в систему iTunes Connect (https://``itunesconnect.``apple.``com).
2. Перейти в раздел Пользователи и роли.
3. Перейти в раздел Мои приложения.
4. Найти приложение, которое планируется тестировать.
5. Загрузить мобильное приложение, собранное с помощью сборщика приложений для мобильных устройств.
6. Перейти в свойства мобильного приложения.
7. Перейти в раздел TestFlight.
8. Перейти в раздел Внутреннее тестирование (открыт по умолчанию).
9. Укажите, кто из внутренних тестировщиков будет заниматься тестированием выбранного мобильного приложения.
10. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта.
Для ОС Windows
Платформа разработчика предоставляет возможность выполнять тестирование работы с покупками без необходимости выполнять сборку мобильного приложения. Для этого в свойствах информационной базы, на которой будет осуществляться тестирование, следует заполнить свойства Адрес сервера покупок и Идентификатор пользователя.
Тестирование мобильных покупок выполняется аналогично таковому для приложения, работающего под управлением ОС Android. Подробное описание этого процесса см. здесь.
28.3.6.15. Статистика использования мобильного приложения
28.3.6.15.1. Общая информация
После того, как мобильное приложение разработано и выпущена первая версия этого приложения, начинают возникать различные вопросы. В числе прочих, в списке могут присутствовать следующие вопросы:
● На каких устройствах и под управлением каких версий операционных систем чаще всего используется мобильное приложение?
● Почему не используется какая-то функция приложения?
● Какие функции используются чаще всего?
● Какие фрагменты приложения вызывают наибольшие проблемы?
● Какой рекламный источник чаще всего приводит к установке приложения?
● И т. д.
Для того чтобы помочь найти ответы на эти (и подобные) вопросы ‑ предназначены сервисы аналитики мобильных приложений. Сразу предупредим, что данный материал не является документацией (или, тем более, учебником) по сервисам аналитики. Данный материал предназначен только для того, чтобы описать возможности мобильной версии «1С:Предприятие» по взаимодействию с поддерживаемыми сервисами аналитики.
Общая схема работы выглядит следующим образом:
1. В прикладное решение подключается файл преобразования (или встраивается программный код), который будет выполнять генерацию событий для сервиса аналитики. При этом рекомендуется предварительно проанализировать, ответы на какие вопросы вы хотите получить. Это связано с тем, что многие сервисы аналитики являются платными инструментами, и, если вы включите для своего приложения отправку в сервис аналитики всех возможных событий ‑ это может оказать не очень бюджетным решением.
2. В сборщике мобильных приложений необходимо указать, какой сервис аналитики (из списка поддерживаемых) будет использоваться в мобильном приложении, и указать настройки этого сервиса. Использование сервиса статистики в мобильной версии «1С:Предприятие» для разработчика требует несколько других настроек и будет описано отдельно.
3. Опубликовать мобильное приложение в соответствующем магазине приложений.
4. Приложение начнет отправлять статистику использования в сервис, а аналитик компании-разработчика мобильного приложения ‑ начнет анализ получаемой информации.
Для работы с сервисом статистики служит свойство глобального контекста СтатистикаИспользованияПриложения. В документации, для упрощения, будет опускаться префикс метода СтатистикаИспользованияПриложения``.. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Мобильная версия «1С:Предприятие» поддерживает следующие сервисы статистики:
● AppMetrica (для ОС Android, iOS и Windows).
● Firebase Analytics (для ОС Android и iOS).
28.3.6.15.2. Устройство механизма
Для того чтобы использовать сервис статистики, необходимо использовать или мобильную версию разработчика или собрать мобильное приложение с указанием на то, что приложение будет использовать сервис статистики. Если приложение на мобильном устройстве может взаимодействовать с сервисом статистики, то управление фактическим взаимодействием с сервисом статистики управляется с помощью флажка в настройках мобильного приложения и с помощью файла настроек.
Мобильное приложение отправляет в сервис статистики информацию о том, какие события происходят в мобильном приложении. С точки зрения сервиса статистики, события делятся на две большие группы:
● События. Событие ‑ это любое взаимодействие пользователя с интерфейсом мобильного приложения на мобильном устройстве.
● Экраны (страницы). Экран ‑ это частный случай события. Экран ‑ это смена активной формы в анализируемом приложении. Термин «экран» используется по той причине, что некоторые сервисы статистики используют понятие экранов для формирования различной отчетности.
В документации события и экраны будут упоминаться под общим термином «события». Если эти термины будет необходимо разделить ‑ это будет делаться явно. Мобильная версия «1С:Предприятия» разделяет события на два подкласса:
● Исходные события ‑ это те события, которые генерирует сама мобильная версия (или код на встроенном языке).
● Отправляемые событие ‑ это события, которое создаются на основе исходных событий и которые фактически отправляются в сервис аналитики.
Для преобразования исходного события в отправляемое событие предназначены специальные настройки. Они представляют собой XML-файл специального формата. Преобразование выглядит следующим образом:
● Провайдер статистики (модуль мобильной версии, отвечающий за преобразование событий и взаимодействие с самим сервисом) мобильного приложения загружает файл настроек. Это происходит при старте мобильного приложения, до того момента, как инициализируется мобильная конфигурация.
● Исходные события передаются провайдеру статистики.
● Провайдер статистики, по правилам, указанным в файле настроек, преобразует исходные события в отправляемые события.
● Отправляемые события отправляются сервису аналитики.
XML-файл настроек можно предоставить мобильному приложению тремя способами (в порядке повышения приоритета):
● С помощью сборщика мобильных приложений, указав этот файл во время настройки собираемого приложения и не указав адрес обновления этого файла. В этом случае в собранной версии будет действовать ровно тот набор правил преобразования исходных событий в отправляемые события. Сменить набор правил можно только выпустив новую версию мобильного приложения. Это рекомендуемый способ.
● Аналогичен предыдущему способу, но в сборщике также указывается адрес обновления, откуда мобильное приложение сможет получить новый файл правил преобразования событий. В этом случае предоставляется возможность обновлять состав отправляемых событий, не выпуская новую версию мобильного приложения. Это также является рекомендованным способом.
● Реализовать всю (или часть) работу с помощью встроенного языка системы «1С:Предприятие». Так, получение и установка настроек будет выполняться с помощью методов ПолучитьНастройки()/УстановитьНастройки(). Аналогичные методы есть для отправки исходных и отправляемых сообщений. Это не рекомендованный способ. Причиной является тот факт, что для отключения работы с сервисом статистики потребуется не только пересборка мобильного приложения, но и изменение исходных текстов прикладного решения. Изменение исходных текстов потребуется для того, чтобы исключить вызовы встроенного языка, которые будут недоступны в том случае, когда мобильное приложение собрано без поддержки сервиса статистики.
Таким образом, самым оптимальным вариантом подключения сервиса статистики к мобильному приложению ‑ это использование сборщика мобильного приложения и не использование встроенного языка.
Таким образом, для включения отправки событий в сервис аналитики необходимо выполнить следующие действия:
1. Подготовить файл настроек для преобразования событий.
2. В сборщике мобильных приложений указать, какой сервис статистики будет использоваться мобильным приложением, настроить провайдер статистики, загрузить в сборщик файл настроек.
3. Собрать мобильное приложение.
4. Отправить мобильное приложение на мобильное устройство.
При использовании сервиса статистики следует помнить о юридических аспектах использования такого рода сервисов. Разработчик приложения с использованием сервиса статистики должен контролировать содержание отсылаемой в сервис информации и соблюдать правила тех сервисов статистики, которые он использует, а также магазинов, через которые распространяется данное приложение. Кроме того, необходимо выполнять следующие особенности:
1. По умолчанию считается, что все пересылаемые данные обезличены и нет никакой возможности, исходя из них, как-то связать эти данные с конкретной копией приложения. В этом случае, достаточно, чтобы разработчик предупредил пользователя об использовании статистических сервисов в Пользовательском соглашении приложения.
2. Если приложение пересылает в сервис какие-либо идентификаторы, которые впоследствии могут быть связаны с конкретной копией приложения (если это не нарушает правил используемых сервисов), то в этом случае, как правило, требуется показ отдельного диалога пользователю, с которым он явным образом соглашается или не соглашается.
3. Пересылка любых личных данных пользователя в сервис статистики запрещена.
Разработчик приложения с использованием механизма статистики использования приложения обязан соблюдать все региональные законы в сфере регистрации пользовательских данных. В частности, при использовании приложения на территории Российской Федерации необходимо соблюдать требования статьи 138.1 Уголовного кодекса Российской Федерации, которая регламентирует незаконный оборот специальных технических средств, предназначенных для негласного получения информации.
28.3.6.15.3. Методы менеджера статистики
Мобильная версия «1С:Предприятие» позволяет взаимодействовать с провайдером статистики с помощью встроенного языка. Данный способ является не рекомендуемым.
Встроенный язык позволяет выполнить следующие действия:
● Получить и установить файл настроек. Используются методы ПолучитьНастройки()/УстановитьНастройки()/ПолучитьТекущиеНастройки(). Эти методы различаются следующим:
● Метод ПолучитьТекущиеНастройки() всегда возвращает те настройки, которые в данный момент используются для преобразования исходных событий в отправляемые события. Для данного метода совершенно неважно, откуда поступили настройки: из мобильного приложения (установлены в сборщике), в результате обновления настроек через Интернет-ресурс или с помощью методов строенного языка.
● Пара методом ПолучитьНастройки()/УстановитьНастройки() предназначена для установки настроек из встроенного языка. Вызов метода УстановитьНастройки() с конкретным файлом настроек приведет к тому, что настройки будут переустановлены. После такой установки метод ПолучитьТекущиеНастройки() вернет только-что установленные настройки. Если вызвать метод УстановитьНастройки(), передав ему в качестве параметра значение Неопределено, то метод ПолучитьТекущиеНастройки() начнет опять возвращать настройки, указанные в сборщике (или полученные через Интернет-сервис).
● Методы ПолучитьАдресОбновления()/УстановитьАдресОбновления()/ПолучитьТекущийАдресОбновления() работают абсолютно аналогично методам работы с настройками, но работа происходит с адресом Интернет-сервиса, через который можно выполнять обновление файла с настройками преобразования исходных событий в отправляемые события.
● Методы ОтправитьСобытие()/ОтправитьЭкран() выполняют передачу событий и экранов непосредственно в сервис статистики, минуя механизм преобразования.
● Метод ВызватьИсходноеСобытие() генерирует исходное событие, которое будет подано на вход механизм преобразования событий с помощью файла настроек. Можно сказать, что данный метод (в некотором смысле) является аналогом интерактивного действия пользователя.
28.3.6.15.4. Файл настроек
Для настройки преобразования исходных событий в отправляемые события предназначен файл настроек. Этот файл в формате XML описывает правила преобразования одних событий в другие. Формат файла описывается схемой (в формате XSD), который поставляется в дистрибутиве мобильной версии «1С:Предприятие».
В общем случае, файл настроек выглядит следующим образом:
Файл состоит из раздела, в котором описываются правила преобразования событий (элемент <``events``>). Рассмотри эти правила подробнее.
Элемент events
Данный элемент описывает, каким образом исходные события будут конвертироваться в отправляемые события. Каждое исходное событие описывается с помощью вложенного элемента <``sourceEvent``>.
Элемент sourceEvent
Данный элемент описывает одно исходное событие и правила его (исходного события) преобразования в отправляемое событие. Имя исходного события указывается в атрибуте name элемента <``sourceEvent``>. Для задания правил предназначены элементы eq (равно), ne (не равно), gt (больше), ge (больше или равно), lt (меньше), le (меньше или равно), like (подобно). Для указания отправляемого события предназначен элемент <``targetEvent``>.
Элементы условий имеют два атрибута:
● name ‑ в этом атрибуте указывается имя параметра, значение которого будет проверяться. Имена (и набор) параметров зависят от исходного события.
● value ‑ определяет значение проверяемого параметра.
Все условия, указанные для одного исходного события, объединяются «по И». Имена исходных событий и их параметров не чувствительны к регистру символов.
Мобильная версия поддерживает следующие исходные события:
● ApplicationStart ‑ запуск мобильного приложения.
● Параметры отсутствуют.
● ApplicationFinish ‑ завершение работы мобильного приложения.
● Параметры отсутствуют.
● ApplicationSleep ‑ «засыпание» мобильного приложения.
● Параметры отсутствуют.
● ApplicationWake ‑ выход мобильного приложения из состояния «сна».
● Параметры отсутствуют.
● FormOpen ‑ открытие формы. Событие имеет следующие параметры:
● ПолноеИмя / FullName ‑ полное имя формы.
● Имя / Name ‑ имя формы (свойство Имя открываемой формы).
● ТекущийЗаголовок / CurrentTitle ‑ заголовок открываемой формы.
● ТекущаяНавигационнаяСсылка / CurrentURL ‑ навигационная ссылка открываемой формы.
● FormClose ‑ закрытие формы. Событие имеет следующие параметры:
● ПолноеИмя / FullName ‑ полное имя формы.
● Имя / Name ‑ имя формы (свойство Имя закрываемой формы).
● ТекущийЗаголовок / CurrentTitle ‑ заголовок закрываемой формы.
● ТекущаяНавигационнаяСсылка / CurrentURL ‑ навигационная ссылка закрываемой формы.
● CommandExecute ‑ выполнение команды. Событие имеет следующие параметры:
● ПолноеИмя / FullName ‑ полное имя команды.
● Имя / Name ‑ имя команды (свойство Имя исполняемой команды).
● ТекущийЗаголовок / CurrentTitle ‑ представление выполняемой команды.
● ТекущаяНавигационнаяСсылка / CurrentURL ‑ навигационная ссылка выполняемой команды.
● Произвольный идентификатор исходного события, которое формируется из встроенного языка. В этом случае состав и назначение параметров события определяется параметрами метода ВызватьИсходноеСобытие().
Если в файле настроек указано свойство <``sourceEvent``>, которое не содержит подчиненных элементов, то это означает, что данное исходное событие будет передано в сервис статистики, но имя отправляемого события будет сформировано как Объект_ИмяИсходногоСобытия. Здесь Объект ‑ это полное имя объекта конфигурации, вызвавшего исходное событие (с точностью до настроек мобильного приложения в сборщике). Если на одном устройстве создано несколько информационных баз из одной конфигурации одного мобильного приложения ‑ события из этих информационных баз будут неразличимы.
targetEvent
Элемент <``targetEvent``> описывает отправляемое событие и обладает следующими атрибутами:
● name ‑ содержит имя отправляемого события. Если имя не указано ‑ оно будет сгенерировано автоматически.
● param``1 и param``2 ‑ параметры отправляемого события. Суть параметров определяется с точки зрения сервисов статистики или с точки зрения пользовательского события.
● type ‑ вид отправляемого события:
● event ‑ событие будет отправлено в сервис статистики как «событие». Это значение атрибута по умолчанию.
● screen ‑ событие будет отправлено в сервис статистики как «экран».
28.3.6.15.5. Настройка сервисов статистики
Общая информация
Информацию об особенностях настройки и работы с конкретными сервисами статистики следует искать в документации этих сервисов. Данный раздел содержит информацию, которая необходима только для того, чтобы подключить соответствующий сервис аналитики к мобильной версии «1С:Предприятие».
AppMetrica
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
1. Войти в сервис AppMetrica (https://``appmetrica.``yandex.``ru/) от имени пользователя, который будет анализировать результаты работы (разработчика приложения).
2. На первом экране нажать кнопку Подключить.
3. В мастере добавления приложения следует указать:
● Название добавляемого приложения в поле Название приложения.
● Указать, что добавляется приложение (а не игра).
● В поле Категория приложения указать наиболее подходящую категорию добавляемого приложения.
● Если приложение опубликовано в магазине, в разделе Ссылка на приложение следует указать ссылку на опубликованное приложение.
● На шаге Детали нужно указать текущий часовой пояс и подтвердить дополнительные условия обработки данных в поле GDPR (если это необходимо).
● Нажать кнопку Добавить приложение.
4. После нажатия кнопки Добавить приложение ‑ создаваемое приложение будет добавлено в сервис. На последней странице вам необходимо сохранить данные, которые указаны в поле API``key. Это значение будет необходимо использовать для заполнения поля Идентификатор приложения в сервисе статистики в диалоге настройки провайдера статистики в сборщике мобильных приложений.
Firebase Analytics
Внимание!** Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.**
Следующие действия необходимо выполнять от имени пользователя, который будет анализировать результаты работы (разработчика приложения):
1. Необходимо войти в консоль разработчика (Firebase Console, https://console.firebase.google.com).
2. Необходимо создать проект (кнопка Создать проект). При создании проекта следует указать название проекта. Название проекта должно содержать только латинские символы. После ввода наименования проекта следует нажать кнопку Продолжить.
3. На странице с описанием свойств создаваемого проекта можно указать необходимость включения Google Аналитики в проекте. По умолчанию данный флажок установлен. Затем необходимо нажать кнопку Далее.
4. На последнем шаге создания проекта следует указать страну, в которой расположена организация, владеющая создаваемым проектом. Затем следует согласиться со всеми условиями сервиса и нажать кнопку Создать проект. После того, как проект создан ‑ нажмите кнопку Далее.
5. На странице проекта необходимо добавить мобильное приложение для ОС Android или iOS. Для этого предназначены две кнопки под заголовком Добавьте сервис``Firebase в свое приложение. Для добавления приложения:
● ОС Android:
● Нажмите кнопку с изображением робота.
● В поле Название пакета``Android укажите полный идентификатор приложения из сборщика мобильных приложений.
● Поля Псевдоним приложения и Хеш сертификата для отладки заполняются по желанию.
● Нажатие кнопки Зарегистрировать приложение выполняется собственно регистрацию.
● На шаге Скачайте файл конфигурации следует нажать кнопку Download``google-``services.``json.
● ОС iOS:
● Нажмите кнопку с надписью iOS.
● В поле Идентификатор пакета``iOS укажите полный идентификатор приложения из сборщика мобильных приложений.
● Поля Псевдоним приложения и Идентификатор``App``Store заполняются по желанию.
● Нажатие кнопки Зарегистрировать приложение выполняется собственно регистрацию.
● На шаге Скачайте файл конфигурации следует нажать кнопку Download``GoogleService-``Info.``plist.
6. Файл, скачанный при регистрации приложения в сервисе, будет необходимо загрузить в сборщик мобильных приложений при настройке параметров сборки для соответствующей мобильной ОС.
28.3.6.16. Характеристики интернет-соединения
При использовании мобильного приложения часто возникают задачи обмена информацией с внешней системой через Интернет. При этом может возникать задача выполнения обмена только через определенные виды интернет-соединения или только в том случае, если интернет-соединение обладает достаточной пропускной способностью (скорость) для выполнения обмена.
Мобильная версия «1С:Предприятия» позволяет определить параметры интернет-соединения, которое в данный момент используется на мобильном устройстве. Получить эти параметры можно с помощью свойства глобального контекста ИнформацияОбИнтернетСоединении.
Для определения типа интернет-соединения используется метод ИнформацияОбИнтернетСоединении.ПолучитьТипСоединения(). Система распознает следующие типы интернет-соединения: подключение с помощью мобильного интернета (GRPS, EDGE и т. д.), WiFi-соединение, подключение по локальной сети и отсутствие интернет-соединения.
С помощью метода ИнформацияОбИнтернетСоединении.ПолучитьОжидаемуюСкоростьИнтернетСоединения() можно выполнить оценку ожидаемой скорости текущего соединения. Если метод возвращает значение 0, то это означает, что в данный момент доступ в Интернет отсутствует на мобильном устройстве.
С помощью метода ИнформацияОбИнтернетСоединении.ПолучитьИспользованиеРоуминга() имеется возможность узнать, что устройство в момент вызова метода находится в роуминге. Нахождение в роуминге может означать, что тарификация скачиваемых данных с помощью мобильной сети передачи данных, существенно (в десятки раз!) превышает таковую при нахождении в домашней сети. Если функция возвращает значение Неизвестно, то это означает, что тип используемого соединения не равен значению ТипИнтернетСоединения.СотовыеДанные.
Важной особенностью инструментов работы с интернет-соединением в мобильной версии является возможность подключить специальный обработчик, который будет срабатывать в следующих случаях:
1. При смене типа интернет-соединения. К такому случаю также относится ситуация, когда на мобильном устройстве отключается любой доступ в Интернет, например пользователь перевел устройство в «режим полета».
2. При изменении ожидаемой скорости интернет-соединения при подключении с помощью мобильного интернета. В этом случае фиксируется изменения используемого стандарта мобильной сотовой связи, например, переход с сети стандарта 2G на сеть стандарта 3G и т. д.
3. При изменении состояния роуминга для текущего мобильного устройства.
Для подключения (или отключения) обработчика изменения интернет-соединения следует использовать методы ПодключитьОбработчикИзмененияИнтернетСоединения() (ОтключитьОбработчикИзмененияИнтернетСоединения()) объекта ИнформацияОбИнтернетСоединении.
28.3.6.17. Использование дополнительной проверки пользователя
28.3.6.17.1. Общая информация
В приложении, работающем на мобильном устройстве, могут возникать ситуации, когда требуется проверить, что в данный момент устройством пользуется именно владелец устройства. Например, выбирается функция, доступа к которой не должен предоставляться всем пользователям, которые получили разблокированное мобильное устройство в руки. Также может потребоваться хранить на мобильном устройстве конфиденциальные данные, например параметры доступа (логин и пароль) к какому-либо удаленному сервису.
Во всех перечисленных случаях, прикладному решению необходимо выполнить идентификацию пользователя каким-либо образом ‑ пароль, графический ключ, отпечаток пальца и т. д. Эту проверку можно выполнить с помощью объектов глобального контекста ДополнительнаяПроверкаПользователя и БезопасноеХранилище. Работа с данными свойствами будет описана далее, в этом разделе.
Говоря о дополнительной проверке пользователя, необходимо понимать, что такая проверка не является средством аутентификации пользователя. Т. е. с помощью дополнительной проверки невозможно утверждать, что устройством пользуется конкретный человек. Можно говорить лишь о том, что пользователь, который здесь и сейчас пользуется устройством, знает способ разблокировать телефон. Т. е. можно говорить о возможности идентифицировать владельца телефона (с учетом оговоренных условностей). Например, если вы сообщили своему бизнес-партнеру способ разблокировки (пин-код или графический ключ) телефона, то программа в телефоне не сможет определить, кто пользуется телефоном: вы или ваш бизнес-партнер.
28.3.6.17.2. Дополнительная проверка пользователя
Свойство глобального контекста ДополнительнаяПроверкаПользователя предназначено для того, чтобы прикладное решение, работающее на мобильном устройстве, запросило дополнительную проверку пользователя с целью убедиться, что с мобильным устройством (и мобильным приложением) в данный момент работает законный владелец. Свойство ДополнительнаяПроверкаПользователя предоставляет доступ к объекту МенеджерДополнительнойПроверкиПользователя. Для получения доступа к какому-либо свойству или методу менеджера, необходимо использовать запись вида ДополнительнаяПроверкаПользователя.Метод(). При описании методов (для упрощения) префикс ДополнительнаяПроверкаПользователя. будет игнорироваться. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Прежде, чем начать проверку, необходимо убедиться, что на данном устройстве поддерживается возможность дополнительной проверки. Это следует сделать с помощью метода ПоддерживаетсяПроверка(). В качестве параметра передается способ дополнительной проверки, работу с которым необходимо проверить. Если проверка поддерживается на устройстве ‑ можно выполнить собственно проверку (идентификацию) пользователя.
Для идентификации пользователя предназначен метод ПроверитьАсинх()/НачатьПроверку(). В данный метод передается способ дополнительной проверки, описание обработчика, который будет вызван после окончания проверки и текст, который платформа отобразит пользователю. Текст должен описывать, зачем и почему от пользователя требуются какие-то действия. Очевидно, что способ проверки, указанный в методе ПроверитьАсинх()/НачатьПроверку(), должен совпадать со способом проверки, который использовался при определении поддержки дополнительной проверки устройством.
Если на мобильном устройстве используется биометрическая идентификация пользователя, то узнать, какой способ используется в данный момент, можно с помощью метода ТекущийСпособБиометрическойПроверки(). Результат работы данного метода можно использовать в разных целях, например:
● Для формирования сообщения, которое передается в метод ПроверитьАсинх()/НачатьПроверку().
● Для определения, что надежность используемого способа проверки устраивает разработчика приложения.
В общем случае, пример дополнительной проверки пользователя мобильного приложения может выглядеть следующим образом:
Процедура ПроверитьПользователя() СпособПроверки = СпособДополнительнойПроверкиПользователя.ТолькоБиометрическая; Если Не ДополнительнаяПроверкаПользователя.ПоддерживаетсяПроверка(СпособПроверки) Тогда Возврат; КонецЕсли; ТекущаяБиометрия = ДополнительнаяПроверкаПользователя.ТекущийСпособБиометрическойПроверки(); Если ТекущаяБиометрия <> СпособБиометрическойПроверки.РаспознаваниеОтпечаткаПальца Тогда Возврат; КонецЕсли; Сообщение = "Отсканируйте отпечаток пальца"; Результат = Ждать ДополнительнаяПроверкаПользователя.ПроверитьАсинх(СпособПроверки, Сообщение); Если Не Результат Тогда // пользователь подтвержден КонецЕсли; КонецПроцедуры
28.3.6.17.3. Защищенное хранилище
Свойство глобального контекста БезопасноеХранилище предназначено для того, чтобы прикладное решение, работающее на мобильном устройстве, получило доступ к безопасному хранилищу конфиденциальных данных. Свойство БезопасноеХранилище предоставляет доступ к объекту МенеджерБезопасногоХранилища. Для получения доступа к какому-либо свойству или методу менеджера, необходимо использовать запись вида БезопасноеХранилище.Метод(). При описании методов (для упрощения) префикс БезопасноеХранилище. будет игнорироваться. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Безопасное хранилище позволяет хранить данные, для доступа к которым предназначен некоторый текстовый ключ. В рамках приложения ключ является уникальным значением. В хранилище могут использовать данные любого типа, который поддерживает XDTO-сериализацию. Нельзя поместить в безопасное хранилище значение Неопределено. При помещении данных в хранилище указывается способ защиты доступа к безопасному хранилищу (одно из значений системного перечисления СпособЗащитыДоступаБезопасногоХранилища):
● ТребуетсяРазблокировкаЭкрана. В этом случае считается, что приложение имеет доступ к защищенному хранилищу в том случае, если пользователь разблокировал устройство (получил доступ к рабочему столу устройства).
● ТребуетсяДополнительнаяПроверкаПользователя. В этом случае для получения доступа к защищенному хранилищу пользователю необходимо пройти дополнительную проверку. Способ дополнительной проверки задается вторым параметром метода ПоддерживаетсяЗащитаДоступа() (одно из значений перечисленияСпособДополнительнойПроверкиПользователя).
● Нет. В этом случае для получения доступа к защищенному хранилищу не нужны дополнительные проверки. Мобильная операционная система гарантирует, что доступ к защищенному хранилищу будет получен только в том случае, если мобильное устройство успешно запустилось.
Такое указание определяет следующее поведение:
● Для доступа к значению будет требоваться именно тот способ проверки, который указан при помещении значения.
● Если на мобильном устройстве будет отключен требуемый способ защиты доступа ‑ данные, которые были помещены в безопасное хранилище с указанием отключенного способа защиты, будут удалены из хранилища и получить к ним доступ будет невозможно.
Безопасное хранилище данных имеет ряд особенностей, которые зависят от используемой мобильной операционной системы:
● ОС Android:
● Размер хранилища: без ограничений.
● Размер одного элемента: без ограничений.
● Количество элементов хранилища: без ограничений.
● ОС macOS:
● Размер хранилища: 80 Мбайт.
● Размер одного элемента: 16 Мбайт.
● Количество элементов хранилища: без ограничений.
● ОС Windows:
● Размер хранилища: 320 Кбайт.
● Размер одного элемента: 16 Кбайт.
● Количество элементов хранилища: 20 элементов.
Прежде, чем начать использование безопасного хранилища, необходимо убедиться, что на данном устройстве поддерживается эта возможность. Это следует сделать с помощью метода ПоддерживаетсяЗащитаДоступа(). В качестве параметров передается способ защиты доступа к хранилищу и способ дополнительной проверки пользователя.
Если на данном экземпляре мобильного устройства поддерживается безопасное хранилище, приложение может выполнять операции помещения и получения данных. Поддерживаются стандартный набор операций:
● Поместить значение в хранилище. Используется метод ПоместитьДанныеАсинх()/НачатьПомещениеЗначения().
● Получить значение из хранилища. Используется метод ПолучитьДанныеАсинх()/НачатьПолучениеЗначения().
● Удалить значение из хранилища. Используется метод УдалитьДанныеАсинх()/НачатьУдалениеЗначения().
● Проверить, что в хранилище есть данные с указанным ключом. Используется метод СодержитКлюч().
Возможность перебора всех ключей защищенного хранилища не поддерживается.
Подробнее рассмотрим особенности работы с хранилищем. При помещении данных в хранилище, кроме собственно ключа и помещаемых данных, необходимо указать, каким образом будут защищены помещаемые данные. Это определяется параметрами СпособЗащитыДоступа и СпособПроверки метода ПоместитьДанныеАсинх()/НачатьПомещениеДанных(). Параметр СпособЗащитыДоступа имеет типСпособЗащитыДоступаБезопасногоХранилища и особенности этого типа были рассмотрены чуть раньше, в данном разделе. Если параметр СпособЗащитыДоступа установлен в значение СпособЗащитыДоступаБезопасногоХранилища.ТребуетсяДополнительнаяПроверкаПользователя, то необходимо указать значение параметра СпособПроверки. Этот параметр имеет тип системного перечисления СпособДополнительноПроверкиПользователя и позволяет указать, каким образом будет выполняться дополнительная проверка пользователя.
Для получения данных (метод ПолучитьДанныеАсинх()/НачатьПолучениеДанных()), кроме указания ключа доступа к данным, необходимо указать текст, который будет показан пользователю при необходимости дополнительной проверки. Пользователь может отказаться от получения данных из безопасного хранилища. В этом случае поведение зависит от варианта метода:
● ПолучитьДанныеАсинх() ‑ в результате исполнения обещания будет получено значение Неопределено.
● НачатьПолучениеДанных() ‑ параметр обработчика обратного вызова ОтмененоПользователем будет установлен в значение Истина.
Методы работы с хранилищем, в большинстве, являются методами, не блокирующими работу приложения. Результат работы методов передается в соответствующий обработчик обратного вызова. Обработчик обратного вызова является одним из параметров метода, который необходимо указать при вызове. В случае возникновения ошибки управление передается в обработчик ошибок, который также должен быть указан при создании объекта ОписаниеОповещения или будет сформировано исключение, которое может быть перехвачено по стандартной схеме использования обещания.
Синхронным является только метод проверки существования в хранилище некоторого значения для указанного ключа (метод СодержитКлюч()).
Также следует обратить внимание на то, что методы проверки при доступе к безопасному хранилищу не гарантируют присутствие устройства у какого-то конкретного пользователя. Эти методы гарантируют, что какой-то человек обладает возможностью разблокировать телефон с помощью требуемого метода, например, знает пин-код или графический узор для разблокировки телефона.
Смотри также:
● Обратный вызов и обработчик оповещения (см. здесь).
● Асинхронность через обещания (см. здесь).
28.3.6.18. Сканирование документов
Мобильная версия «1С:Предприятие» предоставляет возможность выполнить сканирование документов для последующей обработки или архивного хранения (в данном контексте «архивное» понимается как «хранение в архиве», а не какой-либо специфический формат данных). Например, может потребоваться выполнить сканирование какого-либо документа у пользователя, который невозможно (или не целесообразно) привезти для сканирования в офис нашей компании. В тоже время, мобильное устройство располагает камерой, которая позволит выполнить сканирование документа в достаточно высоком качестве и это устройство имеется практически у каждого человека.
Мобильная версия системы «1С:Предприятие» предоставляет доступ к механизму сканирования с помощью свойства глобального контекста СредстваМультимедиа. В документации, для упрощения, будет опускаться префикс метода СредстваМультимедиа.. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы. Рассмотрим предоставляемые возможности более подробно.
Перед тем, как начать сканирование документов, необходимо проверить, что текущее мобильное устройство поддерживает эту возможность. Для этого предназначен метод ПоддерживаетсяСканированиеДокументов(). Дальнейшее использование имеет смысл только в том случае, если этот метод возвращает значение Истина.
Для управления сканированием документов используется объект типа ПараметрыСканированияДокументов, который обладает следующими свойствами:
|
Свойство |
Описание |
|
|
Тип: ●
●
|
|
|
Тип: |
|
|
Тип: |
|
|
Тип: |
|
|
Тип: |
|
|
Тип: ●
●
|
|
|
Тип: |
Всего система предоставляет несколько предопределенных фильтров (значений системного перечисления ФильтрОбработкиСканированияДокументов), который можно комбинировать. В случае, если в параметрах сканирования указаны несколько фильтров ‑ все они будут указаны в интерфейсе сканирования для того, чтобы пользователь мог выбрать нужный фильтр. В интерфейсе сканирования фильтры будут переключаться в том порядке, в каком они перечислены в свойстве ФильтрыОбработки. Доступны следующие фильтры:
● Нет ‑ не использовать фильтры при сканировании документа. Этот фильтр рекомендуется добавлять всегда, чтобы пользователь мог оставить отсканированное изображение «как есть». Если предполагается автоматическая обработка отсканированного документа, то фильтр Нет рекомендуется оставлять единственным.
● ТекстСКартинками ‑ фильтр для обработки документа, содержащего текст с картинками. Этот фильтр обрабатывает картинку со средней агрессивностью. В случае, если документ предполагается обрабатывать вручную, этот фильтр можно делать фильтром по умолчанию. Он улучшает вид документа, экономит тонер при печати, но старается не повреждать фотографии и другие картинки, если они есть в документе.
● Текст ‑ фильтр для обработки документа, содержащего только текст. Этот фильтр обрабатывает картинку максимально агрессивно. В случае, если документ предполагается обрабатывать вручную и в документе не ожидается ничего кроме текста, таблиц, печатей, рамок, подчёркиваний и тому подобной графической информации, то можно указывать этот фильтр в качестве фильтра по умолчанию.
Перед выполнением сканирования необходимо создать значение типа ПараметрыСканированияДокументов, которое потом будет передано в метод, открывающий интерфейс сканирования документов и начинающий процесс сканирования.
Для того, чтобы начать сканирование, следует использовать методы ПоказатьСканированиеДокументов() или СканироватьДокументыАсинх(). Оба этих метода открывают форму интерфейса сканирования документов и позволяют получить результат сканирования, но делают это немного разными способами. Метод ПоказатьСканированиеДокументов() необходимо использовать в том случае, когда страницы сканируемого документа (по мере сканирования) надо сразу отправлять для выполнения с этими страницами каких-либо действий. Для этого, в метод передается два обработчика оповещения: в один (формальный параметр ОбработчикСканирования) управление передается после сканирования каждой страницы, а в другой (формальный параметр ОбработчикЗавершенияСканирования) управление попадает после окончания сканирования. В обработчик завершения сканирования передается массив идентификаторов страниц, которые фактически остались после завершения сканирования многостраничного документа. При использовании метода ПоказатьСканированиеДокументов() следует учитывать, что во время сканирования многостраничного документа пользователь может удалять ранее отсканированные страницы.
Метод СканироватьДокументыАсинх() (в отличие от метода ПоказатьСканированиеДокументов()) не дает возможности получать каждую страницу по отдельности (в процессе сканирования). Метод возвращает объект типа Обещание, который после выполнения обещания будет преобразован в массив значений типа СтраницаСканированияДокументов, которые расположены в том порядке, как их расставил пользователь в интерфейсе сканирования. Результатом исполнения обещания может быть значение Неопределено, если пользователь закрыл интерфейс сканирования без подтверждения результатов сканирования.
Для того, чтобы закрыть интерфейс сканирования, предназначен метод ЗакрытьСканированиеДокументов(). При штатном использовании системы, использование данного метода не требуется. Данный метод используется в тех случаях, когда надо закрыть интерфейс сканирования в обход штатного процесса.
Что возвращает интерфейс сканирования в типе СтраницаСканированияДокументов? Рассмотрим свойства объекта:
|
Свойство |
Описание |
|
|
Тип: |
|
|
Тип: |
|
|
Тип: |
|
|
Тип: |
Рассмотрим, что нам дает значение типа ПараметрыКачестваСканированияДокументов. Значение данного типа показывает, какое качество у текущей страницы документа (по «мнению» механизма сканирования). Качество оценивается по нескольким параметрам, каждый из которых может принимать значение от 0 до 10 (включительно). В зависимости от значения, можно сказать, что параметр попадает в три интервала качества:
● [1.0, 4.0) ‑ низкое качество.
● [4.0, 7.0) ‑ среднее качество.
● [7.0, 10.0] ‑ высокое качество.
В данном случае символ «[» означает «закрытая граница» или «включая значение», а символ «)» означает «открытая граница» или «исключая значение». Таким образом, выражение [1.0, 4.0) означает, что качество будет считаться низким, если: 1.0 <= ЗначениеПараметра < 4.0.
Рассмотрим свойства объекта ПараметрыКачестваСканированияДокументов:
|
Свойство |
Описание |
|
|
Показывает, насколько бумага страницы белая и однородная: ● Низкое качество ‑ документ не похож на документ, напечатанный на белой однотонной бумаге. ● Среднее качество ‑ документ похож на напечатанный на белой однотонной бумаге, но освещен не совсем белым цветом. ● Высокое качество ‑ бумага документа белая, однотонная. |
|
|
Показывает насколько контрастны и выровнены края документа относительно фона, на котором выполняется сканирование: ● Низкое качество ‑ границы документа не контрастны либо очень неровные. Границы документа требуется уточнить дополнительно. ● Среднее качество ‑ границы документа различимы, но присутствуют дефекты. ● Высокое качество ‑ границы документа контрастны и четко различимы. |
|
|
Описывает контрастность текста документа: ● Низкое качество ‑ текст не контрастный. ● Среднее качество ‑ текст контрастный, но присутствуют дефекты. ● Высокое качество ‑ текст контрастный. |
|
|
Обобщенный уровень качества отсканированного документа, определяемый платформой в зависимости от параметров сканирования: ● Низкое качество. ● Среднее качество. ● Высокое качество. |
|
|
Показывает, насколько мало перспективных искажений, хорошо ли расположен документ по отношению к плоскости камеры: ● Низкое качество ‑ устройство расположено не параллельно документу или под большим углом относительно документа. Какие-то области документа находятся намного дальше других от устройства и поэтому плохо видны. ● Среднее качество ‑ устройство расположено почти параллельно плоскости документа. Области документа, расположенные дальше от камеры, видны хуже. ● Высокое качество ‑ устройство расположено над документом и параллельно плоскости документа. Все области документа видны отлично. |
В заключении рассмотрим простой пример запуска интерфейса сканирования в клиентском приложении:
&НаКлиенте Асинх Процедура Сканировать() Если Не СредстваМультимедиа.ПоддерживаетсяСканированиеДокументов() Тогда Возврат; КонецЕсли; ПараметрыСканирования = Новый ПараметрыСканированияДокументов; ПараметрыСканирования.ПроверкаКачества = ПроверкаКачестваСканированияДокументов.НеПроверять; ПараметрыСканирования.РежимОпределенияОриентации = РежимОпределенияОриентацииСканированияДокументов.ПоПервойСтраницеСерии; Страницы = Ждать СредстваМультимедиа.СканироватьДокументыАсинх("Сканирование документа", ПараметрыСканирования); Если Страницы <> Неопределено Тогда Сообщить("Сканирование завершилось. Количество страниц " + Страницы.Количество()); Для каждого Страница Из Страницы Цикл Сообщить("Идентификатор = " + Страница.Идентификатор + "Качество сканирования = " + Страница.ПараметрыКачества.ОбобщенноеКачество); КонецЦикла; Иначе Сообщить("Сканирование завершилось без результата."); КонецЕсли; КонецПроцедуры
Также стоит отметить, что приведенный код не будет работать (и даже компилироваться) на тонком клиенте. В связи с этим, если требуется написать решение, которое будет работать и в тонком клиенте, и на мобильном устройстве, приведенный пример следует заключить в инструкции препроцессора, например таким образом:
&НаКлиенте Асинх Процедура Сканировать() #Если Не ТонкийКлиент Тогда Если Не СредстваМультимедиа.ПоддерживаетсяСканированиеДокументов() Тогда Возврат; КонецЕсли; … #КонецЕсли КонецПроцедуры
28.3.6.19. Работа с NFC
28.3.6.19.1. Общая информация
NFC (Near field communication, связь ближнего поля) ‑ технология беспроводной передачи данных малого радиуса действия, которая даёт возможность обмена данными между устройствами, находящимися на расстоянии около 10 сантиметров. Технология NFC используется в различных случаях:
● для совершения мобильных платежей,
● ускоренного подключения устройств, использующих интерфейс Bluetooth,
● быстрого получения различной информации со специальной метки.
Специальная метка ‑ это очень тонкое устройство, которое поддерживает технологию NFC и позволяет считывать с этого устройства и записывать на него различную информацию. В данной документации такое устройство будет называться NFC-меткой. Объем и формат информации, который может размещаться на NFC-метке, регламентируется форматом NDEF. NDEF (NFC Forum Data Exchange Format) ‑ это сжатый двоичный формат, который представляет собой контейнер (который называется сообщением), содержащий записи различного формата.
Таким образом, мобильная версия системы «1С:Предприятие» поддерживает работу с NFC-метками, на которых могут размещаться данные в формате NDEF. Никакие другие способы и варианты работы с NFC мобильная версия «1С:Предприятие» не поддерживает.
Использования NFC-меток поддерживается:
● ОС Android ‑ версия 4.1 и последующие.
● ОС iOS ‑ версия 13.0 и последующие.
28.3.6.19.2. Программный интерфейс
Для работы с NFC-метками служит свойство глобального контекста Средства``NFC. Вся инфраструктура работы с данными NDEF доступна через свойство Средства``NFC``.Метки``NDEF. В документации, для упрощения, будет опускаться префикс метода Средства``NFC``.Метки``NDEF``.. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Для работы с NFC-метками следует включить функциональность NFC. Если данная функциональность не включена, то собранное мобильное приложение не сможет получить доступ к соответствующим инструментам мобильной операционной системы.
Объект Средства``NFC``.Метки``NDEF представляет собой менеджер меток NFC. С помощью этого менеджера можно выполнить следующие проверки:
● Проверка того, что с помощью данного устройства можно осуществить фоновое сканирование NFC-метки. Это выполняется с помощью метода ПоддерживаетсяФоновоеСканирование().
● Проверка того, что поддерживается активное сканирование NFC-меток. Эта проверка выполняется с помощью метода ПоддерживаетсяАктивноеСканирование().
● Проверка возможности записи информации на NFC-метку выполняется с помощью метода ПоддерживаетсяЗаписьНаМетку().
Таким образом, прикладное решение имеет возможность определить, какими возможностями располагает устройство, на котором оно (приложение) запущено.
Фоновое сканирование меток отличается от активного тем, что во время фонового сканирования (фактически) будут срабатывать только те метки, первой записью сообщения на которых находится запись типа URI. Во время активного сканирования приложение будет пытаться обработать все метки, попадающие в зону действия считывателя мобильного устройства.
Рассмотрим устройство NFC-метки с точки зрения объектной модели системы «1С:Предприятие». Собственно метка представлена объектом типа Метка``NDEF. Объект такого типа не может быть создан самостоятельно, но платформа передаст его прикладному коду в том случае, когда метка будет находиться в зоне действия считывателя устройства. После того, как метка считана платформой, можно получить информацию о том, что с этой меткой можно сделать:
● ПолучитьСообщениеАсинх() ‑ считает с метки сообщение и упакует его в объект Сообщение``NDEF.
● ПоддерживаетсяЗаписьНаМеткуАсинх() ‑ позволяет понять, можно записывать информацию на метку или нельзя.
● ПоддерживаетсяБлокировкаЗаписиНаМеткуАсинх() ‑ позволяет узнать, что метку можно перевести в режим «только чтение».
● Если запись на метку поддерживается, то это действие можно выполнить с помощью метода ЗаписатьСообщениеАсинх().
● Если метка поддерживает блокировку записи, то эту блокировку можно выполнить с помощью метода ЗаблокироватьЗаписьНаМеткуАсинх().
● Свойство Метка``NDEF``.МаксимальныйРазмер позволяет узнать, какой максимальный объем данных можно записать на метку.
После того, как содержимое метки считано, можно получить доступ к данным, которые записаны на этой метке. Объект типа Сообщение``NDEF содержит два свойства. Первое свойство описывает текущий размер данных в сообщении: Сообщение``NDEF``.Размер. Записи сообщения доступны через свойство Сообщение``NDEF``.Записи. В этом свойстве расположен фиксированный массив объектов …Запись``NDEF, которые описывают данные метки:
|
Объект «1С:Предприятия» |
Описание |
|
|
Предназначен для описания пустых записей NDEF. Создать такой объект в системе «1С:Предприятие» невозможно. |
|
|
Предназначен для размещении на NFC-метке текстовой информации. Объект можно создать в системе «1С:Предприятие». |
|
|
Предназначен для размещении на метке какого-либо URI. Объект можно создать в системе «1С:Предприятие». Если такая запись является первой записью сообщения, то при сканировании такой метки устройством имеется возможность выполнить запуск какого-либо приложения с помощью глубинной ссылки. Запускаемым приложением может быть и мобильное приложение системы «1С:Предприятие». |
|
|
Предназначен для размещения на NFC-метке каких-либо медиа данных: картинки или аудио-файла. Следует помнить об ограничении размера информации, которая может быть записана на метку. Объект можно создать в системе «1С:Предприятие». |
|
|
Предназначен
для размещения на NFC-метке данных
в формате, которые нельзя записать с помощью записей |
|
|
Предназначен для описания записи сообщения, формат которой не распознан. Создать такой объект в системе «1С:Предприятие» невозможно. |
Понимая, как устроены данные на NFC-метки, разберемся, как работать с этими метками.
Если мобильное устройство поддерживает активное сканирование, то можно использовать метод менеджера меток ВключитьАктивноеСканирование(). В этот метод передается заголовок окна, которое будет открыто на устройстве и ссылку на метод, который будет обрабатывать соединение с меткой. После того, как мобильное устройство установит соединение с ближайшей NFC-меткой, форма сканирования будет закрыта, а управление будет передано в обработчик. NFC-метка, с которой установлено соединение, будет передана в обработчик через формальный параметр Метка. Если значением параметра Метка является значение Неопределено, то это означает, что форма сканирования была закрыта до того, как установлено соединение с какой-либо NFC-меткой.
Все дальнейшие действия с NFC-меткой необходимо выполнять уже из обработчика. Также следует понимать, что в том случае, если на NFC-метку планируется выполнять запись, то NFC-метка все время должна находиться вблизи мобильного устройства (устройство не должно терять соединение с NFC-меткой).
Пример использования активного сканирования NFC-метки:
&НаКлиенте Процедура СканироватьМеткуNDEF(Команда) МенеджерМеток = СредстваNFC.МеткиNDEF; Если МенеджерМеток.ПоддерживаетсяАктивноеСканирование() Тогда ОбработкаСканированияМетки = Новый ОписаниеОповещения("ПриЧтенииМетки", ЭтотОбъект); МенеджерМеток.ВключитьАктивноеСканирование("Поднесите метку к устройству", ОбработкаСканированияМетки); Иначе Сообщить("Активное сканирование не поддерживается"); КонецЕсли; КонецПроцедуры &НаКлиенте Асинх Функция ПриЧтенииМетки(Метка, ДополнительныеДанные) Экспорт Если Метка = Неопределенно Тогда Возврат; КонецЕсли; Попытка СообщениеNFC = Ждать Метка.ПолучитьСообщениеАсинх(); Исключение Сообщить("Ошибка чтения: " + ИнформацияОбОшибке().Описание); КонецПопытки; КонецФункции
При выполнении пассивного сканирования метки следует понимать следующие особенности:
● Пассивное сканирование работает аналогично использованию глубинного связывания (переходу по URL, который обрабатывается мобильным приложением).
● Пассивное сканирование приведет к какому-либо действию только в том случае, если первой записью в сообщении NFC-метки будет запись URI``Запись``NDEF.
Для того, чтобы выполнить запись на NFC-метку, необходимо:
1. Подготовить записываемые данные.
2. Активировать активное сканирование.
3. Поднести к мобильному устройству метку, которую требуется записать.
4. В обработчике чтения метки проверить возможность записи и, если это возможно ‑ выполнить запись подготовленных данных.
5. Во время записи NFC-метку не следует удалять от мобильного устройства. Если это сделать, то между меткой и устройством пропадет соединение и запись не будет выполнена.
Пример записи данных на NFC-метку:
&НаКлиенте Процедура ЗаписьМеткиNDEF(Команда) МенеджерМеток = СредстваNFC.МеткиNDEF; Если МенеджерМеток.ПоддерживаетсяЗаписьНаМетку()Тогда ОповещениеОПоявленииМетки = Новый ОписаниеОповещения("ПриСканированииМетки", ЭтотОбъект); МенеджерМеток.ВключитьАктивноеСканирование("Поднесите метку к устройству", ОповещениеОПоявленииМетки); Иначе Сообщить("Запись меток не поддерживается"); КонецЕсли; КонецПроцедуры &НаКлиенте Асинх Процедура ПриСканированииМетки(Метка, ДополнительныеДанные) Экспорт Если Метка = Неопределенно Тогда Возврат; КонецЕсли; РазмерСкидки = "10"; URLОбработки = "https://example.com/mycafe/coupone"; Записи = Новый Массив; Записи.Добавить(Новый URIЗаписьNDEF(URLОбработки)); Записи.Добавить(Новый ТекстоваяЗаписьNDEF(РазмерСкидки,)); Сообщение = Новый СообщениеNDEF(Новый ФиксированныйМассив(Записи)); ЗаписьПоддерживается = Ждать Метка.ПоддерживаетсяЗаписьНаМеткуАсинх(); Если ЗаписьПоддерживается Тогда Попытка Ждать Метка.ЗаписатьСообщениеАсинх(Сообщение); Исключение Сообщить("Ошибка записи: " + ИнформацияОбОшибке().Описание); КонецПопытки; Иначе Сообщить("Запись на данную метку не поддерживается"); КонецЕсли; КонецПроцедуры
В данном примере на NFC-метку выполняется запись скидки 10% для предъявителя NFC-метки. NFC-метка будет обрабатываться мобильным приложением, которое перехватывает URL https://``example.``com/``mycafe/``coupone.
Смотри также:
● Используемые функциональности мобильного приложения (см. здесь).
● Глубинное связывание (см. здесь).
28.3.6.19.3. Настройка глубинного связывания с помощью NFC
Настройка использования NFC-метки в качестве «источника» глубинных ссылок состоит из нескольких этапов:
1. Необходимо разработать формат глубинной ссылки и выбрать схему, которая будет использоваться для формирования URL. В данном случае будут действовать все особенности работы с глубинными ссылками.
2. Реализовать в прикладном решении (конфигурации) код обработки перехода по глубинной ссылке.
3. Подготовить и собрать мобильное приложение, которое будет обрабатывать глубинные ссылки.
4. Сформировать одну или несколько NFC-меток с нужными сообщениями в качестве полезной нагрузки.
5. Установить приложение на устройство и проверить работоспособность.
В обработчике перехода по навигационной ссылке (ОбработкаПереходаПоНавигационнойСсылке) можно определить, что переход произошел в результате сканирования NFC-метки с помощью содержимого формального параметра ДанныеПереходаПоНавигационнойСсылке. Если значение этого параметра не равно Неопределено, то следует проверить в этих данных наличие значения по ключу MessageNDEF. Для этого можно воспользоваться методом Получить() типа ДополнительныеДанныеЗапускаПриложенияМобильногоУстройства (это тип значения параметра). Если метод вернул значение типа ЭлементДополнительныхДанныхЗапускаПриложенияМобильногоУстройства, то переход по навигационной ссылке инициирован NFC-меткой. В этом случае свойство Значение этого типа будет содержать объект типа Сообщение``NDEF, которое заполнено данными прочитанной NFC-метки.
Пример определения, что переход по навигационной ссылке вызван сканированием NFC-метки:
Процедура ОбработкаПереходаПоНавигационнойСсылке(ДанныеПереходаПоНавигационнойСсылке, СтандартнаяОбработка) ДопДанные = ДанныеПереходаПоНавигационнойСсыл-ке.ДополнительныеДанныеПереходаВМобильноеПриложение; Если ДопДанные <> Неопределено Тогда ЭлементДопДанных = ДопДанные.Получить("MessageNDEF"); Если ЭлементДопДанных <> Неопределено Тогда // Переход по ссылке инициирован NFC-меткой СообщениеNDEF = ЭлементДопДанных.Значение; КонецЕсли; КонецЕсли; КонецПроцедуры
Смотри также:
● Глубинное связывание (см. здесь).
28.3.6.20. Возможность обмениваться файлами через стандартные интерфейсы мобильной операционной системы
28.3.6.20.1. Общая информация
Мобильные операционные системы предоставляют возможность делиться различными данными (текст, файлы) между приложениями. Чаще всего делятся файлами, которые созданы в том же приложении, которое ими (файлами) делится. Для выполнения этих операций предлагается стандартный программный интерфейс (предоставляемый мобильной операционной системой), а элементы управления, как правило, одинаково выглядят во всех приложениях и удобно размещены в пользовательских интерфейсах. Таким образом, обмен файлами через интерфейсы операционной системы ‑ это наиболее простой и удобный (для пользователя) способ передать файлы одного приложения для обработки в другое приложение. Это механизм достаточно универсален и позволяет передать данные в прикладное решение сразу из интерфейса другого приложения.
Обмен файлов включает две стороны: то приложение, из которого пользователь начинает обмен файлами и то приложение, которое получает выбранные файлы. Система «1С:Предприятие» может как получать файлы для обработки, так и передавать файлы в другие приложения.
28.3.6.20.2. Передача файлов между приложениями
Система «1С:Предприятие» позволяет поделиться данными следующего типа: Строка, ДанныеМультимедиа и Картинка, а также массивами значений этих типов. Возможность обменяться файлами с другими приложениями доступна через свойство глобального контекста СредстваПередачиДанныхНаУстройстве. В документации, для упрощения, будет опускаться префикс метода СредстваПередачиДанныхНаУстройстве.. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
В первую очередь необходимо проверить, что возможность делиться файлами доступна в текущей мобильной операционной системе. Для этого предназначен метод ПоддерживаетсяВозможностьПоделитьсяДанными(). Если метод вернул значение Истина, то текущая мобильная ОС поддерживает возможность делиться данными.
Следующим шагом следует определить, какие данные и в каком виде будут передаваться в другие приложения:
● Значения типа Строка или Картинка могут быть переданы непосредственно, без упаковки в промежуточные объекты.
● Для того, чтобы передать какой-либо файл, его следует «упаковать» в объект ДанныеМультимедиа. Аналогично могут быть переданы произвольные двоичные данные. Однако, в случае произвольных двоичных данных, может сложиться ситуация, что эти данные не может принять ни одно приложение на вашем устройстве.
После того, как данные для передачи подготовлены, следует использовать метод ПоделитьсяДанными() для запуска процесса передачи. В качестве параметров будет необходимо передать:
● Параметр Данные: значение типа Строка, Картинка или ДанныеМультимедиа. Также возможно передать массив из этих значений перечисленных типов. Это будут те данные, которые вы хотите передать в другое приложение.
● Параметр ТипСодержимогоДляВыбораПриложения: в том случае, если приложение работает под управлением ОС Android, значение, указанное в данном параметре, позволит упростить выбор приложений, которые могут принять ваши данные. В качестве значения данного параметра следует указать MIME-тип передаваемых данных. Если параметр не указан ‑ платформа «1С:Предприятие» попытается определить MIME-тип самостоятельно.
● Параметр Заголовок: при работе под управлением ОС Android, значение данного параметра определяет заголовок диалога выбора приложения, которое получит передаваемые данные.
Метод ПоделитьсяДанными() возвращает значение Истина, если операция выполнена успешно и Ложь в противном случае.
28.3.6.20.3. Обработка входящих запросов «Поделиться»
Общая информация
Настройка обработки входящих запросов «Поделиться» выполняется в два шага:
1. Для приложения включается данная возможность и указываются типы (расширения) файлов, которые может получать мобильное приложение. Имеется возможность обрабатывать как конкретные типы файлов, так и все типы файлов, которыми могу делиться пользователи. Настройка выполняется с помощью диалогов Используемая функциональность мобильного приложения (разрешения, необходимые для работы механизма) и диалога Типы файлов (указание типов файлов, которые обрабатывает данная конфигурация).
2. Выполняется доработка конфигурации для обеспечения работы с данными, которые будут получены в результате операции обмена.
Общая схема работы выглядит следующим образом (мобильное приложение корректно настроено, собрано и установлено на мобильном устройстве):
1. Когда пользователь хочет поделиться одним или несколькими файлами, то мобильная операционная система определяет список приложений, которые готовы получить данные, выбранные пользователем. Настройка в прикладном решении нужна для того, чтобы мобильная операционная система определила, что наше приложение умеет работать с определенным типом файлов.
2. При выборе нашего мобильного приложения, дальнейшее поведение зависит от того, какое количество информационных баз создано в приложении:
● Если в приложении одна информационная база, то данные на обработку будут переданы туда.
● Если информационных баз несколько, то используется следующий алгоритм:
● Если пользователь в списке информационных баз и используемый тип файла поддерживают несколько информационных баз ‑ пользователю будет предложено выбрать нужную информационную базу.
● Если используемый тип файла поддерживает только одна информационная база, то управление будет сразу передано в эту базу.
● Если используемый тип файла не поддерживает ни одна из информационных баз, то пользователь получит сообщение об ошибке.
● Если текущий пользователь аутентифицирован в информационной базе, которая поддерживает используемый тип файлов, то файлы будут переданы на обработку в конфигурацию информационной базы.
● Если пользователь аутентифицирован в информационной базе, которая не поддерживает используемый тип данных, то ему будет предложено сменить информационную базу.
3. В конфигурации, которая получит данные пользователя, должен быть сформирован список команд, которыми можно обработать данные. В общем случае не имеет значения, кто будет формировать список команд: мобильная версия или разработчик (с помощью соответствующего обработчика события).
4. В конфигурации будет выполнен программный код, который обрабатывает полученные данные.
Необходимо понимать, что мобильная версия предоставляет возможность обрабатывать не только какие-то конкретные типы файлов, для чего следует включить только функциональность Входящие запросы "Поделиться". Есть возможность «подписаться» на обработку любых файлов (с любыми расширениями), для чего необходимо дополнительно включить функциональность Обработка всех типов входящих запросов "Поделиться". Во втором случае (включены обе функциональности) можно не указывать список обрабатываемых расширений файлов: собранное мобильное приложение будет «настроено» на обработку всех расширений. Следует учитывать, что мобильная версия для разработчика «настроена» на обработку всех расширений. Т. е. мобильная версия для разработчика может получать файлы любого типа.
Программный интерфейс механизма
Внутри приложения, с которым поделились данными, пользователь может выбрать, что с этими данными дальше делать. Список команд формируется в два этапа. На первом этапе мобильная версия анализирует входящие данные и формирует «свой» список команд. Разработчик может переопределить этот список команд в обработчике события ОбработкаФормированияКомандВходящегоЗапросаПоделиться. Если обработчик события ОбработкаФормированияКомандВходящегоЗапросаПоделиться отсутствует, значит будет использоваться список команд, сформированный по умолчанию. Сформированный список команд будет отображен пользователю в виде меню, в котором будет необходимо выбрать необходимое действие с входящими данными. Если после вызова обработчика в списке команд остается всего одна ‑ меню не показывается и данные сразу передаются на обработку.
Если разработчику необходимо модифицировать список команд, то ему следует определить обработчик события ОбработкаФормированияКомандВходящегоЗапросаПоделиться в модуле приложения. Данные, которыми делится пользователь, будут находиться в параметре ДанныеЗапросаПоделиться этого обработчика. Они могут быть полезными для определения, какие команды следует предоставить пользователю. Параметр Команды содержит список команд, которые уже сформировала мобильная версия. Каждая команда описывается с помощью объекта ОписаниеКомандыВходящегоЗапросаПоделиться. Формирование команды, в общем случае, выглядит следующим образом:
#Если МобильноеПриложениеКлиент Или МобильныйКлиент Тогда Процедура ОбработкаФормированияКомандВходящегоЗапросаПоделиться(ДанныеЗапросаПоделиться, Команды) ОбработчикКоманды = Новый ОписаниеОповещения("ОбработкаОбменаФайлами", СервисныеФункцииКлиент, ДанныеЗапросаПоделиться); Команда = Новый ОписаниеКомандыВходящегоЗапросаПоделиться(ОбработчикКоманды, "Обработать данные"); Команды.Добавить(Команда); КонецПроцедуры #КонецЕсли
В данном примере будет создана команда с представлением Обработать данные, при выборе которой будет вызван метод ОбработкаОбменаФайлами() клиентского общего модуля СервисныеФункцииКлиент. В эту процедуру и будут переданы полученные данные. Инструкции препроцессора ограничивают компиляцию текста обработчика только мобильной версией системы. Команда будет добавлена к тем командам, которые сформировала мобильная версия перед вызовом обработчика.
Объект ОписаниеКомандыВходящегоЗапросаПоделиться позволяет указать следующие параметры:
● Доступность. Определяет доступность пункта меню.
● Картинка. Картинка, которая будет отображаться в меню для этой команды.
● Команда. Содержит команду, которая будет предложена пользователю. Может быть значением одного из следующих типов:
● СтандартнаяКомандаВходящегоЗапросаПоделиться ‑ стандартная команда, реализация которой находится в мобильной версии.
● ОписаниеОповещения ‑ обработчик команды написан на встроенном языке. Обработчик должен иметь следующие параметры:
● Данные ‑ значение типа ДанныеЗапросаПоделиться (данные, которыми поделился пользователь).
● ДополнительныеПараметры ‑ дополнительные данные, которые переданы при создании описания оповещения (параметр конструктора объекта ОписаниеОповещения).
● Неопределенно ‑ разделитель в меню.
● Представление. Наименование команды для отображения в меню.
Мобильная версия предоставляет несколько стандартных команд, которые перечислены в системном перечислении СтандартнаяКомандаВходящегоЗапросаПоделиться. Далее приведены описания этих команд. Примечание «условие наличия» описывает, в каком случае команда будет присутствовать в списке команд, сформированных мобильной версией по умолчанию:
|
Значение |
Описание |
|
|
Представление: Условие наличия: если делятся текстовыми данными. |
|
|
Представление: Условие наличия: если подключена система взаимодействия. |
|
|
Представление: Условие наличия: если файл в единственном числе и является файлом, созданным системой «1С:Предприятие». |
|
|
Представление: Условие наличия: если пользователь делится файлами. |
Обработчик команды можно написать, основываясь на следующем тестовом обработчике:
Процедура ОбработкаВыполненияСвоейКоманды(ДанныеЗапроса) Экспорт Текст = ""; Если ДанныеЗапроса.Файлы.Количество() > 0 Тогда Текст = Текст + "Файлы:" + Символы.ПС; Для каждого Файл из ДанныеЗапроса.Файлы цикл Текст = Текст + Файл + Символы.ПС; КонецЦикла; Иначе Текст = Текст + "Файлами не делились" + Символы.ПС; КонецЕсли; Если ДанныеЗапроса.Строки.Количество() > 0 Тогда Текст = Текст + "Строки:" + Символы.ПС; Для каждого Строка из ДанныеЗапроса.Строки цикл Текст = Текст + Строка + Символы.ПС; конеццикла; Иначе Текст = Текст + "Строками не делились" + Символы.ПС; КонецЕсли; Текст = Текст + "Вариант обработки: " + ДанныеЗапроса.ВариантОбработки + Символы.ПС; Текст = Текст + "Запуск: " + ДанныеЗапроса.Запуск + Символы.ПС; Сообщить(Текст); КонецПроцедуры
Данные, которыми пользователь поделился с мобильным приложением, доступны в прикладном решении с помощью объекта ДанныеЗапросаПоделиться. Данный объект содержит следующие свойства:
|
Свойство |
Описание |
|
|
Данное свойство указывает, каким образом
данные переданы в приложение. Данное свойство содержит значение типа ●
●
|
|
|
Данное свойство равно значению |
|
|
При работе под управлением ОС Android данный параметр содержит дополнительные данные (типа |
|
|
Данное свойство содержит массив строк, если с нашим приложением поделились некоторой текстовой информацией. |
|
|
Данное свойство содержит массив с полными путями к файлам, которыми поделились с нашим мобильным приложением. |
Также стоит отметить, что если прикладное решение запущено в результате того, что с ним поделились какими-либо данными, то мобильная версия заполнит свойство глобального контекста ДанныеЗапросаПоделитьсяЗапуска. В этом случае свойство ДанныеЗапросаПоделитьсяЗапуска.ВыполненЗапуск будет установлено в значение Истина. Во всех остальных случаях, свойство ДанныеЗапросаПоделитьсяЗапуска будет содержать значение Неопределено.
Редактирование типов входящих файлов
Для того, чтобы указать, какие файлы будет обрабатывать мобильное приложение при обслуживании входящих запросов «Поделиться», следует воспользоваться диалогом Допустимые типы входящих запросов "Поделиться".
Рис. 536. Редактор допустимых типов входящих запросов
В диалоге необходимо (при необходимости) указать следующие данные для каждого из обрабатываемых типов файлов:
|
Имя колонки |
Описание |
|
|
MIME-тип, соответствующий обрабатываемому
файлу, например |
|
|
Поддерживаемый UTI (Uniform Type Identifier, универсальный идентификатор типа), например |
|
|
Расширение файла, содержащего данные
требуемого типа, например, |
|
|
●
Указывает, каким образом приложение может
получать файлы с расширением ●
●
Если файл с каким-то расширением должен обрабатываться мобильным приложением и через файловый менеджер, и через специальный интерфейс ОС, то в данном диалоге следует указать две строки: одну для просмотра, другую для редактирования. |
|
|
Флаг указывает, что объявлен специальный тип файла, неизвестный операционной системе. Такой флаг следует указывать для всех файлов, которые создает сама мобильная платформа (MXL, GRS и т. д.), а также для всех расширений файлов, которые создаются другими приложениями и не являются стандартными. |
В примере на рис. 536 указаны три строки (описаны файлы трех типов). Мобильное приложение с такими настройками сможет обрабатывать:
● mxl-файлы, открываемые из файлового менеджера мобильного устройства.
● grs-файлы, также открываемые из файлового менеджера мобильного устройства.
● xls-файлы, которыми можно делиться из других приложений (например, собственно из Microsoft Excel, работающего под управлением той или иной мобильной операционной системы).
28.3.6.21. Резервное копирование средствами мобильной операционной системы
Мобильные операционные системы предоставляют встроенные инструменты резервного копирования данных приложений, работающих на мобильных устройствах. В зависимости от используемой операционной системы, для резервного копирования используются следующие сервисы:
● ОС Android: сервис Google Drive или специализированные программы резервного копирования, работающие на персональном компьютере.
● ОС iOS: сервис iCloud или резервное копирование с использованием приложения iTunes.
● ОС Windows: сервис Microsoft OneDrive.
Для того чтобы на мобильном устройстве выполнялось резервное копирование средствами операционной системы, необходимо установить разрешение Резервное копирование средствами ОС в списке свойств Требуемые разрешения мобильного приложения. Если для приложения требуется выключить возможность резервного копирования средствами мобильной операционной системы ‑ разрешение Резервное копирование средствами ОС следует выключить.
Никаких дополнительных действий на устройстве выполнять не требуется. Данное разрешение оказывает воздействие только на мобильное приложение, которое собирается с использованием сборщика мобильных приложений.
28.3.6.22. Прочие возможности мобильного устройства
28.3.6.22.1. Использование фонарика
При использовании мобильного приложения может возникнуть необходимость осветить какой-либо объект. В том случае, если мобильное устройство, используемое в этот момент, имеет вспышку основной камеры, то можно использовать эту вспышку в роли фонарика.
Для проверки, что эта возможность поддерживается устройством, служит метод СредстваУстройства.ПоддерживаетсяФонарик(). Если метод вернул Истина, то можно включать фонарик с помощью вызова метода СредстваУстройства.ВключитьФонарик(Истина). Выключение фонарика выполняется с помощью вызова метода СредстваУстройства.ВключитьФонарик(Ложь).
28.3.6.22.2. Установка приложений
Примечание. Только для мобильных приложений, работающих под управлением ОС Android.
Мобильное приложение может устанавливать на мобильное устройство различные сторонние приложения, необходимые для работы собранного мобильного приложения. Эта возможность может противоречить требованиям безопасности, которые предъявляются к мобильным приложениям.
Управление возможностью установки сторонних приложений осуществляется с помощью разрешения Установка приложений. Данное разрешение оказывает воздействие только на мобильное приложение, которое собирается с использованием сборщика мобильных приложений.
28.3.6.22.3. Спящий режим
Во время эксплуатации мобильного приложения может потребоваться запретить переход мобильного устройства в спящий режим. Например, когда выполняется длительная загрузка данных в мобильном клиенте или в том случае, когда пользователь использует сканер штрихкодов мобильного устройства, но пауза между сканированиями превышает период отключения экрана (и перехода в спящий режим) мобильного устройства.
Для управления переходом в спящий режим у прикладного разработчика есть следующие методы:
● Для того чтобы узнать, может устройство в данный момент переходить в спящий режим или нет, предназначен метод глобального контекста ПолучитьЗапретЗасыпанияКомпьютера().
● Для того чтобы установить (или запретить) возможность перехода в спящий режим, необходимо использовать метод глобального контекста УстановитьЗапретЗасыпанияКомпьютера().
При установке запрета на засыпание мобильного устройства следует понимать, что такой запрет отрицательно сказывается на продолжительности работы мобильного устройства. Запрет спящего режима следует устанавливать только в тех случаях, когда это действительно необходимо. Не рекомендуется устанавливать такой режим «на всякий случай». Также следует понимать границы применимости установки запрета засыпания:
● При закрытии приложения запрет отключается.
● Если пользователь сам переводит мобильное устройство в спящий режим, например, с помощью кнопки питания, то мобильное приложение также засыпает, но при повторной активации приложения ‑ запрет восстанавливается.
● Если пользователь переходит в другое приложение, то запрет отключается и мобильное устройство может заснуть, включая и мобильное приложение на платформе «1С:Предприятие». При переходе обратно в мобильное приложение ‑ запрет восстанавливается.
Таким образом, запрет на засыпание мобильного устройства действует только в тогда, когда мобильное приложение на платформе «1С:Предприятие», откуда был установлен запрет засыпания, является активным приложением.
Мобильная версия системы «1С:Предприятие» дает возможность отслеживать переходы в спящий режим и обратно. Для этого предназначены обработчики событий модуля приложения мобильной версии ПриЗасыпанииКлиентскогоПриложения() и ПриПробужденииКлиентскогоПриложения(). Как следует из названий, первое событие сработает перед тем, как мобильное приложение перейдет в спящий режим, а второе ‑ сразу после выхода мобильного приложения из спящего режима. При засыпании мобильного приложения не рекомендуется выполнять какие-то длительные операции. При выходе приложения из спящего режима можно выполнять различные служебные операции, например, обмен данными с центральной информационной базой, восстанавливать какие-то обработчики, которые могли быть отключены при переходе в спящий режим и т. д.
28.3.6.22.4. Добавление оценки приложения
Если мобильное приложение распространяется через магазин приложений, то количество положительных оценок и отзывов повышает рейтинг приложения в магазине, что напрямую сказывается на количество скачиваний приложения. Пользователь может самостоятельно зайти в магазин и оставить отзыв о приложении. Но такой вариант, скорее всего, будет применим в том случае, если пользователь не доволен приложением. Отзыв в таком случае, скорее всего, будет отрицательным.
Другим вариантом может быть использование метода ПоказатьВводОценкиПриложения(). Этот метод открывает системный диалог оценки приложения. Рекомендуется использовать следующий подход для получения отзыва пользователя о мобильном приложении:
● Пользователь активно использует приложение длительное время (например, 3 месяца).
● После того, как установленный период истек, можно предположить, что пользователю нравится приложение. Ведь он (пользователь) его до сих пор не удалил.
● В этом случае можно открыть в интерфейсе команду, с призывом оставить оценку приложению, нажатие на которую вызовет системный диалог оценки. Как было сказано выше, этот диалог отображается с помощью метода ПоказатьВводОценкиПриложения().
● Приложение не должно навязывать пользователю написание положительного отзыва или предлагать написание отзыва.
Не рекомендуется запрашивать у пользователя слишком много отзывов. При слишком частом вызове диалога может не отображаться. Рекомендуется отображать диалог не чаще 3 раз в год.
28.3.7. Внешние компоненты
В мобильном приложении допускается использовать только компоненты, разработанные по технологии Native API, которые могут быть как отдельными файлами, так и упакованными в zip-архивы особого вида.
Во внешних компонентах, разработанных для использования совместно с мобильным приложением, запрещается использовать работу с пользовательским интерфейсом.
Внешняя компонента должна быть скомпилирована с учетом всех процессоров, архитектуру и операционных систем, используемых на мобильных устройствах. Рекомендуется функциональные модули внешней компоненты реализовывать платформонезависимым образом.
Если внешняя компонента использует дополнительные модули, это рекомендуется указывать в документации к компоненте. Используемые не системные библиотеки должны быть статически включены в результирующий файл внешней компоненты.
Расположение внешних компонент зависит от используемого клиентского приложения и мобильной операционной системы:
● ОС Android:
● Мобильное приложение для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована отлаживаемая конфигурация.
● Мобильное приложение для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● Мобильный клиент:
● Мобильный клиент для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована информационная база.
● Мобильный клиент для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения, однако могут быть загружены через веб-сервер, на котором опубликована информационная база в случае, если в информационную базу загружена новая версия внешней компоненты.
● ОС iOS:
● Мобильное приложение:
● Мобильное приложение для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована отлаживаемая конфигурация.
● Мобильное приложение для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● Мобильный клиент:
● Мобильный клиент для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована информационная база.
● Мобильный клиент для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● ОС Windows:
● Внешние компоненты включаются в состав собранного мобильного приложения в любом случае.
При работе с мобильным клиентом следует учитывать следующую особенность: если мобильный клиент (в варианте для магазина приложений) одновременно позволяет работать с информационными базами, которые используют разные версии одной и той же внешней компоненты, это может привести к возникновению проблемой. Проблема связана с тем, что собранное мобильное приложение может содержать внешние компоненты только одной версии (для одной внешней компоненты). В связи с этим рекомендуется разрабатывать внешние компоненты с безусловным соблюдением совместимости снизу-вверх, так, чтобы любая внешняя компонента версии N+1 поддерживала работоспособность с прикладным решением, которое ожидает только версию внешней компоненты версии N. В то же время, работа под управлением ОС Android не приведет к таким проблемам, т. к. мобильный клиент автоматически загрузит ту версию внешней компоненты, которая используется в конкретной информационной базе.
Отладка прикладного решения, с применением внешних компонент, различается для разных мобильных ОС:
● Для ОС Android ‑ отладка возможна с использованием мобильной версии «1С:Предприятия» для разработчика, путем публикации прикладного решения (подробнее см. здесь) или информационной базы на веб-сервере или при работе через Android Debug Bridge (подробнее см. здесь).
● Для ОС iOS ‑ отладка возможна с использованием мобильной версии «1С:Предприятия» для разработчика, путем публикации прикладного решения (подробнее см. здесь) или информационной базы на веб-сервере.
● Для ОС Windows ‑ допустимо использование только собранного мобильного приложения (с помощью сборщика приложений для мобильных устройств).
Для того чтобы использовать внешнюю компоненту с мобильным приложением, необходимо загрузить ее в конфигурацию, в макет с типом Внешняя компонента (см. здесь). Кроме того, если приложение будет работать только под управлением ОС Android, внешние компоненты можно загружать из макета с типом Двоичные данные, реквизита справочника, временного хранилища и объекта файловой системы.
Для того чтобы собрать мобильное приложение с включением внешних компонент, необходимо выгружать конфигурацию в виде zip-архива (1``cema.``zip). Если конфигурация содержит внешние компоненты, то при выполнении команды Главное меню``‑ Конфигурация``‑ Мобильное приложение``‑ Записать в файл или Главное меню``‑ Конфигурация``‑ Мобильный клиент``‑ Записать в файл, будет автоматически предложен именно такой вариант сохранения. Сборщик приложений для мобильных устройств автоматически будет учитывать наличие внешних компонент при загрузке мобильной конфигурации и последующей сборке мобильного приложения.
28.3.8. Запуск мобильного приложения из внешних источников
28.3.8.1. Общая информация
Мобильное приложение может быть запущено различными способами: непосредственно пользователем, с помощью PUSH-уведомления, из другого мобильного приложения, с использованием некоторой ссылки и т. д. В данном разделе мы будем разбирать возможность вызова мобильного приложения «1С:Предприятия» из другого мобильного приложения или с использованием некоторого URL. Эта возможность может потребоваться для решения различных задач, например:
● Возможность вызова конкретной функции мобильного приложения из другого приложения.
● Возможность использовать некоторый URL для того, чтобы открыть мобильное приложение на конкретном объекте или функции.
● Другие, аналогичные, возможности.
Для реализации возможности вызова мобильного приложения из другого приложения, используются глубинные ссылки (deep linking) и механизм глубинного связывания. Глубинная ссылка ‑ это URL, который указывает на какой-то ресурс на сайте или в приложении. А глубинное связывание ‑ это механизм, который позволит мобильной операционной системе связать URL и мобильное приложение, установленное на устройстве.
Глубинная ссылка может быть сформирована двумя очень похожими способами:
● С использованием собственной схемы.
● С использованием схемы HTTP(s).
Каждый из этих способов имеет свои плюсы и минусы, которые мы сейчас рассмотрим.
Использование собственной схемы, например, схемы example``://, это самый простой способ вызова одного приложения из другого. В этом случае URL для вызова будет иметь вид example``://``Comand``?``Params. Реализация собственной схемы имеет некоторые недостатки: URL для выполнения какого-то действия должен использовать или из программного кода другого приложения или из HTML-страницы (элементы типа <``a``>). Причиной является тот факт, что данный URL, скорее всего, не будет распознан мобильной операционной системой как ссылка, которую может нажать пользователь. Следовательно, интерактивно применить URL с собственной схемой, скорее всего, будет невозможно. Еще одним недостатком собственной схемы является то, что появление на мобильном устройстве еще одного мобильного приложения, обрабатывающего эту же схему, приведет, в общем случае, к неопределенному поведению. Т. е. в ОС Android поведение можно описать, а в ОС iOS ‑ нет. По этой причине настоятельно не рекомендуется перехватывать схему e``1``c``://. Наличие на мобильном устройстве хотя-бы двух приложений, обрабатывающих эту схему, может привести к непредсказуемым последствиям.
Способ с использованием схемы HTTP(s) решает часть перечисленных проблем, но одновременно более сложен в реализации. Этот способ предполагает, что URL глубинной ссылки принадлежит схемам http``:// или https``://. При этом переход по глубинной ссылке, с помощью веб-браузера, приведет к выполнению реального действия на реальном сайте. Пользователь, который использует такую глубинную ссылку на мобильном устройстве, в любом случае получит желаемое:
● Если на устройстве нет мобильного приложения ‑ откроется веб-клиент в веб-браузере мобильного устройства.
● Если на устройстве есть мобильное приложение ‑ будет открыто мобильное приложение, которое и выполнит действие, указанное в глубинной ссылке.
Глубинная ссылка в схеме HTTP(s) адекватно опознается всеми встроенными инструментами мобильной операционной системы. Это значит, что интерактивное использование такой глубинной ссылки не будет вызывать проблем у пользователя. Причем возможность использования не зависит от того, каким образом ссылка доставлена на мобильное устройство: SMS-сообщение, любой мессенджер и т. д.
Использование глубинной ссылки в схеме HTTPS возможно только с использованием реального веб-сайта, доступ к которому должен быть у разработчика мобильного приложения (или, более глобально, всей схемы интеграции приложения и сайта). Доступ к сайту необходим для того, чтобы разместить в определенном каталоге сайта (из глубинной ссылки) определенные файлы, которые необходимы для того, чтобы мобильная операционная система убедилась в том, что мобильное приложение правомочно обрабатывать ссылки, ведущие на сайт. В противном случае мобильное приложение не будет вызвано по глубинной ссылке.
Все мобильные операционные системы предоставляют встроенные средства определения того, какое приложение должно быть вызвано в том случае, когда глубинную ссылку в схеме HTTP(s) использует несколько приложений. В этом случае для определения приложения используется значение хоста ссылки и, иногда, путь на этом хосте.
Кратко обобщим возможности вызова мобильного приложения из внешних источников:
● Для вызова конкретной функции приложения (или сайта) предназначены глубинные ссылки.
● Глубинные ссылки могут включать собственную схему автора приложения или схему HTTP(s).
● Глубинные ссылки с собственной схемой просты в разработке, но в некоторых случаях приводят к неопределенному поведению. Такие глубинные ссылки, в основном. предназначены для взаимодействия нескольких приложений между собой. Настоятельно не рекомендуется подписывать мобильное приложение на работу со схемой E1C.
● Глубинные ссылки со схемами HTTP или HTTPS более сложны в разработке, но более понятны и просты для использования. Таким глубинные ссылки более приспособлены для использования человеком, но также могут использоваться и для межпрограммного взаимодействия.
● Любая схема использования глубинных ссылок доступна только при использовании собранного мобильного приложения. Мобильная версия разработчика не позволяет использовать глубинные ссылки.
● Для обработки нажатия на глубинную ссылку в прикладном решении необходимо реализовать обработчик события.
В данном разделе будет рассмотрено, что необходимо сделать разработчику, чтобы реализовать возможность вызова мобильного приложения из внешних источников.
28.3.8.2. Использование механизма
Для реализации вызова мобильного приложения из внешнего источника необходимы следующие составные части:
1. Глубинная ссылка, с помощью которой будет вызываться мобильное приложение. Если мы хотим, чтобы команда могла как обрабатывалась мобильным приложением, так и служить адресом для использования в веб-клиенте, то желательно, чтобы URL представлял собой внешнюю ссылку информационной базы, опубликованной на веб-сервере. В этом случае в качестве схемой используемой ссылки могут быть только схемы HTTPS или HTTP. В то же время, мы можем придумать нашу собственную схему, на которую будет реагировать только наше мобильное приложение. Важно, что мы будет иметь некоторую команду, которая будет обрабатываться мобильным приложением.
2. Прикладное решение, которое будет выполнять действие, которое закодировано в команде. Для этого в прикладном решении необходимо реализовать обработчик события ОбработкаПереходаПоНавигационнойСсылке(). Этот обработчик расположен в модуле клиентского приложения и в качестве параметров получает полную информацию о том URL, нажатие на который вызвало переход в наше мобильное приложение. Стоит также отметить, что обработчик данного события будет получать управление при выполнении перехода по ссылке через интерфейс «1С:Предприятие» и при выполнении метода встроенного языка ПерейтиПоНавигационнойСсылке().
3. Конфигуратор позволяет указать, на какие схемы или фрагменты URL «подписывается» конфигурация. При этом надо учитывать, что собранное мобильное приложение будет «подписано» на все схемы и URL, которые описаны во всех конфигурациях, включенных в состав мобильного приложения.
4. Сборщик мобильных приложений. Как и в конфигураторе, в сборщике можно указать, какая конфигурация собираемого мобильного приложения будет обрабатывать какую схему или URL. Но самая важная функция сборщика заключается в том, что с помощью сборщика собираемое мобильное приложение получает все настройки, которые нужны для реализации реакции приложения на глубинные ссылки. Также с помощью сборщика можно получить файлы, которые необходимо разместить на веб-сервере для реализации глубинного связывания. Из этого следует один вывод: проверить реакцию приложения на глубинные ссылки можно только в собранном мобильном приложении. Мобильная версия разработчика не позволит проверить работу этого механизма.
Допустим, что нам необходимо сделать так, чтобы мобильное приложение реагировало на любую навигационную ссылку, которая создана с использованием схемы myapp, а также обрабатывала ссылку, которая начинается с https``://``my``.``site``.``com``/``path``/``for``/``service.
Для этого нам необходимо открыть редактор навигационных ссылок мобильного приложения в конфигураторе.
Рис. 537. Навигационные ссылки мобильного приложения
В редакторе, в колонке Навигационная ссылка мобильного приложения, необходимо указать те навигационные ссылки, на которые должно реагировать мобильное приложение, в котором будет наша конфигурация. Затем следует указать, в каких операционных системах мобильное приложение должно реагировать на указанные навигационные ссылки. Это выполняется в колонках Android, iOS и Windows. Аналогичные действия можно выполнить в сборщике мобильных приложений.
Дальнейшая работа выполняется следующим образом:
● После установки приложения на мобильное устройство, приложение регистрирует в мобильной операционной системе глубинные ссылки, которое это приложение может обрабатывать.
● В тот момент, когда пользователь выполняет переход по глубинной ссылке, мобильная операционная система определяет, какое приложение обрабатывает эту ссылку.
● Найденное приложение запускается, и используемая глубинная ссылка передается в это приложение для разбора самим приложением.
● В мобильном приложении срабатывает обработчик события ОбработкаПереходаПоНавигационнойСсылке, который и получает на вход глубинную ссылку, которая привела к запуску мобильного приложения.
Одно мобильное приложение может содержать различные конфигурации, и каждая конфигурация может быть «источником» нескольких информационных баз. В результате одно мобильное приложение может представляться пользователю как несколько приложений. Приложения могут быть одинаковыми (если в разных информационных базах используется одна конфигурация) или разными (если используется разная конфигурация). В связи с этим необходимо сделать следующее уточнение: при определении, куда попадет пользователь при использовании глубинной ссылки, будет пониматься конкретная информационная база. Эта информационная база будет образована комбинацией мобильного приложения и конфигурации этого мобильного приложения.
Исходя из вышесказанного, далее будет приведен алгоритм определения, в какую информационную базу будет передано управление при попытке перехода по глубинной ссылке:
● Если глубинная ссылка позволяет однозначно определить информационную базу, то эта информационная база запускается автоматически. Управление передается в конфигурацию этой информационной базы.
● Если в существует несколько информационных баз, которые обрабатывают разные типы глубинных ссылок, то:
● Если пользователь находится в базе, соответствующей ссылке, она будет сразу передана на обработку
● Если пользователь находится в неподходящей для ссылки базе, ему будет предложено покинуть базу для перехода по ссылке.
● Если в мобильном приложении существует несколько конфигураций, которые обрабатывают одну и ту же глубинную ссылку, то пользователю показывается диалог с доступным списком информационных баз для перехода. Пользователь может пометить специальным флажком, что текущий выбор должен считаться как выбор «по умолчанию». После такого выбора в настройке приложения появляется пункт Автоматически выбирать это приложение при переходе по навигационной ссылке в:. Пользователь может перейти в меню Дополнительно…, чтобы отключить переход по умолчанию, и при следующем переходе можно было снова выбрать нужное приложение для перехода.
● Если при сборке мобильного приложения глубинная ссылка была указана и мобильное приложение получило управление при выборе пользователем соответствующей глубинной ссылки, но не обнаружена информационная база, в которую следует передать управление, то будет сформировано окно с ошибкой.
Для того чтобы сформировать необходимую глубинную ссылку из встроенного языка, предназначен метод ПолучитьВнешнююНавигационнуюСсылку(). Метод может получить как внешнюю навигационную ссылку для текущей информационной базы, так и для других информационных баз. Также имеется возможность добавить в получившуюся глубинную ссылку какие-то дополнительные параметры.
После того, как управление было передано в выбранную информационную базу, сработает обработчик события ОбработкаПереходаПоНавигационнойСсылке. В этот обработчик будет передан объект типа ДанныеПереходаПоНавигационнойСсылке, который содержит информацию о той ссылке, нажатие на которую привело к переходу в данное мобильное приложение. Разработчик может проанализировать эту информацию и принять решение, какое действия необходимо выполнить в данный момент.
28.3.8.3. Вызов другого мобильного приложения в ОС Android
Примечание. Пример в данном разделе не является законченным инструментом. Он предназначены для демонстрации работы с механизмом.
С одной стороны, система «1С:Предприятие» предоставляет возможность вызова другого приложения с помощью механизма намерений (Intent). С другой стороны, система «1С:Предприятие» позволяет обработать необходимость обработки какой-то глубинной ссылки (из списка поддерживаемых данным мобильным приложением). В результате становится возможно реализовать вызов мобильного приложения, написанного на базе мобильной версии «1С:Предприятия», из другого мобильного приложения. При этом вызывающее приложение может не быть написано на базе мобильной версии «1С:Предприятия».
У описываемой возможности есть несколько важных особенностей:
● Глубинная ссылка, используемая для вызова, должна быть зарегистрирована для вызываемого мобильного приложения.
● Данный механизм не предполагает возможность вернуть какое-то значение в результате такого вызова. Значение можно вернуть только в результате обратного вызова.
Для того, чтобы вызвать другое мобильное приложение, необходимо использовать следующий код на встроенном языке:
Запуск = Новый ЗапускПриложенияМобильногоУстройства("android.intent.action.VIEW", "example://testPath?key1=" + ЧисловойПараметр); Запуск.ДополнительныеДанные.Добавить("key2", СтроковыйПараметр); Если Запуск.ПоддерживаетсяЗапуск() Тогда Запуск.Запустить(Ложь); КонецЕсли;
В данном примере необходимо обратить внимание на следующие существенные моменты:
● Мобильная версия «1С:Предприятия» поддерживает только действие android``.``intent``.``action``.``VIEW. Другие действия не будут обработаны мобильным приложением.
● Схема example``:// должна быть указана как поддерживаемая для ОС Android в собираемом мобильном приложении.
● В вызываемое мобильное приложение передается два параметра:
● Числовой параметр с идентификатором key``1 передается непосредственно в URL глубинной ссылки.
● Строковый параметр key``2 передается путем явного указания параметра в списке дополнительных данных объекта, описывающего вызов намерения.
Для того, чтобы вызываемое мобильное приложение каким-то образом отреагировало на вызов, в модуле клиентского приложения должен быть описан обработчик следующего вида:
Процедура ОбработкаПереходаПоНавигационнойСсылке(ДанныеПереходаПоНавигационнойСсылке, СтандартнаяОбработка) БазоваяСсылка = ДанныеПереходаПоНавигационнойСсылке.БазоваяНавигационнаяСсылка; Путь = ДанныеПереходаПоНавигационнойСсылке.ОтносительнаяНавигационнаяСсылка; ДопДанные = ДанныеПереходаПоНавигационнойСсылке.ДополнительныеДанныеПереходаВМобильноеПриложение; Параметр1 = ДанныеПереходаПоНавигационнойСсылке.ПараметрыНавигационнойСсылки.Получить("key1"); Параметр2 = ДопДанные.Получить("key2"); Сообщение = "Произошел запуск по ссылке:" + Символы.ПС + "Базовая ссылка: " + БазоваяСсылка + Символы.ПС + "Относительный путь: " + Путь + Символы.ПС + "Параметр 1: " + Параметр1 + Символы.ПС + "Параметр 2: " + Параметр2; Сообщить(Сообщение); СтандартнаяОбработка = Ложь; КонецПроцедуры
Таким образом видно, что мобильное приложение на базе «1С:Предприятие» имеет возможность не только вызывать другие мобильные приложения, но и само получать данные из других мобильных приложений для выполнения задач, например, интеграции.
28.3.8.4. Использование в других клиентских приложениях
Кроме мобильных клиентских приложений, у системы «1С:Предприятие» существуют и другие клиентские приложения: тонкий клиент, веб-клиент, толстый клиент. В этих клиентских приложениях также поддерживается возможность перехода по навигационной ссылке (внутри приложения) и запуска этих клиентских приложений из внешних источников. В случае веб-клиента таким запуском будет переход по внешней навигационной ссылке. В случае тонкого и толстого клиентских приложений ‑ это будет запуск клиентского приложения с указанием команды /``URL в командной строке запуска клиентского приложения.
В обоих случаях (и при переходе по ссылке внутри приложения и при запуске клиентского приложения извне) управление будет передано в обработчик события ОбработкаПереходаПоНавигационнойСсылке.
Параметр обработчика ДанныеПереходаПоНавигационнойСсылке будет содержать объект, описывающий, какая ссылка использовалась для перехода. Например, значение свойства ДанныеПереходаПоНавигационнойСсылке.Запуск позволит определить ‑ переход по ссылке был выполнен внутри приложения или приложение было запущено с использованием внешней навигационной ссылки. В остальном, обработка перехода по ссылке будет выглядеть также, как и в мобильном приложении.
Процедура ОбработкаПереходаПоНавигационнойСсылке(ДанныеПереходаПоНавигационнойСсылке, СтандартнаяОбработка) БазоваяСсылка = ДанныеПереходаПоНавигационнойСсылке.БазоваяНавигационнаяСсылка; Путь = ДанныеПереходаПоНавигационнойСсылке.ОтносительнаяНавигационнаяСсылка; ДопДанные = ДанныеПереходаПоНавигационнойСсылке.ДополнительныеДанныеПереходаВМобильноеПриложение; Сообщение = "Произошел запуск по ссылке: " + ДанныеПереходаПоНавигационнойСсылке.Запуск + Символы.ПС + "База: " + БазоваяСсылка + Символы.ПС + "Путь: " + Путь; Сообщить(Сообщение); СтандартнаяОбработка = Ложь; КонецПроцедуры
Свойство ДанныеПереходаПоНавигационнойСсылке.``ДополнительныеДанныеПереходаВМобильноеПриложение в клиентском приложении, отличном от мобильного клиентского приложения, будет всегда равно значению Неопределено.
Кроме того, параметры навигационной ссылки, по которой выполнен запуск клиентского приложения, доступны через свойство глобального контекста ДанныеПереходаПоНавигационнойСсылкеЗапуска, которое доступно во всех клиентских обработчиках событий, начиная с обработчика события ПередНачаломРаботыСистемы.
Смотри также:
● Навигационные ссылки (см. здесь).
● Специальный режим запуска (Внимание! Неправильная ссылка!).
● Командная строка запуска клиентских приложений (см. здесь).
28.3.9. Запуск внешних мобильных приложений
Мобильная версия «1С:Предприятия», работающая под управлением ОС Android, предоставляет возможность запускать другие приложения, расположенные на данном мобильном устройстве. При запуске можно передать различные данные, которые будет обрабатывать запускаемое мобильное приложение. После выполнения приложения имеется возможность обработать данные, которые возвращает запущенное приложение.
Данная возможность базируется на механизмах ОС Android, которые называются активности (activity) и намерения (intent). Сразу предупредим, что в данная документация не ставит своей задачей объяснить схему межпроцессного взаимодействия в этой операционной системе. Целью документации является общее описание механизма запуска приложений, который предоставляет мобильная версия «1С:Предприятия», а также указание того, аналоги каких механизмов ОС Android реализованы в платформе. Для четкого понимания работы описываемой механики необходимо иметь знания разработчика на платформе ОС Android. Мобильное приложение, созданное на мобильной версии «1С:Предприятия», не может быть вызвано другим приложением с помощью данных механизмов.
Можно сказать, что активность ‑ это окно, которое открывается пользователю при запуске приложения. Мобильное приложение может иметь несколько окон (активностей), которые предоставляют доступ к различным возможностям приложения. В числе прочего, каждая активность обладает именем класса, которое уникально для каждой активности в системе. Намерение ‑ это описание выполнения одной операции: отправить письмо, выбрать картинку и т. д. Намерение может быть явным или неявным. В случае явного намерения четко указывается класс, идентифицирующий активность. В случае неявного намерения указывается набор требований, которым должно соответствовать приложение, которое может обработать наше намерение. Если требованиям будет соответствовать более одного приложения, то ОС Android предложит пользователю выбрать приложение, которое будет исполнять то или иное намерение. Подобная операция выполняется, если пользователь хочет открыть, например, pdf-документ, а на мобильном устройстве установлено несколько приложений, которые могут такие документы отображать.
Для запуска мобильного приложения предназначен объект ЗапускПриложенияМобильногоУстройства. Создав этот объект, необходимо проверить, что мы можем им пользоваться (или, другими словами, что мы работаем под управлением ОС Android). Для этого следует использовать метод объекта ПоддерживаетсяЗапуск().
Если на данном мобильном устройстве запуск приложений поддерживается, то логика работы выглядит следующим образом:
1. Создается экземпляр объекта ЗапускПриложенияМобильногоУстройства. Дальнейшие действия выполняются с этим экземпляром.
2. Указывается намерение (или идентификатор действия), которое требуется совершить, с помощью свойства Действие.
3. Указывается имя класса приложения, которое необходимо запустить (явное намерение) с помощью свойства ИмяКласса.
4. Если нужно реализовать неявное намерение, то следует указать свойства Категории, Тип, Данные для того, чтобы операционная система подобрала нужные приложения из имеющихся на устройстве. Другим вариантом указания параметров для поиска нужного приложения служит метод УстановитьПараметрыВыбораПриложения(). Объект ПараметрыВыбораЗапускаПриложенияМобильногоУстройства, установленный с помощью вызова этого метода, содержит такие же свойства, что и объект ЗапускПриложенияМобильногоУстройства, но свойства параметров выбора используются только для поиска приложения, удовлетворяющего указанным критериям. Когда найденное внешнее приложение запускается, то в него передаются данные из свойств объекта ЗапускПриложенияМобильногоУстройства.
5. При необходимости, можно указать данные, которые требуются вызываемому приложению. Для этого можно использовать различные свойства:
● Свойство Данные ‑ используется в том случае, когда данные, передаваемые в открываемое приложение, ограничиваются простой текстовой строкой. Как правило, свойство содержит ссылку (URI) на данные (путь к файлу, элемент контекста, ресурс в Интернете), необходимые внешнему приложению. MIME-тип этих данных расположен в свойстве Тип.
● Свойство ДополнительныеДанные. Это свойство используется в том случае, когда вызывающее приложение документирует параметры, которые следует указывать при выполнении каждого намерения. Особенность данного свойства состоит в том, что вызывающее приложение обязано знать идентификаторы и типы данных параметров.
● Свойство ПрикрепляемыеДанные. С помощью данного свойства можно передать внешнему приложению данные в нескольких различных форматах (данные могут быть одинаковыми). Представляет собой «буфер обмена», из которого внешнее приложение сможет получить данные в том формате, который это приложение поддерживает.
6. Вызов приложения осуществляется с помощью одного из методов:
● Если не требуется получить результат работы приложения, то следует использовать метод ЗапуститьБезОжидания().
● Если результат работы требуется, то следует использовать метод ЗапуститьАсинх(). В этом случает будет возвращаться обещание, в результате исполнения которого будет сформирован объект типа РезультатЗапускаПриложенияМобильногоУстройства или Неопределено, если приложение на устройстве не найдено.
Результат выполнения внешнего приложения (объект типа РезультатЗапускаПриложенияМобильногоУстройства) содержит в себе следующую информацию:
|
Свойство |
Описание |
|
|
Содержит
ссылку (URI) на результат работы внешнего приложения. MIME-тип этих данных
расположен в свойстве |
|
|
Коллекция возвращаемых данных в виде «ключ ‑ значение». |
|
|
Число, которое возвращает запускаемое приложение в качестве кода возврата. |
|
|
Коллекция
возвращаемых данных в виде объекта |
|
|
Уникальный идентификатор приложения, которое выполнило требуемое намерение. Фактически ‑ это идентификатор класса активности. |
|
|
MIME-тип
данных, расположение которых указано в свойстве |
Нужно понимать, что все данные, которые передаются в вызываемое приложение и получаются из вызываемого приложения, полностью определяются этим приложением. Другими словами, для того чтобы использовать стороннее приложение, программисту прикладного решения необходимо ознакомиться с документацией к этому стороннему приложению.
Для упрощения понимания схемы работы с внешними приложениями, далее будет приведено два примера такой работы. При этом вначале будет приведен пример на Java (в варианте родного приложения для ОС Android), а затем этот же пример, переписанный на языке «1С:Предприятие».
Отправка сообщения электронной почты
Пример на Java:
Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND_MULTIPLE); intent.setSelector(new Intent(Intent.ACTION_SENDTO, Uri.parse("mailto:"))); intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); intent.putExtra(Intent.EXTRA_SUBJECT, "Тема письма"); intent.putExtra(Intent.EXTRA_TEXT, "Содержимое письма"); String[] addresses = new String[]{"addr1@example.com", "addr2@example.com"}; intent.putExtra(Intent.EXTRA_EMAIL, addresses); ArrayList uris = new ArrayList<>(); uris.add(Uri.parse(FullFileName1); uris.add(Uri.parse(FullFileName2); intent.putParcelableArrayListExtra(Intent.EXTRA_STREAM, uris); App.startIntent(intent, true, 0);
Пример на встроенном языке:
ЗапускПриложения = Новый ЗапускПриложенияМобильногоУстройства(); ЗапускПриложения.Действие = "android.intent.action.SEND_MULTIPLE"; ПарамерыВыбора = Новый ПараметрыВыбораЗапускаПриложенияМобильногоУстройства(); ПарамерыВыбора.Действие = "android.intent.action.SENDTO"; ПарамерыВыбора.Данные = "mailto:"; ЗапускПриложения.УстановитьПараметрыВыбораПриложения(ПарамерыВыбора); ЗапускПриложения.ДополнительныеДанные.Добавить("android.intent.extra.SUBJECT", "Тема письма"); ЗапускПриложения.ДополнительныеДанные.Добавить("android.intent.extra.TEXT", "Содержимое письма"); Получатели = Новый Массив; Получатели.Добавить("addr1@example.com"); Получатели.Добавить("addr2@example.com"); ЗапускПриложения.ДополнительныеДанные.Добавить("android.intent.extra.EMAIL", Получатели); ИменаФайлов = Новый Массив; ИменаФайлов.Добавить(Новый Файл(ПолноеИмяФайла1)); ИменаФайлов.Добавить(Новый Файл(ПолноеИмяФайла2)); ЗапускПриложения.ДополнительныеДанные.Добавить("android.intent.extra.STREAM", ИменаФайлов, "ArrayList"); ЗапускПриложения.ЗапуститьБезОжидания();
Выбор нескольких картинок из галереи
Пример на Java:
public class MyActivity extends Activity { // Начнем выбор из галереи void getImagesFromGallery() { Intent intent = new Intent(); intent.setAction(Intent.ACTION_GET_CONTENT); intent.setType("image/*"); intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); this.startActivityForResult(intent, GET_CONTENT_RESULT); } // Получим результат выбора public void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); if (resultCode == RESULT_OK) { if (requestCode == GET_CONTENT_RESULT && data != null) { Uri pic = data.getData(); if (pic != null) { // Получили одну картинку из галереи ... } else { // Получили несколько картинок из галереи ClipData clipData = data.getClipData(); if (clipData != null { int count = clipData.getItemCount(); for (int i = 0; i < count; i++) { Uri imageurl = clipData.getItemAt(i).getUri(); ... } } else { // Данные из галереи не получены } } } else { // Данные из галереи не получены } } else { // Выход из галереи без выбора картинок } } }
Пример на встроенном языке:
ЗапускПриложения = Новый ЗапускПриложенияМобильногоУстройства(); ЗапускПриложения.Действие = "android.intent.action.GET_CONTENT"; ЗапускПриложения.Тип = "image/*"; ЗапускПриложения.ДополнительныеДанные.Добавить("android.intent.extra.ALLOW_MULTIPLE", Истина); Результат = Ждать ЗапускПриложения.ЗапуститьАсинх(); ИдентификаторДляХранилища = Новый УникальныйИдентификатор; Если Результат <> Неопределено Тогда Если Результат.КодРезультата = -1 Тогда Если Результат.Данные <> "" Тогда // URL на одну картинку лежит в Данные ПоместитьВоВременноеХранилище(Новый Картинка(Результат.Данные), ИдентификаторДляХранилища); ИначеЕсли Результат.ПрикрепляемыеДанные <> Неопределено Тогда // URL в случае нескольких картинок лежит в ПрикрепляемыеДанные Для каждого ЭлементДанных из Результат.ПрикрепляемыеДанные Цикл ПоместитьВоВременноеХранилище(Новый Картинка(ЭлементДанных.ПолучитьСсылкуНаНеизменныйURI()), ИдентификаторДляХранилища); КонецЦикла; Иначе Сообщить("Данные из галереи не получены."); КонецЕсли; Иначе Сообщить("Выход из галереи без выбора картинок."); КонецЕсли Иначе Сообщить("Приложение не найдено."); КонецЕсли;
28.4. Приложение на мобильной платформе
28.4.1. Общая информация
Данный раздел содержит информацию, которую следует учитывать при разработке приложений на мобильной платформе.
28.4.2. Виды приложений на мобильной платформе
Разработку приложений на мобильной платформе можно условно разбить на следующие этапы:
● Принимается решение, каким будет приложение на мобильной платформе:
● Независимое от каких-либо прикладных решений на удаленной системе. В этом случае структура данных приложения на мобильной платформе определяется только областью применения приложения. Скорее всего, никакой обмен данными не потребуется.
● Автономное рабочее место некоторого прикладного решения, расположенного на удаленной системе. В этом случае структура данных в основном определяется прикладным решением, но будут изменения, определяемые как областью применения, так и особенностями приложения на мобильной платформе. Протокол обмена данными, скорее всего, будет разработан специально для обмена конкретного прикладного решения с конкретным приложением на мобильной платформе. Вероятнее всего, этот протокол не будет поддерживать обмен с другими прикладными решениями.
● Универсальное автономное рабочее место. В этом случае структура данных должна учитывать специфику всех прикладных решений, с которыми должно взаимодействовать приложение на мобильной платформе. Также необходимо учитывать особенности приложения на мобильной платформе. Протокол обмена должен быть достаточно универсальным и стандартизированным.
● Уточняется, разрабатываемое приложение должно работать только на мобильном устройстве или оно также может работать и на персональном компьютере (например, на ноутбуке).
● Выполняется реализация приложение на мобильной платформе и его отладка на персональном компьютере (включая механизмы обмена данными). При этом необходимо понимать, что мобильная платформа имеет ряд отличий и особенностей, в силу чего невозможно полностью проверить работоспособность разрабатываемого приложения на персональном компьютере. Однако код на встроенном языке можно отлаживать с использованием персонального компьютера.
● На мобильном устройстве (одном или нескольких) выполняется окончательная проверка и отладка интерфейса и функциональности приложения.
Совет. Рекомендуется выбирать для разработки вариант автономного рабочего места, которое может функционировать и на мобильном устройстве, и на персональном компьютере.
При разработке механизма обмена данными необходимо учитывать, что обмениваться данными должны приложения с разными версиями интерфейса обмена. Это не должно вызывать проблем при обмене. Связано это с тем, что обновление приложения сразу для всей инфраструктуры практически невозможно. Также следует отметить, что синхронизация данных по устаревшей версии протокола обмена может использоваться для выполнения операций резервного копирования перед обновлением конфигурации мобильного приложения.
При разработке приложения на мобильной платформе необходимо учитывать ограничения, которые накладывает мобильная платформа по сравнению с платформой «1С:Предприятие» для персонального компьютера:
● Ограниченный перечень доступных объектов конфигурации и механизмов;
● Ограниченный набор свойств реквизитов;
● Ограниченный набор элементов управляемых форм;
● Упрощенная реализация некоторых механизмов (например, права доступа или начальная страница);
● Отсутствие обычных форм и обычного режима запуска;
● Отсутствие средств отладки мобильного приложения;
● Полный список особенностей см. здесь.
Также следует учитывать, что мобильная платформа и платформа для персонального компьютера, при совпадении версий различаются по предоставляемой функциональности. Ниже приведено функциональное соответствие версий платформы для мобильного устройства и персонального компьютера:
|
Мобильная платформа |
Платформа для персонального компьютера |
|
8.3.9 и последующие |
8.3.9 и последующие |
|
8.3.8 |
8.3.7 |
|
8.3.7 |
8.3.6 |
|
8.3.6 |
8.3.5 |
|
8.3.5 |
8.3.4 |
|
8.3.4 |
8.3.2 |
|
8.3.3 |
8.3.2 |
В документации, которая разрабатывается для приложения на мобильной платформе, прикладной разработчик может не описывать поведение стандартных механизмов системы, а ссылаться на «Руководство пользователя мобильного приложения», которое расположено по адресу http://v8.1c.ru/mobile_user_guide/.
28.4.3. Особенности использования
28.4.3.1. Отчеты
Формирование отчетов на мобильной платформе возможно двумя разными способами:
● Обработка существующих данных и формирование собственно отчета на встроенном языке;
● Реализация на мобильной платформе некоторой формы, с помощью которой можно задать параметры формирования отчета (отборы и т. д.), а само формирование передать в удаленную систему, которая вернет табличный документ для отображения на мобильном устройстве.
Выбор одного из этих вариантов зависит от некоторого набора факторов:
● Содержит или нет информационная база мобильного приложения все данные, которые необходимы для построения отчета;
● Наличие и качество канала связи между мобильным устройством и удаленной системой;
● Какова сложность отчета;
● Каким образом построен обмен с удаленной системой;
● Каким образом предполагается работа с отчетом;
● И т. д.
Если принято решение формировать отчет на мобильном устройстве, то необходимо помнить об особенностях мобильной платформы (см. здесь). Для получения данных доступны выборки, а для построения отчета доступно программное формирование табличного документа (на основании макета) и диаграмм (если таковые требуются).
Если для мобильного приложения доступны постоянные высокоскоростные каналы связи с удаленной системой, которое обладает всеми необходимыми данными для формирования требуемого отчета, то возможным вариантом может служить реализация на мобильном приложении только интерфейсной части отчета (задание отборов, обработка расшифровки и т. д.). Собственно формирование отчета в этом случае будет происходить в удаленном приложении, а возвращаться будет готовый отчет для отображения на устройстве.
При этом возможны и все промежуточные варианты, например, если реализован периодический обмен, можно настройки отчета сформировать на мобильном устройстве и передать на удаленную систему во время сеанса обмена, а обратно получить сформированный отчет для отображения.
Для взаимодействия с удаленным приложением можно использовать Web-сервис (который предоставляет удаленное приложение), обмен данными с помощью плана обмена и т. д.
При необходимости реализации расшифровки отчета, нужно понимать, что мобильное приложение самостоятельно может выполнить только просмотр значений, указанных в качестве расшифровки ячейки отчета. Остальные действия необходимо реализовывать на встроенном языке, включая получение нового варианта отчета с учетом наложенных отборов и т. д.
28.4.3.2. Работа с ролями и пользователями
При работе с ролями в мобильном приложении следует помнить, что из всех прав доступа, которые предоставляет платформа для персонального компьютера, на мобильной платформе доступен только ограниченный набор. Этот набор прав призван обеспечить функционирование различных механизмов, обеспечивающих интерфейс мобильного приложения. Права, которые могут использовать на мобильной платформе, отмечены символом «*» в полном списке прав (см. здесь).
Также имеется возможность выполнять ролевую настройку формы (см. здесь), настраивать ролевую видимость командного интерфейса (см. здесь).
Внимание! Права для доступа к данным (Чтение, Добавление, Изменение, Удаление и т. д.) не поддерживаются мобильной платформой.
Методы управления привилегированным режимом в мобильной платформе используются для совместимости с платформой для персонального компьютера. Сами вызовы методов работы с привилегированным режимом мобильной платформой игнорируются и никаких действий мобильная платформа не выполняет.
При определении прав пользователя действует стандартная схема: если в информационной базе не заданы пользователи, то для определения прав доступа используется свойство конфигурации ОсновныеРоли (см. здесь). Если для доступа к данным мобильного приложения используется пользователь, то права доступа определяются по составу ролей этого пользователя.
Мобильная платформа имеет ограниченный набор средств работы с пользователями информационной базы:
● В информационной базе может существовать только один пользователь. Попытка создать более одного пользователя приводит к генерации исключения.
● Пользователь может быть создан только с помощью программного кода. Интерактивное создание пользователей в конфигураторе не приведет к передаче пользователя на мобильное устройство.
● Мобильная платформа не предлагает средств аутентификации при старте мобильного приложения. Если пользователь указан в списке пользователей, то этот пользователь автоматически будет установлен в качестве пользователя текущего сеанса.
В результате можно рекомендовать следующую схему работы от лица пользователей с разными правами:
● Выполняется создание пользователя с нужным набором ролей или выполняется изменение набора ролей у существующего пользователя.
● Выполняется перезапуск мобильного приложения с помощью конструкции ЗавершитьРаботуСистемы(Ложь, Истина);.
28.4.3.3. Полнотекстовый поиск
Описание особенностей использования полнотекстового поиска в мобильной платформе см. здесь.
28.5. Мобильный клиент «1С:Предприятия»
28.5.1. Общая информация
Данный раздел содержит информацию, которую следует учитывать при разработке приложений, работающих в мобильном клиенте.
Как известно, приложение на мобильной платформе содержит копию используемой конфигурации и работает только с ней. В то же время, мобильный клиент должен работать с той версией конфигурации, которая в данный момент находится в информационной базе, к которой мобильный клиент подключен. Однако магазины приложений могут требовать, чтобы приложение, опубликованное в магазине, не изменяло свою функциональность после установки на устройство пользователя. В некотором смысле данные требования являются взаимоисключающими.
Для того чтобы приложение мобильного клиента могло быть опубликовано в магазине приложений, необходимо выполнить несколько требований:
● Мобильный клиент может работать только с теми конфигурациями, которые указаны перед сборкой. Одно мобильное приложение может работать с несколькими информационными базами.
● Каждая конфигурация имеет собственную электронную подпись (включающая характеристику метаданных конфигурации), благодаря которой отсутствует возможность полной замены конфигурации в информационной базе.
Соблюдение данных требований позволяет собранному приложению мобильного клиента быть опубликованным в магазине приложений и удовлетворить требованиям этого магазина.
Мобильный клиент взаимодействует с информационной базой по протоколу HTTP/HTTPS. Это означает, что мобильный клиент не поддерживает прямое подключение и может работать только с теми информационными базами, которые опубликованы на веб-сервере. При работе с помощью мобильного клиента не требуется обеспечивать точное соответствие версии мобильного клиента и версии расширения веб-сервера или сервера «1С:Предприятие». Совместимость обеспечивается не в рамках номера версии системы «1С:Предприятие», а в рамках версии протокола взаимодействия. В том случае, если протокол взаимодействия будет существенно изменен, на мобильных устройствах будет необходимо обновить приложение тонкого клиента.
В отличие от приложения на мобильной платформе, которое, по сути, является самостоятельным и отдельным приложением, приложение для мобильного клиента является адаптацией обычного приложения, которое работает в тонком клиенте или веб-клиенте. Но для корректной работы этого приложения в мобильном клиенте, платформе необходимо «подсказать», как нужно строить интерфейс в мобильном клиенте. Для этого предназначены специальные свойства элементов формы.
28.5.2. Подготовка конфигурации для работы в мобильном клиенте
Для того чтобы конфигурация была работоспособна в мобильном клиенте, необходимо выполнить некоторый набор действий:
● Установить свойство конфигурации Режим совместимости в значение Версия 8.3.7 и старше.
● Выполнить адаптацию форм конфигурации, с учетом особенностей отображения этих форм на мобильных устройствах.
● В модулях на встроенном языке необходимо использовать директиву компиляции #Если НЕ МобильныйКлиент Тогда … #КонецЕсли везде, где требуется отметить код, который может работать только на мобильном устройстве.
● Сформировать цифровую подпись конфигурации.
Смотри также:
● Директивы компиляции (см. здесь).
28.5.3. Цифровая подпись и дайджест конфигурации
Как уже было сказано, приложение мобильного клиента не может произвольно изменять свои функциональные возможности после загрузки на мобильное устройство пользователя. Данное требование накладывают магазины приложений на мобильные приложения, которые загружают свой код с внешних ресурсов. Чтобы выполнить это требование, каждая конфигурация, которая может работать в мобильном клиенте, содержит некоторую вспомогательную информацию, позволяющую отследить существенное изменение конфигурации.
Вспомогательная информация, предназначенная для отслеживания изменений конфигурации (и возможности работы мобильного клиента с информационной базой), называется дайджестом. В состав дайджеста конфигурации входит следующая информация:
● Имя и внутренний идентификатор следующих объектов конфигурации:
● Справочники;
● Документы;
● Планы видов характеристик;
● Планы обмена;
● Перечисления;
● Бизнес-процессы.
● Имена и состав ключей записи для следующих объектов конфигурации:
● Регистры сведений;
● Регистры накопления;
● Регистры бухгалтерии;
● Регистры расчета.
● Используемые конфигурацией расширения не включаются в состав дайджеста.
Каждая конфигурация, которая будет использоваться в мобильном клиенте, обязана иметь уникальный закрытый ключ. Использование одного и того же закрытого ключа для нескольких конфигураций не допускается. Закрытый ключ используется для формирования цифровой подписи дайджеста мобильной конфигурации. Для некоторого упрощения будем считать, что описанная подпись является подписью мобильной конфигурации. Подпись конфигурации формируется с помощью специального диалога, который открывается из свойств конфигурации (подробнее см. здесь). Во время подписи конфигурации, ее состав фиксируется в информационной базе.
Во время выгрузки мобильной конфигурации, в файл конфигурации помещается открытый ключ для закрытого ключа, с помощью которого формируется подпись мобильной конфигурации. Сборщик мобильных приложений помещает этот открытый ключ в собираемое мобильное приложение (для каждой конфигурации, участвующей в сборке мобильного приложения).
Если мобильный клиент работает под управлением операционной системы iOS, то перед тем, как мобильный клиент будет подключаться к информационной базе, выполняется проверка возможности такого подключения. При работе под управлением ОС Android и Windows та-ких проверок не выполняется. Собственно проверка происходит следующим образом:
● При начале сеанса, мобильный клиент получает с сервера метаданные используемой конфигурации и подпись конфигурации, которая хранится в информационной базе.
● Мобильный клиент строит свою версию дайджеста (на основании полученных метаданных).
● С помощью открытого ключа, размещенного в мобильном приложении, и дайджеста, сформированного в мобильном клиенте, выполняется проверка подписи конфигурации, полученной с сервера «1С:Предприятие».
● Если проверка подписи выполнена успешно, то текущее мобильное приложение может работать с данной информационной базой.
После того, как установлено, что мобильный клиент может подключиться к указанной информационной базе, выполняется проверка неизменности метаданных. Проверка выглядит следующим образом:
● Мобильный клиент получает с сервера метаданные, которые использовались для формирования текущей подписи конфигурации.
● Сравниваются два комплекта метаданных: конфигурация информационной базы и конфигурация, на основании которой формировалась текущая подпись.
● Если конфигурации различаются менее, чем на 20% (или не различаются вовсе) ‑ мобильный клиент начинает работу с данной информационной базой. В противном случае пользователю формируется сообщение об ошибке.
Если конфигурация информационной базы и мобильного клиента существенно (более, чем на 20%) различаются, то необходимо выполнить одно из следующих действий:
1. У автора доработок конфигурации есть доступ к закрытому ключу конфигурации: необходимо заново подписать конфигурацию. Заново собирать и публиковать мобильное приложение в этом случае нет необходимости.
2. У автора доработок нет доступа к закрытому ключу конфигурации. В этом случае есть два варианта действий:
1. Создать расширение (подробнее см. здесь), которое выполняет требуемые функции. При подключении расширения не меняется дайджест конфигурации и можно использовать мобильное приложение, работающее с оригинальной конфигурацией.
2. Собрать (с помощью сборщика мобильных приложений) и опубликовать свой экземпляр мобильного приложения, предназначенного для эксплуатации доработанной конфигурации. Для этой конфигурации будет необходимо создать новый закрытый ключ конфигурации.
В этом приложении можно будет сохранить возможность работы с оригинальной конфигурацией. При этом следует помнить, что публикация в магазине мобильных приложений будет осуществляться от лица компании, доработавшей оригинальную конфигурацию, со всеми вытекающими последствиями (регистрация как разработчика в магазине приложений, сертификаты и т. д.).
Использование для подписи конфигурации нового закрытого ключа автоматически означает, что использовать такую конфигурацию можно будет только с тем мобильным приложением, которое обладает открытым ключом для проверки дайджеста. Следовательно, обновление опубликованного мобильного приложения должно быть выполнено до того, как обновленная конфигурация станет доступна на используемой информационной базе.
Если в приложение мобильного клиента, работающего под управлением ОС iOS, информационная база добавляется с помощью начальной страницы, то проверка возможности работы с таким приложением осуществляется для всех конфигураций, которые добавлены в собранное приложение мобильное клиента во время сборки.
Конфигуратор предоставляет возможность настроить, какие действия будут выполняться в случае обновления конфигурации базы данных. Для этого предназначена настройка Проверка подписи мобильного клиента, которая размещена в диалоге параметров информационной базы см. здесь. В зависимости от значения этого параметра, конфигуратор будет выполнять следующие действия:
● Проверять возможность использования мобильного клиента ‑ выполняется проверка на то, что объем выполненных изменений не превышает 20%. В случае сильного отклонения выдается соответствующая диагностика. Данный режим, в основном, предназначен для специалистов, которые занимаются доработкой конфигурации. Данный режим позволит заранее определить, что объем текущих доработок превысил «порог терпимости» мобильного клиента и необходимо принимать решение о том, как будет выполняться доработка прикладного решения.
● Проверять точное соответствие подписи и конфигурации ‑ выполняется проверка на точное совпадение подписи и конфигурации. В случае несовпадения выдается соответствующая диагностика. Данный режим, в основном, предназначен для разработчиков конфигурации, т. к. они не связаны рамками «сильного отклонения».
● Не выполнять проверку подписи ‑ никаких действий выполняться не будет.
Если при настройке информационной базы выбрана какая-либо проверка подписи, то в диалоге с сообщением о проблеме предлагается выбрать одно из следующих действий:
● Пересоздать подпись ‑ открывается редактор цифровой подписи конфигурации.
● Настроить проверку подписи ‑ открывается диалог параметров информационной базы.
● Продолжить обновление ‑ выполняется обновление конфигурации базы данных.
● Отмена ‑ обновление конфигурации базы данных не происходит.
Кроме проверки, которая выполняется конфигуратором, проверка актуальности цифровой подписи конфигурации выполняется в мобильном клиенте (на стороне клиентского приложения), во время исполнения. Сервер «1С:Предприятия» также выполняет проверку цифровой подписи. Проверка на сервере выполняется согласно значению параметра информационной базы Проверка подписи мобильного клиента. Если в параметрах информационной базы задан какой-либо режим проверки подписи, то сообщения о неактуальной цифровой подписи будут формировать и обычными клиентскими приложениями, кроме следующих случаев:
● Клиентское приложение запущено в режиме отладки.
● Клиентское приложение запущено с помощью OLE Automation (только при работе под управлением ОС Windows).
● При запуске клиентского приложения указана команда /``DisableStartupMessages.
28.5.4. Работа с данными, связанными с текущей строкой таблиц
В том случае, если на форме существуют данные, связанные с текущей строкой таблицы (одной или нескольких), то рекомендуется сделать следующее:
● Все данные формы, связанные с текущими данными таблиц, следует разделить по группам таким образом, чтобы одна группа отображала данные, связанные с текущей строкой только одной таблицы.
● Для каждой такой группы следует установить свойства Использование текущей строки (ИспользованиеТекущейСтроки) и Используемая таблица (ИспользуемаяТаблица) по аналогии с командной формы. Из этого следует, что одна группа может отображать данные только одной таблицы. Именно поэтому выше приводится рекомендация связанные данные размещать в разные группы, по количеству используемых таблиц.
● Для таблиц, которые используются в качестве источников данных для вспомогательных данных, следует установить свойство Использование текущей строки в значение Выбор.
В мобильном клиенте на форме не будет групп, у которых свойство Использование текущей строки установлено в значение Использовать.
Для того чтобы увидеть связанные данные, необходимо открыть контекстное меню на выбранной строки и выбрать специальную команду, выбор которой откроет окно с данными. Название команды формируется как имя скрытой группы. Если в данной таблице текущие данные отображаются в нескольких группах ‑ название команды будет сформировано из заголовков всех групп, объединенных символом «,».
28.6. Мобильный клиент с автономным режимом
28.6.1. Общая информация
Данный раздел содержит описание особенностей разработки конфигурации, которая должна работать в мобильном клиенте с автономным режимом.
При рассмотрении мобильного клиента с автономным режимом будут использоваться следующие термины:
● Основной сервер ‑ кластер серверов прикладного решения, с которым работает мобильный клиент с автономным режимом. Кластер работает на персональном компьютере.
● Автономный сервер ‑ серверная часть мобильного клиента с автономным режимом, которая работает на мобильном устройстве.
● Автономный режим ‑ под этим термином будем понимать такой режим работы мобильного приложения, когда соединение с основной информационной базой отсутствует.
● Обычный режим ‑ под этим термином будем понимать возможность мобильного приложения использовать и основной и автономный сервер.
● Автономная конфигурация ‑ часть основной конфигурации, которая предназначена для работы на мобильном устройстве, в автономном режиме. Формирование (или обновление) автономной конфигурации происходит во время обновления конфигурации информационной базы. Принудительно выполнить пересоздание автономной конфигурации можно при выполнении операции тестирования и исправления информационной базы (см. здесь).
● Внешние ссылки ‑ ссылки на данные информационной базы, типы которых которые не включены в состав автономной конфигурации, но сами эти данные ‑ используются в объектах автономной конфигурации.
Мобильный клиент позволяет работать только при наличии соединения мобильного устройства и веб-сервера, на котором опубликовано приложение. Приложение на мобильной платформе вообще не требует какой-то внешней (по отношению к мобильному устройству) базы данных. Это приложение работает полностью с базой данных, расположенной на мобильном устройстве. Мобильный клиент с автономным режимом объединяет в себе обе этих особенности. Когда между мобильным устройством и информационной базой существует канал связи: мобильный клиент с автономным режимом работает в обычном режиме. В том случае, когда канал нарушается: мобильное приложение переходит в автономный режим, когда используются только те данные (и та конфигурация), которые определены для использования в автономном режиме.
Доступность данных и форм в автономном режиме определяется во время настройки состава автономной конфигурации (подробнее см. здесь). При этом указывается не только список объектов и форм, доступных в автономном режиме, но и то, какие данные (реквизиты и табличные части) будут в автономных объектах.
Для форм, входящих в состав автономной конфигурации, имеется возможность реагировать на изменение доступности основного сервера. С помощью такого механизма разработчик получает возможность адаптировать форму на мобильном устройстве под изменяющиеся условия: доступность или недоступность основного сервера (подробнее см. здесь).
Для начального заполнения базы данных мобильного клиента с автономным режимом следует использовать планы обмена (подробнее см. здесь).
В общем случае, при разработке мобильного клиента с автономным режимом следует ориентироваться на следующие основные сценарии работы:
● Обычный режим работы.
● Для серверных вызовов может использоваться и автономный и основной сервер.
● Объекты автономной конфигурации используются в соответствии с приоритетами, указанными при настройке автономной конфигурации.
● При пропадании канала связи с информационной базой происходит переход в автономный режим. При этом:
● Мобильный клиент с автономным режимом пытается восстановить соединение с основной информационной базой.
● Для работы используется автономная информационная база, состав которой определяется во время настройки состава автономной конфигурации, а объем данных ‑ параметрами плана обмена с точностью до последней синхронизации.
● Приложение должно (при необходимости) выполнить переоткрытие формы приложения.
● Возможности, не вошедшие в состав автономной конфигурации ‑ недоступны.
● При восстановлении канала связи мобильный клиент с автономным режимом должен синхронизировать данные и (при необходимости) выполнить переоткрытие форм приложения.
● Автономный режим работы.
● Включается принудительно, в диалоге свойств информационной базы мобильного приложения или в диалоге свойств пользователя.
● Мобильный клиент с автономным режимом в этом режиме не пытается автоматически восстановить соединение с основной информационной базой.
● Плохое соединение с основной информационной базой.
● Включается принудительно, в диалоге свойств информационной базы мобильного приложения или в диалоге свойств пользователя.
● Режим работы, похожий на обычный режим работы, но объекты, включенные в состав автономной конфигурации, используют автономный сервер (вне зависимости от заданного приоритета), а остальные объекты используют основной сервер.
● Мобильный клиент с автономным режимом пытается восстановить соединение с основной информационной базой. После восстановления соединения становятся доступными объекты, не входящие в состав автономной конфигурации.
В зависимости от заданных приоритетов и наличия соединения с основной информационной базы, можно следующим образом описать, какой сервер будет использоваться при выполнении действий на мобильном устройстве:
|
Приоритет/Соединение |
Есть соединение |
Нет соединения |
|
Автономный |
Автономный сервер |
Автономный сервер |
|
Основной |
Основной сервер |
Автономный сервер |
|
Не входит в автономную конфигурацию |
Основной сервер |
Не доступно |
Далее будут более подробно рассмотрены особенности разработки мобильного клиента с автономным режимом, которые упоминались в данном разделе.
28.6.2. Определение состава автономной конфигурации
Для настройки состава автономной конфигурации предназначено свойство Состав автономной конфигурации. Данное свойство является свойством всей конфигурации.
При нажатии на гиперссылку Открыть, открывается диалог настройки состава:
Рис. 538. Состав автономной конфигурации
Как видно на рисунке, предоставляется возможность указать доступность в автономной конфигурации следующих объектов:
● Собственно объекты конфигурации. В состав автономной конфигурации могут входить все объекты конфигурации, которые поддерживаются мобильной платформой системы «1С:Предприятие».
● Реквизиты объекта конфигурации, табличные части и реквизиты табличных частей.
● Форм, команды и макеты объекта конфигурации.
При настройке автономного мобильного клиента разработчик может указать, какой сервер системы будет преимущественно использоваться для работы с тем или иным объектом. Эта настройка выполняется с помощью указания приоритета использования объекта. Приоритет использования объекта автономной конфигурации может задаваться:
● Для следующих объектов конфигурации в целом:
● Общие модули.
● Планы обмена.
● Подписки на события.
● Общие формы.
● Общие команды.
● Хранилища настроек.
● Константы.
● Справочники.
● Документы.
● Журнал документов.
● Перечисления.
● Отчеты.
● Обработки.
● Планы видов характеристик.
● Регистры сведений.
● Регистры накопления.
● Для формы объекта конфигурации.
● Для команды объекта конфигурации.
Приоритет задается в одноименной колонке и может принимать следующие значения:
● Основной сервер ‑ в этом случае система «1С:Предприятие» старается использовать для доступа к объекту основной сервер системы.
● Автономный сервер ‑ в этом случае система «1С:Предприятие» старается использовать для доступа к объекту конфигурации автономный сервер.
● Авто ‑ данное значение трактуется как Основной сервер для типообразующих объектов конфигурации и как значение типообразующего объекта ‑ если описывается объект, подчиненный типообразующему объекту.
Если для объекта конфигурации, например, справочник Товары указан приоритет Автономный сервер, а для формы элемента этого справочника указан приоритет Авто, то на реальном мобильном устройстве для формы элемента будет использоваться приоритет Автономный сервер. Если для справочника Товары изменить значение приоритета на значение Основной сервер ‑ приоритет для формы изменится автоматически.
Колонка Обмен данными предназначена для включения объекта конфигурации в состав автоматического обмена данными с автономной конфигурацией. Изменение значения этой колонки становится возможным после того, как в диалоге Настройки обмена автономной конфигурации будет выбран план обмена. Колонка Обмен данными может изменяться только для всего объекта целиком, и позволяет указать, что изменение объектов этого типа будет фиксироваться планом обмена для автоматического обмена между основной и автономными информационными базами. Если данный флажок включен, то становятся доступными следующие настройки:
● Авторегистрация ‑ позволяет задать автоматическую регистрацию изменения объекта в плане обмена при изменении объекта. Если флажок сброшен, то регистрацию объекта в плане обмена необходимо выполнять с помощью метода ЗарегистрироватьИзменения() менеджера плана обмена. Данное свойство полностью аналогично свойству Авторегистрация плана обмена.
● Корректировка кодов/номеров ‑ позволяет указать, что будет происходить с номером или кодом объекта конфигурации в том случае, если для кода или номера объекта настроена уникальность кода или номера, а при обмене данными между автономной и основной информационными базами образовались дубликаты кодов или номеров. Если данное свойство установлено в значение Не корректировать ‑ никаких изменений не произойдет. Такую настройку рекомендуется устанавливать в том случае, если код или номер объекта является публичной информацией, например, сообщается клиенту. Если свойство установлено в значение Корректировать, то при записи объекта в информационную базу номер будет скорректирован по стандартным правилам: для текстового номера будет добавлен индекс, а для числового ‑ определено максимальное значение кода или номера, и оно будет увеличено на 1.
Если для автономной конфигурации задан неполный состав метаданных, то в автономном режиме это может привести к возникновению конфликтов. Эти конфликты разрешаются следующим образом:
● Если отсутствующие метаданные используются в объектах автономной конфигурации, то вместо ссылок на такие объекты будут внешние ссылки в следующих местах автономной конфигурации:
● В реквизитах объектов конфигурации.
● В общих реквизитах.
● В стандартном реквизите Владелец.
● В константах.
● Если ссылки на отсутствующие объекты конфигурации используются в каких-либо других механизмах системы, то такая ссылка будет удалена из следующих механизмов системы:
● Командный интерфейс конфигурации и подсистем.
● Состав подсистемы.
● Состав роли прав доступа.
● Состав плана обмена.
● Тип и состав критерия отбора.
● Характеристики справочников и документов.
● Движения документов.
● Состав журнала документов.
Кроме ручного выделения объектов, которые будут входить в состав автономной конфигурации, в диалоге управления составом автономной конфигурации доступны следующие команды:
● Включить все ‑ включает все объекты основной конфигурации в состав автономной.
● Выключить все ‑ исключает из состава автономной конфигурации все объекты.
● Подобрать связанные ‑ команда доступна для объекта основной конфигурации, выбранного в состав автономной конфигурации. Данная команда выбирает объекты основной конфигурации, которые используются в качестве типов реквизитов в выбранном объекте конфигурации. После окончания работы команды отображается диалог, в котором перечислены (и выбраны) выбраны все требуемые объекты. Если этот список устраивает ‑ нажатием кнопки ОК весь список будет добавлен в состав автономной конфигурации.
Если выполнить команду рекурсивно, то будут выбраны не только объекты конфигурации, которые используются непосредственно в текущем объекте, но и все объекты, которые используются в используемых объектах и т. д. Если команда выполнена не рекурсивно, значит, будут отобраны только те объекты, которые используются только в том объекте, для которого выполнена команда.
● Подобрать связанные для всех ‑ команда доступа в том случае, если есть хотя-бы один объект, включенный в состав автономной конфигурации. В этом случае для каждого объекта автономной конфигурации выполняется команда Подобрать связанные. В результате отображается диалог, включающий все подобранные объекты.
Смотри также:
● Обмен данными при работе (см. здесь).
28.6.3. Определение сервера при вызове
Особенностью мобильного клиента с автономным режимом является возможность использования в работе сразу двух серверных частей прикладного решения: автономный сервер и основной сервер. При вызове система анализирует ряд параметров системы, и на основании анализа принимает решение, какой сервер будет использоваться для выбора. Анализируется приоритет использования того или иного объекта, а также заданные режимы работы клиентского приложения. Анализ выполняется как для явного вызова сервера (например, при вызове метода серверного общего модуля), так и для неявного серверного вызова (например, при открытии формы).
Если серверный вызов инициируется со стороны клиентского приложения, то сервер определяется в момент вызова. Если «внутри» этого серверного вызова продолжаются серверные вызовы, то сервер не изменяется. Проиллюстрируем сказанное примерами.
Допустим, существует форма справочника Товары, для которой установлен приоритет использования Автономный сервер. Существует серверный общий модуль СМ1 с приоритетом Основной сервер. Существует серверный модуль СМ2, который не включен в состав автономной конфигурации.
Давайте рассмотрим, какой сервер будет использоваться при выполнении различных действий:
● Клиентское приложение выполняет открытие формы справочника Товары. Т. к. у формы выбран приоритет Автономный сервер, то для открытия формы будет выбран автономный сервер. Данные для отображения формой также будут получаться с автономного сервера.
● Если в форме элемента справочникаТовары вызывается любой (контекстный или внеконтекстный) серверный метод модуля формы ‑ он будет исполнен на автономном сервере.
● Если в форме элемента справочника Товары, из клиентского метода модуля формы вызывается метод общего модуля СМ1, то будет вызван основной сервер или сгенерировано исключение. Вызов будет выполнен, если автономное мобильное приложение подключено к основному серверу, т. к. у общего модуля СМ1 установлен приоритет Основной сервер.
● Если вызов метода общего модуля СМ1 будет выполнен из серверного метода формы элемента справочника Товары, то будет использоваться автономный сервер. Это происходит потому, что серверный вызов из серверного вызова использует сервер, который выбран для самого первого серверного вызова (в нашем примере это автономный сервер).
● Если в форме элемента справочника Товары, клиентский метод пытается вызвать метод общего модуля СМ2, то, аналогично общему модулю СМ1, вызов будет выполнен только при наличии подключения. Причиной этого будет являться то, что общий модуль СМ2 не указан в составе автономной конфигурации.
Несмотря не все вышесказанное, могут возникать ситуации, когда необходимо изменить сервер, который будет использоваться для вызова. Система «1С:Предприятие» позволяет выполнить такую «замену» в некоторых случаях:
● Необходимость вызвать серверный метод основного сервера из метода, который выполняется на стороне автономного сервера. В этом случае можно использовать свойство глобального контекста ОсновнойСервер. С помощью данного свойства на автономном сервере доступны серверные общие модули основного сервера. В этом случае вызов будет выглядеть следующим образом: ОсновнойСервер.ИмяСереверногоОбщегоМодуля.ИмяМетодаОбщегоМодуля().
● Необходимо на стороне клиентского приложения выполнить серверный вызов, который будет использовать строго основной или строго автономный сервер, вне зависимости от текущих параметров. Для этого существуют методы глобального контекста УстановитьИспользуемыйСервер() или УстановитьПреимущественноеИспользованиеОсновногоСервера() (подробнее см. здесь).
● На форме клиентского приложения существует реквизит, тип которого не включен в состав автономной конфигурации. В этом случае открытие формы приведет к тому, что будет использован основной сервер, вне зависимости от того, с использованием какого сервера открыта форма, в которой отображается реквизит.
28.6.4. Форма автономного мобильного приложения
При разработке формы прикладного решения, которая должна работать в мобильном клиенте с автономным режимом, необходимо учитывать общие особенности поведения формы на мобильном устройстве, так и некоторые особенности поведения формы в мобильном клиенте с автономным режимом.
К этим особенностям относятся:
● Изменение поведения элементов формы при недоступности основного сервера.
● Возможность переоткрытия формы при изменении доступности основного сервера.
В том случае, если во время работы с открытой формой меняется доступность основного сервера, то поведения системы зависит от того, с какого сервера выполнялось открытие этой формы:
● Определение сервера, с которого открыта форма, можно выполнить с помощью свойства формы клиентского приложения ИспользуемыйСерверФормы.
● Форма открыта с основного сервера:
● Форма становится недоступной.
● Вызывается событие формы ПриИзмененииДоступностиОсновногоСервера.
● Для формы остается доступной команда Закрыть. Если у формы есть аналог в автономной конфигурации ‑ становится доступной команда Открыть автономно.
● Форма открыта с автономного сервера:
● Элементы, ведут себя в зависимости от значения свойства элемента формы ПоведениеПриНедоступностиОсновногоСервера. Свойство может принимать следующие значения:
● ОтключатьДоступность ‑ элементы с таким значением свойства становятся недоступными после того, как основной сервер становится недоступным.
● НеИзменятьПоведение ‑ элементы с таким значением свойства остаются доступными. Для элементов, связанных с внешней ссылкой, при обращении к ним поведение определяется автономной конфигурацией. Стандартная обработка выбора будет приводить к ошибке. В то же время стандартная обработка может быть переопределена.
● Авто ‑ трактуется следующим образом:
● Элементы, связанные с внешней ссылкой ‑ аналогично ОтключатьДоступность.
● Остальные элементы ‑ аналогично НеИзменятьПоведение.
В том случае, если в интерфейсе формы нажимается кнопка Открыть автономно (или вызывается метод ПереоткрытьСДругогоСервера()), выполняются следующие действия:
● У текущей формы (в которой нажата кнопка) вызывается обработчик события ПередПереоткрытиемСДругогоСервера. В обработчик события передаются все параметры, которые использовались при открытии текущей формы. Разработчик может модифицировать список параметров. Если при выходе из события параметр Отказ установлен в значение Истина ‑ форма не будет переоткрыта.
● Создается новая (автономная) форма. При этом срабатывают все серверные события создаваемой формы.
● У новой (только что созданной) формы вызывается обработчик события ПриПереоткрытииСДругогоСервера. В обработчик события передается переоткрываемая форма и параметры заполнения. Если параметр СтандартнаяОбработка обработчика события установлен в значение Истина ‑ платформа выполнит перенос данных из «старой» формы в новую форму, опираясь на значение параметра ПараметрыЗаполнения. Если параметр СтандартнаяОбработка установлен в значение Ложь, это означает, что разработчик самостоятельно должен выполнить перенос данных из «старой» формы. Для формирования списка копируемых реквизитов можно использовать объект ПараметрыЗаполненияПриПереоткрытииФормы, а для заполнения данных «новой» формы из данных «старой» ‑ метод ЗаполнитьПриПереоткрытииСДругогоСервера().
● Вызывается обработчик события ПриОткрытии новой формы и все остальные события, в соответствии с протоколом открытия формы.
● Состояние «старой» формы зависит от ее режима открытия и места расположения:
● Независимая форма ‑ будет закрыта сразу после завершения открытия новой формы. При этом обработчик события ПриЗакрытии вызывается, обработчик ПередЗакрытием не вызывается. Если для «старой» формы установлено свойство ОписаниеОповещенияОЗакрытии, то значение этого свойства будет передано новой форме. Оповещение будет вызвано при закрытии уже новой формы.
● Блокирующая форма ‑ будет закрыта после закрытия новой формы. При этом обработчик события ПриЗакрытии вызывается, обработчик ПередЗакрытием не вызывается.
● Форма размещена на начальной странице ‑ форма останется на начальной странице. Новая форма будет открыта в независимом режиме.
При переоткрытии формы следует помнить о следующих особенностях:
● Не изменяются владелец формы и параметры открытия формы.
● Не переносятся значения реквизитов следующих типов:
● Диаграмма,
● Табличный документ,
● Планировщик.
● Данные следующих типов переносятся в том случае, если они (данные) полностью загружены в оперативную память:
● Табличная часть,
● Список значений,
● Таблица значений,
● Дерево значений.
28.6.5. Обмен данными при работе
28.6.5.1. Общая информация
Мобильный клиент с автономным режимом должен выполнять регулярный обмен данными между основной и автономными частями прикладного решения. Это необходимо для того, чтобы поддерживать актуальность используемых данных. При работе системы требуется синхронизация:
● Данные из основной информационной базы должны передаваться в автономную базу. Эти данные должны передаваться в объеме, достаточном для заполнения данных объектов автономной конфигурации.
● Данные из автономной информационной базы в основную информационную базу. Это те данные, которые вносились в информационную базу во время автономной работы мобильного приложения.
С точки зрения синхронизации лучше рассматривать обе части решения (автономная и основная части) как разные узлы механизма обмена данными системы «1С:Предприятие». Тогда требования обмена ложатся на готовую и известную инфраструктуру:
● Для регистрации изменений служит план обмена. При этом план обмен может не участвовать в распределенной информационной базе.
● Для передачи данных между автономной и основной частями информационной базы служит стандартная инфраструктура сообщений или стандартные инструменты доступа к списку зарегистрированных изменений.
Состав плана обмен должен включать те объекты, которые отмечены в составе автономной конфигурации. Для каждой информационной базы автономного мобильного приложения, в основной информационной базе должен существовать соответствующий элемент плана обмена.
Таким образом, общая схема работы выглядит следующим образом:
● Первый запуск мобильный клиента с автономным режимом всегда осуществляется при наличии соединения с основным сервером.
● При первом запуске мобильный клиент с автономным режимом дает команду основному серверу на создание автономной информационной базы для мобильного клиента. Во время создания информационной базы приложение работает без возможности перехода в автономной режим, как обычный мобильный клиент. На сервере выполняются следующие действия:
● Создается автономная информационная базы для мобильного устройства.
● В выбранном плане обмена основной информационной базы создается узел плана обмена (при необходимости).
● В автономной информационной базе создается узел обмена, относящийся к основной информационной базе.
● Выполняется первоначальное заполнение автономной информационной базы данными из основной информационной базы.
● После завершения формирования автономной информационной базы, она передается на мобильное устройство, и мобильный клиент предлагает выполнить перезапуск мобильного клиента для начала работы в полноценном режиме (с возможностью перехода в автономный режим и обратно).
● Во время работы выполняется регулярная синхронизация данных между основной и автономной информационными базами. Интенсивность обмен определяется настройками состава автономной конфигурации.
Более подробно рассмотрим все составляющие схемы работы.
Рис. 539. Настройка обмена автономной конфигурации
Настройка обмена данными для автономного мобильного клиента состоит из нескольких шагов:
1. Создание плана обмена, который будет использоваться для регистрации измененных объектов. Этот план обмена следует указать в поле План обмена диалога Настройка обмена формы настройки состава автономной конфигурации. После этого станет доступно указание параметров автоматического обмена данными. Эта настройка состоит из двух частей:
1. Настройка собственно плана обмена:
● В настройках состава автономной конфигурации указать те объекты, которые будут входить в состав автономной конфигурации и для которых будут фиксироваться изменения данных. Для этого предназначена колонка Обмен данными.
● Задать необходимость автоматической регистрации объекта для обмена с мобильным клиентом (колонка Авторегистрация).
● Указать, каким образом будет разрешаться конфликт номеров или кодов объектов во время обмена (колонка Корректировка кодов/номеров).
2. Настройка параметров автоматического обмена между основной и автономной информационными базами:
● Выполнять обмен после записи. Данный флажок указывает, что необходимо выполнить обмен данными сразу после записи объекта, который входит в состав плана обмена, который указан в свойстве План обмена.
● Период обмена ‑ указывает, с каким интервалом будет выполняться обмен данными между автономной и основной информационными базами.
● Элементов в транзакции ‑ указывает, какое количество измененных объектов будет обработано в рамках одной транзакции получения данных. Если требуется записать в базу данных больше объектов, чем указано в данном свойстве ‑ будет сформировано несколько транзакций. Параметр аналогичен параметру ЭлементовВТранзакции метода ЗаписатьИзменения() менеджера плана обмена.
● Свойство Удалять неиспользуемые узлы автоматически через ХХ дней указывает, что узел плана обмена, с которым обмен не выполнялся указанное количество дней, будет автоматически удален системой. При анализе времени обмена используется свойство ДатаОбмена, которое заполняется только для плана обмена, который используется для обмена данными с мобильными клиентами с автономным режимом.
2. Реализация одной из стратегий начального формирования автономной информационной базы.
3. Реализация одной из стратегий регулярного обмена данными между автономной и основной информационными базами.
Разработчик может использовать различные события модуля плана обмена для того, чтобы управлять выгрузкой данных в автономную информационной базу. Состав событий отличается при создании автономной информационной базы и при синхронизации информации.
Новый узел распределенной информационной базы создается в том случае, если к основной информационной базе подключается мобильный клиент от имени пользователя, для которого еще не создан узел (или этот узел уже удален). В этом случае вызываются обработчики следующих событий элемента плана обмена:
● ПриАвтоматическомСозданииНовогоУзла. Данное событие вызывается после того, как платформа создала новый элемент плана обмена, но еще не записала его. К моменту вызова обработчика события, у элемента заполнены все стандартные реквизиты. При этом реквизит Код равен:
● Код плана обмена текстовый ‑ значению свойства Имя пользователя информационной базы, который запускает мобильного клиента с автономным режимом. Если такой код уже существует, то код будет модифицирован стандартным, для аналогичной ситуации, образом.
● Код плана обмена цифровой ‑ максимальное значение среди всех кодов плана обмена, увеличенное на 1.
Наименование плана обмена заполняется значением свойства ПолноеИмя пользователя информационной базы.
Если при выходе из обработчика параметр Отказ установлен в значение Ложь, то выполняется сохранение узла плана обмена в информационной базе и создание автономной информационной базы продолжается. Если параметр Отказ установлен в значение Истина, то создание автономной информационной базы не выполняется, и мобильный клиент продолжает работу именно в этом режиме, без попытки создания автономной информационной базы.
● ПередСозданиемНачальногоОбраза. Данное событие вызывается перед тем, как начнется создание образа автономной информационной базы. В обработчик передается параметр ТолькоЗарегистрированные, который управляет возможностью передачи в автономную базу всех данных основной базы (значение Ложь) или только тех данных, которые зарегистрированы для передачи (значение Истина). Этот параметр управляет поведением системы после завершения работы обработчика события.
Если необходимо записать в начальный образ какие-то специфические данные, которые, например, не фиксируются планом обмена, но нужны на автономной стороне, то это можно сделать в этом же обработчике. Для этого предназначен параметр ПотокДанныхОбмена. Метод ПотокДанныхОбмена.Записать() приведет к тому, что записываемый объект будет сразу размещен в автономной информационной базе.
Таким образом, после окончания работы обработчика события ПередСозданиемНачальногоОбраза в начальный образ будут помещены те объекты, которые записывались с помощью потока данных обмена и начнется обработка всех объектов основной информационной базы, которые надо поместить в начальный образ. Состав объектов определяется значением параметра ТолькоЗарегистрированные, при этом в обработчике события ПриОтправкеДанныхПодчиненному имеется возможность продолжить фильтрацию объектов.
● ПриОтправкеДанныхПодчиненному. Штатное событие, возникающее при обмене данных с помощью распределенной информационной базы.
Во время регулярного обмена данными используется стандартный набор событий, сопровождающий обмен данными. Собственно обмен данными может быть инициирован следующим образом:
● Запуском мобильного клиента на мобильном устройстве.
● Автоматический запуск обмена с интервалом, который указан в настройках обмена автономной конфигурации (параметр Период обмена).
● При записи объекта данных, если объект входит в состав плана обмена с автономной конфигурацией и указан параметр Выполнить обмен при записи в настройках обмена автономной конфигурации.
● С помощью вызова метода ОбменДаннымиСОсновнымСервером.ВыполнитьОбмен().
После того, как обмен завершен и в этом обмене передавались какие-либо данные, будет вызван обработчик события ПослеОбменаДаннымиСОсновнымСервером модуля приложения. Обработчик получит в качестве параметров признак отображения оповещений о выполнении обмена и дату и время последнего успешного обмена данными. Для обмена в активном приложении дата обмена будет соответствовать текущему времени.
28.6.5.2. Интервал обмена данными
Остановимся подробнее на периодичности обмена данными. Есть два различных интервала времени, используемых в обмене данными. Эти интервалы работают отдельно друг от друга.
Первый интервал времени задается свойствами Период обмена и Выполнять обмен после записи настроек автономного плана обмена. Эти настройки используются в том случае, когда приложение активно (с приложением работает пользователь на экране мобильного устройства). В этом случае обмен выполняется через интервалы времени, указанные в свойстве Период обмена. Если при этом установлен флаг Выполнять обмен после записи, то интервал времени Период обмена начинает измеряться после записи любого объекта информационной базы, участвующего в обмене. При выполнении такого обмена срабатывают все обработчики модуля плана обмена (серверные обработчики) и обработчик события ПослеОбменаДаннымиСОсновнымСервером модуля приложения (клиентский обработчик).
Если приложение переведено в фоновый режим или пользователь вышел из конкретного приложения в список приложений данного мобильного приложения, то рассмотренный выше интервал обмена перестает работать. В этом случае обмен осуществляется каждые 15 минут. Этот интервал не может быть настроен разработчиком, но может быть изменен мобильной операционной системой в соответствии со своими внутренними алгоритмами. В этом случае будут срабатывать все серверные обработчики обмена (модуль плана обмена), но не будет вызываться клиентский обработчик модуля приложения, т. к. в этом случае не запущено клиентское приложение. Однако при запуске клиентского приложения будет вызван обработчик события модуля приложения ПослеОбменаДаннымиСОсновнымСервером, если в фоновом режиме был выполнен хотя-бы один обмен данными. При этом в качестве значения формального параметра ДатаОбмена обработчика будет выступать дата и время последнего непустого обмена данными, который выполнен в фоновом режиме.
Также стоит отметить, что фоновый обмен выполняется по очереди для всех информационных баз, зарегистрированных в приложении. Для выполнения фонового обмена на устройствах фирмы Apple требуется, чтобы версия ОС iOS была не ниже 13. При работе под управлением ОС Android фоновый обмен поддерживается даже в том случае, если мобильное приложение вообще не запущено на устройстве.
28.6.5.3. Формирование начального образа автономной информационной базы
Можно выделить несколько вариантов формирования начального образа автономной информационной базы. Следует понимать, что приведенный список вариантов не является исчерпывающим, а предназначен лишь для описания некоторых характерных случаев:
● Вариант 1:
● Никакая фильтрация данных не используется.
● В начальный образ попадают все данные основной информационной базы.
● Такой вариант можно применять в том случае, если все информационные базы автономных мобильных клиентов идентичны основной информационной базе.
● Вариант 2:
● Фильтрация объектов, которые должны попасть в начальный образ автономной информационной базы выполняется в обработчике события ПриОтправкеДанныхПодчиненному.
● В начальный образ будут передаваться все данные основной информационной базы.
● Такой вариант можно применять в том случае, если при формировании начального образа требуется минимальная фильтрация данных, в начальный образ должно попасть большинство данных основной информационной базы.
● Вариант 3:
● В начальный образ автономной информационной базы попадают только те объекты, которые зарегистрированы в плане обмена. Для этого в обработчике события ПередСозданиемНачальногоОбраза необходимо установить параметр ТолькоЗарегистрированые в значение Истина. Все необходимые данные регистрируются в плане обмена в этом же обработчике. Для этого следует использовать метод ЗарегистрироватьИзменения() менеджера плана обмена.
● В начальный образ попадают только зарегистрированные данные основной информационной базы.
● Такой вариант можно применять в том случае, когда данных для передачи в начальный образ автономной информационной базы существенно меньше, чем общий объем данных в основной информационной базе.
● Вариант 4:
● В начальный образ автономной информационной базы попадают только те объекты, которые зарегистрированы в плане обмена. Для этого в обработчике события ПередСозданиемНачальногоОбраза необходимо установить параметр ТолькоЗарегистрированые в значение Истина. Однако, т. к. новый узел плана обмена создан только-что, то для этого узла нет ни одного зарегистрированного объекта данных. Значит данные, которые необходимо все-таки передать в начальный образ, следует записывать вручную, с помощью параметра ПотокДанныхОбмена обработчика события создания начального образа.
● Такой вариант можно применять в том случае, когда данных для передачи в начальный образ автономной информационной базы существенно меньше, чем общий объем данных в основной информационной базе и не требуется никаких дополнительных преобразований данных.
● Вариант 5:
● Является комбинаций двух предыдущих вариантов (3 и 4). В этом случае совмещается регистрация в плане обмена нужных элементов и прямая запись других объектов в самом обработчике.
28.6.5.4. Способы обмена данными
Для регулярного обмена информацией между автономной и основной информационными базами также можно использовать несколько различных вариантов. Следует понимать, что приведенный список вариантов не является исчерпывающим, а предназначен лишь для описания некоторых характерных случаев:
● Вариант 1:
● Никакая фильтрация данных не используется.
● В обмен попадают все данные обеих информационных баз.
● Такой вариант можно применять в том случае, если все информационные базы автономных мобильных клиентов идентичны основной информационной базе.
● Вариант 2:
● Фильтрация данных при обмене выполняется в обработчике события ПриОтправкеДанныхПодчиненному/ПриОтправкеДанныхГлавному.
● Позволяет реализовать практически любой сценарий фильтрации.
● Вариант 3:
● В плане обмена выключается автоматическая регистрация объектов.
● Для включения в пакет обмена используется или принудительная регистрация в самом объекте или используется обработчик события ПередНачаломОтправкиДанныхПодчиненному/ ПередНачаломОтправкиДанныхГлавному.
Смотри также:
● Настройка состава автономной конфигурации (см. здесь).
● Использование планов обмена (см. здесь).
28.6.6. Переключение между автономным и основным серверами
В процессе работы мобильного клиента с автономным режимом могут использовать одновременно и автономный и основной сервер. Прикладное решение может определить доступность основного сервера, может вызвать основной сервер из кода, выполняющегося на автономном сервере, но не может вызвать автономный сервер из кода, выполняющего на основном сервере.
Для определения доступности основного сервера предназначен метод глобального контекста ОсновнойСерверДоступен().
При нахождении на автономном сервере, предоставляется возможность вызвать метод основного сервера, который доступен в серверном общем модуле основного сервера. Для этого существует свойство глобального контекста ОсновнойСервер. Вызов будет выглядеть следующим образом ОсновнойСервер.ИмяОбщегоМодуля.ИмяМетода(). Если основной сервер недоступен ‑ будет выброшено исключение.
Когда клиентской части автономного мобильного приложения требуется вызвать сервер, то вызов будет выполнен в соответствии с установленными приоритетами автономной конфигурации. Однако система предоставляет возможность явно указать используемый сервер с помощью метода УстановитьИспользуемыйСервер().
Данный метод работает следующим образом:
● Если при вызове метода явно указывается используемый сервер ‑ устанавливается использование. Под явным указанием сервера понимаются значения системного перечисления ИспользуемыйСервер.
● Если при вызове метода указано значение Неопределено ‑ устанавливается тот режим вызова сервера, который был до последней установки используемого сервера.
● При выходе из метода, в котором изменялся используемый сервер ‑ устанавливается использование того сервера, который был до входа в метод.
Рассмотрим пример:
УстановитьИспользуемыйСервер(ИспользуемыйСервер.Основной); // строка 1 УстановитьИспользуемыйСервер(ИспользуемыйСервер.Автономный); // строка 2 УстановитьИспользуемыйСервер(Неопределено); // строка 3
После строки строка 1, в качестве используемого сервера будет установлен основной сервер. После строки строка 2, в качестве используемого сервера будет установлен автономный сервер.
После строки строка 3 будет использован сервер, который был до использования последней установки сервера. Таким образом, будет установлен основной сервер, т. к. предпоследняя установка используемого сервера (строка 1) выбирала основной сервер.
Получить используемый сервер можно с помощью метода ПолучитьИспользуемыйСервер().
Как было сказано выше, явная установка используемого сервера с помощью метода УстановитьИспользуемыйСервер(), действует до завершения работы метода, в котором эта установка была выполнена. Это не всегда удобно. Иногда может потребоваться перевести все мобильное приложение на использование основного сервера, например, в том случае, когда не до конца выполнена начальная инициализация автономных данных. Для указания необходимости преимущественного использования основного сервера предназначен метод глобального контекста УстановитьПреимущественноеИспользованиеОсновногоСервера(). У этого метода есть две важных особенности:
1. Действие метода распространяется на все приложение, а не только на текущий метод.
2. Метод УстановитьПреимущественноеИспользованиеОсновногоСервера() сработает только в том случае, если в текущем стеке еще не было вызова метода УстановитьИспользуемыйСервер().
Тогда схема работы выглядит следующим образом:
● Определяется, что выполнен первый запуск автономного мобильного приложения. Устанавливается преимущественное использование основного сервера.
● Запускается фоновое задание начального заполнения автономных данных, в рамках которого используется метод УстановитьИспользуемыйСервер() для того, чтобы процедура заполнения автономных данных использовала для своей работы автономный сервер.
● После завершения заполнения отключается преимущественное использование основного сервера.
28.6.7. Особенности использования автономного мобильного приложения
28.6.7.1. Обновление конфигурации на мобильном устройстве
Первый запуск мобильного клиента с автономным режимом невозможен в автономном режиме. Для первого запуска всегда требует устойчивый канал связи с основной информационной базой, т. к. при первом запуске выполняется загрузка автономной конфигурации.
Далее, при каждом запуске клиентского приложения, а также при создании/восстановлении соединения между мобильным приложением и основным сервером, выполняется проверка наличия обновления автономной конфигурации. Могут наблюдаться один из следующих сценариев:
1. Обновление обнаружено во время запуска клиентского приложения, до начала фактического использования:
● Обновление автономной конфигурации автоматически скачивается на устройство.
● Конфигурация автономной информационной базы обновляется скачанной конфигурацией.
2. До подключения к основному серверу, клиент работал в автономном режиме с возможностью подключения к основному серверу:
● Пользователю предлагается подтвердить обновление конфигурации.
● Если пользователь соглашается с предложением, то обновление автономной конфигурации скачивается на мобильное устройство, клиентское приложение перезапускается и после перезапуска выполняется обновление автономной информационной базы скачанной конфигурацией.
● Если пользователь отказывается от обновления, то клиентское приложение продолжает работу со старой версией автономной конфигурации, без возможности подключения к основному серверу (фактически ‑ в автономном режиме).
3. Если обновление конфигурации обнаруживается во время очередного подключения к основному серверу (без автономной работы), то выполняется завершение текущего сеанса и дальнейшая работа выполняется по предыдущему сценарию работы.
28.6.7.2. Внешние ссылки
Внешние ссылки ‑ это ссылки на объекты, которые не включены в состав автономной конфигурации, но сами эти ссылки используются в автономных объектах. В качестве внешних ссылок могут выступать ссылки на любые объекты конфигурации, в том числе и на те, которые не доступны на мобильном устройстве. На мобильном устройстве не поддерживается какая-либо работа с автономными ссылками: получение значений реквизитов, получение объекта и т. д. Фактически, внешние ссылки предназначены для отображения представления реальных данных в соответствующих полях формы. В результате пользователь не будет волноваться из-за «потери» данных.
Если поле формы отображает данные, которые являются внешней ссылкой, то:
● При отсутствии соединения с основным сервером:
● Поле становится недоступным.
● Представление ссылки кешируется в то время, когда подключение есть.
● Если сохраненного представления внешней ссылки нет на мобильном устройстве, то в виде представления выступает сообщение о недоступности информации.
● При наличии соединения с основным сервером
● Ссылка доступна для использования.
● При использовании идет обращение к основному серверу.
28.6.7.3. Командный интерфейс
Если команда не выбрана в состав автономной конфигурации, то такая команда будет недоступна в автономном режиме. Если команда включена в состав автономной конфигурации, то в ее (команды) доступность в автономном режиме определяется свойством команды Поведение при недоступности основного сервера. Если это свойство установлено в значение Авто, то это трактуется как значение Не изменять поведение. Если для команды недоступно редактирование свойств, то для них используется значение Не изменять поведение.
28.6.7.4. Пользователи
Мобильный клиент с автономным режимом не поддерживает работу с пользователями. В то же время, при запуске приложения выполняется запрос пользователя и пароля. Аутентификация будет выполняться основным сервером. Если при следующем запуске приложения будет указан пользователь, отличающийся от пользователя, который был указан при первом (после создания информационной базы) входе в базу, то будет выдано сообщение об ошибке. Таким образом, если на одном мобильном устройстве с одной основной информационной базой работают несколько пользователей ‑ для каждого пользователя необходимо создать собственную информационную базу (приложение) на мобильном устройстве.
Если у пользователя, от имени которого выполняется вход в основную базу, был изменен пароль, то автономная часть узнает об этом, только после успешной аутентификации на основном сервере.
28.6.7.5. История
История хранится в информационной базе и на основном сервере, и на автономном. Если мобильное устройство имеет доступ к основному серверу ‑ история сохраняется сразу в обоих информационных базах. Если мобильное устройство не имеет доступ к основному серверу ‑ история сохраняется только в автономной информационной базе. После получения доступа к основному серверу выполняется объединение историй и сохранение их в обоих информационных базах.
28.6.7.6. Избранное
Избранное хранится в информационной базе и на основном сервере, и на автономном. Если мобильное устройство имеет доступ к основному серверу ‑ избранное сохраняется сразу в обоих информационных базах. Если мобильное устройство не имеет доступ к основному серверу ‑ избранное сохраняется только в автономной информационной базе. После получения доступа к основному серверу выполняется объединение списка избранного и сохранение его в обоих информационных базах.
28.7. Взаимодействие с мобильным устройством при разработке
28.7.1. Общая информация
Помещение мобильного приложения на мобильное устройство возможно несколькими способами:
● Через фирменный магазин приложений App Store (https://itunes.apple.com/ru/genre/ios), Google Play (https://play.google.com/) или Microsoft Store (https://``www.``microsoftstore.``com). Данный способ используется для распространения публичных версий мобильных приложений. Описание подготовки прикладного решения к публикации см. здесь.
Подготовленное к публикации мобильное приложение одобряется и публикуется по правилам соответствующего магазина приложений. Подробности этого процесса в данной книге не рассматриваются.
● С помощью мобильной версии «1С:Предприятия» для разработчика. Этот способ используется только для разработки мобильных приложений. Далее будет рассмотрен этот способ.
Для того чтобы начать использовать мобильную версию «1С:Предприятия», необходимо выполнить некоторые действия:
● на мобильное устройство должна быть установлена мобильная версия «1С:Предприятия» для разработчика;
● мобильное приложение опубликовано на веб-сервере;
● на мобильном устройстве создана информационная база (приложение) на основе опубликованного мобильного приложения.
После выполнения этих операций получается готовая инфраструктура для разработки и исполнения мобильного приложения на мобильном устройстве. При этом система может быть настроена таким образом, что обновление конфигурации будет приводить к тому, что мобильная версия «1С:Предприятия» для разработчика автоматически обновит конфигурацию на мобильном устройстве.
Далее будет более подробно рассмотрено каждое действие.
28.7.2. Установка инструментов разработчика
28.7.2.1. Общая информация
В зависимости от разрабатываемой конфигурации, разработчику могут потребоваться различные инструменты разработчика:
● Для разработки мобильного приложения ‑ мобильная платформа разработчика.
● Для разработки мобильного приложения ‑ мобильный клиент разработчика.
● Для разработки мобильного приложения с автономным режимом ‑ мобильный клиент разработчика с автономным режимом.
Собственно алгоритмы формирования инструментов разработчика одинаковы и для мобильной платформы, и для мобильного клиента. Различия присутствуют только в именах файлов, которые необходимо использовать в том или ином случае. Так, если для подготовки мобильной платформы разработчика для ОС iOS необходимо из дистрибутива мобильной версии «1С:Предприятия» (файл mobile.``zip) получить файл prjios.``zip, то в случае мобильного клиента следует использовать файл prjios_``client.``zip, а для мобильного клиента с автономным режимом будет нужен файл prjios_``standalone.``zip.
В таблице приведено соответствие имен файлов для разных видов клиентского приложения мобильной версии системы «1С:Предприятие»:
|
Мобильная операционная система Вид клиентского приложения |
Имена файлов |
|
Android |
|
|
Мобильная платформа |
|
|
Мобильный клиент |
|
|
Мобильный клиент с автономным режимом |
|
|
iOS |
|
|
Мобильная платформа |
|
|
Мобильный клиент |
|
|
Мобильный клиент с автономным режимом |
|
|
Windows |
|
|
Мобильная платформа |
|
|
Мобильный клиент |
|
|
Мобильный клиент с автономным режимом |
|
В данной таблице:
● суффикс ‑arm, ‑arm64, ‑x86, ‑x64, ‑x86_64 означает архитектуру используемого процессора;
● суффикс ‑sim означает вариант, предназначенный для использования в эмуляторе устройства (только для разработки под ОС iOS).
28.7.2.2. Для ОС Android
Для разработки мобильного приложения для ОС Android необходимо выполнить следующие требования:
● Установить на компьютере Android Studio (http://developer.android.com/studio/index.html). Для работы платформы разработчика необходимо, чтобы на компьютере был установлен Android``SDK``Platform-``tools версии не ниже 26.
● Проверить, что нужные компоненты установлены, можно с помощью Android Studio. Для этого в стартовом окне необходимо выбрать Configure ‑ SDK``Manager. Для удобства работы можно включить флажок Show``Package``Details в открывшемся окне.
● На закладке SDK``Platforms можно проверить наличие нужных версий Android SDK.
Рис. 540. Выбор версий Android SDK
● Затем на закладке SDK``Tools необходимо указать Android``SDK``Build-``Tools, Android``SDK``Platform-``Tools. Рекомендуется устанавливать все инструменты (Tools) и, собственно, SDK согласованно. В этом случае все версии будут совместимы друг с другом. Желательно не устанавливать версии, которые являются не окончательными (rc, beta и т. д.). Такие версии не будут приниматься сборщиком как пригодные для использования. Например, на рис. 541 видно, что для Android``SDK``Build-``Tools доступно обновление до версии 31.0.0``rc5. Это обновление устанавливать не следует!
Рис. 541. Выбор версий инструментов (Tools)
● После выполненных установок нажатие кнопки OK или Apply приведет к запуску процесса установки необходимых компонентов. Перед началом процесса установки Android Studio запросит подтверждение установки выбранных компонентов (с указанием всего списка).
● На компьютере должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● Для работы необходимо мобильное устройство на Android, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной версии «1С:Предприятия» для разработчика на мобильное устройство, работающее под управлением Android, необходимо выполнить следующие действия:
● В настройках мобильного устройства необходимо установить следующие флажки:
● Неизвестные источники;
● Отладка через``USB;
● Скачать с сайта производителя и установить на компьютер USB-драйвер мобильного устройства;
● Подключить мобильное устройство к компьютеру;
● С помощью интерпретатора командной строки ОС Windows выполнить команду:
Пример для ARM-платформы:
%ANDROID_SDK%\platform tools\adb.exe install -r "<Каталог платформы>\1cem-arm.apk"
Пример для x86-платформы:
%ANDROID_SDK%\platform tools\adb.exe install -r "<Каталог платформы>\1cem-x86.apk"
Где, Каталог платформы ‑ каталог, в котором расположен соответствующий файл с мобильной версией «1С:Предприятия». Если мобильная версия «1С:Предприятия» уже установлена на мобильное устройство, то данная команда выполнит ее переустановку.
● Мобильная версия «1С:Предприятия» будет передана на мобильное устройство, и ее иконка появится в списке установленных приложений.
● Мобильное устройство можно отключить от компьютера и далее запускать систему нажатием на иконку «1С:Предприятие» в списке приложений мобильного устройства.
Для установки мобильной версии «1С:Предприятия» для разработчика можно воспользоваться командой конфигуратора:
● Для мобильной платформы: Главное меню``‑ Конфигурация``‑ Мобильное приложение``‑ Использование``Android``debug``bridge ‑ Установить мобильную платформу.
● Для мобильного клиента:Главное меню``‑ Конфигурация``‑ Мобильный клиент``‑ Использование``Android``debug``bridge ‑ Установить мобильный клиент.
В этом случае надо будет выполнить дополнительную настройку конфигуратора (подробнее см. здесь). Установку мобильной платформы можно выполнить или на физическое мобильное устройство, подключенное к компьютеру или на эмулятор устройства, созданный с помощью менеджера виртуальных устройств Android. Менеджер виртуальных устройств может быть запущен из Android Studio: Главное меню``‑ Tools ‑ Android ‑ AVD``Manager.
28.7.2.3. Для ОС iOS
Для разработки мобильного приложения для ОС iOS необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера фирмы Apple (далее ‑ Mac) с установленной операционной системой OS X 11 и последующие версии.
● На компьютере Mac должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● На этом компьютере необходимо установить средство разработки Xcode версии 12.5 и выше (https://developer.apple.com/xcode/).
● Необходимо зарегистрироваться в программе iOS Developer Program (https://developer.apple.com/programs/ios/).
● Для работы необходимо мобильное устройство на iOS, соответствующее системным требованиям (подробнее см. здесь).
Установка мобильной версии «1С:Предприятия» для разработчика на мобильное устройство, работающее под управлением iOS, выполняется путем выполнения следующих действий:
1. Установить на компьютер Mac пакет Xcode;
2. Запустить Xcode;
3. Добавить в Xcode учетную запись разработчика:
● Открыть настройки Xcode (команда Xcode ‑ Preferences) на вкладке Accounts.
● В левом нижнем углу формы нажать «+», в списке типов учетных записей выбрать Apple``ID, нажать кнопку Continue и в появившемся диалоге ввести имя пользователя и пароль Apple ID для учетной записи разработчика.
● После добавления учетной записи, в Xcode станут доступны команды разработчиков, которые привязаны к добавленной учетной записи.
4. Подключить мобильное устройство к компьютеру Mac;
5. Распаковать файл с необходимым проектом мобильной версии «1С:Предприятия» на компьютере Mac;
6. Открыть проект мобильной версии «1С:Предприятия» для разработчика в системе Xcode (двойным щелчком мыши по файлу 1``cem.``xcodeproj или выбрать файл 1``cem.``xcodeproj с помощью команды File ‑ Open);
7. В настройках проекта выбрать вкладку Signing &``Capabilities и в поле Team выбрать одну из команд разработчиков, которые стали доступны после добавления в Xcode учетной записи разработчика;
8. В поле Bundle``Identifier ввести идентификатор приложения;
9. Открыть инструмент Organizer с помощью команды меню Window ‑ Organizer;
10. В открывшемся окне, в панели слева выбрать подключенный телефон (отмечен зеленым маркером);
11. В панели снизу выбрать команду Add``to``Portal;
12. Средство Organizer запросит необходимые для телефона сертификаты и provisioning profile с сайта Apple и установит их на телефон автоматически. Потребуется ввести пароль разработчика, полученный при регистрации в iOS Developer Program.
13. С помощью команды Product ‑ Edit``Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся диалоге:
● В свойстве Scheme выбрать значение 1``cem;
● В свойстве Destination выбрать подключенный телефон;
● В свойстве Build``configuration выбрать значение Release;
● Нажать кнопку OK.
14. Запустить проект с помощью команды Product ‑ Run.
15. Мобильная версия «1С:Предприятия» будет передана на мобильное устройство, запущена и ее иконка появится в списке установленных приложений мобильного устройства.
Мобильное устройство можно отключить от компьютера Mac и далее запускать мобильную версию «1С:Предприятия» нажатием на иконку «1С:Предприятие» в списке приложений мобильного устройства. Если в момент отключения на мобильном устройстве была запущена мобильная версия «1С:Предприятия» для разработчика, которая запущена с помощью Xcode, то она будет остановлена.
28.7.2.4. Для ОС Windows
Для разработки мобильного приложения для ОС Windows необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера с установленной операционной системой Windows 8.1 и выше.
● Необходимо иметь учетную запись Microsoft (https://login.live.com/).
● Для работы необходимо устройство на Windows (планшет или компьютер с сенсорным экраном), соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной версии «1С:Предприятия» для разработчика на устройство, работающее под управлением Windows, необходимо выполнить следующие действия:
● Скопировать на устройство файл поставки мобильной версии «1С:Предприятия» (mobile.``zip).
● Извлечь из него файл сертификата ‑ 1``cem.``cer.
● Установить сертификат в хранилище Доверенные люди на локальной машине.
● Извлечь из файла поставки мобильной версии «1С:Предприятия» файл с необходимым дистрибутивом нужной архитектуры.
● Запустить PowerShell от имени администратора (прав администратора системы недостаточно);
● Выполнить команду:
Show WindowsDeveloperLicenseRegistration
В открывшемся окне указать данные учетной записи Microsoft;
● Выполнить команду:
Add AppxPackage <Каталог><имя файла>.appx
При этом:
● <Каталог> ‑ каталог, в который помещена мобильная версия «1С:Предприятия» для разработчика;
● <имя файла> ‑ имя устанавливаемой версии платформы (подробнее см. здесь).
● В дальнейшем запускать систему можно нажатием на иконку «1С:Предприятие» в списке приложений.
28.7.3. Публикация мобильного приложения на веб-сервере
28.7.3.1. Общая информация
Внимание! При работе с мобильным клиентом, действия, указанные в данном разделе, выполнять не требуется.
Чтобы мобильное приложение было доступно мобильной платформе, необходимо выполнить публикацию мобильного приложения на веб-севере. Фактически, публикация делится на две части:
● Подготовка инфраструктуры для работы и начальная выгрузка конфигурации мобильного приложения ‑ выполняется один раз.
● Обновление конфигурации мобильного приложения в подготовленной инфраструктуре.
Для подготовки инфраструктуры служит команда Конфигурация``‑ Мобильное приложение``‑ Публиковать…. В открывшемся диалоге следует указать флажок Создавать виртуальный каталог на веб-сервере. Если флажок не установлен, то будут недоступны реквизиты Имя и Каталог, а также при нажатии кнопки Опубликовать не будет выполняться создание виртуального каталога на веб-сервере.
Внимание! Для выполнения публикации требуются административные права.
Рис. 542. Публикация мобильного приложения
Затем указать свойства виртуального каталога веб-сервера:
● Имя ‑ определяет имя виртуального каталога. Это имя будет участвовать в URL конфигурации мобильного приложения для указания на мобильном устройстве при создании информационной базы.
● Веб-сервер ‑ определяет используемый веб-сервер. Если используется веб-сервер Microsoft Internet Information Services, то становится возможным указание флажка Использовать аутентификацию операционной системы на веб-сервере.
● Каталог ‑ указывает физический каталог на диске, в котором будет находиться файл конфигурации мобильного приложения в виде xml-файла и куда будет отображен виртуальный каталог веб-сервера.
Флажок Обновлять мобильное приложение при обновлении конфигурации базы данных управляет возможностью автоматического обновления конфигурации мобильного приложения при обновлении конфигурации базы данных. Если флажок установлен ‑ обновление будет выполняться.
Операцию обновления конфигурации также можно выполнить принудительно, с помощью команды Конфигурация``‑ Мобильное приложение``‑ Обновить публикуемое приложение. Если к моменту вызова данной команды публикация мобильного приложения не выполнялась ‑ будет открыт диалог публикации, описанный выше.
Внимание! На веб-сервере публикуется конфигурация базы данных, а не редактируемая конфигурация.
Для выполнения собственно публикации необходимо нажать кнопку Опубликовать. При этом выполняются следующие действия:
● Если установлен флажок Создавать виртуальный каталог на веб-сервере, то создается виртуальный каталог на веб-сервере;
● Создается каталог на диске, в который отображается виртуальный каталог;
● Предлагается выгрузить конфигурацию мобильного приложения в каталог (указанный в реквизите Каталог диалога публикации);
● Проверяется, соответствует конфигурация базы данных редактируемой конфигурации или нет;
● Если конфигурация информационной базы не соответствует редактируемой конфигурации ‑ предлагается выполнить обновление конфигурации базы данных. Однако эту операцию можно не выполнять, если требуется опубликовать именно конфигурацию базы данных;
● Выполняется проверка мобильного приложения (см. здесь);
● Если ошибок нет, то выполняется выгрузка конфигурации информационной базы в файл, в противном случае выгрузка не производится.
Файл с конфигурацией мобильного приложения, выгруженный с помощью команды Публиковать…, имеет фиксированное имя 1``cema.``xml. Поиск (и обновление) именно этого файла выполняется при выполнении команды Обновить публикуемое приложение. При создании виртуального каталога, файл конфигурации (1``cema.``xml) устанавливается в качестве его (каталога) страницы по умолчанию. Это позволяет в диалоге создания информационной базы на мобильном устройстве указывать URL в сокращенном виде.
Кнопка Отключить диалога публикации мобильного приложения выполняет отмену публикации: удаляет виртуальный каталог на веб-сервере и физический каталог.
28.7.3.2. Дополнительная информация о публикации
В каталоге публикации формируется следующая структура:
● 1``cema.``xml ‑ описание конфигурации, содержит данные о названии, языках и требуемых разрешениях.
● 1``Cv8.1``CM ‑ файл, предназначенный для ускорения создания информационной базы. Данный файл содержит собственно конфигурацию.
● Если конфигурация содержит внешние компоненты, то в каталоге публикации создается структура каталогов следующего вида (все каталоги и файлы являются необязательными):
● Android
● <ИмяВнешнейКомпоненты>.``xml
● ARM
● <ИмяВнешнейКомпоненты>.``so
● <ИмяВнешнейКомпоненты>.``apk
● ARM64
● <ИмяВнешнейКомпоненты>.``so
● <ИмяВнешнейКомпоненты>.``apk
● i386
● <ИмяВнешнейКомпоненты>.``so
● <ИмяВнешнейКомпоненты>.``apk
● x86_64
● <ИмяВнешнейКомпоненты>.``so
● <ИмяВнешнейКомпоненты>.``apk
● iOS
● <ИмяВнешнейКомпоненты>.``xml
● Universal
● <ИмяВнешнейКомпоненты>.``a
● <ИмяВнешнейКомпоненты>.``dylib
● WindowsRuntime
● <ИмяВнешнейКомпоненты>.``xml
● ARM
● <ИмяВнешнейКомпоненты>.``dll
● i386
● <ИмяВнешнейКомпоненты>.``dll
● x86_64
● <ИмяВнешнейКомпоненты>.``dll
Если конфигурация содержит несколько внешних компонент, то в каталоге публикации (в соответствующей структуре каталогов) будет столько уникальных наборов файлов, сколько внешних компонент находится в конфигурации.
Все файлы, которые образуются в результате публикации, являются неотъемлемой частью опубликованной конфигурации. Удаление, перемещение или переименование файлов приведет к нарушению работоспособности опубликованной конфигурации.
Для нормальной работы опубликованной конфигурации, на веб-сервере должны быть зарегистрированы типы MIME для следующих расширений:
● Выполняется конфигуратором при публикации:
● .``xml ‑ application/xml.
● .1``CM ‑ application/octet-stream.
● Необходимо регистрировать вручную при необходимости отладки внешних компонент:
● .``so ‑ application/octet-stream.
● .``apk ‑ application/octet-stream.
28.7.4. Запуск и перезапуск приложения на мобильной платформе
28.7.4.1. Общая информация
Запуск мобильного приложения осуществляется непосредственно на мобильном устройстве или из конфигуратора. На устройстве должна быть установлена мобильная версия «1С:Предприятия» для разработчика.
Запуск из конфигуратора возможен при одновременном выполнении двух условий: разработка выполняется с использованием ОС Android и выполнена соответствующая настройка конфигуратора (см. здесь).
28.7.4.2. Перезапуск мобильного приложения, опубликованного на веб-сервере
Если мобильное приложение запущено с помощью мобильной платформы разработчика и для приложения установлен флажок Перезапуск из конфигуратора (см. здесь), то существует возможность перезапускать мобильное приложение из конфигуратора. Это можно сделать с помощью команды главного меню Отладка``‑ Начало отладки``‑ Мобильное приложение: начать отладку или Отладка``‑ Начало отладки``‑ Мобильный клиент: начать отладку.
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
Используемые в конфигурации внешние компоненты также будут размещены в каталоге, на который отображается виртуальный каталог веб-сервера. Будут копироваться только те файлы внешней компоненты, которые предназначены для использования на ОС Android и iOS (если таковые существуют в составе архива с внешней компонентой).
Мобильное приложение выполняет проверку обновления при открытии в том случае, если установлен флажок Перезапуск из конфигуратора в свойствах мобильного приложения на мобильном устройстве. Если этот флажок сброшен, то при открытии наличие обновлений не проверяется. Однако такую проверку можно выполнить вручную (см. здесь).
28.7.4.3. Запуск и перезапуск мобильного приложения при использовании Android debug bridge
Запуск и перезапуск мобильного приложения можно выполнять с помощью конфигуратора. Это можно сделать с помощью команды главного меню Отладка``‑ Начало отладки``‑ Мобильное приложение: начать отладку или Отладка``‑ Начало отладки``‑ Мобильный клиент: начать отладку. Чтобы при этом использовался Android Debug Bridge, конфигуратора должен быть соответствующим образом настроен (см. здесь). Кроме того, конфигурация должна быть опубликована в файловой системе (публикация на веб-сервере в этом случае не является обязательной) (см. здесь).
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
При работе с помощью Android Debug Bridge, используемые в конфигурации внешние компоненты также будут скопированы на используемое мобильное устройство. Будут копироваться только те файлы внешней компоненты, которые предназначены для использования на ОС Android (если таковые существуют в составе архива с внешней компонентой).
После перезапуска мобильной платформы разработчика будет обнаружена новая конфигурация и будет выдано предложение выполнить обновление.
28.7.5. Отладка прикладного решения
Отладка прикладного решения на мобильном устройстве возможна только при использовании протокола отладки HTTP. Мобильное приложение, функционирующее под управлением ОС Android, можно запускать в режиме отладки непосредственно из конфигуратора, с использованием Android Debug Bridge (см. здесь). Мобильное приложение, функционирующее под управлением ОС iOS или ОС Windows, нельзя запустить в режиме отладки непосредственно из конфигуратора. Подробное описание настройки мобильных приложений см. здесь.
Для отладки приложения используются два параметра в свойствах информационной базы мобильного приложения:
● Отладка разрешена ‑ указывает, будет в данном мобильном приложении разрешена отладка или не будет.
● Адрес отладки ‑ указывает расположение сервера отладки, если отладка разрешена.
● Вышеописанные параметры игнорируются в том случае, если:
● Информационная база запускается непосредственно из конфигуратора ‑ в этом случае в качестве адреса сервера отладки выступает адрес конфигуратора, выполняющего запуск мобильного приложения, применимо только для работы через Android Debug Bridge;
● Для конфигурации установлен флажок Перезапуск из конфигуратора ‑ в этом случае адрес сервера отладки получается из публикации мобильного приложения.
28.7.6. Управление приложениями на мобильной версии для разработчика
28.7.6.1. Создание приложения
Для того чтобы создать приложение на мобильной платформе разработчика, следует:
● Запустить «1С:Предприятие» на мобильном устройстве;
● Выбрать команду добавления приложения;
● В открывшемся окне ввести URL веб-сервера, на котором опубликовано мобильное приложение (см. здесь) в поле Адрес;
● При необходимости, следует указать имя пользователя и пароль для авторизации на веб-сервере, на котором опубликовано мобильное приложение и нажмите кнопку Загрузить;
● Затем следует указать имя приложения и нажать кнопку Готово;
● После закрытия окна будет создано приложение.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
28.7.6.2. Изменение свойств приложения
Свойства приложения изменяются в специальном окне. В зависимости от операционной системы, доступ к этой команде выполняется по-разному:
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Изменить.
● Для ОС iOS: в правой части строки с именем нужного приложения нажмите картинку с изображением знака больше.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Изменить.
В открывшемся окне можно изменять свойства приложения, которые указывались при его создании: наименование приложения, URL расположения конфигурации, имя и пароль пользователя для доступа к веб-серверу, на котором располагается конфигурация мобильного приложения.
Также в этом окне можно выполнить следующие действия:
● Запустить мобильное приложение. Для этого необходимо нажать кнопку Открыть.
● Проверить наличие новой версии конфигурации мобильного приложения на веб-сервере. Для этого необходимо нажать кнопку Проверить обновления. В случае наличия новой версии конфигурации будет предложено выполнить обновление мобильного приложения.
● Удалить приложение с помощью кнопки Удалить.
Внимание! После удаления приложения, данные информационной базы восстановить невозможно.
● Настроить возможность автоматического обновления и перезапуска мобильного приложения в случае, если на веб-сервере будет обнаружена новая версия конфигурации (см. здесь). Для этого следует изменить состояние флажка Перезапуск из конфигуратора.
● Настроить возможность отладки (флажок Отладка разрешена) и указать адрес отладчика (в поле Адрес отладчика). Подробнее про отладку см. здесь.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
28.7.6.3. Удаление приложения
Для удаления приложения следует выбрать команду Удалить и подтвердить свое действие. В зависимости от операционной системы, доступ к этой команде выполняется по-разному:
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Удалить.
● Для ОС iOS: нажмите кнопку Изменить, затем нажмите картинку в левой части строки с именем удаляемого приложения. Затем в правой части этой же строки нажмите кнопку Удалить.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Удалить.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
Внимание! После удаления приложения, данные информационной базы восстановить невозможно.
28.7.7. Сборка мобильного приложения перед публикацией в магазине приложений
Для того, чтобы опубликовать мобильное приложение в магазине приложений, его необходимо собрать с использованием сборщика мобильных приложений. Мобильную версию системы «1С:Предприятие» для разработчика нельзя опубликовать в магазине приложений.
Подробное описание настройки и использования сборщика мобильных приложений см. здесь. Описание публикации мобильного приложения в магазине приложений с использованием сборщика мобильных приложений см. здесь (только для ОС iOS и Android). Описание процесса публикации мобильного приложения вручную необходимо получить в документации разработчика соответствующего магазина приложений.
28.8. Сборщик приложений для мобильных устройств
28.8.1. Общая информация
Сборщик приложений для мобильных устройств предназначен для хранения и компиляции различных артефактов мобильного приложения в единый файл, пригодный для публикации в магазине приложений или непосредственного использования на устройстве. В состав этих артефактов входят:
● Конфигурация прикладного решения.
● Графическая информация.
● Мультимедийная информация.
● Внешние компоненты.
● Собственно мобильная версия «1С:Предприятия».
Сборщик позволяет собирать как мобильные приложения, так и приложения мобильных клиентов. В обоих случаях одно собранное мобильное приложение позволяет использовать несколько конфигураций.
Сборщик приложений для мобильных устройств функционирует только под управлением ОС Windows. Работа под управлением других операционных систем не поддерживается.
Сборка поддерживается для всех платформ, на которых работает мобильная версия системы «1С:Предприятие», при этом предоставляется возможность отключать сборку под операционные системы, которые не требуются в каждом конкретном случае. Однако в рамках одной операционной системы вариативность сборки не поддерживается. Это означает, что для ОС Android и Windows всегда собираются все архитектуры, без возможности управлять этим.
Результатом сборки являются:
● ОС Android: исполняемые файлы (apk-файлы) для архитектур ARM, ARM64, x86, x86-64, а также пакет приложений (aab-файл). Файл пакета приложений используется для публикации приложения в магазин приложений Google Play.
● ОС iOS: файл проекта для самостоятельной сборки в Xcode, исполняемый файл (ipa-файл) и мобильное приложение для работы в эмуляторе iOS. Возможность сборки ipa-файла регулируется настройкой.
● ОС Windows: исполняемые файлы (appx-файлы) для архитектур x86, x86-64 и ARM.
28.8.2. Настройка сборщика
28.8.2.1. Общая информация
Настройка сборщика состоит из нескольких этапов, самыми важными из которых являются настройка параметров сборочной инфраструктуры и параметров поставщика прикладных решений. Если все этапы настройки не выполнены ‑ выполнить сборку мобильного приложения будет невозможно.
Общая схема настройки сборщика выглядит следующим образом:
1. Выполняется настройка параметров сборщика с помощью диалога настройки (см. здесь).
2. Выполняется настройка параметров поставщика мобильных решений (см. здесь).
3. Загружается одна или несколько мобильных версий системы «1С:Предприятие» (см. здесь).
4. Загружаются файлы с профилями обеспечения (provisioning profile) в том случае, если планируется использовать push-уведомления для ОС iOS (см. здесь).
5. Загружается один или несколько вариантов различной аудиоинформации для мобильных приложений (см. здесь).
6. Загружается один или несколько вариантов различной графической информации для мобильных приложений (см. здесь).
7. Загружаются мобильные конфигурации, из которых будут собираться мобильные приложения (см. здесь).
8. Создаются нужные записи о мобильных приложениях (см. здесь).
После выполнения всех шагов можно выполнять сборку мобильных приложений (см. здесь) и публикацию их в магазинах приложений (см. здесь).
28.8.2.2. Настройка инфраструктуры
28.8.2.2.1. Общая информация
Первым этапом следует установить необходимый набор программного обеспечения (сборочная инфраструктура) на компьютере, на котором будет выполняться сборка приложений для мобильных устройств. В дальнейшем этот компьютер будет называться сборочный сервер. Состав сборочной инфраструктуры зависит от того, для каких мобильных операционных систем будет выполнять сборку сборщик мобильных приложений.
Пути к необходимым компонентам необходимо указать в настройках сборщика с помощью диалога Сервис``‑ Настройки параметров сборщика. Указание путей на конкретном сборочном сервере выполняется в диалоге Пути к компонентам (Сервис``‑ Настройки параметров сборщика``‑ Создать). В этом диалоге приведены гиперссылки, упрощающие процесс поиска дистрибутивов программных продуктов, которые требуются для создания сборочной инфраструктуры.
Сборочная инфраструктура включает в себя следующие программные пакеты:
● Для любой сборки:
● Если используется мобильная версия 8.3.18 или предшествующая, то требуется JDK версий от 1.8 до 13 (включительно).
● Начиная с мобильной версии 8.3.19, требуемая версия JDK определяется параметрами мобильной версии.
● Сборка для ОС Android:
● Актуальная версия Android Studio с установленным SDK.
● Не поддерживается использование версий SDK и необходимых компонентов (Tools, Build tools), которые не достигли стадии релиза (beta, release candidate и т. д.).
● Минимальный номер используемого SDK ‑ 26.
● Начиная с мобильной версии 8.3.19, требуемая версия SDK определяется параметрами мобильной версии.
● ОС iOS (при необходимости собирать ipa-файлы):
● Утилиты pscp и plink (требуется версия 0.71 или последующие) из пакета PuTTY.
● На компьютере Mac должен быть установлен пакет Xcode версии 10.0 или последующие.
● Начиная с мобильной версии 8.3.19, параметры мобильной версии содержат требования к версии утилиты plink, а также уточняют требования к версии пакета Xcode.
● ОС Windows:
● Windows 10 SDK.
● В случае необходимости собирать приложения для работы на ОС Windows, сборочный сервер должен функционировать под управлением ОС Windows 8.1 и старше.
Параметр Рабочий каталог и кеш сборщика указывает путь к каталогу, который используется для собственно сборки и хранения кешей используемых компонентов. Каталог может занимать существенный объем дискового пространства ‑ несколько гигабайт. Каталог следует указывать такой, чтобы путь содержал только латинские символы. Пользователь, от имени которого работает сервер «1С:Предприятия», используемый для сборки, должен иметь полный доступ в рабочий каталог сборщика. Крайне желательно размещать рабочий каталог сборщика на компьютере сборочного сервера. Принудительная очистка этого каталога (между процессами сборки) не влияет на результаты сборки, но влияет на время сборки. Тем не менее, для более эффективного использования дискового пространства, сборщик может автоматически удалять из каталога кеша все каталоги артефактов, которые не использовались более 30 дней. Таким образом, кеш будет содержать только те артефакты (мобильные версии, наборы вспомогательных данных, внешние компоненты и т. д.), которые реально используются в текущих сборочных процессах.
Параметр Каталог автоматической загрузки дистрибутива мобильной версии позволяет указать каталог, который может использоваться сборщиком для выполнения автоматической загрузки новой мобильной версии платформы. Желательно создавать такой каталог на диске компьютера, который является сборочным сервером (для ускорения процесса загрузки). Для выполнения такой загрузки необходимо разместить в этом каталоге файл дистрибутива мобильной версии (mobile*.``zip). Если мобильная версия, которая размещена в каталоге автоматической загрузки, отсутствует в информационной базе сборщика, эта версия будет загружена. Каталог автоматической загрузки проверяется каждые 2 минуты. Если такая версия уже существует в информационной базе ‑ загрузка выполнена не будет. Каталог автоматической загрузки очищается в рамках регулярного процесса очистки кеша сборщика. Другими словами, все файлы в каталоге автоматической загрузки, попадающие под маску mobile*.``zip, будут удалены во время ближайшего следующего (относительно времени помещения файла с дистрибутивом в каталог загрузки) запуска регламентного задания очистки каталога кеша.
При настройке сборщика следует понимать, что в сборщике мобильных приложений, развернутых в файловом варианте информационной базы, недоступны следующие возможности (и настройки, с ними связанные):
● Автоматическая загрузка дистрибутивов мобильных версий платформы «1С:Предприятие».
● Автоматическая очистка каталога кеша сборщика от устаревших артефактов.
● Автоматическая очистка базы сборщика от устаревших артефактов, хранящихся в информационной базе (см. здесь).
28.8.2.2.2. Для ОС Android
Требуемая версия Android SDK определяется той версией мобильной платформы, которая используется для сборки. Начиная с мобильной версии 8.3.19, версия Android SDK, требуемая для сборки, указывается в параметрах мобильной версии. Для предшествующих версий требуемая версия не контролируется сборщиком. Поведение определяется сборочным сценарием Gradle, который используется для сборки.
Сборщик мобильных приложений поддерживает сборку только с использованием пакета Gradle. Сборка с помощью Apache ANT не поддерживается. Если необходимо собрать мобильное приложение на основе мобильной версии 8.3.10 или предшествующих версии, то следует воспользоваться сборщиком мобильных приложений версии 8.3.18.
Примечание. Gradle для своей работы требует постоянного доступа к сети Интернет. При отсутствии такого доступа сборка приложений для работы под управлением ОС Android будет невозможна.
В общем случае, минимальный уровень API, который следует установить с помощью пакета Android Studio, является API 26. В том случае, если мобильная версия содержит требования к версии API, который используется для сборки, то следует устанавливать API требуемого уровня.
Путь к Android SDK следует указать в поле Android``SDK (версия 26 и старше).
Смотри также:
● Информация о мобильной версии «1С:Предприятие» (см. здесь).
28.8.2.2.3. Для ОС iOS
Если требуется собирать исполняемый файл для работы на ОС iOS, то следует установить флажок Собирать пакет приложения (.``ipa) на компьютере``Apple и задать параметры доступа к этом компьютеру. Корректность указания параметров можно проверить с помощью гиперссылки Проверить подключение. Если все настройки выполнены корректно, то после нажатия на гиперссылку откроется окно, в котором указана версия операционной системы на компьютере Mac. Если флажок Собирать пакет приложения (.``ipa) на компьютере``Apple сброшен, то результатом сборки для ОС iOS будет архив проекта для самостоятельной сборки приложения с помощью Xcode и мобильное приложение для работы в эмуляторе.
Для того чтобы сборщик приложений для мобильных устройств мог выполнять какие-либо действия на стороне компьютера Mac, этот компьютер необходимо настроить. Для этого необходимо выполнить следующие действия:
1. Установить все доступные обновления ОС macOS.
2. Установить программу Xcode. Получить пакет можно здесь: https://developer.apple.com/xcode/. Требования к версии Xcode определяются мобильной версией системы «1С:Предприятие», которая используется для сборки конкретного мобильного приложения.
3. Скачать и установить в связку ключей Система сертификат Apple``Worldwide``Developer``Relations (http://developer.apple.com/certificationauthority/AppleWWDRCA.cer).
4. С помощью средств портала разработчика Apple создать и установить в связку ключей Система сертификат дистрибуции для Apple AppStore или для корпоративного распространения:
● Для этого потребуется создание личного ключа средствами связки ключей.
● Следует обратить внимание на то, что все личные ключи и сертификаты должны располагаться в связке Система.
● После создания личного ключа, на вкладке Доступ диалога свойств ключа установить настройку Разрешить всем программам получать доступ к этому объекту.
5. С помощью вкладки Accounts настроек Xcode установить профиль обеспечения (provisioning profile), соответствующий сертификату дистрибуции.
6. В настройках Общий доступ, системных настроек компьютера Mac, необходимо разрешить режим Удаленный вход.
7. Здесь же следует получить имя компьютера, которое затем указать в настройках сборщика приложений для мобильных устройств.
8. Также следует убедиться, что IP-порт номер 22 (SSH) компьютера Mac доступен для компьютера, на котором функционирует серверная часть сборщика приложений для мобильных устройств.
Смотри также:
● Информация о мобильной версии «1С:Предприятие» (см. здесь).
28.8.2.2.4. Для ОС Windows
Сборщик мобильных приложений, начиная с версии 8.3.19, позволяет собирать мобильные приложения, которая работают только под управлением ОС Windows 10. Сборка мобильных приложений, работающих под управлением ОС Windows 8.1 и Windows Phone 8.1 не поддерживается. Если требуется собрать мобильное приложение, которое будет работать под управлением ОС Windows 8.1 (любого варианта), то необходимо использовать мобильную версию 8.3.13 или предшествующие, а для сборки использовать сборщик мобильных приложений версии 8.3.18.
Для сборки мобильного приложения, работающего под управлением ОС Windows, следует скачать и установить Windows 10 SDK. Путь к этому SDK следует указать в параметре Путь к``Windows 10``SDK.
28.8.2.2.5. Автоматическая очистка артефактов
Примечание. Данный механизм не работает, если сборщик запускается в файловом варианте информационной базы.
В силу того, что файлы мобильной версии «1С:Предприятия» и собранных мобильных приложений занимают существенный объем, реализована возможность автоматической очистки информационной базы от устаревших версий как мобильной версии, так и собранных приложений. Для этого сборщик фиксирует дату загрузки (для мобильной версии «1С:Предприятия») и последней сборки (для мобильного приложения). Затем вычисляются даты удаления (отдельно для файлов мобильной версии «1С:Предприятие» и результатов сборки) и удаляются все объекты, дата изменения которых меньше получившейся даты удаления. Время хранения объектов настраивается отдельно для файлов мобильной версии «1С:Предприятие» и файлов результатов сборки. Эта настройка выполняется с помощью следующих параметров:
● Продолжительность хранения файлов мобильной версии, дней. Значение по умолчанию ‑ 180 дней.
● Продолжительность хранения собранных версий, дней. Значение по умолчанию ‑ 90 дней.
Если любой из параметров, описывающих продолжительность хранения, будет установлен в значение 0, то для соответствующих объектов автоматическое удаление не будет использоваться.
Если удаленный объект заново потребуется в сборщике, то:
● Файлы мобильной версии «1С:Предприятия» можно повторно загрузить из файла mobile*.``zip соответствующей версии.
● Файлы мобильного приложения будет необходимо собрать заново.
28.8.2.3. Настройка параметров поставщика
28.8.2.3.1. Общие настройки
После настройки инфраструктуры необходимо выполнить настройку параметров поставщика собираемых мобильных приложений. Для этого необходимо открыть диалог Сервис``‑ Настройка параметров поставщика.
Вначале следует указать, для каких мобильных операционных систем будут собираться приложения в сборщике. Для этого предназначена группа флажков Новые прикладные решения данного поставщика собирать. Установка каждого флажка делает доступной закладку с параметрами для соответствующей операционной системы.
28.8.2.3.2. Параметры для ОС Android
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения.
Для сборки мобильного приложения необходимо создать (или импортировать) ключ подписи приложений (группа Ключ подписи приложений). С помощью этого ключа подписывается собранное приложение в виде apk-файла. Ключ подписи приложения никогда не меняется в течение всего времени существования вашего приложения. Ключ подписи хранится в виде хранилища ключей Java ‑ двоичный файл, который служит хранилищем сертификатов и закрытых ключей. Ключ подписи приложения является конфиденциальной информацией и должен храниться в секрете. Для работы с ключом подписи приложения предназначены следующие команды:
● Установить ключ подписи приложения ‑ загрузить в базу сборщика существующий ключ подписи, который находится в файле. Для того, чтобы успешно выполнить эту операцию, необходимо предварительно указать пароль и псевдоним ключа подписи в полях формы.
● Создать ключ ‑ создать новый ключ подписи приложения. В этом случае пользователь вводит все параметры создаваемого ключа подписи. При этом создаваемый ключ подписи заменит ранее установленный (или созданный) ключ подписи. При этом приложение, которое подписано «новым» ключом подписи, перестанет обновлять приложение, которое подписано «старым» ключом подписи приложения.
● Сохранить ключ подписи ‑ сохраняет ключ подписи приложения, который расположен в базе данных сборщика, в файл. Никаких преобразований не выполняется.
● Получить хеш ключа ‑ формирует хеши SHA1 и SHA256 для ключа подписи приложения. Этот хеш необходим в том случае, когда мобильное приложение использует доступ к картам Google.
С помощью мобильной версии можно собирать не только мобильные приложения (apk-файлы), но и пакеты мобильных приложений (aab-файлы). Пакет мобильных приложений поддерживаются всеми магазинами приложений и является предпочитаемым форматом публикации. Если планируется публикация приложения, то необходимо создать (или импортировать) ключ загрузки приложения (группа Ключ загрузки приложения). Этот ключ будет использован для подписи пакета приложений во время сборки пакета. Ключ загрузки записан в виде хранилища хранилище ключей Java ‑ двоичный файл, который служит хранилищем сертификатов и закрытых ключей. Ключ загрузки приложения является конфиденциальной информацией и должен храниться в секрете. Однако, существует возможность предоставить третьим лицам сертификат криптографии, созданный с помощью вашего ключа загрузки. Для работы с ключом загрузки приложения предназначены следующие команды:
● Установить ключ загрузки приложения ‑ загрузить в базу сборщика существующий ключ загрузки, который находится в файле. Для того, чтобы успешно выполнить эту операцию, необходимо предварительно указать пароль и псевдоним ключа загрузки в полях формы.
● Создать ключ ‑ создать новый ключ загрузки приложения. В этом случае пользователь вводит все параметры создаваемого ключа загрузки. При этом создаваемый ключ загрузки заменит ранее установленный (или созданный) ключ загрузки. Правила работы магазина Google Play допускают эту ситуацию. В случае замены ключа загрузки, вам потребуется заново предоставить в магазин Google Play сертификат ключа загрузки для продолжения нормальной работы.
● Сохранить ключ подписи ‑ сохраняет ключ загрузки приложения, который расположен в базе данных сборщика, в файл. Никаких преобразований не выполняется.
Команда Экспортировать ключи подписи и загрузки позволяет одним действием выполнить экспорт из сборщика следующих артефактов:
● Закрытый ключ подписи приложения для магазина Google Play. Этот файл потребуется в том случае, когда в магазине Google Play выполняется смена режима публикации приложения.
● Закрытый ключ подписи и сертификат подписи приложения для магазинов Google Play, Huawei AppGallery и RuStore. ZIP-архив c файлами сертификата и зашифрованного закрытого ключа потребуется в том случае, когда создается новое приложение в магазине приложений.
● Сертификат ключа загрузки приложения в магазины Google Play, Huawei AppGallery и RuStore. Сертификат будет использоваться магазином для проверки того, что загружаемый для публикации пакет приложений действительно предоставлен вами, как разработчиком приложения.
Если выбрана выгрузка артефактов, связанных с магазином Google Play, следует перед выгрузкой выбрать открытый ключ, которым будет зашифрован закрытый ключ подписи. Этот открытый ключ предоставляется консолью разработчика магазина Google Play.
Если выбрана выгрузка артефактов, связанных с магазином RuStore, следует перед выгрузкой указать ключ шифрования, которым будет зашифрован закрытый ключ подписи. Этот ключ шифрования предоставляется консолью разработчика магазина RuStore.
Для выполнения указанных операций будет использоваться утилита PEPK, которая хранится в сборщике мобильных приложений. Все указанные артефакты будут размещены в каталоге, который указан в поле Файлы сохранять в каталог. Перед сохранением файлов каталог будет очищен от любого содержимого. Артефакты для разных магазинов будут сохранены в следующих каталогах:
● магазин Google Play ‑ подкаталог google,
● магазин Huawei AppGallery ‑ в подкаталоге huawei,
● магазин RuStore ‑ в подкаталоге rustore.
Имена файлов с артефактами для разных магазинов совпадают, но размещаются в разных подкаталогах:
● android_``sign_``encrypted_``private_``key.``pepk ‑ файл закрытого ключа подписи приложения.
● android_``sign_``encrypted_``key.``zip ‑ закрытый ключ подписи и сертификат подписи приложения (в zip-архиве).
● android_``upload_``key.``pem ‑ сертификат ключа загрузки приложения в магазин.
Если собранное мобильное приложение будет публиковаться в магазин приложений непосредственно из сборщика, с помощью команд группы Доступ к консоли разработчика следует получить требуемый доступ. Для получения доступа следует проделать следующие действия (последовательность действия приводится на момент создания документации):
1. Войти в консоль разработчика Google Play Console (https://play.google.com/apps/publish) от имени пользователя, который является владельцем профиля разработчика в магазине Google Play.
2. В левой части экрана выбрать пункт меню Настройка``‑ Доступ к``API. На открывшейся странице следует выбрать Доступ к``API ‑ Связанный проект``Google``Cloud. Затем следует выбрать радиокнопку Создать проект, а затем нажать кнопку Связать проект с аккаунтом.
3. На открывшейся странице следует нажать гиперссылку Включить игровые сервисы``Google``Play.
4. В разделе страницы Клиенты``OAuth следует нажать гиперссылку Настроить окно запроса доступа``OAuth. После нажатия на эту гиперссылку произойдет переход в Google Cloud Platform, в раздел APIs &``Services ‑ OAuth``consent``screen.
5. На этой странице следует указать переключатель External в разделе User``Type и нажать кнопку CREATE.
6. На следующей странице App``information следует ввести обязательные параметры (заголовки которых отмечены символом «*»):
● App``name ‑ название приложения.
● User``support``email ‑ адрес электронной почты поддержки пользователей.
● App``logo ‑ выбрать желательно, но это не обязательное поле.
● Email``addresses ‑ адрес электронной почты разработчика.
7. После ввода всей необходимой информации, следует три раза нажать кнопку SAVE``AND``CONTINUE, чтобы завершить создание приложения.
8. В меню, в левой части страницы, следует выбрать пункт Credentials (в разделе APIs &``Services), затем на открывшейся странице (вверху) нажимаем кнопку +``CREATE``CREDENTIALS, а в выпадающем меню выбираем пункт OAuth``client``ID.
9. В открывшейся форме следует выбрать Web``application, затем необходимо ввести имя приложения и нажать кнопку CREATE.
10. В результате этого действия станут доступны значения Client``ID и Client``Secret, которые нужно ввести в одноименные поля настройках поставщика на закладке Параметры для ОС Андроид (в сборщике мобильных приложений).
11. Теперь следует нажать гиперссылку Получить доступ к консоли разработчика в сборщике мобильных приложений. Гиперссылка расположена под полями Client``ID и Client``Secret. В открывшемся окне следует разрешить доступ к консоли разработчика.
12. В консоли разработчика Google Play Console можно повторно перейти в раздел Настройки``‑ Доступ к``API и в разделе Клиенты``OAuth нажать гиперссылку Обновить. После обновления станет доступно поле с идентификатором клиента.
Так как доступ к консоли разработчика имеет ограничение по времени, то периодически может требоваться обновлять этот доступ с помощью команды Обновить параметры доступа к консоли разработчика. Если публикацией не пользовались очень долго и обновить параметры тоже не получается, необходимо повторно получить доступ к консоли разработчика.
28.8.2.3.3. Параметры для ОС iOS
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения.
Если для сборки приложения (ipa-файла) используется пакет Xcode версии 8 и последующих, то на закладке Группы разработчиков необходимо указать идентификаторы групп разработчиков, соответствующих учетным записям на портале https://developer.apple.com/. Для каждой группы разработчиков предоставляется возможность указать способ распространения приложений по умолчанию. Указанное значение будет использоваться при настройке параметров собираемых мобильных приложений для ОС iOS.
Если для сборки приложения (ipa-файла) используется пакет Xcode версии 7 или предшествующие, то на закладке Сертификаты необходимо указать те сертификаты, которые будут использоваться для подписи собранного приложения (ipa-файла). При нажатии кнопки Добавить происходит загрузка списка сертификатов с компьютера Mac. В связи с этим, если не настроено подключение к компьютеру Mac, добавить сертификат будет невозможно.
Закладка Доступ к``iTunes``Connect описывает имена пользователей и пароли доступа в iTunes Connect. Эти параметры используются при необходимости загрузки собранных приложений в магазин приложений (AppStore).
28.8.2.3.4. Параметры для ОС Windows
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения. Следует помнить, что префикс назначается магазином Windows Store, а не вводится вручную. Для получения данного префикса следует нажать на ссылку Перейти к``Windows``Store и получить идентификатор с помощью веб-интерфейса магазина приложений.
Поле Идентификатор поставщика в``Windows````Store автоматически заполняется при установке сертификата разработчика. Поле Имя поставщика в Windows Store можно получить из поля Пакет/Свойства/Отображаемое имя издателя. Данное поле доступно в описании любого приложения, с помощью команды Управление приложениями``‑``Удостоверение приложения.
Установка сертификата разработчика выполняется с помощью команды Установить ключи разработчика. Перед выполнением команды необходимо ввести пароль для доступа к ключу в поле Пароль для приватного ключа разработчика. Должны быть выбраны и будут загружены два файла: с расширением «.cer» (собственно сертификат) и с расширением «.pvk» (приватный ключ для этого сертификата). Информацию по получению ключа разработчика можно получить здесь: https``://``msdn``.``microsoft``.``com``/``en``-``us``/``library``/``windows``/``desktop``/``jj``835832(``v``=``vs``.85).``aspx (на английском языке).
28.8.3. Загрузка необходимых данных
28.8.3.1. Общие данные
28.8.3.1.1. Мобильные версии
Для того, чтобы собрать любое мобильное приложение, необходимо загрузить в сборщик требуемую мобильную версию «1С:Предприятия». Мобильная версия распространяется в файлах mobile_``A_``B_``C_``D.``zip. Где A_``B_``C_``D ‑ это полный номер мобильной версии. Так, для версии 8.3.12.64 имя файла будет выглядеть следующим образом ‑ mobile_8_3_12_64.``zip. Для загрузки необходимо использовать именно этот файл. Сборщик загрузит только те файлы, которые требуются для сборки. Фактический номер загружаемой версии определяется по файлу version.``txt, который расположен в корне архива. Если номер загружаемой версии превышает номер версии сборщика, то сборщик не будет загружать такую мобильную версию. Например, если сборщик мобильных приложений имеет версию 8.3.18, то в него нельзя будет загрузить мобильную версию системы «1С:Предприятие» с номером 8.3.19 и последующие. Это связано с тем, что использование более поздних (по времени выпуска) мобильных версий могут требовать изменения в коде сборщика. Отсутствие таких изменений может привести либо к полной невозможности выполнить сборку, либо к некорректной сборке (которая формально выполнена корректно), либо к ошибкам в процессе сборки, которые не позволяют однозначно понять причину этой ошибки. В общем случае действует следующее правило: сборщик версии N позволит работать с мобильной версией версии N и всех предыдущих, но не позволит использовать последующие мобильные версии. Проверка выполняется по первым 3 цифрам номера версии.
Сборщик мобильных приложений поддерживает как полную, так и частичную загрузку мобильной версии. В процессе загрузки определяется следующая информация:
● Версия загружаемых файлов.
● Все загруженные варианты мобильной версии (для Android, iOS и Windows):
● Для сборки мобильного приложения.
● Для сборки мобильного клиента.
● Для сборки мобильного клиента с автономным режимом.
Таким образом, уже при загрузке мобильной версии становится ясно, что и каким образом можно собрать с помощью загруженной версии.
Рис. 543. Мобильная версия
В данном примере загружена версия 8.3.19.29, а сборка для ОС Android будет выполняться с помощью Gradle. Также, данная мобильная версия может быть использована для сборки как мобильных приложений, так и мобильных клиентов (в том числе с автономным режимом) для всех поддерживаемых операционных систем.
Начиная с версии 8.3.19, мобильная версия системы «1С:Предприятие» содержит информацию о версиях утилит окружения, которые необходимы для сборки с использованием это версии. Эту информацию можно получить на закладке Версии окружения. Для мобильных версий 8.3.18 и предшествующих, требования к версиям окружения в составе мобильной версии отсутствуют, поэтому закладка Версии окружения не отображается.
Рис. 544. Версии окружения
Список требований к версиям утилит окружения может изменяться с течением времени. Если при сборке используемая версия той или иной утилиты окружения не соответствует требованиям используемой мобильной версии, то поведение зависит от мобильной версии: сборка будет прервана (критическая ошибка) или в журнал сборки может быть внесено предупреждение о несоответствии версий, но сборка будет продолжена.
Контролируются следующие версии окружения:
● Версия``Java. Указывается, какой интервал версий Java поддерживается для данной мобильной версии. Версия 8.0 означает Java версии 1.8.
● Версия``API``Android, требуемая для сборки. Содержит номер API Level, который должен быть установлен на компьютер сервера сборщика. Если требуемый API Level не установлен ‑ сборку приложения для ОС Android будет невозможна.
● Минимальная версия``Android для приложения. В данном поле указывается минимальная версия ОС Android, на которой можно будет запустить мобильное приложение, собранное с использованием данной мобильной версии. Версия указывается для информации.
● Рекомендуемая версия``Android для приложения. В данном поле указывается версия ОС Android, которая рекомендуется для работы мобильного приложения, собранного с использованием данной мобильной версии. Позволяет быстро определить, будет соответствовать собранное мобильное приложение требованиям магазина Google Play. Версия указывается для информации.
● Требуемая версия``Xcode. В поле содержится требование к версии системы Xcode. Этот программный продукт должен быть установлен на компьютере Mac для того, чтобы сборщик мог собрать двоичный вариант мобильного приложения (ipa-файл).
● Требуемая версия утилиты``plink. Утилита plink используется для подключения к компьютеру Mac. С ее помощью выполняется вся коммуникация между компьютером сборщика и компьютером Mac.
Если для сборки используется мобильная версия 8.3.18 или предшествующие, то безусловно используются следующие проверки:
● Версия Java должна быть не ниже 1.8 (8.0). Нарушение требования сопровождается предупреждением, сборка не прекращается.
● Требуется Xcode версии 10.0 и последующие. Нарушение требования сопровождается предупреждением, сборка не прекращается.
● Требуется утилита plink версии 0.71 и последующие. Нарушение требования является фатальным, сборка прерывается.
Проверка версии Xcode и утилиты plink производится только в том случае, если в сборщике настроена необходимость выполнения сборки двоичной версии мобильного приложения (ipa-файл) для ОС iOS.
В любой момент времени можно повторно загрузить мобильную версию с помощью команды Загрузить платформу. При повторной загрузке не проверяется, что загружается та же версия, что и была загружена ранее. Поэтому такую загрузку следует выполнять аккуратно.
Если мобильная версия платформы устарела и удалена, то в нижней части формы будет присутствовать надпись Файлы мобильной платформы удалены (устарели). В форме списка также будет присутствовать флажок, оповещающий об этом.
При загрузке мобильной версии в сборщик мобильных приложений, рекомендуется выполнять загрузку в точности того файла, который загружен с ресурсов фирмы «1С». Никакой предварительной обработки файла mobile_<номер версии>.``zip не требуется. Сборщик загрузит только те файлы, которые ему требуются.
Для упрощения (и ускорения) загрузки мобильной версии, можно настроить каталог, который будет мониторить сборщик мобильных приложений. В случае размещения в этом каталоге файла с дистрибутивом мобильной версии, эта мобильная версия будет автоматически загружена сборщиком (если эта версия отсутствует в списке загруженных версий). Более подробно о настройке сборщика для выполнения этой операции см. здесь.
28.8.3.1.2. Профили обеспечения
Профили обеспечения (provisioning profiles) ‑ это специальные файлы, которые обеспечивают доступ мобильному приложению к некоторым возможностям iOS. Загруженные профили обеспечения используются для сборки ipa-файлов. Загруженный профиль обеспечения также можно загрузить повторно через форму элемента и команду Загрузить профиль обеспечения.
28.8.3.1.3. Аудиоинформация
Данный справочник хранит аудиоинформацию, которая будет использоваться при сборке мобильных приложений. Разработчик может загрузить несколько наборов аудиоинформации. Сборщик не накладывает каких-либо ограничений на сочетание набора аудиоинформации и различных мобильных приложений. Для загрузки необходимо использовать команду Загрузить аудиоинформацию.
В загружаемом архиве должно располагаться каталоги: iOS, Android и Windows (регистр символов важен). Имена файлы в этих каталогах должны состоять только из символов ".", "_", цифр и латинских букв в нижнем регистре. Для iOS поддерживаются только файлы с расширениями WAV, CAF и AIFF, остальные файлы при сборке мобильного приложения пропускаются.
Аудиоинформацию можно в любой момент времени загрузить повторно. Если потребуется ‑ предоставляется возможность выгрузить весь набор обратно, в виде архива. Для этого необходимо использовать команду Еще``‑ Выгрузить аудиоинформацию.
28.8.3.1.4. Графическая информация
Данный справочник хранит графическую информацию, которая будет использоваться при сборке мобильных приложений. Разработчик может загрузить несколько наборов графической информации. Сборщик не накладывает каких-либо ограничений на сочетание набора графической информации и различных мобильных приложений. Для загрузки графической информации следует воспользоваться командой формы Загрузить графическую информацию.
При загрузке графической информации система ожидает, что графическая информация будет представлена zip-файлом со следующей структурой (регистр имени файла и каталога ‑ важен!):
● Для ОС Android. Каталог Android. В этом каталоге файлы:
● Иконки мобильного приложения соответствующего разрешения:
● icon-36``x36.``png;
● icon-48``x48.``png;
● icon-72``x72.``png;
● icon-96``x96.``png;
● icon-144``x144.``png.
● Заставки мобильного приложения соответствующего разрешения:
● splash-320``x480.``png;
● splash-480``x854.``png;
● splash-640``x960.``png;
● splash-768``x1024.``png;
● splash-800``x1280.``png;
● splash-854``x480.``png;
● splash-1024``x768.``png;
● splash-1242``x2208.``png;
● splash-1280``x800.``png;
● splash-1536``x2048.``png;
● splash-2048``x1536.``png;
● splash-2208``x1242.``png.
● Иконки для отображения push-сообщений соответствующего разрешения и размера:
● pushsmallicon-18``x18.``png;
● pushsmallicon-24``x24.``png;
● pushsmallicon-36``x36.``png;
● pushsmallicon-48``x48.``png;
● pushsmallicon-72``x72.``png;
● pushlargeicon-36``x36.``png;
● pushlargeicon-48``x48.``png;
● pushlargeicon-72``x72.``png;
● pushlargeicon-96``x96.``png;
● pushlargeicon-144``x144.``png.
● Для ОС iOS. Каталог iOS. В этом каталоге файлы:
● Иконки мобильного приложения соответствующего разрешения:
● icon-29``x29.``png;
● icon-40``x40.``png;
● icon-50``x50.``png;
● icon-57``x57.``png;
● icon-58``x58.``png;
● icon-72``x72.``png;
● icon-76``x76.``png;
● icon-80``x80.``png;
● icon-87``x87.``png;
● icon-100``x100.``png;
● icon-114``x114.``png;
● icon-120``x120.``png;
● icon-144``x144.``png;
● icon-152``x152.``png;
● icon-167``x167.``png;
● icon-180``x180.``png;
● icon-1024``x1024.``png.
● Заставки мобильного приложения соответствующего разрешения:
● splash-320x480.png;
● splash-640x1136.png;
● splash-640x960.png;
● splash-750x1334.png;
● splash-768x1024.png;
● splash-1024x768.png;
● splash-1125x2436.png;
● splash-1242x2208.png;
● splash-1536x2048.png;
● splash-2048x1536.png;
● splash-2208x1242.png;
● splash-2436x1125.png.
● Для ОС Windows Store. Каталог Windows Store. В этом каталоге файлы:
● Иконки мобильного приложения соответствующего разрешения:
● icon-50``x50.``png;
● icon-150``x150.``png;
● icon-30``x30.``png.
● Заставки мобильного приложения соответствующего разрешения:
● splash-620``x300.``png;
● splash-1208``x800.``png;
● splash-2048``x1536.``png.
В архиве могут находиться не все картинки, перечисленные выше. В этом случае будут использовать стандартные иконки и заставки из состава мобильной версии «1С:Предприятие». При сборке мобильного приложения в журнале сборки будет указано, какая картинка взята из установленной графической информации, а какая осталась стандартной. Переименование картинки из формата, используемого для загрузки в сборщик мобильных приложений, в формат, используемый для конкретной мобильной операционной системы, выполняется сборщиком автоматически. В журнале сборки отображается информация о соответствии имени картинки из архива графической информации и реального имени картинки.
Для проверки того, что загруженный набор картинок содержит все необходимые файлы служит команда Проверить состав картинок. В результате проверки отображается диалог, который содержит список картинок, отсутствующих в загруженном архиве.
Графическую информацию можно в любой момент времени загрузить повторно. Если потребуется ‑ предоставляется возможность выгрузить весь набор обратно, в виде архива. Для этого необходимо использовать команду Еще``‑ Выгрузить графическую информацию.
28.8.3.2. Конфигурации
28.8.3.2.1. Общая информация
Для хранения конфигураций предназначен специальный справочник Мобильные конфигурации. Конфигурации должны храниться исключительно в группах. Группа конфигураций предназначена для хранения различных версий одного прикладного решения. Фактически группа и описывает собой прикладное решение. А в группе хранятся версии этого прикладного решения или конфигурации. Настоятельно не рекомендуется смешивать в одной группе разные приложения.
Во время загрузки конфигурации выполняется проверка, что текущая версия сборщика поддерживает номер формата загружаемой конфигурации. Если конфигурация имеет номер формата, который не поддерживается текущим сборщиком, необходимо выполнить одно из следующих действий:
● Обновить сборщик до более свежей версии.
● Использовать для выгрузки конфигурации более раннюю версию конфигуратора. Желательно использовать конфигуратор той версии системы «1С:Предприятие», из мобильной версии которой получен и сам сборщик.
Каждая группа может хранить один тип конфигураций, который указывается в поле Тип конфигурации:
● предназначенных для сборки мобильных приложений;
● предназначенных для сборки приложений мобильных клиентов.
После того, как в группу загружена хотя-бы одна конфигурация, сменить тип конфигурации в группе становится невозможно.
При загрузке конфигурации, сборщик контролирует, что в группу загружается корректная конфигурация:
● Конфигурация для сборки мобильного приложения: файлы с расширением 1``cema.``zip и 1``cema.``xml.
● Конфигурация для сборки приложения мобильного клиента: файлы с расширением 1``cemca.``xml и 1``cemca.``zip.
Из загруженной конфигурации получается следующая информация:
● Имя конфигурации (свойство конфигурации Имя).
● Представление конфигурации на всех поддерживаемых языках (свойство конфигурации Синоним).
● Версия конфигурации (свойство конфигурации Версия).
● Версия режима совместимости конфигурации (свойство конфигурации Режим совместимости).
● Версия формата выгрузки.
● Основной язык конфигурации (свойство конфигурации Основной язык).
● Список разрешений конфигурации (свойство конфигурации Требуемые разрешения мобильного приложения).
● Внешние компоненты (если загружается конфигурация в формате .zip-файла).
Дата загрузки конфигурации, а также ее имя и версия определяют Наименование загруженной конфигурации.
В сборщике мобильных приложений предоставляется возможность изменять только комментарий к загруженной конфигурации. Остальные параметры должны редактироваться только в конфигураторе.
В любой момент времени имеется возможность повторной загрузки конфигурации. Кроме того, имеется возможность выгрузить конфигурацию в файл на диск. Для этого предназначена команда Еще``‑ Выгрузить конфигурацию. Особого смысла данное действие не имеет, т. к. по результату выгрузки восстановить конфигурацию для последующего изменения не получится.
Конфигурация, загружаемая в сборщик, должна быть предварительно выгружена из конфигуратора. В зависимости от используемого вида приложения, различаются команды для выгрузки и форматы этой выгрузки:
● Для мобильной платформы. Используется команда Главное меню``‑ Конфигурация``‑ Мобильное приложение``‑ Записать в файл. Формат: zip-файл 1``cema.``zip. Выгрузка содержит собственно файл конфигурации и различная сопутствующая информация, например, внешние компоненты, которые в конфигураторе загружены в макеты типа Внешняя компонента.
● Для мобильного клиента. Используется команда Главное меню``‑ Конфигурация``‑ Мобильный клиент``‑ Записать в файл. Формат: xml-файл 1``cemca.``xml или zip-файл 1``cemca.``zip. Если конфигурация содержит внешние компоненты ‑ выгрузка выполняется только в формате zip-файла. Если конфигурация не содержит внешних компонент ‑ выгрузка всегда выполняется в формате xml-файла.
Сборщик мобильных приложений умеет загружать конфигурации любых форматов, которые могли быть использованы на момент выпуска соответствующей версии сборщика. Следует помнить, что загрузку в сборщик следует выполнять в точности в том виде, в котором конфигурация выгружена из конфигуратора. Никаких дополнительных действий с файлом выгрузки предпринимать не требуется. «Упрощение» получившейся выгрузки может привести к тому, что конфигурация будет успешно загружена в сборщик, но выполнить сборку будет невозможно.
Рекомендуется при обновлении мобильной версии системы «1С:Предприятие» рекомендуется следующий порядок действий:
1. Обновить сборщик до версии, которая идет в дистрибутиве новой мобильной версии (файл mobile.``zip).
2. Выполнить выгрузку конфигурации с помощью конфигуратора новой версии, даже если в самой конфигурации ничего не менялось. Это обеспечит максимальную совместимость выгрузки конфигурации и новой мобильной версии «1С:Предприятия».
3. Загрузить обновленным сборщиком новую выгрузку конфигурации.
4. Собрать новую версию мобильного приложения (при необходимости).
28.8.3.2.2. Загрузка конфигурации в сборщик
Для загрузки конфигурации необходимо нажать кнопку Загрузить конфигурацию. Будет открыт диалог, с помощью которого можно выполнить несколько связанных действий:
● Загрузить конфигурацию в нужную (или новую) группу конфигураций (загрузить версию конфигурации).
● Создать новую версию мобильного приложения для сборки.
Рассмотрим подробнее, как выполняется загрузка конфигурации.
Рис. 545. Загрузка новой конфигурации
Первым шагов необходимо выбрать загружаемую конфигурацию в поле Файл конфигурации. Диалог загрузки хранит историю 10 последних успешных загрузок. Таким образом, если вы постоянно загружаете конфигурации из каких-либо фиксированных мест, то после успешной загрузки конфигураций, последние 10 мест окажутся в истории. Для загрузки конфигурации из истории файлов конфигураций необходимо просто выбрать нужный элемент истории. Если история загруженных файлов пустая, то будет автоматически открыт диалог выбора файла конфигурации.
После выбора конфигурации процесс загрузки разделяется на два принципиально разных процесса:
● Загрузка конфигурации, которую еще не загружали в сборщик мобильных приложений.
● Загрузка конфигурации, которая ранее загружалась в сборщик.
Начнем рассмотрение с первого процесса. Допустим, в сборщик загружается конфигурация, которой еще не было в сборщике. В этом случае диалог примет вид, показанный на рис. 545. Сборщик определил имя версию и тип загружаемой конфигурации. Также сборщик определил (и показал выбор в поле Конфигурация), что конфигурация ранее не загружалась и для нее нужно создать новую группу. В поле Загрузить конфигурацию в новую группу с именем нужно указать название группы конфигураций. По умолчанию, в это поле подставляется представление загружаемой конфигурации. Если загрузка завершится успешно, то при загрузке следующих версий данной конфигурации, сборщик автоматически будет определять, в какую группу нужно выполнить загрузку.
Флажок Создать новую группу приложений для этой конфигурации указывает сборщику, хочет пользователь использовать загружаемую конфигурацию в новом мобильном приложении или конфигурация будет использоваться в существующем приложении. Если флажок установлен, то после загрузки конфигурации, будет автоматически создана и открыта для редактирования группа мобильных приложений. Параметры группы будут заполнены по умолчанию, а в список конфигураций будет автоматически добавлена группа, имя которой указано в поле Загрузить конфигурацию в новую группу с именем. Группа мобильных приложений к моменту открытия формы редактирования еще не записана в информационную базу.
Если для загрузки выбрана конфигурация, которая уже загружалась в сборщик, то диалог будет выглядеть несколько по-другому.
Рис. 546. Загрузка новой версии конфигурации
Когда загружается новая версия конфигурации, сборщик пытается автоматически определить, к какой группе конфигураций относится загружаемая версия. В том случае, когда эта попытка оказывается успешной, диалог выглядит аналогично тому, как он выглядит на рис. 546.
Сборщик автоматически определил, что конфигурация ранее загружалась в сборщик (поле Конфигурация). Конфигурация загружалась в группу, которая уже указана в поле Загрузить конфигурацию в группу.
Если данная конфигурация была добавлена в какое-либо мобильное приложение ‑ сборщик найдет это приложение и предложит создать для него новую версию. Найденное приложение подставляется в поле Мобильное приложение с этой конфигурацией. Необходимость создать новую версию мобильного приложения управляется одноименным флажок.
Если в сборщике уже есть готовая структура хранения конфигураций, которая была создана до версии сборщика мобильных приложений 8.3.18, то в данной структуре отсутствует информация о том, какую конфигурацию в какую группу загружать. Поэтому, если новая версия конфигурации впервые загружается в сборщике версии 8.3.18 и последующих или сборщик неверно выбрал группу для загрузки, можно выполнить следующие действия после выбора файла с конфигурацией:
● В поле Конфигурация указать значение уже загружалась (для конфигурации есть группа).
● В поле Загрузить конфигурацию в группу выбрать ту группу конфигураций, куда на самом деле должна быть загружена новая версия. При этом необходимо помнить, что выбирать группу для загрузки следует в строгом соответствии с типом загружаемой конфигурации (отображается в поле Параметры конфигурации``‑ Тип). Другими словами: сборщик не позволит загрузить конфигурацию для мобильного клиента в группу для мобильной платформы (и наоборот).
● Если необходимо, чтобы сборщик «запомнил» выбранное соотношение (конфигурация и группа загрузки) ‑ необходимо выбрать флажок Использовать выбранную группу для загрузки других версий этой конфигурации. После успешной загрузки ‑ сборщик запомнит, что новые версии загружаемой сейчас конфигурации надо поместить в выбранную группу и всегда будет предлагать ее в дальнейшем. Если загрузка в другую группу выполняется разово ‑ флажок ставить нет необходимости. Нет необходимости устанавливать этот флажок и в том случае, если сборщик корректно определил группу загрузки.
Если при выборе конфигурации сборщик обнаружил несколько групп, пригодных для загрузки конфигурации, он сформирует предупреждение, а в списке выбора поля Загрузить конфигурацию в группу, будет сформирован список подходящих конфигураций. Тогда можно выбрать нужную группу из списка выбора или все-таки выбрать нужную группу из списка.
Если сборщик обнаружит несколько приложений, в которых указана группа конфигураций, в которую загружается новая версия, он также выдаст предупреждение. В этом случае список подходящих приложений будет сформирован в списке выбора поля Мобильное приложение к этой конфигурацией. В отличие от выбора группы конфигураций, нельзя выбрать произвольное мобильное приложение, т. к. это не имеет смысла.
После указания все параметров в диалоге загрузки, остается нажать кнопку Загрузить. После этого будет выполнены следующие действия:
● При необходимости, будет создана группа конфигураций.
● В выбранную группу будет загружена конфигурация.
● Для группы, в которую загружена конфигурация, будет указан информация, необходимая для того, чтобы при дальнейшей загрузке верно определять группу загружаемой конфигурации. Это действие будет выполнено только при необходимости (создается новая группа или указан флажок Использовать выбранную группу для загрузки других версий этой конфигурации.
● При необходимости (установлен флажок Создать новую группу приложений для этой конфигурации) будет создана и открыта для редактирования группа нового мобильного приложения.
● При необходимости (установлен флажок Создать новую версию для выбранного мобильного приложения) будет открыта для редактирования новая версия существующего мобильного приложения.
● Путь к загруженной конфигурации будет запомнен для использования в истории поля Файл конфигурации.
28.8.4. Настройка собираемого приложения
28.8.4.1. Общая информация
Структура хранения мобильных приложений организована аналогично хранению конфигураций. Вначале создается группа, которая описывает общие параметры собираемого мобильного приложения, затем, в этой группе, для каждой версии мобильного приложения создается свой элемент с уникальными настройками.
Параметры собираемого мобильного приложения могут задаваться как в группе приложений, так и непосредственно в элементе. В общем случае используется схема «наследования» параметров: в элемент приложения переносятся практически все настройки, заданные в группе (с небольшими особенностями, описанными отдельно). В элементе приложения можно точечно изменить настройки или сохранить те значения, которые «унаследованы» от группы. В результате разработчику предоставляется возможность один раз настроить основные параметры собираемого приложения и затем только создавать новый экземпляр приложения при выпуске очередной версии одной или нескольких конфигураций.
28.8.4.2. Группа приложений
28.8.4.2.1. Общая информация
Группа мобильных приложений описывает общие параметры, которые будут использоваться для сборки приложений и начальной установки параметров конкретного приложения. Перед созданием приложения необходимо ознакомиться с лицензионной политикой фирмы «1С», описывающей правила лицензирования мобильных приложений. Для ознакомления с лицензионной политикой следует выполнить переход по ссылке из группы мобильного приложения (или через меню Сервис``‑ Лицензионная политика) и затем установив соответствующий флажок.
Во-первых, группа определяет, какой вид приложений будет собираться в данной группе: мобильное приложение или мобильный клиент. Собирать в одной группе и мобильные приложения и мобильные клиенты невозможно. Изменять тип сборки можно только до тех пор, пока в группе не создано ни одного конкретного приложения. После создания поле Собирать становиться недоступным для изменения. Если в поле Собирать указано Для мобильного клиента, то становится возможным выбрать, в каком режиме сборщик будет собирать приложение: как мобильный клиент или как мобильный клиент с автономным режимом. За этот выбор отвечает поле автономный режим (подробнее про автономный режим см. здесь). В отличие от поля Собирать, указание необходимости собираться приложение, которое работает в автономного режиме, доступно в любое время (кроме уже собранного приложения). Таким образом, существует возможность для каждой версии конфигурации собирать и приложение мобильного клиента, и приложение мобильного клиента с автономным режимом. Для такой сборки будет необходимо создать две приложения, которые будут различаться только значением свойства автономный режим (и номером сборки).
Во-вторых, необходимо определить, для каких мобильных операционных систем будут собираться приложения по умолчанию. Для этого предназначена группа Собирать мобильное приложение на закладке Общие настройки. В зависимости от выбранных операционных систем, станут доступны несколько (от одной до трех) закладок с настройками, характерными для выбранных операционных систем (подробнее о специфических параметрах см. здесь).
Затем указывается мобильная версия «1С:Предприятие», которая будет использоваться для сборки приложений группы. Если указана конкретная версия ‑ всегда будет использоваться именно она, до тех пор, пока в группе не выберут новую версию. Если поле Мобильная платформа будет оставлено пустым, то сборщик при создании нового элемента в данной группе будет выбирать мобильную версию «1С:Предприятие» с максимальным номером (из списка загруженных в сборщик). Таким образом, становится возможным автоматически использовать самую «свежую» мобильную версию при сборке нового приложения.
Затем следует указать аудиоинформацию и набор графических файлов, которые будут использоваться приложениями в данной группе. Значения свойств Графические ресурсы и Аудиоресурсы будут «наследоваться» при создании нового мобильного приложения.
Поле Режим печати позволяет указать, какой способ печати будет использовать собираемое мобильное приложение. Это поле задается как в сборщике (описываемое поле), так и в свойствах информационной базы на мобильном устройстве. Приоритет имеет настройка, установленная в свойствах информационной базы. Каждая настройка может быть установлена в одно из следующих значений:
● Авто ‑ в этом случае режим печати выбирается автоматически:
● Если из приложения на устройстве ранее выполнялась печать встроенными средствами приложения ‑ будет продолжено использование этого способа печати.
● Иначе будет использовать печать средствами устройства.
Рекомендуется указывать это значение по умолчанию.
● Средствами устройства ‑ используется печать с использованием инструментов мобильной операционной системы, под управлением которой работает мобильное приложение. Печать выполняется на принтерах, которые поддерживает мобильная операционная система. При сборке приложений рекомендуется использовать этот способ печати в том случае, если собирается новая версия мобильного приложения, которое ранее выполняло печать встроенными средствами приложения, а теперь надо изменить для него режим печати.
● Встроенными средствами приложения ‑ в этом случае используется печать на принтерах, которые поддерживают языки PCL3 и ZPL. Печать выполняется только на поддерживаемых моделях принтеров. При сборке приложения рекомендуется указывать данный режим печати в том случае, когда у потребителей мобильного приложения имеется парк принтеров, совместимых с мобильной версией «1С:Предприятие» и эти принтера не поддерживаются используемой мобильной операционной системой.
Флажок Автоматизированное тестирование позволяет включить в собираемое мобильное приложение возможность выполнения автоматизированного тестирования в собранном мобильном приложении. По умолчанию флажок выключен.
Смотри также:
● Автоматизированное тестирование (см. здесь).
28.8.4.2.2. Идентификаторы мобильных приложений
В группе Идентификаторы мобильных приложений необходимо задать идентификатор мобильного приложения, которое будет собираться в данной группе. Здесь указывается вторая часть идентификатора (первая указана при настройке свойств поставщика мобильных приложений). После указания идентификаторов сборщик автоматически сформирует полные идентификаторы приложений для мобильных операционных систем, отмеченных для сборки в группе Собирать мобильное приложение. Следует помнить, что идентификатор мобильного приложения для ОС Windows следует получать в магазине приложений этой ОС, а не придумывать.
Полный идентификатор мобильного приложения для каждой мобильной ОС формируется по следующему алгоритму: поле Префикс идентификатора приложения из соответствующего свойства поставщика, символ "." и поле Идентификатор решения (для соответствующей ОС). Данное поле обязательно для заполнения. Идентификатор решения может состоять из символов латинского алфавита, цифр и символов "." и "_". Никакая часть идентификатора решения (в то числе идущая после любого символа ".") не может начинаться с цифры.
Для проверки, что в базе сборщика уже нет приложений с получающимися идентификаторами, предназначена команда Проверить уникальность идентификаторов. Глобальной проверки данная команда не выполняет.
28.8.4.2.3. Настройки, специфичные для различных мобильных операционных систем
Android
На вкладке Для ОС``Android выполняется настройка параметров сборки мобильного приложения, которое будет функционировать под управлением ОС Android.
Поле Формат результата сборки (находится на закладке Для ОС``Android) позволяет указать, каков будет результат сборки:
● Только``apk-файлы ‑ в этом случае сборщик будет собирать 4 apk-файла, которые можно загрузить на конкретное устройство при условии совпадения архитектуры процессора устройства и собранного apk-файла. Собираются мобильные приложения для работы на следующих архитектурах: ARM, ARM 64, x86, x86-64. Рекомендуется использовать в тех случаях, когда не предполагается публикация мобильного приложения или публикация выполняется средствами, отличными от магазина приложений Google Play.
● Только``aab-файл (пакет для магазина) ‑ в этом случае сборщик будет собирать только пакет приложений (aab-файл), который невозможно загрузить на конкретное устройство, но этот файл можно загрузить в магазины приложений. Рекомендуется использовать только в том случае, когда результат сборки будет использоваться только для публикации в магазин приложений Google Play.
● Все варианты результирующих файлов ‑ в этом случае сборщик будет собирать все варианты мобильных приложений. Данный вариант рекомендуется использовать в том случае, когда требуется собрать и вариант для публикации в магазине и вариант для сдаточного тестирования непосредственно на устройствах. В это случае, если сдаточное тестирование будет пройдено успешно, не потребуется тратить время на сборку приложения для размещения в магазине приложений Google Play.
Флажки Использовать сервисы``Google, Использовать сервисы``Huawei и Использовать сервисы RuStore позволяют указать, что в собираемом приложении будут использовать мобильные сервисы Google (GMS), Huawei (HMS) или RuStore. Если флажок (или флажки) Использовать сервисы … отключен, то при сборке приложения будут удалены библиотеки, отвечающие за взаимодействие с тем или иным набором мобильных сервисов. С одной стороны ‑ это может уменьшить размер мобильного приложения, с другой стороны это может привести к ошибкам, если мобильное приложение будет использовать, например, работу с картами, а при сборке было отключено использование мобильных сервисов. Поддержка мобильных сервисов, отличающихся от GMS, начинается с разных версий:
|
Мобильный сервис |
Мобильная версия |
|
Сервисы Huawei (HMS) |
8.3.24 |
|
Сервисы RuStore |
8.3.26 |
Если для сборки используется мобильная версия младше, чем указанная в таблице выше, то соответствующий набор мобильных сервисов будет недоступен. Также рекомендуется, чтобы версия сборщика мобильных приложений была не ниже, чем мобильная версия, используемая для сборки. Другими словами, если нужно собрать мобильное приложение для магазина (и сервисов) RuStore, следует использовать мобильную версию 8.3.26 (или последующие версии) и сборщик из комплекта этой мобильной версии (или последующую версию).
В группе, описывающей параметры, необходимые для работы с GMS, можно выделить следующие параметры:
● Группа Ключ для карт``Google ‑ параметры, необходимые для взаимодействия мобильного приложения и сервиса Google Maps. Подробнее о данных параметрах см. здесь.
● Поле Идентификатор приложения``Google``Ad``Mob содержит значение идентификатора приложения в сервисе Google AdMob, который следует получить при настройке рекламного сервиса (см. здесь).
● Поле Ключ проверки встроенных покупок должен быть указан в том случае, когда в мобильном приложении используются встроенные покупки с помощью сервиса Google Play In-App Billing. Данное значение получается при настройке сервиса Google Play In-App Billing (см. здесь).
● Группа Работа с``Firebase``Cloud``Messaging предназначена для операций с файлом google-``services.``json. Этот файл необходим в том случае, если собираемое приложение использует push-уведомления. Данный файл получается при настройке сервиса Firebase Cloud Messaging (см. здесь).
В группе, описывающей параметры, необходимые для работы с HMS, можно выделить следующие параметры:
● Поле Ключ проверки встроенных покупок должен быть указан в том случае, когда в мобильном приложении используются встроенные покупки с помощью сервиса Huawei In-App Purchases. Данное значение получается при настройке сервиса Huawei In-App Purchases (см. здесь).
● Группа Работа с``AppGallery``Connect предназначена для операций с файлом agconnect-``services.``json. Данный файл необходим для того, чтобы мобильное приложение могло взаимодействовать с любым сервисом из состава HMS. Описание получения этого файла можно получить в любом разделе, касающемся настройки компонента HMS.
В группе, описывающей параметры, необходимые для работы с RuStore, можно выделить следующие параметры:
● Поле Токен для работы с географическими картами ‑ данные, необходимые для работы с картами RuStore. Получение данного токена см. здесь.
● Поле Код приложения для встроенных покупок ‑ код приложения из консоли разработчика RuStore. Получить этот код можно в адресной строке веб-браузера. Например, если в адресной строке консоли разработчика присутствует URL вида: https://console.rustore.ru/apps/123456, то 123456 ‑ это и есть искомый код приложения.
● Поле Идентификатор проекта для PUSH-уведомлений ‑ сюда следует ввести значение ID проекта, которое получено при настройке PUSH-уведомлений (см. здесь) в консоли разработчика RuStore.
iOS
В том случае, когда планируется собирать пакет приложения для (ipa-файл) для устройство, работающих под управлением ОС iOS, для сборщика необходимо указать ряд параметров, зависящих от того, какая версия системы Xcode используется на компьютере Mac для сборки ipa-файла:
● Xcode 8 и старше: в поле Группа разработчиков следует указать группу разработчиков с нужным идентификатором (настройка выполняется в параметрах поставщика). В поле Способ распространения можно изменить способ распространения для текущего мобильного приложения. В Xcode должны быть сконфигурированы и установлены все необходимые сертификаты.
● Xcode 7 и младше: в поле Сертификат для сборки следует указать сертификат, которым будет выполняться цифровая подпись пакета приложения.
Фактически, содержимое поля Группа разработчиков, сообщает сборщику, с помощью какой версии Xcode будет выполняться сборка. Надо понимать, что, если поле Группа разработчиков очищено, но на компьютере Mac установлен Xcode версии 8 и старше ‑ сборка будет невозможна.
Поля Профиль обеспечения … (provisioning profile) используются в тех случаях, когда для сборки приложения для iOS требуется указание некоторого набора дополнительных параметров, согласно SDK фирмы Apple. В этом случае профили обеспечения создаются на компьютере Mac, затем загружаются в одноименный справочник и уже элементы этого справочника выбираются в полях Профиль обеспечения …:
● Поле Профиль обеспечения следует указывать в том случае, когда приложение использует push-уведомления.
● Поле Профиль обеспечения для демонстрации экрана требуется указывать в том случае, когда приложение мобильного клиента будет выполнять демонстрацию экрана мобильного устройства через систему взаимодействия.
● Поле Профиль обеспечения для активации приложения по расширению файла будет необходимо указать, если планируется использовать возможность активации приложения по расширению файла (попытка открыть файл с выбранным расширением приведет к открытию мобильного приложения).
В поле Идентификатор в``AppStore следует ввести числовой идентификатор, соответствующий собираемому приложению в магазине приложений компании Apple. Этот идентификатор будет использоваться при выгрузке приложения в магазин приложений.
Группа Работа с``Firebase``Cloud``Messaging предназначена для операций с файлом GoogleService-``Info.``plist. Этот файл необходим в том случае, если собираемое приложение использует сервис статистики Firebase Analytics. Данный файл получается при настройке сервиса Firebase Analytics (см. здесь).
Поле Идентификатор приложения``Google``Ad``Mob содержит значение идентификатора приложения в сервисе Google AdMob, который следует получить при настройке рекламного сервиса (см. здесь).
Windows
В поле Цвет фона стартового экрана можно указать цвет фона (в 16-ричном виде) стартового экрана приложения.
28.8.4.2.4. Настройки сервиса статистики
Если мобильное приложение планирует использовать сервис статистики, то необходимо выполнить ряд настроек в сборщике мобильных приложений. Настройки выполняются только в группе приложений.
Первым шагом в поле Статистика использования приложения необходимо выбрать используемый сервис статистики. Затем необходимо настроить параметры выбранного провайдера в диалоге, который открывается нажатием кнопки Параметры….
В диалоге следует указать следующие параметры:
● В поле Режим использования указывается, как будет выполняться включение сервиса статистики:
● Выключить ‑ в установленном мобильном приложении сервис статистики будет выключен по умолчанию.
● Включить, не запрашивая разрешения пользователя ‑ это означает, что после установки мобильного приложения сервис статистики будет включена без явного оповещения об этом пользователя.
● Включить, запрашивая разрешения пользователя ‑ это означает, что после установки мобильного приложения пользователь будет проинформирован, что приложение будет использовать сервис аналитики. При этом у пользователя будет запрошено разрешение на это использование. Пользователь может отказаться без потери функциональных возможностей приложения. Текст, который будет показан пользователю, задается с помощью поля Текст запроса разрешения (ниже в диалоге).
● Идентификатор приложения в сервисе статистики ‑ позволяет указать идентификатор приложения в том сервисе статистики, который выбран для данного приложения. Значение параметра зависит от используемого сервиса.
● Период отправки данных ‑ определяет интервал времени, по истечении которого, провайдер сервиса статистики будет пытаться отправить данные в сервис.
● Не включать имя конфигурации в имена событий ‑ отключает указание имени конфигурации в исходных событиях мобильного приложения. Используется для укорачивания имен событий/экранов, если приложение, например, работает только с одной конфигурацией.
● Собирать информацию об источниках трафика ‑ разрешает собирать эту информацию.
● Собирать информацию об аварийном завершении приложения ‑ разрешает отправлять в сервис статистики информацию об аварийном завершении работы мобильного приложения.
● Собирать информацию о покупках ‑ разрешает передачу в сервис статистики информации о покупках в мобильном приложении.
● Адрес обновления настроек регистрации ‑ содержит URL, откуда мобильное приложение может загрузить файл с настройками преобразования событий.
● XML-файл с настройками провайдера статистики ‑ позволяет загрузить (гиперссылка Загрузить) или удалить (гиперссылка Удалить) XML-файл с начальными настройками преобразования событий.
28.8.4.2.5. Используемые конфигурации
На закладке Конфигурации и версия указывается версия приложения в формате A.``B.``C (поле Версия приложения) и номер сборки (поле Номер сборки). Оба эти параметра, совместно, обеспечат полный номер версии приложения в формате A.``B.``C.``D, где D ‑ номер сборки. Если в списке конфигураций указан одна конфигурация, то номер версии можно получать автоматически из этой конфигурации. Если используется несколько конфигураций, то номер версии приложения лучше задавать самостоятельно. Ниже свойства Версия приложения указывается, что будет использоваться в качестве версии приложения.
В списке, расположенном ниже номера версии, указываются конфигурации, которые будут использоваться при сборке мобильного приложения. В данной таблице указываются группы из справочника мобильных конфигураций. Конкретные элементы здесь указать невозможно. Формирование списка конкретных конфигураций, которые будут размещены в собираемом приложении, будет выполнено при создании конкретного приложения.
28.8.4.2.6. Мобильный клиент
Если собирается приложение для мобильного клиента, то для настройки становится доступной закладка Мобильный клиент. На этой закладке выполняется настройка приложения мобильного клиента.
На закладке Список приложений формируется список информационных баз, с которыми может работать создаваемое мобильное приложение. Чтобы добавить информационную базу, следует нажать кнопку Добавить, затем в поле Тип указать Информационная база, выбрать конфигурацию и ее представление в списке мобильного клиента и указать URL, по которому расположена опубликованная информационная база с указанной конфигурацией. Последним действием можно указать (поле С.) будет данная информационная база сразу отображаться в списке приложений мобильного клиента или для ее отображения нужно будет вручную указать это уже в собранном мобильном клиенте. Это может потребоваться в том случае, если собираемое приложение мобильного клиента включает доступ к информационной базе, которая нужна не очень большому количеству пользователей (относительно общего количества пользователей приложения). В этом случае пользователи, которым требуется такая информационная база, смогут добавить ее в свой список, а другие пользователи эту базу не увидят вовсе.
Следует отметить, что можно не указывать URL информационной базы. В этом случае в сборщике будет отображаться текст `<< Любая ссылка
` и для работы с информационной базой ее адрес нужно будет явным образом ввести на мобильном устройстве. Одна конфигурация может быть добавлена в список несколько раз. В этом случае можно указать для каждой записи свой URL публикации информационной базы.
Кроме задания адресов информационных баз, имеется возможность указания адресов различных веб-страниц. Так, если приложение мобильного клиента запускается с пустым списком информационных баз, то будет автоматически открыта веб-страница, адрес которой указан в поле Адрес начальной веб-страницы сборщика мобильных приложений. Также эту веб-страницу можно открыть в любой момент командой Начало работы меню формы со списком информационных баз. С помощью данной страницы можно реализовать несколько операций:
● Регистрацию пользователя в информационной базе (или сервисе). Такая возможность может потребоваться в том случае, если информационная база требует указания имени пользователя и пароля, а пользователь еще не зарегистрирован. Если для приложения мобильного клиента, которое используется для доступа к корпоративным информационным базам, регистрацию пользователя может выполнить администратор этой информационной базы, то для информационной базы, доступной публично, такую регистрацию можно сделать с помощью специальной веб-страницы. Адрес этой страницы необходимо указать в свойстве Адрес начальной веб-страницы.
● Добавить в приложение мобильного клиента ссылку на веб-сервис, предоставляющий список общих информационных баз. Работа системы в этом случае аналогично поведению платформы для персонального компьютера (подробнее). Для этого на веб-странице должна располагаться гиперссылка, сформированная особым образом (с помощью схемы e1``c:// и команды AddToStartCfg). После добавления ссылки на веб-сервис, мобильный клиент автоматически выполнит получение списка информационных баз и отобразит полученный список.
● Запустить необходимую информационную базу, без добавления ее в список информационных баз приложения мобильного клиента. Для этого на веб-странице должна располагаться гиперссылка, сформированная особым образом (с помощью схемы e1``c:// и команды WS).
Предполагается, что на начальной странице будет реализован следующий сценарий работы:
1. Пользователю предлагается интерфейс регистрации в информационной базе (или сервисе).
2. При необходимости, после успешной регистрации ссылка на веб-сервис получения списка общих информационных баз добавляется в приложение мобильного клиента.
3. Выполняется запуск необходимой информационной базы. При этом пользователь использует для авторизации в информационной базе имя и пароль, полученные на первом шаге данного сценария.
Сборщик также предоставляет возможность указать адрес веб-страницы в списке информационных баз. Для этого следует нажать кнопку Добавить, затем в поле Тип указать Web-страница, в поле Представление указать, как данная веб-страница будет представлена в списке информационных баз, а в поле Адрес веб-сервера указать URL добавляемой веб-страницы. Поле С. (как и для информационной базы) определяет начальную видимость записи в списке приложений мобильного клиента.
Веб-страница, указанная в списке, предполагает задание страницы, на которой выполняются действия, для доступа к которым требуется авторизация, но эти действия не реализованы (по любым причинам) в информационной базе (или базах), доступ к которым имеет пользователь. В качестве примера такого действия можно привести оплату доступа к информационной базе или сервису (если доступ является платным).
Веб-страницы, которые указываются в поле Адрес начальной веб-страницы и в списке информационных баз, будут открываться в приложении мобильного клиента, а не веб-браузером по умолчанию на используемом мобильном устройстве. На этих страницах допустимо указание гиперссылок, использующих схему e1``c://. Нажатие по таким ссылкам обрабатывается непосредственно мобильным клиентом и позволяет добавлять информационные базы в список приложений мобильного клиента.
На закладке Список общих информационных баз сборщик позволяет указать, на основании каких ресурсов приложение мобильного клиента будет формировать список общих информационных баз. Флажок Использовать произвольный адрес списка общих информационных баз предоставит возможность пользователю добавить адрес веб-сервиса, который возвращает список общих информационных баз. В том случае, если адреса веб-сервисов списков общих информационных баз известны на момент создания мобильного приложения, то их можно указать в списке на этой закладке. Необходимо помнить, что мобильный клиент использует тот же веб-сервис получения списка общих информационных баз, что и интерактивная программа запуска платформы для персонального компьютера. Описание этого веб-сервиса см. здесь.
Флажок Разрешить добавлять информационные базы, используя``QR-коды включает или выключает одноименную возможность. Следует понимать, что включение флажка не означает получение такой возможности в собранном приложении. Использование QR-кодов в собранном приложении (при условии включения флажка) будет доступно при выполнении одного из следующих условий:
● Разрешено использовать произвольный адрес списка общих информационных баз (установлен флажок Использовать произвольный адрес списка общих информационных баз).
● В списке информационных баз и веб-страниц присутствует хотя-бы одна строка с пустым адресом веб-сервера (колонка Адрес веб-сервера).
А том случае, когда собранное приложение получает поддержку сканирования QR-кодов для добавления информационных баз, в список разрешения приложения добавляют разрешение, необходимое для использования камеры устройства, а в интерфейсе мобильного приложения появляется команда Добавить с помощью``QR-кода.
Состояние флажка Разрешить добавлять информационные базы, используя``QR-коды можно изменять как в группе, так и в настройках конкретного мобильного приложения, но окончательно «решение» принимается во время сборки приложения.
В том случае, если поле Адрес веб-сервера в списке Адреса информационных баз и веб-страниц или Пути к спискам общих информационных баз, содержит URL, который начинается со строки «https://», то сборщик дает возможность указать способ проверки сертификата сервера и клиентский сертификат:
● В поле Способ проверки сертификата сервера можно указать, откуда взять корневой сертификат для проверки сертификата сервера:
● Не проверять ‑ означает, что сертификат сервера проверяться не будет, но соединение мобильного клиента с сервером будет шифроваться.
● Хранилище сертификатов ОС ‑ означает, что для проверки сертификата сервера будут использоваться корневые сертификаты, размещенные в хранилище сертификатов устройства, на котором будет работать собираемое мобильное приложение. Соединение мобильного клиента и сервера будет шифроваться.
● Указанный сертификат ‑ означает, что для проверки сертификата сервера будет использоваться корневой сертификат, указанный в поле Сертификат сервера. Соединение мобильного клиента и сервера будет шифроваться.
● В поле Сертификат сервера указывается корневой сертификат, который используется для проверки сертификата сервера. Поле доступно только в том случае, если в поле Способ проверки сертификата сервера выбрано значение Указанный сертификат.
● В поле Клиентский сертификат указывается сертификат, который используется для удостоверения клиентского приложения.
В полях Сертификат сервера и Клиентский сертификат указываются сертификаты, предварительно загруженные в справочник Сертификаты для работы по``HTTPS. Загруженные сертификаты (для удобства применения) разделяются на корневые сертификаты (с установленным флагом Для проверки сертификата сервера) и клиентские сертификаты.
28.8.4.2.7. Навигационные ссылки мобильного приложения
На этой закладке настраиваются навигационные ссылки, которые будут обрабатываться этим мобильным приложением. Как и любые настройки группы приложений, на этой закладке создаются начальные настройки, которые потом можно будет изменить уже в конкретной версии мобильного приложения.
Указывается конфигурация, обрабатываемая ссылка и то, на какой мобильной операционной системе будет обслуживаться данная ссылка. Т. к. в группе еще не известно, какая конфигурация будет использоваться для сборки (а конфигурация содержит в себе список обрабатываемых навигационных ссылок), то указывается группа конфигураций. В этом смысле логика полностью эквивалентна логике настройки списка используемых конфигураций.
28.8.4.2.8. Схема e1c:
Описание команд
На веб-страницах, которые указываются в свойстве Адрес начальной веб-страницы и в записи типа Web-страница (в самом сборщике и в списке общих информационных баз), допускается указание URL (например, в элементе <``a``>), который принадлежит схеме e``1``c.
Такой адрес будет обрабатываться непосредственно мобильным клиентом. В адресе имеется возможность указать команды (и параметры) командной строки запуска мобильного клиента.
Кроме общих команд, реализованы несколько специализированных команд:
● Команда AddToStartCfg. Эта команда предназначена для добавления в приложение мобильного клиента ссылки на веб-сервис (или файл) получения списка общих информационных баз. Сервис описывается параметрами команды. Команда имеет следующий вид:
AddToStartCfg[&N=<пользователь>][&P=<пароль>][&Title=<заголовок>][[&InternetService=]|[&CommonInfoBases=]]
в данной команде используются следующие параметры:
● N``=<пользователь> ‑ позволяет указать пользователя, от имени которого будет выполнен доступ к сервису.
● P``=<пароль> ‑ пароль пользователя, указанного в параметре N.
● Title``=<заголовок> ‑ представление веб-сервиса в списке интернет-сервисов получения списков общих информационных баз мобильного клиента.
● InternetService``=<``URL``> ‑ URL сервиса получения списка общих информационных баз. После добавления мобильный клиент выполнит получение списка, который возвращает данный сервис. В одной команде может использоваться или параметр InternetService или CommonInfoBases.
● CommonInfoBases``=<``URL``> ‑ содержит полное имя файла со списком общих информационных баз (файл .v8i). После добавления мобильный клиент выполнит получение списка, который содержится в заданном файле. В одной команде может использоваться или параметр InternetService или CommonInfoBases.
● Команда AddByQRCode. Команда запускает сканирование QR-кода. Команда имеет следующий вид:
AddByQRCode[&SkipDetails]
в данной команде используются следующие параметры:
● SkipDetails ‑ не отображать пользователю детальную информацию о добавленных информационных базах.
● Команда AddInfoBase. Команда выполняет добавление информационной базы в список информационных баз текущего мобильного приложения. Команда имеет следующий вид:
AddInfoBase[&WS=<строка соединения>][&Run][&DisplayAuthDialog][&DisableUseBiometrics][&UseBiometrics[-|+]][&DisableRememberMe][&RememberMe[-|+]]
в данной команде используются следующие параметры:
● WS``=<строка соединения> ‑ описывает строку соединения с информационной базой, которую требуется добавить в список информационных баз.
● Run ‑ после добавления информационной базы выполнить ее запуск.
● DisplayAuthDialog ‑ показывать диалог аутентификации при первом запуске.
● DisableRememberMe ‑ отключает видимость флажка Запомнить меня в диалоге аутентификации.
● RememberMe``[-|+] ‑ начальное состояние флажка Запомнить меня. По умолчанию флажок включен.
● DisableUseBiometrics ‑ отключает видимость флажка Использовать биометрию в диалоге аутентификации.
● UseBiometrics``[-|+] ‑ начальное состояние флажка Использовать биометрию. По умолчанию флажок включен.
Смотри также:
● Сервис получения списка общих информационных баз (см. здесь).
● Формат файла со списком общих информационных баз (см. здесь).
Содержимое QR-кода
Для того чтобы QR-код был успешно распознан мобильной версией «1С:Предприятие», в нем должна быть закодирована конкретная информация. В зависимости от того, для использования каким клиентским приложением предназначен QR-код, в нем может кодироваться различная информация.
Мобильная платформа разработчика
1. URL расположения конфигурации. Данный URL получается в результате публикации мобильного приложения на веб-сервере.
Пример текста для генератора QR-кода:
http://host/cfgFolder
2. Строка соединения с информационной базой в виде ws``=``URL. На следующих строках допускается указание команд WSN и WSP. Эти команды задают параметры аутентификации на веб-сервере, где расположена конфигурация (подробнее о параметрахсм. здесь).
Пример текста для генератора QR-кода:
ws=http://host/cfgFolder wsn=<имя пользователя> wsp=<пароль пользователя>
Мобильный клиент
3. URL информационной базы. По такому URL может быть выполнено обращение с помощью тонкого клиента платформы для персонального компьютера или с помощью веб-браузера.
Пример текста для генератора QR-кода:
http://host/folder/dbName
4. Элемент файла списка информационных баз (*.``v8``i), описывающий информационную базу (описание формата см. здесь). При этом допускается использовать команды N, P, WSN, WSP,DisplayAuthDialog`,DisableRememberMe,```RememberMe,DisableUseBiometrics`,UseBiometrics. Команды N, Pописывают параметры аутентификации в приложении «1С:Предприятия». КомандыWSN, WSP` описывают параметры аутентификации на веб-сервере, где опубликовано приложение.
Пример текста для генератора QR-кода:
[Текст для списка информаицонных баз] Connect=ws="https://host/dbName/"; MobilePublicKey=AC05BDFD484C8F21C078A2E564765057 N=<пользователь ИБ> P=<пароль пользователя ИБ> WSN=<пользователь веб-сервера> WSP=<пароль пользователя веб-сервера>
Если в сформированном QR-коде будут присутствовать команды, которые не поддерживаются мобильным клиентом, эти команды будут пропущены.
5. Элемент файла списка информационных баз (*.``v8``i), описывающий список общих информационных баз (описание формата см. здесь). При этом допускается использовать команды N, P, WSN, WSP. Команды N, P описывают параметры аутентификации в приложении «1С:Предприятия». Команды WSN, WSP описывают параметры аутентификации на веб-сервере, где опубликовано приложение.
Пример текста для генератора QR-кода:
[Список общих баз] InternetService=https://host/service/ WSN=<пользователь веб-сервера> WSP=<пароль пользователя веб-сервера>
Примеры
В данном разделе будут рассмотрены примеры различных ссылок. При этом следует учитывать, что ссылки будут приведены в виде, максимально удобном для чтения, а не для размещения в реальном атрибуте href. Для размещения в атрибуте следует привести строку к корректному виду.
<a href="e1c://?AddToStartCfg&Title="Прикладное решение"&N=User1C&InternetService=https://my.site.com/is/hs/">
Переход по этому адресу приведет к добавлению в приложение мобильного клиента сервиса получения списка общих информационных баз, для доступа к которому будет использоваться пользователь User``1``C.
Переход по этому адресу приведет к подключению мобильным клиентом к прикладному решению, которое опубликовано по адресу https://``test.``app-``site.``com/``app-``name. При этом это приложение не будет добавлено в список информационных баз мобильного клиента.
Переход по указанному адресу приведет к выполнению двух действий:
1. В приложение мобильного клиента будет добавлен интернет-сервис получения списка общих информационных баз, опубликованный по адресу https://``my.``site.``com/``is/``hs/, и начнется получение этого списка.
2. После выполнения этого действия будет выполнено подключение мобильного клиента к информационной базе, опубликованной по адресу https://``test.``app-``site.``com/``app-``name.
28.8.4.3. Конкретное приложение
Для того чтобы получить конкретное приложение, необходимо в созданной ранее группе создать конкретное приложение. При создании приложения будут заполнены все поля, которые могут быть заполнены автоматически или могут быть «унаследованы» из родительской группы. В подавляющем большинстве «наследование» выполняется путем установки в нужное поле значения, указанного в группе.
Однако есть несколько исключений:
● Мобильная версия, используемая для сборки. Если в родительской группе указана конкретная версия ‑ в приложении будет использоваться указанная версия. Если поле Мобильная платформа в группе не указана, то сборщик попытается подобрать мобильную версию с максимальным номером, которая соответствует следующим условиям: не помечена на удаление, не удалена из информационной базы и подходит для текущего режима сборки (поле Собирать). Если в базе сборщика нет подходящих версий, то пользователь может попробовать сам указать нужную версию. Если нужно версии подобрать не получилось ‑ сборка будет невозможна.
● Конфигурации, используемые для сборки. Для каждой группы конфигураций, которые указаны в родительской группе (закладка Конфигурации и версия) выполняется поиск самой новой загруженной конфигурации, которая будет соответствовать следующим условиям: не помечена на удаление, принадлежит выбранной группе конфигураций и подходит для текущего режима сборки (поле Собирать). Считается, что чем больше код элемента, тем более «свежая» версия у конфигурации. Сборщик выбирает конфигурацию с самым большим кодом. В результате при создании нового приложения в него попадут самые свежие конфигурации (из необходимых), загруженные в сборщик.
● На закладках, соответствующих используемым мобильным операционным системам, устанавливаются полные идентификаторы приложений. В конкретном приложении изменить полный идентификатор приложения невозможно. Изменение возможно только через изменение идентификаторов приложений в группе и будет действовать только для вновь собираемых приложений.
● Для мобильного приложения определяется и указывается версия и номер сборки мобильного приложения.
На закладке Конфигурации и представления имеется возможность указать, какие конфигурации будут включены в собираемое приложение, а также каким будет представление собираемого приложения на всех поддерживаемых языках. Кроме автоматически добавленных конфигураций, на закладке Конфигурации приложения, можно добавить произвольный список конфигураций. Для того, чтобы оперативно получить информацию об используемой конфигурации, нужно использовать команду контекстного меню списка конфигураций Открыть конфигурацию. Если требуется выделить текущую конфигурацию в списке мобильных конфигураций, следует использовать команду контекстного меню списка конфигураций Найти конфигурацию в дереве. Обе команды удобно использовать в собранном приложении, т. к. собранное приложение открывается с отключенным редактированием, что затрудняет работу со списками.
Представление мобильного приложения определяется следующим образом:
● Определяются все языки локализации, которые присутствуют во всех используемых конфигурациях данного мобильного приложения.
● Для каждого языка локализации формируется представление. Представление конфигурации на конкретном языке будет представление той конфигурации, в которой язык встретился первый раз (по порядку обхода).
● Затем анализируется список Представление приложения группы мобильных приложений. Для совпадающих языков представление заполняется из группы.
Затем на закладке Представления мобильного приложения можно отредактировать представления для всех найденных языков. Язык представления всего приложения по умолчанию (название иконки приложения на мобильном устройстве) выбирается в поле Язык. Если необходимо изменить представление приложения на постоянной основе ‑ рекомендуется это делать в списке Представление приложения группы мобильных приложений.
Закладка Навигационные ссылки мобильного приложения служит для редактирования ссылок, которые будет обслуживать мобильное приложение. На данной закладке собираются настройки, выполненные в конфигураторе и в группе мобильных приложений. В форме собираемого приложения имеется возможность выполнить одно действие, которое недоступно при настройке группы мобильных приложений: это возможность сформировать файлы, необходимые для настройки глубинного связывания на веб-сервере. Сформированные файлы необходимо разместить в каталоге .``well-``known того домена, на который ведет глубинная ссылка в схеме HTTP(s). Таким образом, если мобильное приложение обрабатывает глубинную ссылку вида https://``my.``site.``com, то по адресу https://``my.``site.``com/.``well-``known должны лежать файлы, которые будут сформированы сборщиком при нажатии кнопки Сформировать (в колонке Настройки для сайта (.``json)) в строке списка обрабатываемые навигационных ссылок. Если мобильное приложение обрабатывает несколько различных ссылок, которые используют один домен ‑ достаточно сформировать файлы настроек для сайта только в одной из строк. Если ссылки расположены в различных доменах ‑ необходимо сформировать свои настройки сайта для каждого уникального домена.
Более подробная информация о требованиях мобильных операционных систем к файлам, которые должны размещаться в каталогах .well-known, можно получить по следующим ссылкам:
● Для ОС Android: https://``developer.``android.``com/``training/``app-``links/``verify-``site-``associations#``web-``assoc.
● Для ОС iOS: https://``developer.``apple.``com/``documentation/``safariservices/``supporting_``associated_``domains_``in_``your_``app?``language=``objc.
● Для ОС Windows: https://``docs.``microsoft.``com/``ru-``ru/``windows/``uwp/``launch-``resume/``web-``to-``app-``linking.
Остальные параметры собираемого приложения, при необходимости, могут быть изменены относительно настроек, указанных в группе.
28.8.4.4. Результат сборки
На закладке Результаты сборки размещены результаты сборки мобильного приложения.
Поле Дата и время сборки мобильного приложения содержат дату и время последней успешной сборки текущего мобильного приложения. Поля Дата последней выгрузки в … содержат дату и время, когда выполнялась выгрузка собранного приложения в соответствующий магазин приложений (поддерживается Google Play и Apple AppStore).
Ниже, в таблице, приводится список артефактов, которые были сформированы во время последней сборки. Для каждого артефакта указывается его тип и наличие собственно приложения и журнала сборки. Если запись отображается бледным цветом ‑ значит она устарела и все файлы удалены из базы данных. Наличие того или иного артефакта сборки зависит от выбранного режима сборки. Другими словами, не все артефакты сборки будут одновременно доступны после любой сборки. Всего доступны следующие артефакты сборки:
● Для ОС Android:
● Мобильное приложение или приложение мобильного клиента или приложение мобильного клиента с автономным режимом для всех следующих архитектур: ARM, ARM 64, x86, x86-64 (apk-файлы).
● Пакет приложений для размещения в магазине (aab-файл). Пакет включает файлы для всех архитектур и может состоять из файлов мобильного приложения, приложения мобильного клиента или приложения мобильного клиента с автономным режимом.
● Журнал сборки для каждого из вышеперечисленных артефактов. В некоторых случаях журнал сборки будет один на все артефакты, собранные для ОС Android.
● Для ОС iOS:
● Мобильное приложение или приложение мобильного клиента или приложение мобильного клиента с автономным режимом для ОС iOS.
● Проект для сборки с помощью Xcode мобильного приложения или приложения мобильного клиента или приложения мобильного клиента с автономным режимом.
● Мобильное приложение или приложение мобильного клиента или приложение мобильного клиента с автономным режимом для симулятора iOS.
● Журнал сборки для мобильного приложения/мобильного клиента и проекта для Xcode является общим. Журнал сборки для эмулятора является отдельным.
● Для ОС Windows:
● Мобильное приложение или приложение мобильного клиента или приложение мобильного клиента с автономным режимом для следующих архитектур: ARM, x86, x86-64 (appx-файлы).
● Журнал сборки для каждого из вышеперечисленных артефактов.
На данной закладке предоставляется возможность получить из базы сборщика все результаты сборки (и приложения и журналы сборки) одним архивом. Для этого необходимо выполнить команду формы Еще``‑ Получить приложения. В результате будет сформирован zip-архив, который содержит все файлы, полученные в результате сборки. Этот архив предлагается сохранить на клиентский компьютер. Архив имеет следующую структуру:
● В папке Android расположены файлы приложений для ОС Android. Суффикс имени файла определяет архитектуру процессора для каждого файла. Файлы имеют расширение .apk (приложение) или .aab (пакет приложений).
● В папке iOS расположены файлы приложений для ОС iOS. Файл с расширением .zip содержит архив проекта для самостоятельной сборки с помощью Xcode. Файл с расширением .ipa содержит исполняемый файл, пригодный для отправки на устройство или в магазин приложений. Файл, имя которого оканчивается на «-simul.zip», является мобильным приложением для работы на эмуляторе.
● В папке Windows расположены файлы приложений для ОС Windows. Суффикс имени файла определяет архитектуру процессора для каждого файла. У этих файлов будет расширение .appx.
● В папке Logs расположены журналы сборки все файлов. У эти файлов расширение .log.
● Именем каждого файла (включая файлы журналов сборки) выступает полный идентификатор приложения для соответствующей операционной системы.
При необходимости, можно загрузить из информационной базы каждый артефакт сборки. Для этого необходимо встать на нужную строку результатов сборки и нажать кнопку Получить приложение. Если необходимо посмотреть журнал сборки для этого артефакта ‑ следует в той же строке нажать кнопку Показать журнал.
28.8.5. Сборка приложения
Сборка мобильного приложения начинается по команде Собрать приложение. Данная команда доступна как в форме конкретного приложения, так и в списке мобильных приложений.
Перед сборкой конкретное приложение (элемент справочника) должен быть записан.
Сборка выполняется следующим образом:
1. Выполняются начальные проверки:
● Проверяется, что в собираемом приложении указана хотя-бы одна мобильная операционная система.
● Проверяется наличие нужного набора файлов для выбранной мобильной версии «1С:Предприятия» (мобильное приложение или мобильный клиент).
● Проверяется, что указана хотя-бы одна конфигурация.
● Проверяется, что режимы совместимости всех конфигураций, указанных в собираемом мобильном приложении, позволяют работать под управлением используемой для сборки мобильной версии (версии режима совместимости меньше номера мобильной версии). Если конфигурация выгружена в конфигураторе версии 8.3.23 или предшествующей версии, то сборка допускается, а в журнал сборки помещается рекомендация перевыгрузить конфигурацию с помощью Конфигуратора версии 8.3.24 или последующей версии.
● Если не пройдена хотя-бы одна проверка ‑ сборка невозможна.
2. Выполняется удаление из базы данных результатов предыдущей сборки.
3. Формируется кеш для используемой мобильной версии «1С:Предприятие». Кеш формируется в каталоге platform каталога, указанного в качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
4. Формируется кеш используемой графической информации. Кеш формируется в каталоге pictures каталога, указанного в качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
5. Формируется кеш используемых аудиофайлов. Кеш формируется в каталоге sounds каталога, указанного в качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
6. Формируется кеш внешних компонент, используемых в мобильном приложении. Кеш формируется в каталоге external-``components каталога, указанного в качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
7. Фактическая выгрузка в кеш выполняется только в том случае, если необходимых файлов нет на диске или они не соответствуют файлам в базе данных.
Если выполняется сборка для ОС Android, то происходит выбор компонентов, которые будут использоваться для сборки. Алгоритм подбора выглядит следующим образом:
1. Если используемая мобильная версия содержит требования к инфраструктуре ‑ выполняется проверка этих требований.
2. Если используемая версия не содержит требований к инфраструктуре ‑ сборка запускается «как есть». В том случае, если при сборке возникнут ошибки ‑ эти ошибки следует искать в журналах сборки.
Также в рамках подготовительных действий проверяется наличие инструментов сборки, нужных в случае сборки мобильных приложений для конкретных мобильных операционных систем. В общем случае выполняются следующие проверки:
● Наличие и корректность версии JDK выполняется в любом случае.
● Возможность собрать требуемый вид мобильного приложения с использованием указанной мобильной версии «1С:Предприятие». Другими словами, невозможно собрать приложение мобильного клиента с использованием мобильной версии «1С:Предприятие» младше 8.3.12.
● При указании сборки для ОС Android, дополнительно к общим проверкам проверяется:
● Версия SDK (по вышеописанному алгоритму).
● Наличие ключей подписи и загрузки приложения.
● При указании сборки для ОС iOS, дополнительно к общим проверкам проверяется:
● Корректность указанной версии мобильного приложения.
● Наличие утилит PuTTY (и ее версии).
● Настройка параметров подключения к компьютеру Mac.
● Корректность версии пакета Xcode на компьютере Mac.
● При указании сборки для ОС Windows, дополнительно к общим проверкам проверяется:
● Наличие Windows 10 SDK на компьютере сервера сборщика.
● Наличие сертификата разработчика.
Тексты запросов разрешений, необходимых мобильному приложению, задаются для приложения в целом. Однако каждая конфигурация, используемая в составе мобильного приложения, может иметь собственные тексты запросов разрешений. Сборщик использует следующий алгоритм определения списка текстов запросов разрешений (на различных языках), который будет использоваться для собираемого мобильного приложения:
● На основании всех конфигураций собираемого приложения формируется список языков собираемого мобильного приложения.
● Для каждого языка получается текст запроса разрешения. Для этого сборщик обходит используемые конфигурации в порядке расположения в списке и пытается получить текст запроса разрешения. Для приложения будет использоваться первый непустой текст запроса для каждого языка.
● Затем для каждого разрешения удаляются все языки, где текст запроса разрешения не указан. Для таких языков будет использоваться текст из платформы на этом языке (если удаленный язык входит в состав языков локализации мобильной версии) или английский текст (если удаленный язык не входит в состав языков локализации мобильной версии).
● Если в состав мобильного приложения входят конфигурации с указанием текстов запросов разрешений и конфигурации без указания таких текстов, то для формирования результирующего текста запросов будут использоваться только те конфигурации, где тексты запросов разрешений есть.
● Если все конфигурации мобильного приложения не используют текстов запросов разрешений ‑ все тексты запросов разрешений будут взяты из платформы.
Получившийся список текстов запросов разрешений будет помещен в собираемое приложение.
Каждая внешняя компонента, используемая в собираемом мобильном приложении, должна быть собрана для всех операционных систем, для которых собирается мобильное приложение. Если мобильное приложение собирается для ОС iOS и Android, то и внешняя компонента должна быть собрана для ОС iOS и Android. Однако могут возникать ситуации, когда внешняя компонента пишется только для одной мобильной операционной системы. В этом случае сборщик мобильных приложений будет записывать в журнал сборки мобильного приложения предупреждение о том, что определенная мобильная компонента не собрана для определенной мобильной операционной системы. Но сборка все равно будет продолжена. При попытке использования отсутствующей внешней компоненты на мобильном устройстве (в собранном приложении) будет сформировано исключение.
После выполнения всех подготовительных действий запускается сборка всех требуемых артефактов. Каждый артефакт собирается своим фоновым заданием. Режим сборки зависит от варианта информационной базы сборщика:
● Сборщик развернут в клиент-серверном варианте. Количество одновременно запущенных фоновых заданий определяется количеством процессорных ядер на компьютере, который исполняет роль сборочного сервера. Если количество фоновых заданий, которые необходимо запустить, превышает количество ядер, то количество запущенных фоновых заданий будет равно числу ядер, а остальные фоновые задания будут ожидать в очереди завершения уже запущенных сборочных заданий. Ожидающие фоновые задания будут запускаться по мере завершения ранее запущенных фоновых заданий.
● Сборщик развернут в файловом варианте. Сборка выполняется последовательно. Одновременно выполняется только одно фоновое задание. Ожидающие фоновые задания будут запускаться по мере завершения ранее запущенных фоновых заданий.
Если для какой-либо мобильной операционной системы сборка не заказывалась (не установлен соответствующий флажок в настройках мобильного приложения), то соответствующие фоновые задания не запускаются.
При сборке приложений для ОС Android с использованием Gradle, в рабочем каталоге сборщика формируется каталог gradle. Он занимает существенный объем (несколько гигабайт), однако удалять его после каждой сборки не рекомендуется, т. к. при следующей сборке он опять будет формироваться заново, а кроме того, наличие этого кеша существенно ускоряет процесс сборки приложения.
Во время сборки приложения для ОС iOS, сборка ipa-файла на компьютере Mac выполняется только в том случае, если в настройках сборщика указаны параметра подключения к компьютеру Mac. На компьютере Mac, указанном в настройках сборщика, должен быть установлен и корректно настроен пакет Xcode.
Во время сборки на экран выводится окно, отображающее время, которое уже заняла сборка и состояние каждого из запущенных сборочных процессов.
Каждое фоновое задание создает в рабочем каталоге сборщика свой собственный рабочий каталог. Имя этого каталога является текстовым представлением уникального идентификатора, полученного средствами платформы. Это значит, что имя рабочего каталога каждого фонового задания является уникальным при каждом выполнении. После окончания работы соответствующего фонового задания ‑ рабочий каталог этого фонового задания удаляется.
После окончания сборки результаты записываются в базу данных.
Если сборка для всех требуемых артефактов завершилась успешно ‑ собранное мобильное приложение становится недоступным для изменений. Его можно только пересобрать и посмотреть параметры, которые использовались для сборки. Это сделано для минимизации возможности получить уже собранное мобильное приложение, которое отличается от параметров, которые были заданы при его сборке.
Рабочий каталог сборщика может быть очищен полностью в произвольный момент времени (если только в этот момент не выполняется сборка мобильного приложения). После этого следующие несколько процессов сборки могут выполняться большее время (пока сборочный кеш опять не будет заполнен необходимой информацией).
Журнал сборки может оказать помощью при решении проблем со сборкой или работой приложения. В этом журнале присутствует как информация собственно сборщика мобильных приложений, так и информация тех утилит, которые запускаются сборщиком в процессе работы. В журнал попадает стандартный вывод (stdout) и стандартный вывод ошибок (stderr) запускаемых утилит.
Внимание! При обращении в фирму «1С» с проблемами, связанными с работой сборщика мобильных приложений, журнал сборки следует прикладывать сразу и полностью. Это существенно облегчит и упростит диагностику проблем.
28.8.6. Публикация приложения
Для собранных приложений сборщик предоставляет возможность загрузки в магазин приложений. Поддерживается работа с Google Play и Apple AppStore.
Рис. 547. Загрузка в магазины приложений
Загрузку можно выполнить по команде Загрузить в магазины из конкретного приложения или списка мобильных приложений. Если команда Загрузить в магазины выбрана для группы приложений, то сборщик автоматически выберет в этой группе такое приложение, которое удовлетворяет всем нижеуказанным условиям:
● Оно собрано и от момента сборки которого прошло минимальное количество времени.
● Оно собиралось для операционных систем Android или iOS.
● Собранное приложение не устарело.
● Собранное приложение не помечено на удаление.
Если в группе таких приложений не найдено ‑ будет выдано диагностическое сообщение о невозможности публикации приложения по причине отсутствия этого пригодного приложения. Непосредственно выгрузка выполняется из диалога, внешний вид которого показан выше.
Чтобы выгрузка была возможна, необходимо выполнение следующих условий (для каждого магазина):
● Должны быть собраны все требуемые приложения.
● В сборщике указаны параметры доступа к магазину приложений:
● Для Apple AppStore:
● в карточке поставщика (Сервис``‑ Настройка параметров поставщика``‑ Параметры для ОС``iOS ‑ Доступ к``iTunes``Connect).
● настроены параметры доступа к компьютеру Mac (Сервис``‑ Настройка параметров сборщика, группа параметров доступа к компьютеру Mac)
● Для Google Play: в карточке поставщика (Сервис``‑ Настройка параметров поставщика``‑ Параметры для ОС``Android ‑ Доступ к консоли разработчика).
Если загрузка по каким-то причинам невозможна ‑ эти причины будут сформированы в поле Диагностика для каждого магазина приложений.
Для магазина Google Play можно указать, какая конфигурация приложения загружается в магазин (поле Конфигурация).
Нажатие кнопки Загрузить приложение запускает процесс загрузки. Если загрузка завершилась неудачей, то нажатие кнопки Журнал для … позволит посмотреть журнал загрузки. Следует помнить, что журнал загрузки можно посмотреть только сразу после попытки загрузки. После закрытия формы Загрузить в магазины приложений журналы будут утеряны.
Подробнее о публикации приложения в магазинах приложений см. здесь.
28.8.7. Дополнительные возможности сборщика мобильных приложений
28.8.7.1. Интерфейс взаимодействия с сервисом «1С:Центр уведомлений» по рассылке push-уведомлений
28.8.7.1.1. Общая информация
Фирмой «1С» реализован вспомогательный сервис для отправки уведомлений ‑ 1С:Центр уведомлений. Подробное описание назначения и работы с сервисом см. здесь. Этот сервис имеет собственный пользовательский интерфейс. В то же время, сборщик мобильных приложений позволяет выполнять ряд операций без посещения сайта. К этим операциям относятся:
● Регистрация на сайте https://``pushnotifications.1``c.``com.
● Регистрация и отмена регистрации получателя уведомлений в сервисе.
● Подключить к зарегистрированному приложению возможность получать уведомления через поддерживаемые сервисы: APNs, FCM, WNS.
Для доступа к форме работы с сервисом необходимо открыть форму редактирования группы мобильных приложений и в этой форме нажать кнопку Работа с сервисом "1С:Центр уведомлений". В результате будет открыта форма работы с сервисом.
Рис. 548. Диалог работы с сервисом
Далее будут более подробно рассмотрены выполняемые действия.
28.8.7.1.2. Регистрация на сайте
Для подключения к сервису «1С:Центр уведомлений» необходимо ввести имя пользователя и пароль. Для этого следует нажать кнопку Указать параметры доступа к сервису. Для каждого пользователя сборщика необходимо регистрировать свои параметры доступа к сервису.
Если у пользователя нет доступа к сервису «1С:Центр уведомлений», то имеется возможность зарегистрироваться в сервисе непосредственно из сборщика. Для этого в форме регистрации параметров доступа необходимо нажать кнопку Зарегистрироваться в сервисе "1С:Центр уведомлений".
В процессе регистрации необходимо указать действующий номер мобильной радиотелефонной связи для получения код подтверждения, затем ввести в форму полученный код и остальные параметры.
После окончания регистрации, станет возможно выполнить регистрацию приложения в сервисе.
28.8.7.1.3. Работа с приложением
Диалог предоставляет возможность выполнить регистрацию мобильного приложения, которое будет получать уведомления. Для регистрации необходимо нажать кнопку Зарегистрировать приложение. В качестве наименования приложения будет использован текст из поля диалога Описание приложения. По умолчанию данное поле заполняется наименованием группы мобильных приложений.
Если использование приложения через сервис «1С:Центр уведомлений» больше не планируется, то необходимо нажать кнопку Удалить регистрацию приложения. Следует помнить, что удаление регистрации невозможно восстановить. Даже если повторно выполнить регистрацию, то с точки зрения сервиса, это будет новое приложение и ранее заданные данные для сервисов отправки уведомлений придется устанавливать заново.
28.8.7.1.4. Работа с сервисами
После выполнения регистрации приложения в сервисе, можно выполнить подключение к приложению сервисов отправки уведомлений. Текущий статус подключения отображается в нижней части диалога.
Нажатие кнопки Подключить … приводит к тому, что сборщик выполняет попытку подключения соответствующего сервиса. В зависимости от подключаемого сервиса, может потребоваться ввод некоторой дополнительной информации. Подробнее об этом см. здесь.
28.8.7.2. Отладка встроенных покупок
Описание отладки работы механизма встроенных покупок с помощью сборщика мобильных приложений см. здесь.
28.8.8. Рекомендации по обновлению сборочной инфраструктуры
Выход новой мобильной версии (с изменением в третьей цифре номера версии) системы «1С:Предприятие» сопровождается выпуском новой версии сборщика мобильных приложений. Также могут измениться требования, которые мобильная версия выставляет для сборочной инфраструктуры. Обновление сборочной инфраструктуры рекомендуется выполнять следующим образом:
● Использовать для редактирования мобильной конфигурации ту же версию системы «1С:Предприятие», что и планируемая к использованию мобильная версия. Если вы планируете использовать мобильную версию 8.3.19, то и конфигуратор для редактирования тоже рекомендуется использовать версии 8.3.19.
● Обновить существующую информационную базу сборщика мобильных приложений до версии, которая поставляется в дистрибутиве мобильной версии (файл mobile*.``zip).
● Выгрузить с помощью конфигуратора новую версию мобильной конфигурацию.
● Загрузить в обновленный сборщик:
● Мобильную версию, из состава которой получен дистрибутив сборщика.
● Мобильную конфигурацию, которая используется в мобильном приложении.
● Для новой мобильной версии следует оценить требования к версиям окружения и, при необходимости, обновить пакеты, которые не соответствуют требованиям новой мобильной версии. Например, может потребоваться установить новый Android API Level или обновить версию пакета Xcode.
При таком порядке обновления ожидается минимальное количество проблем несовместимости между различными версиями системы.
28.9. Публикация в магазине приложений
28.9.1. Общая информация
Подготовка приложения для размещения в магазине приложений делается аналогично проверке мобильного приложения перед публикацией в магазине приложений.
28.9.2. Для ОС Android
28.9.2.1. Google Play
28.9.2.1.1. Обновление существующих настроек публикации
Если вы уже публиковали приложения в магазине приложений (apk-файлы), то вам необходимо выполнить ряд действий, чтобы иметь возможность выполнять публикацию пакетов приложений.
**Внимание 1! Начиная с августа 2021 года, публикация пакета приложений является единственным способом публикации приложений в магазине Google Play.
Внимание 2! Смена режима публикации является необратимой. Включив возможность публикации пакета приложений, вернуться к публикации apk-файлов более не возможно.
Внимание 3! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.**
Предварительные действия:
1. Экспорт закрытого ключа для ключа подписи:
1. Откройте настройки поставщика в сборщике мобильных приложений.
2. Перейдите на закладку Параметры для ОС``Android.
3. Для ключа подписи приложений выполните команду Экспорт закрытого ключа.
4. Запомните имя и месторасположение pepk-файла. Имя файла по умолчанию будет android_``sign_``encrypted_``private_``key.``pepk.
2. Создание ключа загрузки приложения:
1. Откройте настройки поставщика в сборщике мобильных приложений.
2. Перейдите на закладку Параметры для ОС``Android.
3. Для ключа загрузки приложений выполните команду Создать ключ загрузки приложения. Если ключ уже создан ‑ новый ключ можно не создавать.
4. Затем выберите команду Экспорт сертификата ключа.
5. Запомните имя и месторасположение pem-файла. Имя файла по умолчанию будет android_``upload_``certificate.``pem.
Для того, чтобы включить возможность публикации пакета приложений, вам необходимо выполнить следующие действия:
1. Войти в консоль разработчика Google Play Console (https://play.google.com/apps/publish) от имени пользователя, который является разработчиком приложения.
2. В списке приложений следует выбрать приложение, для которого будут изменяться настройки. Откроется страница Панель управления.
3. В меню, расположенном в левой части страницы, необходимо выбрать команду Настройка``‑ Целостность приложения. Команда Настройка находится в группе настроек Выпуск. Откроется страница Программа подписания приложений``Google``Play.
4. В группе переключателей Зарегистрируйтесь в программе подписания приложений``Google``Play необходимо выбрать пункт Экспортировать и загрузить ключ из``Java``Keystore.
5. В открывшемся списке действия сразу нажмите гиперссылку шага «3. Загрузить закрытый ключ».
6. Выберите pepk-файл, приготовленный на предварительном этапе. По умолчанию pepk-файл имеет имя android_``sign_``encrypted_``private_``key.``pepk.
7. В шаге 4. Для большей безопасности создайте новый ключ загрузки выберите команду Показать инструкции.
8. Затем нажмите гиперссылку шага «c. Загрузить сертификат ключа загрузки».
9. Выберите pem-файл, приготовленный на предварительном этапе. По умолчанию pem-файл имеет имя android_``upload_``certificate.``pem.
10. На странице Программа подписания приложения``Google``Play следует нажать кнопку Сохранить. После принятия условий использования, в магазин Google Play станет можно публиковать только пакеты приложений.
28.9.2.1.2. Создание нового приложения в магазине Google Play
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Перед тем, как начать загрузку приложений в магазин Google Paly с помощью сборщика мобильных приложений, в магазине необходимо выполнить ряд действий. Рассмотрим эти действия.
Предварительные действия:
1. Создание и экспорт закрытого ключа (и сертификата) для ключа подписи:
1. Откройте настройки поставщика в сборщике мобильных приложений.
2. Перейдите на закладку Параметры для ОС``Android.
3. Для ключа подписи приложений выполните команду Создать ключ подписи приложения или Установить ключ подписи приложения (если ключ ранее создавался). Если ключ подписи приложения уже есть в сборщике ‑ этот шаг можно пропустить.
4. Выберите команду Экспорт закрытого ключа и сертификата.
5. Запомните имя и месторасположение zip-файла. Имя файла по умолчанию будет android_``sign_``encrypted_``key.``zip.
2. Создание и экспорт ключа загрузки приложения:
1. Откройте настройки поставщика в сборщике мобильных приложений.
2. Перейдите на закладку Параметры для ОС``Android.
3. Для ключа загрузки приложений выполните команду Создать ключ загрузки приложения или Установить ключ загрузки приложения (если ключ ранее создавался). Если ключ загрузки приложения уже создан ‑ новый ключ можно не создавать.
4. Затем выберите команду Экспорт сертификата ключа.
5. Запомните имя и месторасположение pem-файла. Имя файла по умолчанию будет android_``upload_``certificate.``pem.
3. Сохранение собранного пакета приложений (aab-файла):
1. Найти нужную версию приложения.
2. Открыть его и перейти на закладку Результаты сборки.
3. В списке артефактов сборки найти собранный пакет приложений для ОС Android и нажать кнопку Получить приложение.
4. Запомните имя и месторасположение aab-файла.
Для того, чтобы начать публикацию пакета приложений в магазине приложений Google Play, необходимо выполнить следующие действия:
1. Войти в консоль разработчика Google Play Console (https://play.google.com/apps/publish) от имени пользователя, который является разработчиком приложения. Откроется страница Все приложения.
2. Над списком приложений следует нажать кнопку Создать приложение. Откроется форма создания приложения.
3. В форме создания приложения необходимо заполнить все необходимые поля исходя из характеристик приложения, которое планируется опубликовать. После заполнения формы следует нажать кнопку Создать приложение (правый нижний угол экрана).
4. После создания приложения необходимо один раз вручную загрузить приложение для того, чтобы программное обеспечение магазина получило информацию о вашем приложении. Для этого необходимо создать версию приложения. Создадим версию для закрытого тестирования, для чего перейдем в пункт Тестирование``‑ Закрытое тестирование (меню в левой части экрана). Откроется форма Закрытое тестирование.
5. В форме закрытого тестирования, в списке Активные версии, следует нажать гиперссылку Управлять версией в строке Alpha. На открывшейся странице нужно нажать кнопку Создать новый выпуск. Откроется страница Создание закрытой тестовой версии.
6. В разделе Программа подписания приложений``Google``Play следует нажать гиперссылку Управление подписанием приложений.
7. Т. к. мы будем загружать приложения, которые собраны в сборщике мобильных приложений, то в меню Параметры подписания приложений следует выбрать пункт Экспортировать и загрузить ключ из``Java``Keystore. Затем следует выполнить следующее:
1. В пункте 3. Загрузить созданный``zip-архив следует выбрать для загрузки файл закрытого ключа и сертификата (имя по умолчанию: android_``sign_``encrypted_``key.``zip).
2. В пункте 4. Для большей безопасности создайте новый ключ загрузки нажать гиперссылку Показать инструкции.
3. В пункте c. Загрузить сертификат ключа загрузки следует выбрать файл сертификата (имя по умолчанию: android_``upload_``certificate.``pem).
4. Файлы, требуемые для загрузки, были сформированы на предварительных шагах.
5. После указания необходимых файлов следует нажать кнопку Обновить. В этот момент произойдет загрузка всех необходимых файлов и сменить параметры подписания приложений будет невозможно без полного удаления приложения!
8. В разделе Программа подписания приложений``Google``Play следует нажать кнопку Продолжить.
9. Затем в разделе Наборы``App``Bundle и``APK-файлы следует выбрать для загрузки ранее собранный aab-файл вашего приложения.
10. После завершения загрузки следует нажать кнопки Сохранить и Проверка выпуска.
11. Если в процессе проверки обнаружены ошибки ‑ их следует исправить. После того, как приложение пройдет проверки ‑ оно станет доступно для публикации.
12. Загрузка приложения с помощью сборщика мобильных приложений станет доступной только после того, как в магазине загружена вручную хотя-бы одна версия приложения.
28.9.2.1.3. Загрузка приложения
С помощью сборщика приложений для мобильных устройств
Первую загрузку приложения в магазин Google Play следует выполнять вручную. Последующие загрузки можно выполняться с помощью сборщика приложений для мобильных устройств. После загрузки приложений, собственно публикацию следует выполнять все равно из консоли магазина Google Play.
Необходимо открыть элемент списка мобильных приложений, для которого необходимо выполнить загрузку приложения, и выбрать команду Загрузить в магазины…. Сборщик проведет анализ выбранного мобильного приложения и сообщит пользователю о возможности или невозможности выполнить загрузку. Если загрузка доступна (установлен флажок Загрузить в``Google``Play), то необходимо указать конфигурацию, в которую будет помещено приложение в поле Конфигурация, а затем нажать кнопку Загрузить. Сборщик попытается выполнить загрузку. Состав загружаемых файлов зависит от мобильной версии, которая использовалась для сборки мобильного приложения, и формата результата сборки:
● Мобильная версия 8.3.18 или предшествующие ‑ загружаются 4 файла приложения (apk-файлы) для архитектур ARM, ARM64, x86 и x86-64.
● Мобильная версия 8.3.19 и последующие:
● Формат результата сборки Только``apk-файлы ‑ загружаются 4 файла приложения (apk-файлы) для архитектур ARM, ARM64, x86 и x86-64.
● Во всех остальных случаях загружается один файл пакета приложений (aab-файл).
Для доступа к Google Play, используются параметры, которые можно задать в диалоге настройки параметров поставщика на закладке Параметры для ОС``Android. Эту настройку может выполнить только администратор сборщика.
По окончанию загрузки сборщик сообщит состояние загрузки. Если загрузка закончилась неудачно ‑ рекомендуется нажать кнопку Журнал для``Google``Play. Будет открыт документ, в котором находится журнал загрузки. Журнал не сохраняется в информационной базе и будет утерян после закрытия окна загрузки.
Сборщик не выполняет публикацию версии приложения, он выполняет только загрузку приложения в магазин. Собственно публикацию следует выполнить вручную, из консоли магазина приложений.
Вручную
Если требуется выполнять загрузку пакета приложений в ручном режиме, то необходимо выполнить следующий набор шагов:
1. Войти в консоль разработчика Google Play Console (https://play.google.com/apps/publish) от имени пользователя, который является разработчиком приложения. Откроется страница Все приложения.
2. Найти публикуемое приложение и перейти в Панель управления этого приложения.
3. Создать новый выпуск требуемого вида (рабочая версия или версия для тестирования).
4. Загрузить файлы в параметрах выпуска.
В общем случае, описание работы с файлами приложений и консолью разработчика следует получать в справочной системе Google Play Console (https://``support.``google.``com/``googleplay/``android-``developer).
28.9.2.2. Huawei AppGallery
28.9.2.2.1. Создание нового приложения в магазине
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Перед тем, как начать загрузку приложений в магазин Huawei AppGallery, необходимо выполнить ряд действий. Рассмотрим эти действия:
1. Необходимо зарегистрироваться разработчиком HUAWEI и подтвердить свой аккаунт.
2. Войдите в AppGallery Connect (https://developer.huawei.com/consumer/ru/service/josp/agc/index.html#/).
3. Перейдите в раздел Мои приложения.
4. Нажмите кнопку Создать приложение.
5. Заполните информацию о вашем приложении и нажмите кнопку ОК:
1. Поле Тип пакета: APK (приложение``Android).
2. Поле Устройство: Мобильный телефон.
3. Поле Имя приложение: необходимо указать имя приложения, как оно будет отображаться пользователю.
4. Поле Категория приложения: Приложение.
5. Поле Язык по умолчанию: следует указать язык вашего приложения.
6. После создания приложения необходимо заполнить все поля, которые обязательны для заполнения. Эти поля отмечены символом «*» перед именем поля. После этого нажмите кнопку Сохранить в правом верхнем углу страницы.
Свойство приложения Имя пакета определяется при загрузке самого первого apk-файла в консоли AppGallery Connect после создания приложения. Имя пакета невозможно отредактировать, поэтому, в случае ошибки указания загружаемого пакета, будет необходимо удалить приложение, создать его заново и потом загрузить первую версию приложения с корректным именем пакета.
28.9.2.2.2. Загрузка приложения
Вручную
Если требуется выполнять загрузку пакета приложений в ручном режиме, то необходимо выполнить следующий набор шагов:
1. Войдите в AppGallery Connect (https://developer.huawei.com/consumer/ru/service/josp/agc/index.html#/).
2. Перейдите в раздел Мои приложения. Найдите приложение, версию которого вы планируете загрузить.
3. На странице приложения перейдите на закладку Размещение и в левом меню выберите пункт + Версия/Обновление.
4. Задайте нужные параметры версии.
5. В разделе Версия приложения нажмите кнопку Управление пакетами.
6. Укажите в диалоге загружаемые файлы и нажиме кнопку Выбрать.
7. Завершите формирование версии нажатие кнопки Сохранить в правой верхней части страницы.
В общем случае, описание работы с консолью разработчика следует получать в справочной системе Huawei AppGallery Connect (https://``developer.``huawei.``com/``consumer/``en/``doc/``distribution/``app/``agc-``help-``overview-0000001100246618).
28.9.2.3. RuStore
Публикация приложения в магазине RuStore описана по ссылке: https://www.rustore.ru/help/developers/publishing-and-verifying-apps/app-publication (на русском языке).
28.9.3. Для ОС iOS
Перед отправкой приложения в Apple AppStore необходимо создать приложение в портале iTunes Connect и заполнить всю требуемую информацию о приложении. Затем следует нажать кнопку Ready``to``Upload``Binary, при этом статус вашего приложения в iTunes Connect должен измениться на Waiting``For``Upload.
28.9.3.1. Из архива проекта
После формирования файла с архивом приложения для ОС iOS следует скопировать файл архива на компьютер Mac и выполнить следующие действия:
● Распаковать файл с проектом мобильного приложения <ИдентификаторПриложения>.``zip на компьютере Mac.
● Открыть проект мобильной платформы разработчика в системе Xcode (двойным щелчком мыши по файлу 1``cem.``xcodeproj или выбрать файл 1``cem.``xcodeproj с помощью команды File ‑ Open в системе Xcode).
● С помощью команды меню Xcode Product ‑ Edit``Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся диалоге:
● В свойстве Scheme выбрать значение 1``cem.
● В свойстве Build``configuration выбрать значение Release.
● Нажать кнопку OK.
● Создать архив приложения с помощью команды Xcode Product ‑ Archive.
● Открыть инструмент Organizer с помощью команды меню Xcode Window ‑ Organizer.
● В верхней панели переключится на архивы Archives.
● Выбрать созданный архив и нажать кнопку Distribute….
● Следовать указаниям помощника.
28.9.3.2. Бинарный файл (.ipa)
С помощью сборщика приложений для мобильных устройств
Необходимо открыть элемент списка мобильных приложений, для которого необходимо выполнить загрузку приложения, и выбрать команду Загрузить в магазины…. Сборщик проведет анализ выбранного мобильного приложения и сообщит пользователю о возможности или невозможности выполнить загрузку. Если загрузка доступна (установлен флажок Загрузить в``Apple``AppStore), то нажав кнопку Загрузить, сборщик попытается выполнит загрузку. При этом используется имя пользователя и пароль доступа к iTunes Connect, который можно указать в диалоге настройки параметров поставщика на закладке Параметры для ОС``iOS (если настройку выполняет администратор сборщика) или в диалоге Сервис``‑ Параметры доступа к``iTunes``Connect (если публикацию может выполнять обычный пользователь).
Публикация выполняется с помощью компьютер Mac, на котором выполнялась сборка мобильного приложения.
По окончанию загрузки сборщик сообщит состояние загрузки. Если есть подозрение, что загрузка закончилась неудачно ‑ рекомендуется нажать кнопку Журнал для``AppStore. Будет открыт документ, в котором находится журнал загрузки. Журнал не сохраняется в информационной базе и будет утерян после закрытия окна загрузки.
Вручную
Отправка подготовленного пакета приложения (ipa-файл) в Apple App Store выполняется с помощью утилиты Application``Loader, входящей в комплект средств разработки Xcode. Для запуска утилиты загрузчика приложений необходимо сначала запустить Xcode, затем выбрать меню Xcode ‑ Open``Developer``Tool ‑ Application``Loader.
В загрузчике необходимо ввести данные вашей учетной записи в программе для разработчиков Apple. Затем необходимо выбрать Deliver``Your``App. В открывшемся диалоге выбрать приложение, которое вы хотите отправить. Если его нет в списке, значит в iTunes Connect для этого приложения не заполнена необходимая информация. Далее необходимо нажать Next, затем Choose, и выбрать требуемый ipa-файл. Для отправки файла необходимо нажать Send и дождаться завершения процесса.
28.9.4. Для ОС Windows
С помощью сборщика приложений для мобильных устройств
Сборщик приложений для мобильных устройств не поддерживает публикацию приложений в магазин Windows Store.
Вручную
Прежде чем выполнять сборку приложения в сборщике приложений для мобильных устройств, необходимо зарезервировать идентификатор вашего приложения в магазине Windows Store. Для этого необходимо зайти в информационную панель магазина (https://``appdev.``microsoft.``com/``StorePortals/).
Для создания приложения следует выбрать + Создать новое приложение. Теперь необходимо ввести планируемый идентификатор приложения и нажать гиперссылку Проверить доступность. Если введенное имя занято, то зарезервировать данное имя будет невозможно, о чем будет сообщено справа от поля с идентификатором приложения. Если имя доступно, то следует нажать кнопку Зарезервировать имя приложения.
После сборки мобильного приложения следует загрузить получившиеся файлы в созданное приложение из информационной панели. Для этого в информационной панели следует нажать мышью на созданное приложение и в левом меню выбрать пункт Отправки, а затем нажать кнопку Начать отправку.
В открывшейся форме необходимо установить свойства приложения, цены, описание продукта, его возрастной ценз и т. д. Затем следует нажать гиперссылку Пакеты и загрузить файлы appx-файлы, созданные сборщиком приложений для мобильных устройств. Если загрузка прошла успешно ‑ следует нажать кнопку Сохранить. После заполнения всех параметров отправки следует нажать кнопку Отправить в Магазин и ожидать результатов проверки.