Академический Документы
Профессиональный Документы
Культура Документы
В зависимости от решаемой задачи, разработчик может разрабатывать приложение для мобильной платформы или приложение,
функционирующее в мобильном клиенте. Между этими вариантами разработки есть существенные отличия:
● Приложение на мобильной платформе является аналогом тонкого клиента, работающего с файловой информационной базой,
находящейся на том же компьютере, что и само клиентское приложение. Приложение на мобильной платформе работает с информационной
базой, расположенной на мобильном устройстве. Из вышесказанного следует, что клиентская и серверная часть прикладного решения
функционируют на мобильном устройстве. Наличие информационной базы на мобильном устройстве означает, что для синхронизации данных
между мобильным устройством и основной системой (если таковая существует) необходимо реализовывать необходимые инструменты.
Кроме того, приложение на мобильной платформе ‑ это отдельная технология, для использования которой следует разработать полностью
новое решение или существенно доработать текущее.
● Мобильный клиент является аналогом тонкого клиента для обычного компьютера, использующего для доступа к информационной базе
веб-сервер. Другими словами, при работе мобильного клиента на мобильном устройстве отсутствует информационная база. В мобильном
клиенте клиентский код исполняется на мобильном устройстве, а серверный код исполняется на сервере приложений. При этом, как
очевидно, сервер приложений функционирует не на мобильном устройстве. Так как на мобильном устройстве отсутствует информационная
база, то это означает, что мобильный клиент работает только в том случае, если между мобильным устройством и веб-сервером существует
соединение. Мобильный клиент не может работать в режиме офлайн.
Для того чтобы прикладное решение работало в мобильном клиенте, необходимо не переписать его (как в случае с приложением на
мобильной платформе), а адаптировать. При адаптации следует помнить о то, что мобильный клиент обладает специфическим набором
особенностей и ограничений, которые следует учитывать при доработке прикладного решения. Существенной особенностью мобильного
клиента является то, что он поддерживает технологию расширений конфигурации.
● Мобильный клиент с автономным режимом ‑ это мобильный клиент, для которого доступна возможность работы в автономном режиме,
т. е. без подключения к информационной базе. Для того чтобы прикладное решение могло работать в автономном режиме, необходимо более
существенно доработать приложение, которое может работать в мобильном клиенте. Для мобильного клиента с автономным режимом
требуется выбрать набор метаданных, которые доступны в автономном режиме, реализовать формы автономного режима и способы
синхронизации данных в информационной базе. С точки зрения сложности разработки, мобильный клиент с автономным режимом находится
между мобильным клиентом и мобильным приложением.
Интерфейс мобильных приложений ‑ аналог интерфейса Такси. В целом, интерфейсы приложения мобильной платформы и мобильного клиента
выглядят аналогично. Тем не менее, работа интерфейса в каждом из возможных вариантов обладает своей спецификой, которую следует
учитывать во время разработки прикладного решения.
● Мобильная версия «1С:Предприятия». Данный термин будет использоваться в том случае, когда необходимо коротко описать все
возможности, предоставляемые фирмой «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.
Интерфейс мобильной версии «1С:Предприятия» является аналогом интерфейса Такси, с возможностью переключения между окнами с
помощью главного меню приложения. Навигация в приложении зависит от того, какая форма активна в данный момент:
● Форма открывается командой из меню функций ‑ в левой части заголовка окна находится кнопка открытия главного меню приложения.
Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства или специальной кнопки.
● Форма открывается другими командами или из встроенного языка ‑ в левой части заголовка окна находится кнопка возврата в
предыдущее окно (<). При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была
вызвана команда открытия закрываемой формы. Главное меню приложения доступно с помощью жеста с левой стороны экрана
устройства.
● При последовательном открытии таких окон образуется цепочка открытых окон, в которой пользователю доступна только самая
последняя открытая форма. При этом закрытие текущей формы приводит к активизации предыдущей формы цепочки, т. е. той формы,
откуда была открыта закрываемая форма. Следует понимать, что возврат может произойти не в ту форму, в которой пользователь
находился до того, как переключился на закрываемую форму.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Например: форма создания объекта, вызванная из главного меню приложения или с помощью встроенного языка.
● При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была вызвана команда
открытия закрываемой формы.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Например: форма, для которой свойство Режим открытия окна установлено в значение Блокировать окно владельца или Блокировать
весь интерфейс.
● При наличии сохраняемых данных (признак реквизита Сохраняемые данные) ‑ стандартная кнопка Отмена.
● Если форма содержит одну из команд Отмена, Закрыть, Нет ‑ отображается эта команда.
● Главное меню приложения недоступно для формы, блокирующей весь интерфейс. Для формы, блокирующей окно владельца, главное
меню приложения доступно с помощью жеста с левой стороны устройства.
При запуске мобильного приложения отображается полноэкранная картинка, заданная разработчиком приложения. В определенный момент
времени в нижней части экрана появляется логотип и копирайт фирмы «1С», перекрывая часть заставки:
Интерфейс мобильной версии «1С:Предприятия» ориентирован на то, что в один момент времени на экране отображается одна форма. Под нее
освобождается максимум свободного места на экране. Поэтому, команды, которые на персональном компьютере формируют командный
интерфейс основного раздела (панели навигации и действий), собраны в главное меню приложения. Главное меню приложения содержит
команду возврата на начальную страницу, список разделов (команды каждого раздела отображаются в виде подменю), а также команды
отображения информации о программе и перехода к списку приложений. Вызов главного меню приложения осуществляется жестом с левой
стороны экрана (если доступно) или с помощью специальной кнопки ≡, расположенной в левой части заголовка окна.
Начальная страница поддерживает отображение разного количества форм, в зависимости от используемого варианта:
● Мобильный клиент ‑ отображаются все доступные формы начальной страницы (алгоритм выбора формы и способ отображения описан
далее).
● Мобильный клиент с автономным режимом ‑ аналогично мобильному клиенту, с учетом особенностей автономного режима (описано далее).
● Из списка форм, указанных в настройках рабочей области начальной страницы исключаются формы, которые недоступны в соответствии с
правами доступа.
● Мобильная платформа ‑ из оставшихся форм (в результате предыдущих шагов) выбирается первая видимая форма, при этом обход форм
рабочего стола идет сверху вниз, вначале левая колонка, затем правая (если задано расположение форм начальной страницы в две
колонки).
● Мобильный клиент ‑ отобранные для отображения формы располагаются в виде закладок, у которых переключатель закладок
расположен сверху. При запуске прикладного решения отображаются две закладки: первая видимая форма и специальная закладка,
нажатие на которую приводит к загрузке всех остальных форм начальной страницы. После загрузки всех форм, под каждую форму будет
создана отдельная закладка начальной страницы.
● Мобильный клиент с автономным режимом ‑ в обычном режиме работы поведение аналогично мобильному клиенту. Если мобильный
клиент находится в автономном режиме или в настрйоках приложения установлен флажок Рассчитывать на плохое соединение, то при
выборе форм начальной страницы пропускаются формы, которых нет в автономной конфигурации. В сявзи с этим, чтобы работа
пользователя не зависела от режима работы, рекомендуется в качестве первой формы начальной страницы выбирать такую форму,
которая 1) имеет прикладной смысл и 2) доступна в автономной конфигурации.
Если при формировании начальной страницы в автономной конфигурации не обнаружено ни одной формы, то на начльной страницы
отображается форма, содержимое которой зависит от режима работы:
● Автономный режим:
● В форме кнопка Начало …, после нажатия на котороую загружаются формы начальной страницы.
Кроме формы, на начальной странице может располагаться командный интерфейс основного раздела. Состав командного интерфейса основного
раздела на мобильной версии аналогичен таковому на платформе для персонального компьютера (кроме группы См.также). Командный
интерфейс основного раздела отображается в виде матрицы кнопок (каждая кнопка связана с одной командой), сгруппированной по страницам.
Картинка на кнопке получается из связанной команды. Если команда не обладает настраиваемой картинкой, используется стандартная
картинка для данной группы команд.
Команды выводятся так чтобы максимально заполнить рабочую область окна. Группы команд размещается на страницах так, чтобы избежать
переноса между страницами, т. е. если после одной группы команд вторая не помещается полностью в оставшееся место, то она начинается с
новой страницы. Если все команды не помещаются на экран, то они размещаются на нескольких страницах, которые можно пролистывать.
Отображение сообщений пользователю зависит от того, сколько не просмотренных сообщений имеется в настоящий момент. Первое не
просмотренное сообщение отображается в виде диалога с текстом сообщения и кнопкой ОК. После прихода второго сообщения в диалоге
дополнительно появляется кнопка Все сообщения. В кнопке Все сообщения имеется подпись с полным количеством пришедших сообщений.
По нажатию на кнопку Все сообщения открывается панель сообщений, которая содержит все непрочитанные сообщения. Если в диалоге нажата
кнопка ОК или закрывается панель сообщений, то список сообщений очищается. Нажатие на сообщение приводит к активации элемента формы,
если сообщение связано с таковым. Для повторного открытия списка сообщений следует повторно вызвать действие, приводящее к открытию
списка.
Данный раздел содержит описание механизмов, которые используются одинаково как в приложении на мобильной платформе, так и в
мобильном клиенте.
Все приложения на мобильных устройствах работают в рамках специального механизма, обеспечивающего безопасное исполнение программ
(«песочница», sandbox). В рамках этого механизма, приложениям предоставляется ограниченный доступ к файловой системе мобильного
устройства. При разработке мобильного приложения может требоваться доступ к файловой системе, например для промежуточного хранения
данных или записи документов, сформированных в системе, для последующего обмена с другими компьютерами.
Для получения доступа к таким местам файловой системы предназначены специальные функции:
● КаталогВременныхФайлов() ‑ возвращает каталог временных файлов данного приложения. При необходимости каталог может быть очищен
операционной системой.
● КаталогДокументов() ‑ каталог документов, которые предназначены для обмена с внешним (по отношению к мобильному приложению)
окружением.
Вне зависимости от реальных возможностей мобильной ОС, не рекомендуется использовать для работы любые другие каталоги файловой
системы мобильного устройства из соображений безопасности, а также требований разработчиков мобильных ОС к прикладным приложениям.
Если в прикладном решении требуется каким-то образом использовать файл, расположенный на мобильном устройстве, то для выбора файла
можно использовать объект ДиалогВыбораФайла. Данный диалог поддерживает работу только в режиме выбора существующего файла
(РежимДиалогаВыбораФайла.Открытие) и не поддерживает режим работы РежимДиалогаВыбораФайла.Сохранение. Если требуется сохранить файл
на мобильном устройстве, следует использовать интерактивный вариант метода ПолучитьФайл().
На мобильном устройстве имя файла в библиотеке может не соответствовать тому, как этот файл отображается системными приложениями. При
этом представление файла не может быть использовано для идентификации файла, передачи в качестве параметров методов работы с файлами
и т. д. Представление предназначено исключительно для отображения пользователю. Для получения представления следует использовать
метод Файл.ПолучитьПредставлениеФайлаБиблиотекиМобильногоУстройства().
Следует помнить, что в каталоги библиотек мобильного устройства (в общем случае) невозможно выполнить запись файлов обычным способом.
Запись возможна только с помощью методов ПолучитьФайл() или ПолучитьФайлы().
1. Если путь к каталогу (или файлу) начинается со строки content:, то для записи в такой каталог допустимо использовать только методы
ПолучитьФайл() или ПолучитьФайлы(). Также допустимо использовать такие пути в конструкторах следующих объектов: Файл,
ДвоичныеДанные, Картинка, ЗапускПриложенияМобильногоУстройства и в качестве параметров следующих методов: ЗапуститьПриложение(),
ПерейтиПоНавигационнойСсылке(), КопироватьФайл(), ПереместитьФайл(), УдалитьФайлы(), НайтиФайлы().
2. Если путь к каталогу (или файлу) не начинается со строки content:, то для работы с такими файлами и путями можно использовать все
возможности мобильной платформы по работе с файлами. Следует помнить, что мобильные операционные системы работают с разными
файловыми системами. Следовательно, разделители путей и маски всех файлов отличаются на разных мобильных операционных систем.
3. Для того, чтобы получить маску всех файлов и разделитель пути к файлу универсальным способом, который учитывает используемую
операционную систему и место исполнения кода, необходимо использовать специальные методы ПолучитьМаскуВсеФайлы() и
ПолучитьРазделительПути(). Для унификации с кодом прикладного решения для персонального компьютера, можно использовать методы,
которые возвращают указанные параметры отдельно для клиентской и серверной части прикладного решения:
ПолучитьМаскуВсеФайлыКлиента()/Сервера() и ПолучитьРазделительПутиКлиента()/Сервера().
При отображении информации из библиотек мобильного устройства может потребоваться показывать не полноценные изображения, а
уменьшенные копии (preview, картинка представления). В результате снижается вероятность получения ошибки нехватки памяти при работе с
мобильным приложением, которое активно использует картинки или видео-файлы из библиотек мобильного устройства. Для того, что получить
картинку представления для файла, расположенного в библиотеке мобильного устройства, следует использовать метод
Файл.ПолучитьКартинкуПредставленияФайлаБиблиотекиМобильногоУстройства(). При использовании данного метода следует помнить, что для
получения картинки представления, путь к обрабатываемому файлу должен принадлежать схеме content (начинаться со строки content:).
Для мобильных устройств используется обычная картинка с вариантами, которая используется платформой для персонального компьютера.
Описание формата картинки и ее манифеста см. здесь.
Для устройств на ОС Android используются картинки, соответствующие разрешению экрана используемого устройства.
29.3.4. Форма
Для тех механизмов или объектов конфигурации, которые не поддерживаются мобильной версией «1С:Предприятия», будут недоступны
свойства элементов формы, связанные с этим механизмом или объектом. Например, свойство Сочетание клавиш или события, связанные с
перетаскиванием.
Принципы и правила формирования формы для мобильной версии «1С:Предприятия» в основном совпадают с таковыми для тонкого клиента,
однако, есть некоторые особенности, которые следует учитывать при разработке форм мобильного приложения:
● Экраны смартфонов, в основном, ориентированы на вертикальное расположение (портретная ориентация), поэтому форма существенно
ограничена по своей ширине и слабо ограничена по высоте.
● Для мобильных устройств не принята прокрутка формы по горизонтали, т. к. полосы прокрутки на мобильных устройствах не отображаются
постоянно, поэтому пользователь может не обратить внимания на то, что форма (отчет или таблица) показывает только фрагмент
информации. В связи с этим, при формировании форм, разработчик обязан сам предпринимать усилия для того, чтобы все элементы формы
помещались в ней по ширине, например, используя группы с группировкой Горизонтальная если возможно. Если таких усилий не
предпринято, то форма будет ограниченно работоспособна, т. к. горизонтальная полоса прокрутки в формах на мобильной платформе не
поддерживается.
● Поле ввода;
● Поле надписи;
● Поле переключателя;
● Поле картинки;
● Поле флажка;
● Поле индикатора;
● Поле диаграммы;
● Кнопка;
● Таблица;
Группы, включая саму форму, и большая часть элементов формы, отображаются в виде списков, как это принято в мобильных интерфейсах.
Элементы формы условно делятся на три типа:
● Поле ввода;
● Поле надписи;
● Поле переключателя;
● Кнопка;
● Поле диаграммы.
3. Не могут располагаться в строке списка. В эту группу входят все остальные элементы.
● Строкой списка выступает либо элемент формы, либо группа с горизонтальной группировкой элементов.
● Если в группе с вертикальной группировкой находятся элементы, которые не могут располагаться в строке списка, то в списке
отображается разрыв.
● Визуальными разделителями строк являются горизонтальные линии, отображением которых нельзя управлять.
Особенностью поведения элементов 2 типа является то, что они располагаются в строке списка, только если сгруппированы с элементами 1
типа. Сами по себе элементы 2 типа в список не оформляются.
Многие элементы формы не имеют рамок (поля ввода и кнопки, у которых цвет рамки установлен в значение Авто). В связи с этим,
выравнивание полей ввода на форме (как на платформе для персонального компьютера) не имеет практического смысла. Вместо него
используется алгоритм выравнивания значений в полях ввода. В зависимости от наличия и расположения заголовка у поля ввода, информация
в нем выравнивается по-разному:
● Заголовок поля отсутствует или отображается не слева, то числовые значения выравниваются вправо, а остальные ‑ влево.
● Выравнивание полей остальных типов зависит от того, есть в группе с этими полями поле для редактирования текста или нет. Если
такое поле есть, то выравнивание остальных полей осуществляется аналогично выравниванию этого поля. В противном случае ‑ вправо.
Как было уже сказано выше, прокрутка формы по горизонтали не применяется на мобильных устройствах. В тоже время вертикальная
прокрутка формы является вполне допустимой. Исходя из этих предпосылок, мобильная версия «1С:Предприятия»
пытается автоматически перестроить форму таким образом, чтобы она поместилась на экране мобильного устройства. В процессе адаптации
уменьшается ширина элементов формы для тех элементов, ширина которых в конфигурации задана так, что превышает фактическую ширину
экрана на мобильном устройстве. Ширина для таких элементов формируется таким образом, чтобы элемент поместился (по ширине) в текущей
ориентации мобильного устройства без горизонтальной прокрутки. Кроме изменения ширины, система может выполнить попытку уменьшить
количество отображаемых элементов формы, чтобы улучшить визуальный вид формы. Для управления необходимостью такой перестройки
предназначено свойство формы Вариант сворачивания элементов формы по важности (СворачиваниеЭлементовПоВажности). Значение Авто
трактуется как Использовать.
Для того чтобы мобильной версии было проще адаптировать форму, у элементов формы (и колонок таблиц) имеется свойство Важность при
отображении (ВажностьПриОтображении). Изменяя значение этого свойства, разработчик может добиться нужного вида формы на экране
устройства. Значение этого свойства мобильный клиент обрабатывает следующим образом:
● Если более важный элемент расположен под менее важными, и эти менее важные элементы занимают более трех строк формы, то менее
важные элементы объединяются и помещаются в сворачиваемую группу. Важно понимать, что здесь и далее важна высота, а не количество
элементов. Другими словами, три строки сетки формы могут занимать как три элемента высотой каждый по одной строке, так и один элемент
формы, занимающий три строки высоты.
● Если первым или последним из сворачиваемых элементов является командная панель, то она не сворачивается, так как может относиться к
важному элементу.
● Если более важный элемент расположен внутри иерархии групп или страниц, и при этом в разных местах иерархии над ним расположены
менее важные элементы, занимающие более трех строк, в каждом уровне иерархии формируется сворачиваемая группа.
● Если имеются несколько элементов более высокой важности, то менее важные элементы, находящиеся между ними, помещаются в
сворачиваемую группу, если менее важные элементы занимают более трех строк.
● Менее важные элементы, находящиеся ниже последнего более важного элемента, не сворачиваются.
● Если внутри свернутой группы также расположены элементы разной важности, то к этой группе алгоритм применяется рекурсивно.
● Если в свертываемую группу попадает один элемент с заданным заголовком, то используется заголовок этого элемента.
● Если не подходит ни один из вышеперечисленных пунктов ‑ заголовок формируется соединением, через ",", всех заголовков элементов,
входящих в свертываемую группу.
Если для элемента формы свойство ВажностьПриОтображении установлено в значение Авто, то фактическое значение свойства будет
определяться по следующим правилам:
● Значение ОченьВысокая для элемента формы, отображающего данные основного реквизита формы (и подчиненные реквизиты).
● Значение Высокая, если элемент растягивается по вертикали и является одним из следующих элементов:
● поле HTML-документа.
● Значение Высокая, если источником команд для командной панели выступает собственно управляемая форма.
● Значение важности элемента, который является источником команд для командной панели.
● Значение важности самого важного элемента в той же группе, что и командная панель, при условии, что для командной панели не
установлен источник команд.
На форме не отображается отметка незаполненного как для элементов, расположенных на форме, так и для элементов, расположенных в
таблице.
29.3.4.4.2. Форма
Свойство ТекущийЭлемент позволяет получить и установить текущий элемент формы. Однако установка текущего элемента формы не приводит к
переходу этого элемента в режим редактирования и никак не отображается визуально. Чтобы перевести элемент формы в режим
редактирования, следует воспользоваться методом НачатьРедактированиеЭлемента().
Если при открытии формы выполняются какие-либо действия, то следует учитывать тот факт, что до окончания работы всех обработчиков
формы не будет выполняться обновления экрана мобильного устройства.
Для облегчения работы с полем ввода с помощью сенсорных экранов мобильных устройств, во всех полях, кроме полей ввода текста и полей,
где используется автоподбор, редактирование значения непосредственно в поле ввода не предполагается. Поле ввода ведет себя как кнопка,
заголовок которой отображает представление текущего значения, а нажатие этой кнопки открывает специализированный редактор. В том
случае, если в поле ввода используется автоподбор, имеется возможность очистить значение с помощью кнопки Очистить, расположенной в
левой части заголовка окна.
Длинное нажатие в поле ввода приводит к появлению контекстного меню, которое состоит из стандартных команд системы и команд, которые
добавлены в это меню во время разработки.
Для отображения кнопок очистки, открытия и регулирования, следует установить в значение Да соответствующее свойство поле ввода. Кроме
этого, имеется дополнительная возможность по управлению видимостью кнопок очистки и открытия, которые отображаются непосредственно в
поле ввода. Эта возможность предоставляется с помощью свойств АвтоОтображениеКнопкиОчистки и АвтоОтображениеКнопкиОткрытия. Данные
свойства обрабатываются только в том случае, если соответствующее свойство поля ввода установлено в значение Да. Возможны следующие
варианты поведения (значения свойств АвтоОтображениеКнопкиОчистки и АвтоОтображениеКнопкиОткрытия):
● Только для заполненного ‑ в этом случае кнопка будет отображаться только в том случае, если значение в поле отличается от значения по
умолчанию для используемого типа или если данные, отображаемые полем ввода, имеют составной тип.
Кнопка выбора всегда не отображается, при этом событие НачалоВыбора срабатывает в момент нажатия на само поле ввода. Если для
редактирования значения поля используется отдельная форма, то рядом с полем размещается специальный маркер (>), нажатие на который
приведет к открытию этой формы. Расположение и внешний вид редакторов отличается на планшете и телефоне.
Многострочное поле ввода всегда работает в режиме ввода текста. Такое поле ввода не поддерживает выбор значений и автоподбор. Если поле
ввода связано с данными, отличными от типа Строка, то для такого поля ввода игнорируется значение флажка МногострочныйРежим.
Многострочное поле ввода может отображаться тремя различными способами:
1. Автоматическая подстройка высоты поля под высоту текста (чтобы избежать прокрутки). Подстройка происходит в том случае, когда поле
занимает всю ширину формы, не указана высота поля (свойство Высота) и поле может растягиваться по вертикали (свойство
РастягиватьПоВертикали).
2. Поле имеет заданную высоту и допустима вертикальная прокрутка внутри поля. Поле отображается таким образом в том случае, когда
указана высота поля (свойство Высота) и поле не может растягиваться по вертикали (свойство РастягиватьПоВертикали).
3. Поле занимает максимально возможное место на форме. Поле отображается таким образом в том случае, когда указана высота поля
(свойство Высота) и поле может растягиваться по вертикали (свойство РастягиватьПоВертикали).
Для мобильной платформы также актуальны дополнительные свойства поля ввода, которые позволят более эффективно использовать
прикладное решение. Эти свойства позволяют дополнительно настроить поле ввода (только в том случае, если поле ввода отображает данные
типа Строка) для выполнения некоторых специфических задач:
● Свойство АвтоИсправлениеПриВводеТекста ‑ позволяет включить автоматическое исправление вводимого текста. Поведение зависит от
настроек используемой виртуальной клавиатуры. Значение Авто означает, что для многострочных полей ввода автоматическое исправление
работает, а для обычных (однострочных) ‑ нет.
● Свойство ПроверкаПравописанияПриВводеТекста ‑ позволяет включить проверку правописания при вводе текста. При работе под
управлением ОС Android данное свойство игнорируется, т. к. данная возможность управляется системой и зависит от других настроек.
При работе под управлением ОС Windows данное свойство и свойство АвтоИзменениеРегистраПриВводеТекста всегда включаются
одновременно. При установке свойства ПроверкаПравописанияПриВводеТекста в значение Использовать, операционной системой будет
автоматически включено изменение регистра вначале предложения при вводе текста. Это изменение будет выполнено вне зависимости от
значения свойства АвтоИзменениеРегистраПриВводеТекста. Значение свойства АвтоИзменениеРегистраПриВводеТекста будет использоваться
при работе под управлением других операционных систем.
Значение Авто означает, что для многострочных полей ввода автоматическая проверка работает, а для обычных (однострочных) ‑ нет.
● Свойство АвтоИзменениеРегистраПриВводеТекста ‑ позволяет управлять автоматическим изменением регистра символов при вводе текста.
Поведение зависит от используемой операционной системы и настроек используемой виртуальной клавиатуры.
При работе под управлением ОС Windows данное свойство и свойство АвтоИзменениеРегистраПриВводеТекста всегда включаются
одновременно. При установке свойства ПроверкаПравописанияПриВводеТекста в значение Использовать, операционной системой будет
автоматически включено изменение регистра вначале предложения при вводе текста. Это изменение будет выполнено вне зависимости от
значения свойства АвтоИзменениеРегистраПриВводеТекста. Значение свойства АвтоИзменениеРегистраПриВводеТекста будет использоваться
при работе под управлением других операционных систем.
● Авто ‑ для многострочных полей ввода аналогично значению Предложения, а для обычных (однострочных) ‑ Нет.
● Свойство СпециальныйРежимВводаТекста ‑ позволяет задать специальный вид виртуальной клавиатуры при вводе в поле ввода:
● Цифры и пунктуация ‑ используется виртуальная клавиатура для ввода цифр и символов пунктуации.
● Email ‑ используется виртуальная клавиатура для ввода адреса электронной почты. На клавиатуре будет присутствовать символ @.
● Номер телефона ‑ используется виртуальная клавиатура для ввода номера телефона, которая содержит цифры и клавиши * и #.
При работе на планшетах под управлением ОС Android, все виды виртуальных клавиатур, кроме клавиатуры вида Номер телефона, могут
выглядеть одинаково, в связи с наличием большого количества свободного места на экране.
При разработке форм, предполагающих ввод различной информации (номера телефонов, адреса электронной почты и т. д.), может возникать
необходимость специальным образом именовать кнопку завершения ввода на используемой виртуальной клавиатуре. Это должно помочь
пользователю понять, какое действие будет выполнено после нажатия этой кнопки. Для этого существует свойство поля ввода
ТекстКнопкиВводаЭкраннойКлавиатуры. Значение данного свойства обозначают текст, который будет отображаться на кнопке завершения ввода.
При работе под управлением ОС Android при указании значения Продолжить будет отображаться Далее, а при указании значения Подключиться
‑ Ввод. Под управлением ОС Windows значение данного свойства будет игнорироваться. Управление текстом на кнопки ввода не
поддерживается.
Флажок может отображать только два состояния. При работе под управлением ОС iOS флажок всегда отображается в виде тумблера.
Поле переключателя вида Переключатель всегда выводится в отдельной вертикальной группе (количество колонок не настраивается). Поле
переключателя вида Переключатель не комбинируется с другими элементами в одной строке.
Поле переключателя вида Тумблер всегда выводится в одной строке (количество колонок не настраивается).
29.3.4.4.6. Кнопка
В том случае, когда кнопка расположена в вертикальной группе, она растягивается до ширины родительской группы. Текст внутри кнопки
выравнивается по левому краю кнопки, кроме случая, когда цвет рамки кнопки отличается от значения по умолчанию ‑ в этом случае текст
выравнивается по центру кнопки.
29.3.4.4.7. Группа
При отображении групп управляемой формы поддерживается только отступ для групп с режимом отображения Обычное выделение и Сильное
выделение.
При отображении свертываемой группы (свойство группы Поведение установлено в значение Свертываемая), имеется ряд особенностей:
● Свертываемая группа всегда отображается с вариантом отображения Картинка и его (варианта отображения) настройка игнорируется.
Группа вида Страницы позволяет реализовать несколько вариантов панели с закладками. Вид панели (и ее поведение) зависит от значения
свойства Отображение закладок:
● Закладки сверху.
● Закладки отображаются в виде тумблера. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в конце
текст отображается символ …. Картинки в заголовках не отображаются.
● Закладки снизу.
● Закладки отображаются в виде панели кнопок. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в
конце текст отображается символ …. Картинки в заголовках отображаются, при этом текст заголовка всегда отображается под картинкой.
● Если на экране не хватает места для отображения заголовков всех страниц группы, то в конец списка добавляется кнопка Еще. Нажатие
на эту кнопку открывает список заголовков всех страниц группы.
● Закладки слева.
● Закладки выводятся в виде списка. Нажатие на закладку приводит к открытию нового окна с содержимым закладки, которое замещает
текущую форму (со списком закладок). Для возврата к списку закладок служит специальная кнопка (<), расположенная в левой верхней
части заголовка страницы.
● Пролистывание.
● Закладки выводятся в виде точек под страницами. Текст и картинки не отображаются. Переключение между страницами выполняется
жестом слева-направо или справа-налево в области страниц.
● В платформе для персонального компьютера данное значение интерпретируется как значение Закладки слева.
● Закладки справа.
29.3.4.4.8. Таблица
Поведение текущей строки в таблице определяется свойством таблицы Использование текущей строки (ИспользованиеТекущейСтроки):
● Значение Выбор. В этом случае свойства ТекущаяСтрока, ТекущийЭлемент, ТекущиеДанные определены только во время выполнения:
В остальное время эти свойства таблицы имеют значение Неопределено. Для команды формы, которой необходимы данные текущей строки,
следует явно указать такую необходимость в свойстве команды формы Использование текущей строки. Дополнительно необходимо указать
таблицу, данные из которой будет использовать команда, с помощью свойства Используемая таблица.
Если текущая строка устанавливается из встроенного языка, то установленное значение сохраняется до окончания выполнения метода
встроенного языка верхнего уровня (вызванного системой из интерфейса, а не из другого метода встроенного языка).
Данное значение рекомендуется использовать для таблиц, логически не связанных с какими-то другими данными (в том числе и
табличными).
● Значение ОтображениеВыделения. В этом случае текущая строка существует всегда, если таблица содержит хотя-бы одну строку.
Данное значение рекомендуется использовать для таблиц, которые логически связанны с какими-то другими данными (в том числе и
табличными).
● Значение ОтображениеВыделенияИВыбор. В этом случае текущая строка существует всегда, если таблица содержит хотя-бы одну строку.
В списке текущая строка визуально определяется всегда. Также в правой части строки имеется кнопка, которая выполняет одновременно два
действия: активизацию строки и ее выбор.
● Значение Авто. Данное значение трактуется как значение Выбор и на мобильной платформе и в мобильном клиенте.
● при отображении дерева ‑ только в тех случаях, когда определено свойство ТекущаяСтрока.
● Отображение колонок, которые не помещаются в видимой части таблицы, зависит от значения свойства таблицы управляемой формы
Поведение при сжатии по горизонтали (ПоведениеПриСжатииПоГоризонтали) и от свойства Важность при отображении
(ВажностьПриОтображении) колонок этой таблицы:
● Значение Скрывать элементы по важности ‑ в этом случае колонки, которые не помещаются на форму, будут скрываться по мере
убывания значения свойства Важность при отображении у колонки. Таким образом, вначале будут скрыты колонки с самой низкой
важностью (Очень низкая), затем со следующей важностью (Низкая) и т. д. Если есть несколько колонок с одинаковой важностью, то
скрытие осуществляется справа налево. Другими словами, чем левее в таблице расположена колонка, тем выше у нее шансов быть
отображенной на форме (при прочих равных).
● Значение Переносить элементы по важности ‑ в этом случае колонки скрываются по мере убывания важности (аналогично поведению
Скрывать элементы по важности), а значения скрытых колонок отображаются в отдельной строке, мелким шрифтом, через запятую и с
чередованием цветов.
● основной режим;
Основной режим аналогичен режиму отображения таблицы на платформе для персонального компьютера, за исключением отображения
текущей и выбранных строк. В мобильной платформе эти строки не отображаются. Исключением служит кратковременная подсветка текущей
строки таблицы при открытии формы. Таблица формы автоматически подстраивается под размер содержимого в том случае, если одновременно
выполняются следующие условия:
● в объекте, который отображается таблица, содержится менее 100 строк данных. Если строк более 100 ‑ будет доступна прокрутка.
Режим выбора нескольких строк характеризуется специальной колонкой с флажками, с помощью которых и выполняется выбор. Колонка всегда
отображается самой первой. В этом режиме контекстные команды таблицы доступны и действуют на все выделение сразу.
Режим сортировки строк характеризуется наличием специальной колонки с маркером, за который можно таскать строку. Эта колонка всегда
отображается самой последней. В этом режиме недоступны контекстные команды таблицы.
Режим множественного выделения в таблице (свойство РежимВыделения установлено в значение Множественный) на мобильной платформе
визуально никак не отображается. Признаком его существования служит специальная команда Выбор нескольких, которая доступна в
командной панели, связанной с таблицей. При выборе этой команды таблица переходит в режим выбора нескольких строк.
Если установлен режим множественного выбора (свойство МножественныйВыбор установлено в значение Истина), то таблица сразу находится в
режиме выбора нескольких строк, при этом команда перехода в этот режим в командной панели отсутствует.
Если в таблице доступно изменение порядка строк (например, табличная часть документа), то для активизации этого режима необходимо
выполнить специальную команду Перестановка строк, которая доступна в командной панели, связанной с таблицей. В этом случае таблица
переходит в режим сортировки строк, и сбрасываются выделенные строки (если они были).
Для таблицы поддерживаются только два режима ввода строк (свойство РежимВводаСтрок): в конце списка и в конце окна. Всегда используется
режим выделения строки ‑ Строка (свойство РежимВыделенияСтроки). Фактическое значение свойства игнорируется.
Контекстное меню
Таблица формы поддерживает использование контекстного меню, которое открывается жестом от правой границы таблицы или длительным
нажатием на строку.
Заполнение командной панели и контекстного меню имеет важные отличия от платформы для персонального компьютера. На платформе для
персонального компьютера вопрос распределения команд между командной панелью и контекстным меню ‑ это вопрос дизайна формы. На
мобильной платформе (в силу отсутствия текущей строки) это вопрос функциональной модели. Если команда использует свойства таблицы,
связанные с текущей строкой, то такая команда должна располагаться в контекстном меню. Если такая команда размещена разработчиком в
другом месте, то система может принудительно переместить ее в контекстное меню. Исключением из этого правила выступает случай, когда
команда может выполнять свою работу как в связи с текущей строкой, так и без таковой. В качестве примера можно привести команду Создать
динамического списка, отображающего данные иерархического справочника. Внеконтекстное использование команды предполагает создание
элемента в корне справочника, а контекстное ‑ в текущей группе.
Для того чтобы указать системе, что команда оперируется данными текущей строки, предназначено свойство команды формы
ИспользованиеТекущейСтроки. Для того чтобы связать команду формы с таблицей, чьи данные она должна обрабатывать, служит свойство
команды ИспользуемаяТаблица. Использование данного свойства означает, что на мобильной платформе невозможно реализовать команду,
оперирующую одновременно данными более одной таблицы. Для управления размещением команды существует свойство команды
ОтображениеВКонтекстномМеню:
● Авто ‑ команда, которая использует данные текущей строки, всегда располагается в контекстном меню. Команда, которая не использует
данные текущей строки ‑ всегда располагается в командной панели таблицы.
Строка поиска
Управление расположением строки поиска также отличается от платформы для персонального компьютера. В зависимости от значения свойства
таблицы ПоложениеСтрокиПоиска, возможно следующее поведение:
● Авто ‑ строка поиска доступна по нажатию кнопки командной панели (если таблица отображает динамический список и этот динамический
список является основным реквизитом формы) или появляется при жесте вниз по заголовку таблицы (в остальных случаях);
● Верх, Командная панель ‑ строка поиска расположена между командной панелью таблицы и заголовком таблицы;
● Потянуть сверху ‑ строка поиска появляется при жесте вниз по заголовку таблицы;
В том случае, если у двух и более таблиц формы свойство ПоложениеСтрокиПоиска установлено в значение Заголовок формы, то фактическое
поведение будет аналогично тому, как если у каждой из таких таблиц данное свойства установлено в значение Верх.
При прокрутке таблицы, связанной с динамическим списком, в ее верхней и нижней частях появляются полупрозрачные кнопки. Нажатие на эти
кнопки приводит к переходу в начало или конец списка (соответственно).
Для управления высотой таблицы управляемой формы предназначено свойство Вариант управления высотой (ВариантУправленияВысотой):
● В строках формы ‑ в этом случае высота таблицы задается с помощью свойства Высота таблицы управляемой формы. Если значение этого
свойства равно 0, то высота таблицы будет равна 8 единицам для таблицы, отображающей динамический список и 4 единицам ‑ во всех
остальных случаях.
● В строках таблицы ‑ в этом случае высота таблицы задается с помощью свойства ВысотаВСтрокахТаблицы таблицы управляемой формы.
Если значение этого свойства равно 0, то высота таблицы будет равна 7 строкам для таблицы, отображающей динамический список и 3
строкам ‑ во всех остальных случаях.
● По содержимому ‑ если таблица связана с динамическим списком, то высота таблицы задается значением свойства ВысотаВСтрокахТаблицы.
Если значение этого свойства равно 0, то высота таблицы определяется значением свойства ВысотаВСтрокахТаблицы.
Если таблица не связана с динамическим списком, то полностью отображаются все строки таблицы, но не менее 3 и не более 100 строк. При
добавлении 101-й строки таблица сжимается до высоты, указанной в свойстве ВысотаВСтрокахТаблицы. Если это свойство установлено в
значение 0, то для определения высоты используется свойство Высота. При этом содержимое таблицы начинает прокручиваться по
вертикали. При удалении 101-й строки таблица растягивается по высоте до размера, достаточно для размещения 100 строк таблицы.
Значение По содержимому рекомендуется использовать для таблиц, отображающих небольшое количество строк.
Обновление данных
Обновление данных, отображаемых таблицей, можно осуществлять в стиле, принятом на мобильных устройствах: путем попытки потянуть
список вниз или вверх при достижении первой или последней (соответственно) строки отображаемых данных (pull to refresh). Для управления
данной возможностью предназначено свойство таблицы Запрос обновления (ЗапросОбновления):
● Нет ‑ обновление можно выполнить только через команду командной панели таблицы;
● Любое другое значение означает, что обновление можно инициировать попыткой потянуть список в соответствующую сторону. При этом в
области таблицы за пределами данных отображается анимация.
При выполнении обновления списка, таким образом, будет вызван обработчик события таблицы ОбработкаЗапросаОбновления. В том случае,
если таблица адаптируется под содержимое, то обработчик таблицы ОбработкаЗапросаОбновления вызываться не будет.
Если динамический список, связанной с таблицей, не содержит отображаемых данных, то внутри таблицы отображается надпись Нет данных
для отображения. Таблица, не связанная с динамическим списком, не отображает никакого текста при отсутствии данных для отображения.
Вместо редактирования данных в строке таблицы, связанной с табличной частью или таблицей значений, мобильная платформа предоставляет
специальную системную форму. Эта форма содержит все отображаемые на родительской форме колонки текущей строки таблицы. При
использовании этой формы необходимо помнить о следующих особенностях:
● Колонки, для которых установлено свойство Только просмотр, отображаются в системной форме также без возможности редактирования;
● Поддерживается управление настройками динамического списка с помощью встроенного языка. Для интерактивной настройки необходимо
самостоятельно реализовать соответствующие формы настройки.
● Имеется возможность выполнять сортировку по нажатию на заголовок. По нескольким колонкам таким образом сортировать нельзя.
Панель навигации формы реализована с помощью специального меню, которое отображается в нижней части формы в виде переключателя.
Нажатие кнопки переключателя приводит к открытию соответствующей формы.
● Если командная панель содержит стандартные пары команд ОК-Отмена и Да-Нет, то кнопка с отрицательным действием переносится в
левую часть заголовка формы, а положительная отображается в командной панели формы. В меню Еще присутствуют все команды, кроме
команды с отрицательным действием, которая была перенесена в заголовок формы.
● Если командная панель не содержит вышеуказанных пар команд, но содержит стандартную команду формы Отмена, Нет или Закрыть, то
кнопка с такой командой переносится в панель в заголовке слева.
● Команда, которая размещена в левой части заголовка формы, будет отображаться специальным символом (<), но будет выполнять свою
изначальную функцию.
● При отображении кнопки в командной панели формы учитывается свойство Отображение этой кнопки. Свойства команды, связанной с
этой кнопкой, игнорируются при определении режима отображения кнопки.
● Если командная панель содержит кнопку по умолчанию, то она всегда отображается в заголовке первой.
● Если свободного места в правой части заголовка достаточно для отображения оставшихся команд ‑ они отображаются там. В противном
случае отображается кнопка Еще и система пытается сделать так, чтобы кнопка Еще не была единственной: если команда, отображаемая
в правой части заголовка еще не определена, то ей станет первая команда из списка оставшихся команд, а остальные будут расположены
в меню Еще.
В список стандартных команд не включаются команды непосредственного удаления (для объектов ссылочного типа), вызова справки, вывода
списка, изменения формы. Стандартные команды Записать и закрыть и Провести и закрыть отображаются в командных панелях с заголовком
Готово.
Для прикладных решений, работающих под управлением ОС iOS, необходимо помнить о том, что системные механизмы закрытия формы не
задают пользователю вопрос о необходимости сохранения данных в том случае, когда закрывается форма с модифицированными данными.
Командная панель, связанная с таблицей, располагается сверху или снизу таблицы и по ширине не превышает ширины самой таблицы. При
прокрутке таблицы командная панель всегда остается в видимой области.
Мобильная версия «1С:Предприятия» предоставляет набор возможностей, которые позволяют выполнять звонки из мобильных приложений.
Звонки можно выполнять как с подтверждением пользователя, так и без такового. Также система предоставляет доступ к журналу звонков и
возможность обрабатывать события, возникающие при получении или совершении телефонных звонков. Прикладное решение может
определить возможности по работе с телефонией. Для этого предназначены методы ПоддерживаетсяНаборНомера(),
ПоддерживаетсяЖурналЗвонков() и ПоддерживаетсяОбработкаЗвонков() объекта СредстваТелефонии. Обработка звонков возможна только на ОС
Android.
● Параметр равен значению Истина ‑ в этом случае при выполнении метода номер начинает набираться автоматически. На экране появляется
стандартный интерфейс программы работы со звонками.
● Параметр равен значению Ложь ‑ в этом случае при выполнении метода будет открыто приложение работы со звонками, в котором будет
установлен заданный номер. Пользователю останется только нажать кнопку начала вызова.
Мобильные устройства, функционирующие под управление ОС Android, предоставляют возможность доступа к журналу звонков. Имеется
возможность перебрать записи журнала с установкой необходимого отбора. Для работы с журналом необходимо использовать метод
ПолучитьЖурналЗвонков() объекта СредстваТелефонии.
Следующий пример демонстрирует получение списка всех пропущенных звонков на мобильном устройстве.
Копировать в буфер обмена
Если СредстваТелефонии.ПоддерживаетсяЖурналЗвонков() Тогда
Журнал = СредстваТелефонии.ПолучитьЖурналЗвонков();
Отбор = Новый ОтборКомпоновкиДанных;
НовыйЭлемент = Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("ТипЗвонка");
НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
НовыйЭлемент.ПравоеЗначение = ТипЗвонкаЖурналаЗвонков.Пропущенный;
НовыйЭлемент.Использование = Истина;
ЗаписиЖурнала = Журнал.НайтиЗаписи(Отбор);
Для каждого Запись Из ЗаписиЖурнала Цикл
// обработка списка звонков
КонецЦикла;
КонецЕсли;
При работе с журналом звонков следует помнить, что отбор журнала выполняется с помощью объекта ОтборКомпоновкиДанных.
Для обработки событий звонков (на устройствах под управлением ОС Android) предоставляется возможность подключения/отключения
обработчика звонков. После того, как в системе регистрируется обработчик событий звонков, при наступлении того или иного события
вызывается зарегистрированный обработчик, в который передается информация о звонке. Обработчик не позволяет управлять собственно
звонком, для этого используется штатная программа операционной системы.
С помощью данного механизма можно реализовать, например, собственный журнал звонков мобильного приложения или реализовать
напоминание о пропущенном звонке.
Копировать в буфер обмена
&НаКлиенте
Процедура УправлениеОбработчикомЗвонков(ПодключитьОбработчик)
Если НЕ СредстваТелефонии.ПоддерживаетсяОбработкаЗвонков() Тогда
// обработка звонков не поддерживается
Возврат;
КонецЕсли;
Обработчик = Новый ОписаниеОповещения("ОбработчикЗвонков", ЭтотОбъект, "Параметры");
Если ОбрабатыватьСобытияЗвонка Тогда
СредстваТелефонии.ПодключитьОбработчикЗвонков(Обработчик);
Иначе
СредстваТелефонии.ОтключитьОбработчикЗвонков();
КонецЕсли;
КонецПроцедуры
Процедура ОбработчикЗвонков(НомерТелефона, Дата, ВариантСобытия, ТипЗвонка, ДопПараметры) Экспорт
// обработка событий звонков
КонецПроцедуры
Мобильная версия «1С:Предприятия» предоставляет набор инструментов, позволяющих работать с сообщениями (SMS и MMS). Предоставляется
возможность отправлять и получать сообщения. Доступ к списку сообщений определяется используемой мобильной операционной системой.
Отправка сообщений возможна как в интерактивном, так и в полностью программном режиме (не интерактивном режиме).
Мобильная версия «1С:Предприятия» предоставляет средства для определения возможностей используемой мобильной ОС. Для этого у объекта
глобального контекста СредстваТелефонии существуют методы ПоддерживаетсяОтправкаSMS(), ПоддерживаетсяПриемSMS() и
ПоддерживаетсяОтправкаMMS(). В зависимости от используемой мобильной операционной системы, существуют следующие ограничения на
работу с сообщениями:
● Для ОС iOS:
● Для ОС Android:
● Для ОС Windows:
Сообщение в «1С:Предприятии» представлено объектом SMSСообщение. Отправка сообщения выглядит следующим образом:
Копировать в буфер обмена
&НаКлиенте
Процедура ОтправитьСМС(Кому, Текст, ПослатьИнтерактивно)
СМС = Новый SMSСообщение();
СМС.Текст = Текст;
СтрокаПолучатели = СтрЗаменить(Кому, ",", Символы.ПС);
Для Счетчик=1 По СтрЧислоСтрок(СтрокаПолучатели) Цикл
СМС.Получатели.Добавить(СокрЛП(СтрПолучитьСтроку(СтрокаПолучатели, Счетчик)));
КонецЦикла;
СредстваТелефонии.ПослатьSMS(СМС, ПослатьИнтерактивно);
КонецПроцедуры
В качестве значения параметра Кому могут быть переданы несколько номеров телефонов, разделенных символом «,». Параметр
ПослатьИнтерактивно определяет, как будет отправлено сообщение:
● Параметр установлен в значение Ложь ‑ будет открыто приложение работы с сообщениями, которое указано в качестве приложения по
умолчанию для используемой мобильной ОС. В этом приложении будет открыта форма отправки сообщения с заполненными полями. В этом
случае пользователь должен самостоятельно нажать кнопку отправки сообщения в открытой форме.
Для того чтобы SMS-сообщение было преобразовано в MMS-сообщение, необходимо добавить вложения в сообщения. Это делается с помощью
свойства SMSСообщение.Вложения. При этом в качестве значения свойства ТипСодержимого объекта MMSВложение следует указывать MIME-тип
передаваемых данных, например, для jpeg-файла это будет image/jpeg.
Если мобильная ОС позволяет, мобильная версия «1С:Предприятия» позволяет подписаться на оповещение о получении SMS-сообщений.
Копировать в буфер обмена
&НаКлиенте
Процедура ПодключитьОбработчикПолученияСообщений()
ПолучательСообщений = Новый ОписаниеОповещения("ПолучениеСообщения", ЭтотОбъект);
СредстваТелефонии.ПодключитьОбработчикSMSСообщений(ПолучательСообщений);
КонецПроцедуры
&НаКлиенте
Процедура ПолучениеСообщения(Сообщение, ДополнительныеПараметры) Экспорт
Сообщить(Сообщение.Отправитель + " - " + Сообщение.Текст);
КонецПроцедуры
При получении входящего сообщения, будет вызываться обработчик оповещения для обработки полученного сообщения. Сообщения,
полученные с помощью установленного обработчика оповещения, также будут доступны и из системного приложения по работе с сообщениями.
Проверить возможность доступа у журналу сообщений можно с помощью метода СредстваТелефонии.ПоддерживаетсяЖурналSMS(). Если
используемая мобильная ОС предоставляет доступ к журналу сообщений, то становится доступной возможность получать сообщения в
соответствии с наложенным отбором.
Следующий пример демонстрирует получение списка всех не прочитанных сообщений на мобильном устройстве.
Копировать в буфер обмена
Если СредстваТелефонии.ПоддерживаетсяЖурналSMS() Тогда
Журнал = СредстваТелефонии.ПолучитьЖурналSMS();
Отбор = Новый ОтборКомпоновкиДанных;
НовыйЭлемент = Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Прочитано");
НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
НовыйЭлемент.ПравоеЗначение = Ложь;
НовыйЭлемент.Использование = Истина;
ЗаписиЖурнала = Журнал.НайтиЗаписи(Отбор);
Для каждого Запись Из ЗаписиЖурнала Цикл
// обработка списка сообщений
КонецЦикла;
КонецЕсли;
При работе с журналом SMS следует помнить, что отбор журнала выполняется с помощью объекта ОтборКомпоновкиДанных.
● Допустимо указывать фрагменты номеров, только если в качестве правого значения элемента отбора используется строка, и при этом вид
сравнения должен быть ВидСравненияКомпоновкиДанных.Содержит или ВидСравненияКомпоновкиДанных.НеСодержит. Пробелы, скобки и
дефисы в номере не игнорируются.
● Если в качестве значения отбора указан массив номеров, то сообщение считается удовлетворяющей условию только в том случае, если в
сообщении и отборе одинаковое количество номеров и все номера полностью совпадают друг с другом.
В результате поиска формируется список сообщений, упорядоченный так, чтобы в начале списка были самые новые сообщения.
Большое количество мобильных устройств поддерживает определение координат, по которым располагается устройство. Также предоставляется
возможность выполнять преобразование полученных координат в адрес и наоборот. Для доступа к этим функциям предназначен провайдер
геопозиционирования. Каждый провайдер описывается именем и определенным набором параметров (возможностей). Конкретный провайдер
геопозиционирования может поддерживать не все возможности.
1. Выбирается необходимый провайдер геопозиционирования. В каждом случае следует выбирать тот провайдер, который максимально
подходит для реализации поставленной задачи. В общем случае стоит выбирать провайдера, который обеспечивает минимальное
энергопотребление и максимальную точность определения координат.
Пример:
Копировать в буфер обмена
// Определим провайдера, который не приводит к расходованию
// средств и использует для определения координат
// сеть сотовой связи
ИскомыйПровайдер = Неопределено;
Провайдеры = СредстваГеопозиционирования.ПолучитьПровайдеров();
Для каждого Провайдер Из Провайдеры Цикл
Если НЕ Провайдер.Платный и Провайдер.ИспользуетСотовуюСеть Тогда
ИскомыйПровайдер = Провайдер;
Прервать;
КонецЕсли;
КонецЦикла;
Если ИскомыйПровайдер = Неопределено Тогда
Сообщить("Требуемый провайдер не обнаружен");
Иначе
Сообщить("Найден провайдер: " + ИскомыйПровайдер.Имя);
КонецЕсли;
В случае необходимости получить самый энергоэффективный провайдер или самый точный провайдер, можно воспользоваться методами
ПолучитьСамогоЭнергоЭкономичногоПровайдера() или ПолучитьСамогоТочногоПровайдера() (соответственно).
2. Выполняется определение координат с помощью выбранного провайдера геопозиционирования. Для получения координат используются
два метода. Метод ПолучитьПоследнееМестоположение() возвращает последние данные о местоположении, полученные выбранным
провайдером. Среди свойств объекта ДанныеМестоположения (который возвращает метод ПолучитьПоследнееМестоположение()), есть
свойство Дата, которое описывает, когда были получены данные о местоположении. Если эти данные были получены очень давно, то
необходимо вызвать метод ОбновитьМестоположение() для того, чтобы провайдер геопозиционирования заново определил данные о
местоположении. Один из параметров метода определяет тайм-аут на определение местоположения. В том случае, если метод завершен по
тайм-ауту, фактическое определение координат в данном случае зависит от особенностей реализации конкретной версии мобильной
операционной системы.
Пример:
Копировать в буфер обмена
// Если местоположение на данном устройстве ни разу не выполнялось
// или выполнено более часа назад - обновить местоположение и
// получить определенные координаты
Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера);
Если Координаты = Неопределено Или ТекущаяДата()-МестноеВремя(Координаты.Дата) > 3600 Тогда
СредстваГеопозиционирования.ОбновитьМестоположение(ИмяПровайдера, 60);
Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера);
КонецЕсли;
3. При необходимости, выполняется подписка на изменение координат. После того, как потребность в подписке отпала ‑ можно отключить
оповещение об изменении координат.
После получения данных о местоположении, имеется возможность выполнить несколько вспомогательных операций, связанных с полученным
местоположением:
● Показать карту, на которой отображены координаты одной или нескольких точек. Для этого предназначен метод ПоказатьНаКарте().
Данная возможность предоставляется не на всех мобильных ОС. Метод ПоддерживаетсяОтображениеКарты() позволяет определить
возможность отображения на карте одной или нескольких точек. Для отображения точек на карте в каждой мобильной ОС будет
использовать фирменное приложение разработчика операционной системы.
ПРИМЕЧАНИЕ 1. Для работы методов преобразования координат в адрес и обратно, на мобильном устройстве должен быть доступ в
Интернет.
ПРИМЕЧАНИЕ 2. Не поддерживается работа механизма геопозиционирования в фоновом режиме на устройствах под управлением ОС iOS.
Для того чтобы мобильное приложение могло работать с геопозиционированием под управлением ОС Android, необходимо получить
специальный ключ для работы с Google Maps. Для этого необходимо выполнить следующие действия:
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, находящееся в форме группы мобильного приложения. Затем необходимо сохранить группу мобильного
приложения.
29.3.5.4.1. Запись
Мобильные устройства обладают различными мультимедийными возможностями: сделать фотоснимок, сделать аудио‑ или видеозапись. Для
различных мобильных устройств эти возможности могут быть доступны или нет. Для определения возможности выполнения той или иной
операции предоставляются специальные функции: ПоддерживаетсяФотоснимок(), ПоддерживаетсяВидеозапись(),
ПоддерживаетсяАудиозапись().
В том случае, если мобильное устройство поддерживает ту или иную возможность, можно воспользоваться методом глобального контекста,
который активирует необходимое системное приложение для выполнения нужного действия: СделатьФотоснимок(), СделатьВидеозапись(),
СделатьАудиозапись(). При работе мобильного приложения под управлением любой мобильной операционной системы, запись звука
выполняется в формате стерео, битрейт 128 Кбит/с и частота дискретизации 44 кГц. Результатом работы метода
СредстваМультимедиа.СделатьАудиозапись() является объект ДанныеМультимедиа, где расширение файла установлено в значение m4a, а MIME-
тип ‑ в значение audio/mp4.
В связи с тем, что мобильные устройства могут обладать двумя камерами (передней и задней), платформа предоставляет мобильному
приложению возможность работать с камерами по выбору. Для этого следует использовать системное перечисление ТипКамерыУстройства при
определении возможностей мобильного устройства и при выполнении того или иного действия.
Копировать в буфер обмена
Передняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Передняя);
Задняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Задняя);
Вышеприведенный программный код позволяет определить, какая из двух камер устройства поддерживает фотосъемку. С помощью этих
методов можно определять наличие той или иной камеры на устройстве. При выполнении фото‑ или видеосъемки, также имеется возможность
указать используемую камеру. Если тип камеры указан как ТипКамерыУстройства.Авто, то на устройствах это будет обрабатываться следующим
образом:
● На устройстве имеется одна камера ‑ будет использована эта камера (в зависимости от наличия).
Кроме того, при попытке сделать фотоснимок или выполнить видеосъемку, имеется возможность указать некоторые дополнительные параметры,
влияющие на результат действия.
При попытке выполнить фотосъемку имеется возможность (кроме типа камеры) дополнительно указать:
● С каким разрешением необходимо выполнить съемку. Если указано разрешение, не поддерживаемое устройством, будет выбрано
ближайшее подходящее разрешение. Перечень поддерживаемых разрешений можно получить с помощью метода
ПолучитьПоддерживаемыеРазрешенияКамеры() объекта СредстваМультимедиа. Для устройств, работающих под управлением ОС iOS, данный
параметр игнорируется.
● С каким качеством будет получен результирующий снимок. Фактически определяет степень сжатия jpeg-файла. 100 ‑ означает
максимальное качество.
● Какой снимок должен быть получен в результате: цветной или черно-белый. Для устройств, работающих под управлением ОС iOS,
указание на необходимость получить черно-белый снимок, не влияет на интерфейс камеры (но сам снимок будет черно-белым).
● Начальный режим использования вспышки при открытии интерфейса камеры. Для этого служит параметр ТипПодсветки метода
СделатьФотоснимок(). Имеется возможность принудительно включить, выключить вспышку или предоставить устройству определить режим
работы вспышки автоматически.
● С помощью параметра Отметка можно управлять возможностью вставки в правый нижний угол фотографии даты и времени формирования
снимка, а также произвольного текста. Для этого в качестве значения параметра следует передать объект ОтметкаНаФотоснимке.
Для того, чтобы ускроить получение данных снимка при работе под управлением ОС Android, рекомендуется выполнять следующие действия:
● В том случае, если приложению не требуется фронтальная камера, принудительно устанавливать в качестве основной камеры заднюю
камеру (параметр ТипКамеры метода СредстваМультимедиа.СделатьФотоснимок()). Если устанавливается автоматический режим определения
камеры ‑ не рекомендуется в интерфейсе фотокамеры выполнять переключение на переднюю камеру устройства.
● При фотографировании желательно держать устройство горизонтально (широкой стороной вниз) и камерой слева.
● По возможности уменьшать разрешение и качество получаемого снимка до разумных значений (параметры Разрешение и Качество метода
СредстваМультимедиа.СделатьФотоснимок()). Например, установка параметра Качество в 50%, а параметра Разрешение в 50% от
максимального разрешения камеры, может уменьшить время получения снимка в 1,5 раза.
При попытке выполнить видеосъемку, кроме указания типа камеры, имеется возможность указать качество получаемого ролика. Устройства,
работающие под управлением ОС iOS, игнорируют этот параметр.
29.3.5.4.2. Воспроизведение
Мобильная версия «1С:Предприятия» предоставляет возможность воспроизводить звуковые оповещения, воспроизводить аудиофайлы и
выполнять синтез речи. Возможность выполнения синтеза речи зависит от языка, на котором предполагается выполнять синтез.
Для воспроизведения звукового оповещения (короткий звуковой или вибросигнал) предназначен метод
СредстваМультимедиа.ВоспроизвестиЗвуковоеОповещение(). Имеется возможность воспроизвести либо стандартный звук системы, либо
звуковой файл, имя которого передается в качестве параметра Звук этого метода. Этот звуковой файл должен входить в состав мобильного
приложения. Однако на мобильной платформе разработчика отсутствует возможность подключать ресурсы (к которым относятся
воспроизводимые файлы). Для того чтобы указанный файл был прикреплен к мобильному приложению, следует воспользоваться
возможностями сборщика приложений для мобильных устройств (см. здесь). В силу этого, проверить использование звуковых оповещений из
файлов можно только в собранном приложении. Возможность использования вибрации при воспроизведении звукового оповещения
управляется параметром Вибрация метода ВоспроизвестиЗвуковоеОповещение(). Если имя файла со звуковым оповещением указано без
расширения, то используются следующие расширения (в зависимости от ОС) по умолчанию:
Воспроизведение оповещения нельзя приостановить или остановить. Оно всегда воспроизводится целиком и полностью.
Если необходимо воспроизвести некоторый звуковой файл, то следует воспользоваться методом СредстваМультимедиа.ВоспроизвестиАудио(). В
качестве источника воспроизведения могут выступать объект ДанныеМультимедиа (результат работы метода СделатьАудиозапись()), объект
ДвоичныеДанные (который содержит непосредственно аудиофайл требуемого формата) или имя файла (тип Строка). Воспроизведение
аудиофайла, входящего в состав мобильного приложения, не поддерживается. В том случае, если прикладное решение должно обрабатывать
состояние остановки воспроизведения ‑ надо указать обработчик оповещения (в параметре ОбработчикОстановкиВоспроизведения), который
будет вызываться в том случае, если воспроизведение остановлено или прервано.
С точки зрения возможности воспроизведения различных форматов аудиофайлов, рекомендуется опираться на MIME-тип файла.
Воспроизведение и запись аудиофайлов возможно только в том случае, если эти файлы имеют следующие MIME-типы (в зависимости от
используемой мобильной ОС):
● ОС iOS ‑ audio/mp4;
● ОС Android ‑ audio/3gpp;
● ОС Windows ‑ audio/aac.
Далее приведен простой пример, в котором на форме находятся две кнопки, нажатие на одну из которых (обработчик ВоспроизвестиАудио())
приводит к выбору проигрываемого файла и запуск его воспроизведения, а при нажатии на вторую кнопку (обработчик Остановить()) ‑
выполняется остановка ранее запущенного воспроизведения.
Копировать в буфер обмена
&НаКлиенте
Процедура ВоспроизвестиАудио(Команда)
Диалог = Новый ДиалогВыбораФайла(РежимДиалогаВыбораФайла.Открытие);
Если Диалог.Выбрать() Тогда
Данные = Диалог.ПолноеИмяФайла;
СредстваМультимедиа.ВоспроизвестиАудио(Данные);
Файл = Новый Файл(Диалог.ПолноеИмяФайла);
Сообщить("" + Файл.ПолучитьПредставлениеФайлаБиблиотекиМобильногоУстройства() + " длительностью " +
СредстваМультимедиа.ПолучитьПродолжительностьАудио(Данные) + " секунд");
КонецЕсли;
КонецПроцедуры
&НаКлиенте
Процедура Остановить(Команда)
СредстваМультимедиа.ОстановитьВоспроизведениеАудио();
КонецПроцедуры
На мобильной платформе имеется возможность использовать синтезатор речи, встроенный в операционную систему. Доступность синтезатора
для конкретного языка следует проверять с помощью метода СредстваМультимедиа.ПоддерживаетсяВоспроизведениеТекста(). Если синтезатор
речи доступен ‑ можно воспроизвести текст с помощью метода СредстваМультимедиа.ВоспроизвестиТекст(). При необходимости обрабатывать
прерывание синтеза речи, имеется возможность установить соответствующий обработчик с помощью параметра
ОбработчикОстановкиВоспроизведения. Прервать воспроизведение текста можно с помощью метода
СредстваМультимедиа.ОстановитьВоспроизведениеТекста().
Мобильное устройство, обладающее камерой, позволяет выполнять функции сканирования штрихкодов. Для доступа к этой возможности
платформа предоставляет специальный интерфейс.
ПРИМЕЧАНИЕ. Для эффективного сканирования штрихкодов желательно, чтобы камера мобильного устройства обладала возможностью
автоматической наводки объектива камеры на резкость (автофокусом). В противном случае сканирование штрихкодов будет затруднено.
1. Определяется возможность работы с механизмом сканирования. Для этого необходимо использовать метод
ПоддерживаетсяСканированиеШтрихКодов() объекта глобального контекста СредстваМультимедиа.
2. В том случае, если сканирование поддерживается, метод ПоказатьСканированиеШтрихКодов() объекта СредстваМультимедиа открывает
специальный интерфейс по сканированию штрихкодов. При выполнении операции сканирования вызывается специальный обработчик,
содержащий информацию о результате сканирования.
3. Закрыть интерфейс сканирования можно или вручную, с помощью стандартной кнопки перехода к предыдущей форме интерфейса ОС
Android, или из встроенного языка, с помощью метода ЗакрытьСканированиеШтрихКодов() объекта СредстваМультимедиа.
Рассмотрим пример работы с данным механизмом. Для демонстрации будет использоваться простая форма, на которой расположена кнопка
открытия интерфейса сканирования и признак закрытия этого интерфейса после однократного сканирования. Сканированный штрихкод будет
выводиться в виде сообщения.
ПРИМЕЧАНИЕ. Данный пример не является законченным инструментом. Он предназначены для демонстрации работы с механизмом
сканирования штрихкодов.
В форме необходимо создать реквизит ЗакрытьИнтерфейс типа Булево и разместить на форме элемент, отображающий этот реквизит. Также
следует создать команду формы ОткрытьИнтерфейсСканирования, которую также следует разместить на форме. Модуль формы будет иметь
следующий вид:
Копировать в буфер обмена
// Обработчик команды формы ОткрытьИнтерфейсСканирования
&НаКлиенте
Процедура ОткрытьИнтерфейсСканирования(Команда)
ОбработчикСканирования = Новый ОписаниеОповещения("ОбработкаСканирования", ЭтотОбъект);
ОбработчикЗакрытия = Новый ОписаниеОповещения("ОбработкаЗакрытияИнтерфейса", ЭтотОбъект);
СредстваМультимедиа.ПоказатьСканированиеШтрихКодов("Наведите камеру на штрихкод", ОбработчикСканирования,
ОбработчикЗакрытия);
КонецПроцедуры
&НаКлиенте
Процедура ОбработкаСканирования(Штрихкод, Результат, Сообщение, ДополнительныеПараметры) Экспорт
Если Результат Тогда
Текст = "" + Штрихкод;
Иначе
При открытии интерфейса сканирования в метод ПоказатьСканированиеШтрихКодов() передается два описания оповещения. Первое
оповещение срабатывает (параметр <ОбработчикСканирования>) в том случае, когда система успешно распознала штрихкод, второе оповещение
(параметр <ОбработчикЗакрытия>) срабатывает в том случае, когда закрывается окно, предназначенное для сканирования штрихкода. Закрытие
может быть как программное, так и интерактивное. Пример программного закрытия приведен в обработчике оповещения
ОбработкаСканирования(), а интерактивное закрытие можно выполнить, нажав кнопку Назад в интерфейсе сканирования.
При открытии формы сканирования можно указать, какие штрихкоды будет распознавать система: линейные (например, EAN), двухмерные
(например, QR-код) или все. Задается это с помощью параметра <ТипШтрихКода> метода ПоказатьСканированиеШтрихКодов(). При этом надо
помнить, что указание на необходимость распознавать все типы штрихкодов снижает производительность сканирования, т. к. система будет
тратить больше времени на поиск в изображении различных штрихкодов.
При сканировании штрихкодов с использованием камеры мобильного устройства, будут распознаваться следующие штрихкоды, в зависимости
от операционной системы мобильного устройства:
● ОС Android:
● Линейные штрихкоды:
● UPC-A;
● UPC-E;
● EAN-8;
● EAN-13;
● Code39;
● Code93;
● Code128;
● RSS-14;
● RSS Expanded;
● ITF;
● Codabar.
● Двумерные штрихкоды:
● QR Code;
● Data Matrix.
● ОС iOS:
● Линейные штрихкоды:
● UPC-A;
● UPC-E;
● EAN-8;
● EAN-13;
● Code39;
● Code93;
● Code128;
● RSS-14;
● RSS Expanded;
● ITF;
● Codabar;
● PDF417.
● Двумерные штрихкоды:
● QR Code;
● DataMatrix;
● Aztec Code;
● MaxiCode.
● ОС Windows:
● Линейные штрихкоды:
● UPC-A;
● UPC-E;
● EAN-8;
● EAN-13;
● Code39;
● Code93;
● Code128;
● ITF;
● Codabar;
● RSS-14;
● RSS Expanded;
● PDF417.
● Двумерные штрихкоды:
● QR Code;
● DataMatrix;
● Aztec Code;
● MaxiCode.
Мобильная версия «1С:Предприятия» предоставляет прикладному разработчику несколько способов работы с электронной почтой. Один способ
позволяет реализовать полноценный почтовый клиент на платформе «1С:Предприятие» (объект ИнтернетПочта и связанные объекты), а другой
способ позволяет реализовать только отправку почтовых сообщений с помощью приложения по работе с электронной почтой, установленное в
системе по умолчанию (объект СредстваПочты).
При отправке почтовых сообщений типа ТипТекстаПочтовогоСообщения.HTML с помощью объекта СредстваПочты (под управлением ОС Android)
выполняется конвертация текста сообщения в формат Spannable. Отправляемое письмо отображается большинством почтовым клиентов.
При использовании текстов почтовых сообщений с типом ТипТекстаПочтовогоСообщения.HTML (под управлением ОС Android) не рекомендуется
использовать следующие возможности:
● встроенные таблицы;
● встроенные изображения;
Рекомендуется проверять отображение электронных писем на максимальном количестве устройств, чтобы минимизировать зависимость от
различий реализации на разных ОС и в разных версиях почтовых программ.
Также следует помнить, что тип текстов почтовых сообщений ТипТекстаПочтовогоСообщения.РазмеченныйТекст не поддерживается объектом
СредстваПочты.
Список контактов ‑ это база данных, которая хранит информацию о субъектах, с которыми общается владелец мобильного устройства. Описание
контакта содержит идентификационные данные контакта, адреса, телефоны и другую информацию, необходимую для связи с субъектом. Также,
на мобильном устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор
информации, которые пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На
мобильном устройстве всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
Каждая запись в списке контактов связана с какой-либо одной учетной записью. Мобильная операционная система может выполнять
синхронизацию списка контактов с данными учетной записи (зависит от настроек ОС). Если контакт связан с локальной учетной записью, то
синхронизация информации не выполняется и все данные расположены только на мобильном устройстве.
Основная информация о контакте хранится в объектах типа ДанныеКонтакта. Объекты данного типа содержат всю информацию о контакте, но
не содержат связь контакта с учетной записью. В описании контакта есть несколько типов данных, которые могут содержать более одного
значения. Такими данными являются номера телефонов, адреса, адреса электронной почты и другие. Для хранения таких данных
предназначены массивы объектов типа ЭлементДанныхКонтакта. Для хранения списка идентификаторов в программах мгновенных сообщений
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта
УчетнаяЗаписьКонтактов.
Связь между учетной записью контактов и собственно элементов списка контактов образует объект ДанныеКонтактаУчетнойЗаписи. Кроме
информации о контакте и учетной записи, данный объект содержит также идентификатор, по которому выполняется синхронизация между
списком контактов на мобильном устройстве и учетной записью. Можно сказать, что свойство ГлобальныйКлючКонтакта объекта
ДанныеКонтактаУчетнойЗаписи является аналогом свойства Ссылка для прикладных объектов «1С:Предприятие».
Для идентификации контакта на мобильном устройстве существует объект ЛокальныйКлючКонтакта. Все операции с контактами (создание,
изменение, удаление, поиск) выполняются с использованием данного объекта. Для выполнения операций с контактами следует использовать
менеджер контактов (одноименный объект).
Следующий пример демонстрирует создание элемента списка контактов в локальной учетной записи:
Копировать в буфер обмена
&НаКлиенте
Процедура СоздатьЭлементКонтакта(Имя, Отчество, Фамилия, ЭлектроннаяПочта, Телефон)
ДанныеКонтакта = Новый ДанныеКонтакта;
ДанныеКонтакта.Имя = Имя;
ДанныеКонтакта.Отчество = Отчество;
ДанныеКонтакта.Фамилия = Фамилия;
ЭлементПочта = Новый ЭлементДанныхКонтакта(ТипАдресаЭлектроннойПочтыДанныхКонтакта.Рабочий, ЭлектроннаяПочта);
ДанныеКонтакта.АдресаЭлектроннойПочты.Добавить(ЭлементПочта);
ЭлементТелефон = Новый ЭлементДанныхКонтакта(ТипНомераТелефонаДанныхКонтакта.Рабочий, Телефон);
ДанныеКонтакта.НомераТелефонов.Добавить(ЭлементТелефон);
МК = Новый МенеджерКонтактов;
ЛокальныеКонтакты = МК.ПолучитьЛокальнуюУчетнуюЗаписьКонтактов();
Контакт = Новый ДанныеКонтактаУчетнойЗаписи(ДанныеКонтакта, ЛокальныеКонтакты);
МК.ДобавитьКонтакт(Контакт);
КонецПроцедуры
На мобильных устройствах имеется возможность просмотра календаря и заведения в нем различных событий. События характеризуются
некоторым набором характеристик, таких как дата и время начала и завершения, описание, занятые лица и т. д. Также, на мобильном
устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор информации, которые
пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На мобильном устройстве
всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
На мобильном устройстве может быть несколько календарей (с разными именами). Каждый календарь связан с какой-либо одной учетной
записью. Мобильная операционная система может выполнять синхронизацию событий календарей с данными учетной записи (зависит от
настроек ОС). Если события календаря связаны с локальной учетной записью, то синхронизация информации не выполняется и все данные
расположены только на мобильном устройстве.
Основная информация о календаре хранится в объекте ДанныеКалендаря. События календаря описываются объектом ДанныеСобытияКалендаря.
Данные объекты описывают характеристики календаря или события календаря, но не описывают, с какой учетной записью связан объект.
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта
УчетнаяЗаписьКалендарей.
Связь между данными календарей и событий и учетными записями образуется объектами ДанныеКалендаряУчетнойЗаписи и
ДанныеСобытияКалендаряУчетнойЗаписи. Эти объекты, кроме информации о собственно данных и информации об учетной записи, хранят
информацию значения ключей, по которым выполняется синхронизация между мобильным устройство и сервисом, с которым выполняется
синхронизация. Для синхронизации данных о календарях используется ГлобальныйКлючКалендаря, для синхронизации данных о событиях
календарей используется ГлобальныйКлючСобытияКалендаря.
Для идентификации данных календарей и событий на мобильном устройстве существует объекты ЛокальныйКлючКалендаря и
ЛокальныйКлючСобытияКалендаря. Все операции с календарями и событиями (создание, изменение, удаление, поиск) выполняются с
использованием данного объекта. Для выполнения операций с календарями и событиями следует использовать менеджер календарей
(одноименный объект).
Платформа предоставляет информацию о некоторых характеристиках экрана устройства, на котором выполняется клиентское приложение
(персональный компьютер или мобильное устройство). Для этого служит метод ПолучитьИнформациюЭкрановКлиента(). В результате
возвращается массив структур, описывающих экраны, подключенные к устройству.
Каждый элемент массива описывает один экран, подключенный к устройству. Параметры Высота и Ширина описывают, соответственно, высоту и
ширину экрана в точках. При этом для мобильного устройства эти параметры зависят от ориентации устройства (если это разрешено в
настройках), а платформы для персонального компьютера всегда возвращает канонические параметры подключенных экранов. Таким образом,
на мобильном устройстве можно анализировать, в каком положении находится устройство и на основании этого принимать решения о
трансформации интерфейса приложения. Для облегчения работы с ориентацией существует событие ПриИзмененииПараметровЭкрана, которое
можно обработать в модуле управляемого приложения и в модуле управляемой формы.
В качестве примера рассмотрим изменение отображения формы, отображаемой на рабочем столе. В указанной форме есть два списка, которые
отображают некоторую информацию. При портретной ориентации экрана (узкая сторона устройства ‑ нижняя) списки будут отображаться друг
под другом, а при ландшафтной (широкая сторона устройства ‑ нижняя) ориентации ‑ списки расположены рядом. Для реализации такого
поведения в модуле формы, расположенной на рабочем столе, следует разместить обработчик события ПриИзмененииПараметровЭкрана
следующего вида:
Копировать в буфер обмена
&НаКлиенте
Процедура ПриИзмененииПараметровЭкрана()
МассивИнформаций = ПолучитьИнформациюЭкрановКлиента();
Если МассивИнформаций[0].Ширина > МассивИнформаций[0].Высота Тогда
ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Горизонтальная;
Иначе
ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Вертикальная;
КонецЕсли;
КонецПроцедуры
При работе информационной системы регулярно возникает необходимость оповестить пользователя о каком-либо событии. Событие может
возникать как по расписанию, так и в случае возникновения другого события. Само событие может наступить как на мобильном устройстве,
которым владеет пользователь, так и в каком-то другом месте информационной системы.
Для извещения пользователя о наступлении событий служат уведомления. Они могут создаваться локально или рассылаться с помощью push-
сервисов. Локальные уведомления служат для информирования о событиях, которые происходят на устройстве пользователя. Обычно
источником push-уведомлений выступает центральный узел информационной системы. С помощью push-уведомлений он информирует
удаленных пользователей о том, что изменились данные, важные для пользователей. Однако это не единственный сценарий использования
push-уведомлений. Push-уведомления могут рассылать специализированные сервисы, информирующие о курсах валюты, результатах
спортивных состязаний, прогнозах погоды и т. д.
Локальные уведомления служат для извещения о событиях, которые происходят непосредственно на мобильном устройстве. Локальные
уведомления бывают моментальными и запланированными. Они используются для информирования о разных событиях и, кроме того, их
отличает поведение на мобильном устройстве. Моментальные уведомления используются в том случае, когда необходимо «здесь и сейчас»
оповестить пользователя о наступлении события, например завершении какого-либо процесса. Таким процессом может быть операция
синхронизации с внешней системой. Запланированные уведомления позволяют в назначенное время напомнить пользователю о необходимости
выполнить какую-либо операцию. Запланированное уведомление может быть однократным или периодическим. Однократное запланированное
уведомление можно использовать, например, если в системе помечено, что какому-то контрагенту необходимо перезвонить в определенное
время. Повторяемое запланированное уведомление можно использовать, например, в том случае, когда какая-то операция повторяется каждый
день, вне зависимости от внешних событий.
Чтобы использовать локальные уведомления, следует установить разрешение Локальные уведомления (см. здесь). Сборщик приложений для
мобильных устройств добавляет соответствующее разрешение для собираемого мобильного приложения. Следует учитывать, что мобильная
версия «1С:Предприятия» для разработчика обладает всеми разрешениями для работы с локальными уведомлениями. Поэтому рекомендуется
после окончания разработки механизма проверить его функционирование на обычной мобильной версии «1С:Предприятия». Для этого следует
воспользоваться сборщиком приложений для мобильных устройств и проверить работоспособность получившегося приложения на одном или
нескольких устройствах.
Для работы с локальными уведомлениями используется менеджер доставляемых уведомлений (свойство глобального контекста
ДоставляемыеУведомления) и объект ДоставляемоеУведомление. Объект описывает собственно уведомление (включая параметры его
отображения), а с помощью менеджера выполняется управление механизмом уведомлений.
● Дата и время первого отображения уведомления задается в формате универсального времени (UTC). Для перевода из локального времени
можно использовать функцию глобального контекста УниверсальноеВремя().
● Если свойство ДатаПоявленияУниверсальноеВремя задано пустым значением (или не задано вовсе), то уведомление будет отображено
сразу. Таким уведомлением можно извещать пользователя о том, что мобильное приложение завершило какую-то длительную операцию,
например, завершило операцию синхронизации данных.
● Если необходимо, чтобы уведомление появлялось регулярно, следует использовать свойство ИнтервалПовтора объекта
ДоставляемоеУведомление. В результате можно реализовать простой вариант безусловного таймера, который по истечении заданного
интервала времени будет формировать уведомление. Значение, описывающее интервал повторения уведомления, зависит от используемой
мобильной операционной системы. Особенности указания интервала описаны в синтакс-помощнике. Система не предоставляет возможности
указать дату и время окончания срабатывания уведомления. Для ОС Windows уведомление будет показано 5 раз (включая самое первое
отображение).
● При необходимости, имеется возможность установить наклейку ‑ число, отображаемое в шторке уведомлений (ОС Android) или поверх
иконки приложения (ОС iOS). Для этого служит свойство Наклейка. При работе под управлением ОС iOS имеется возможность устанавливать
и получать значение наклейки с помощью методов УстановитьНаклейку() и ПолучитьНаклейку() менеджера доставляемых уведомлений. При
работе в ОС Windows не поддерживается возможность создания наклейки на иконке приложения.
● При отображении уведомления имеется возможность воспроизвести некоторую мелодию. Для указания воспроизводимой мелодии служит
свойство ЗвуковоеОповещение объекта ДоставляемоеУведомление. Если в качестве значения этого свойства установлено значение системного
перечисления ЗвуковоеОповещение.ПоУмолчанию, то будет воспроизводиться мелодия, установленная для уведомлений в используемой
операционной системе. Если в качестве значения свойства ЗвуковоеОповещение указано имя файла, то будет воспроизведен именно этот
файл. Однако, в мобильной версии «1С:Предприятия» для разработчика, отсутствует возможность подключать ресурсы (к которым относятся
воспроизводимые файлы). Для того чтобы файл с оповещением был прикреплен к мобильному приложению, следует воспользоваться
возможностями сборщика приложений для мобильных устройств (см. здесь). В силу этого, проверить использование звуковых оповещений из
файлов можно только на собранном мобильном приложении.
В ряде случаев может возникать необходимость удалять установленные (но еще не наступившие) уведомления. Такое может потребоваться в
тех случаях, когда действие, для напоминания о котором установлено уведомление, уже выполнено. Для удаления уведомления можно
использовать метод ОтменитьЛокальныеУведомления() менеджера доставляемых уведомлений. При этом следует помнить, что отменяются сразу
все локальные уведомления, которые были установлены данным мобильным приложением, и время срабатывания которых еще не наступило.
После появления уведомления, нажатие на него приведет к запуску (или активизации) приложения. Однако этого может оказать недостаточно
для полноценной обработки уведомления. В этом случае можно воспользоваться обработчиком уведомлений. Подключается этот обработчик с
помощью метода ПодключитьОбработчикУведомлений() менеджера доставляемых уведомлений.
Копировать в буфер обмена
&НаКлиенте
Процедура ПриОткрытии(Отказ)
Обработчик = Новый ОписаниеОповещения("ОбработчикУведомлений", ЭтотОбъект);
ДоставляемыеУведомления.ПодключитьОбработчикУведомлений(Обработчик);
КонецПроцедуры
&НаКлиенте
Процедура ОбработчикУведомлений(Уведомление, Локальное, Показано, ДополнительныеПараметры) Экспорт
// Важные и нужные действия
КонецПроцедуры
В результате, после того, как пользователь мобильного приложения нажмет на уведомление, будет активизировано мобильное приложение,
создавшее уведомление, и в этом приложении будет вызван обработчик уведомления. В рамках этого обработчика можно реализовать
необходимую обработку уведомления. Следует помнить, что объект, который передается в параметре Уведомление, содержит реальные данные
только в свойствах Текст и Данные. Остальные свойства заполнены значениями по умолчанию.
Также следует отметить, что уведомление может не отображаться в шторке уведомлений. Для информирования мобильного приложения об этом
факте, в процедуру обработки уведомлений передается параметр Показано. Так, если мобильное приложение запущено и активно, то локальное
уведомление не будет отображено на экране, но обработчик уведомлений будет вызван, а параметр Показано будет установлен в значение
Ложь. В этом случае задача привлечения внимания пользователя лежит на прикладном разработчике.
29.3.5.10.3. Push-уведомления
Общая информация
Push-уведомления (далее в этом разделе термины «уведомление» и «push-уведомление» используются равнозначно) предназначены для
оповещения о событиях, которые произошли где-то в другом месте. Например, в корпоративной информационной системе изменились какие-то
данные, важные для мобильных пользователей системы.
1. Собственно мобильное приложение. Получает уведомления и реализует реакцию на них со стороны мобильного устройства.
2. Прикладное решение, которое занимается рассылкой уведомлений (отправитель). В роли отправителя выступает прикладное решение,
созданное на платформе «1С:Предприятие».
3. Сервис доставки уведомлений. Этот сервис обеспечивает передачу уведомление от отправителя получателю (мобильному приложению).
Таким сервисом может быть:
4. Фирмой «1С» разработан специальный вспомогательный сервис для отправки уведомлений. Этот сервис предназначен для облегчения
реализации отправки уведомлений из тиражных прикладных решений. Сервис позволяет использовать все сервисы отправки уведомлений, с
которыми может работать мобильная версия «1С:Предприятия». Сервис позволяет изолировать получателей уведомлений одного
отправителя, от других отправителей, которые работают с тем же мобильным приложением. Кроме того, сервис позволяет избежать
публикации конфиденциальной информации, что может быть прямо запрещено политикой сервиса отправки уведомлений. Особенности
работы с этим сервисом будут описаны далее, в соответствующих разделах. Следует понимать, что сервис фирмы «1С» не может работать
без использования собственно сервисов отправки уведомлений. Сервис расположен по адресу https://pushnotifications.1c.com.
Чтобы использовать уведомления, следует установить разрешение Push-уведомления (см. здесь). Сборщик приложений для мобильных
устройств добавляет соответствующую привилегию для собираемого мобильного приложения. Работа с мобильной версией «1С:Предприятия»
для разработчика имеет некоторые особенности, которые будут рассмотрены ниже. В любом случае, рекомендуется после окончания разработки
механизма проверить его функционирование на обычной мобильной версии «1С:Предприятия». Для этого следует воспользоваться сборщиком
приложений для мобильных устройств и проверить работоспособность получившегося мобильного приложения с использованием всех сервисов
доставки уведомлений.
Обработка push-уведомления мало отличается от обработки локального уведомления (см. здесь). Очевидно, что параметр Локальное будет
иметь значение Ложь, если обработчик будет вызван для обработки push-уведомления.
Для понимания работы с push-уведомлениями, следует учитывать, что в процессе разработки и внедрения системы участвуют несколько
различных ролей. В ряде случаев исполнители ролей могут объединяться, но само количество ролей остается неизменным:
● Разработчик мобильного приложения ‑ занимается разработкой мобильного приложения (получателя уведомлений). Реализует всю
необходимую функциональность приложения для получения уведомлений.
● Разработчик отправителя уведомлений ‑ занимается разработкой информационной системы, которая занимается рассылкой
уведомлений и механизма получения и хранения идентификаторов получателей уведомлений.
● Пользователь мобильного приложения ‑ использует мобильное приложение. Настройка мобильного приложения также выполняется
этим пользователем, поэтому настройки мобильного приложения должны быть максимально просты и понятны даже неподготовленному
пользователю.
● Внедренец отправителя ‑ занимается установкой и настройкой системы-отправителя уведомлений в сети пользователя системы.
При рассмотрении схем работы с тем или иным сервисом, описание действий будет происходить от лица носителя той или иной роли.
Схема работы содержит описание действий, которые надлежит выполнить представителю той или иной роли в момент выполнения своих
действий. Порядок описания действий всегда будет одинаковый (разработчик мобильного приложения, разработчик отправителя, внедренец
отправителя, пользователь мобильного приложения), однако это не означает, что физический порядок действий будет ровно таким же.
Кроме действий, описанных далее в разделе, реализация следующих этапов считается обязательной, и далее про них отдельно упоминаться не
будет:
Также считается, что мобильное приложение и отправитель «знают» о том, что они могут взаимодействовать друг с другом:
● Отправитель имеет некоторый публичный программный интерфейс (сервис обмена) для того, чтобы получить идентификатор получателя
уведомления от мобильного приложения.
● Получатель (мобильное приложение) умеет использовать сервис обмена, который публикует отправитель для выполнения обоих действий.
Далее будут рассмотрены действия (по ролям), которые необходимо выполнить для работы с тем или иным сервисом отправки уведомлений.
Пошаговые инструкций для выполнения конкретных шагов будут приведены далее в данном разделе.
APNs
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте компании Apple. При регистрации
следует получить специальный сертификат.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
FCM
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений в сервисе Firebase. При регистрации следует
получить специальный ключ сервера.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
● Загрузить в систему-отправителя ключ сервера проекта Firebase для мобильного приложения, которое будет получать уведомления.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
WNS
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте компании Microsoft. При регистрации
следует получить Секреты приложения и ИД безопасности приложения.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
● Реализовать механизм ввода и хранения Секреты приложения и ИД безопасности приложения. Эти данные необходимы для получения
маркера доступа, который, в свою очередь, используется для отправки уведомлений.
● Указать в системе-отправителе Секреты приложения и ИД безопасности приложения, которое будет получать уведомления.
● Секреты приложения и ИД безопасности приложения должны быть получены у разработчика мобильного приложения.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Сервис фирмы «1С» позволяет несколько упростить процесс отправки и получения уведомлений для тиражных решений.
● Выбрать, какие сервисы будут использоваться для доставки уведомлений на мобильное устройство. Затем следует предоставить сервису
фирмы «1С» артефакты, которые необходимы для отправки уведомлений для используемых сервисов. Следует помнить, что
предоставляемые артефакты могу являться конфиденциальной информацией.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
● Реализовать механизм ввода и хранения ключа сервера приложения (Ключ доступа отправителя) для текущего экземпляра системы-
отправителя уведомлений. Регистрацию конкретного экземпляра отправителя на сайте сервиса фирмы «1С» выполняет внедренец
отправителя.
● Выполнить регистрацию конкретного экземпляра отправителя на сайте сервиса фирмы «1С». Получившийся ключ сервера
зарегистрированного приложения (Ключ доступа отправителя) ввести в соответствующие настройки отправителя.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Для проверки работы механизма отправки уведомлений на ОС iOS, необходимо самостоятельно собрать собственную мобильную версию
«1С:Предприятия» для разработчика. При сборке следует использовать специальный профиль обеспечения (provision profile), для которого
разрешена возможность работать с push-уведомлениями. При создании «собственной» мобильной версии «1С:Предприятия» для разработчика
необходимо указать корректный идентификатор мобильного приложения, при этом идентификаторы com.e1c.mobile и com.e1c.mobile.ios
использоваться не могут, т. к. они зарезервированы для использования фирмой «1С».
Для установки соединения с APNs, на отправляющем компьютере должен быть доступен удостоверяющий сертификат мобильного приложения
получателя уведомлений. Сертификаты для APNs бывают двух видов Apple Development IOS Push Services (сертификат разработчика) и Apple
Production IOS Push Services (сертификат публичного мобильного приложения). Сертификат разработчика предназначен для разработки
мобильного приложения и его отладки. Его следует использовать, если приложение установлено на устройство с помощью средств разработки.
Сертификат публичного мобильного приложения следует использовать, если мобильное приложение распространяется через магазин
приложений.
● Сертификат должен содержать секцию 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 есть ‑ следует пропустить этот пункт и перейти к следующему пункту.
2. Нажать кнопку + над списком iOS AppIDs. Если у пользователя недостаточно прав ‑ кнопка создания будет недоступна.
3. В поле Name следует задать описание приложения (латинскими буквами). В разделе App ID Suffix выбрать пункт Explicit App ID. В поле
Bundle ID следует указать полный идентификатор мобильного приложения (можно получить в сборщике приложений для мобильных
устройств). В разделе App Services следует отметить пункт Push Notifications.
5. Следует проверить все указанные параметры и нажать кнопку Submit для подтверждения создания App ID.
4. Необходимо создать профиль обеспечения (provision profile) для сборки мобильного приложения, которое может получать уведомления.
Данный профиль обеспечения (provision profile) в дальнейшем должен быть использован в сборщике приложений для мобильных устройств.
1. Необходимо выбрать пункт меню Provisioning profiles ‑ All в левой части экрана Certificates, Identifiers & 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:
2. Выбрать команду Связка ключей ‑ Ассистент сертификации ‑ Запросить сертификат у бюро сертификации.
3. В открывшемся диалоге необходимо заполнить поля, при этом в качестве значения поля E-mail пользователя рекомендуется указать тот
адрес электронной почты, который указывался при регистрации в программе iOS Developer Program. В качестве значения свойства Запрос
необходимо указать Сохранен на диске.
4. После нажатия кнопки Продолжить будет сформирован файл запроса сертификата *.certSigningRequest.
6. Формируем сертификат для отправителя уведомлений. Для этого необходимо вернуться в окно веб-браузера с открытой консолью
разработчика.
1. Необходимо выбрать пункт меню Certificates ‑ All в левой части экрана Certificates, Identifiers & Profiles.
3. В зависимости от потребности, необходимо указать пункт Apple Push Notification service SSL (Sandbox) (если нужен сертификат для
разработки и отладки приложения) или пункт Apple Push Notification service SSL (Production) (если нужен сертификат для
распространяемого приложения). Затем следует нажать кнопку Continue.
5. Необходимо нажать кнопку Continue. На данном экране предлагается создать файл запроса сертификата, который уже создан на
предыдущем шаге.
6. Необходимо загрузить файл, сформированный на предыдущем шаге (с расширением .certSigningRequest) и нажать кнопку Generate.
7. После окончания формирования сертификата, его следует скачать с сайта с помощью кнопки Download.
7. Последним шагом необходимо выполнить конвертацию сертификата в необходимые форматы. Для этого необходимо на компьютере Mac,
где формировался файл запроса сертификата, выполнить следующие действия:
4. Выполняется конвертация получившегося сертификата из формата .P12 в формат .PEM. Для этого следует в консоли macOS выполнить
следующую команду:
Копировать в буфер обмена
openssl pkcs12 in pushcert.p12 out pushcert.pem nodes clcerts
● Сертификат в формате .P12 ‑ необходим в том случае, если рассылка уведомлений выполняется с помощью сервиса фирмы «1С».
Сертификат должен использовать разработчиком получателя для регистрации приложения-получателя уведомлений в сервисе фирмы «1С».
● Сертификат в формате .PEM ‑ необходим в том случае, если уведомления будут отправляться непосредственно через сервис APNs, и в этом
случае сертификат должен быть предоставлен разработчику отправителя или внедренцу отправителя (если интерфейс программы-
отправителя уведомлений предусматривает возможность указания сертификата программы-получателя уведомлений).
Следующие действия должен выполнить внедренец приложения-отправителя во время развертывания и настройки приложения-отправителя в
компьютерной сети заказчика:
2. Необходимо создать проект (кнопка Добавить проект). При создании проекта следует указать название проекта и страну размещения
организации. Название проекта должно содержать только латинские символы. После окончания создания проекта следует нажать кнопку
Продолжить.
3. На странице проекта следует нажать гиперссылку Добавить Firebase в свое приложение для Android. После этого следует выполнить
следующие действия:
1. В поле Название пакета Android следует указать полный идентификатор приложения. С таким идентификатором приложение будет
размещено в магазине Google Play. Этот же идентификатор будет использоваться для сборки мобильного приложения в сборщике
мобильных приложений. После указания идентификатора приложения следует нажать кнопку Зарегистрировать приложение.
2. Загрузить предлагаемый файл google-services.json. Данный файл будет необходимо указать в сборщике мобильных приложений. После
загрузки файла следует нажать кнопку Продолжить.
5. Значение, расположенное в поле Ключ сервера, необходимо использовать в качестве ключа аутентификации для отправки уведомлений
(параметр ДанныеАутентификации метода Отправить() объекта МенеджерОтправкиДоставляемыхУведомлений). Рекомендуется относиться к
данному ключу как к конфиденциальной информации. Получение данного ключа третьими лицами позволит им отправлять push-уведомления
от вашего имени.
Получившийся ключ сервера (Ключ сервера) необходимо предоставить внедренцу приложения-отправителя для указания в настройках
приложения.
Следующие действия должен выполнить внедренец приложения-отправителя во время развертывания и настройки приложения-отправителя в
компьютерной сети заказчика:
2. Необходимо создать проект (кнопка Добавить проект). В поле Название проекта нажать кнопку выбора из списка и выбрать приложение
GCM, которое следует перенести в FCM. После этого указать страну размещения организации. Затем нажать кнопку Добавить Firebase для
запуска процесса импорта.
4. Также следует изменить код на встроенном языке для того, чтобы отправка оповещений использовала сервис FCM.
Описание работы с сервисом GCM приведено в документации к «1С:Предприятию» версии 8.3.12 и младше (https://its.1c.ru
/db/v8312doc#bookmark:dev:TI000001543).
Следующие действия должен выполнить внедренец приложения-отправителя во время развертывания и настройки приложения-отправителя в
компьютерной сети заказчика:
3. Необходимо создать новое приложение (кнопка Создать новое приложение). На открывшейся странице необходимо указать имя
приложения, которое будет отображать в магазине приложений. После указания имени следует проверить доступность этого имени
(гиперссылка Проверить доступность) и после этого нажать кнопку Зарезервировать имя продукта.
6. На странице приложения необходимо получить значения, указанные в разделах Секреты приложения и ИД безопасности пакета.
Рекомендуется относиться к данному ключу как к конфиденциальной информации.
7. Полученные значения следует указать в качестве параметров вызова метода ПолучитьМаркерДоступа() объекта
МенеджерОтправкиДоставляемыхУведомлений. В качестве параметра метода ИдентификаторПриложения указывается значение из раздела
Секреты приложения, а в качестве значения параметра КлючПриложения указывается значение из раздела ИД безопасности пакета.
Полученный маркер доступа будет использовать для отправки уведомлений.
Полученные Секреты приложения и ИД безопасности пакета необходимо предоставить внедренцу приложения-отправителя для указания в
настройках приложения.
● Зарегистрироваться в том сервисе рассылки уведомлений, который будет использоваться приложением. Если приложение использует
несколько сервисов ‑ необходимо зарегистрироваться во всех. Сохранить артефакты, которые предоставляет каждый сервис рассылки
уведомлений.
● Необходимо зарегистрироваться на сайте сервиса https://pushnotifications.1c.com/signup. Для регистрации необходимо иметь действующий
номер подвижной беспроводной радиотелефонной связи (мобильный номер). В процессе регистрации на него будет выслан код
подтверждения регистрации. В контактных данных рекомендуется указывать данные ответственного лица разработчика мобильного
приложения.
● Необходимо зарегистрировать мобильное приложение, которое будет выступать получателем уведомлений. Для этого следует выбрать
пункт меню Доставляемые уведомления ‑ Мобильные приложения и нажать кнопку Зарегистрировать приложение.
● Необходимо подключить созданное мобильное приложение к используемым сервисам. Для этого в списке Ваши мобильные приложения
нажать ссылку Подключить к APNS, GCM, 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 ‑ ключ сервера проекта (Ключ сервера), зарегистрированного в консоли разработчика Firebase Cloud Messaging.
Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Сервис фирмы «1С» ‑ ключ программного интерфейса отправителя (Ключ доступа отправителя), который получен при регистрации
отправителя на сайте сервиса. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Если для отправки уведомлений используется сервис фирмы «1С», то параметр ИспользоватьПромежуточныйСервис должен быть
установлен в значение Истина.
● Если отправка выполняется одновременно с использованием нескольких сервисов, то в качестве данных аутентификации может выступать
соответствие, где ключом выступает вид сервиса (значение перечисления ТипПодписчикаДоставляемыхУведомлений), а в качестве значения ‑
те данные, которые необходимы соответствующему сервису.
Следует понимать, что невозможно одновременно (в одном вызове метода Отправить()) отправлять уведомления с использованием сервиса
доставки уведомлений (APNs, FCM, WNS) и сервиса фирмы «1С». Если у метода Отправить() значение параметра
ИспользоватьПромежуточныйСервис установлено в значение Истина, то значением параметра ДанныеАутентфикации может быть только Ключ
доступа отправителя, полученный у сервиса фирмы «1С».
● Перечень получателей уведомлений описывается с помощью свойства Получатели объекта ДоставляемоеУведомление, которое выступает
значением первого параметра метода Отправить() менеджера доставки отправляемых уведомлений.
При работе с сервисом WNS следует помнить, что значение маркера доступа (которое получается с помощью метода ПолучитьМаркерДоступа())
не является постоянным значением. Его необходимо периодически получать повторно. Для определения необходимости выполнения этой
процедуры у метода Отправить() существует возвращаемый параметр ИнформацияОПроблемахОтправкиДоставляемыхУведомлений. Если при
отправке уведомлений возникает какая-либо проблема, то вышеуказанный параметр будет содержать список обнаруженных проблем. Если в
списке проблем будет проблема типа ОшибкаДанныхАутентификации, то это означает, что необходимо заново получить маркер доступа и
повторить попытку отправки уведомления.
Если обработчик уведомления не подключен, то уведомление сохраняется в памяти до окончания сеанса и будет передано обработчику
уведомления после его подключения (в этом сеансе). Если до окончания сеанса обработчик не был подключен ‑ уведомление теряется после
завершения сеанса.
● Если мобильное приложение активно, то уведомление сразу доставляется в мобильное приложение, при этом наклейка и звуковое
оповещение игнорируются.
● Если мобильное приложение не активно в момент получения уведомления, то уведомление отображается операционной системой. Если
пользователь нажал на уведомление, то будет запущено соответствующее приложение. Если пользователь удалил уведомление ‑ приложение
не будет проинформировано о существовании уведомления. В ОС iOS (версии 7 и младше) уведомление удаляется из центра уведомления
либо явным действием пользователя, либо вытесняется другими уведомлениями данного приложения.
● Если мобильное приложение, в момент получения уведомления, работает в фоновом режиме и не активно, то работа с уведомлением
выполняется по-разному на разных платформах:
● В ОС iOS уведомление будет передано в мобильное приложение только после того, как его выберет пользователь из панели
уведомлений.
● В ОС Android уведомление сразу передается в мобильное приложение и одновременно отображается в панели уведомлений. После того,
как пользователь выбрал уведомление в панели, происходит активизация приложения, но повторно уведомление в приложение не
передается.
● В ОС Windows уведомление будет передано в мобильное приложение только после того, как его выберет пользователь в центре
уведомлений.
● В том случае, если в мобильном приложении развернуто несколько информационных баз, то пользователю предлагается переключиться,
если в данный момент он работает с другой информационной базой. Если конкретную информационную базу определить не получается ‑
выдается соответствующее диагностическое сообщение.
Мобильная версия «1С:Предприятия» предоставляет возможность показывать рекламную информацию в мобильном приложении. При
необходимости воспроизведения рекламы, прикладной разработчик может настроить отображение рекламного баннера с использованием
рекламного сервиса Google AdMob (https://www.google.com/admob/). Данный сервис доступен для использования при работе как под
управлением ОС Android, так и под управлением ОС iOS.
● Баннер ‑ прямоугольное объявление, занимающее часть главного окна приложения. Может обновляться автоматически через некоторое
время.
● Полноэкранный рекламный баннер ‑ полноэкранный формат объявлений, используемый для показа в момент перехода между формами
приложения. Такое объявление занимает всю площадь экрана мобильного устройства.
Данная документация рассматривает только вопросы, касающиеся технических аспектов работы мобильного приложения с рекламным
сервисом.
3. Реализовать программный интерфейс работы с рекламой, используя данные, полученные на предыдущих шагах.
Для управления отображением рекламной информации служит свойство глобального контекста ОтображениеРекламы. В документации, для
упрощения, будет опускаться префикс метода ОтображениеРекламы.. В примерах и реальных приложениях, очевидно, такие пропуски
недопустимы. После старта мобильного приложения, система имеет следующие настройки по умолчанию:
Для того чтобы рекламная информация стала отображаться в приложении, необходимо выполнить следующие действия:
1. Использование рекламы в мобильном приложении должно быть разрешено с помощью метода УстановитьИспользование(Истина);.
● Баннер ‑ метод УстановитьОтображениеРекламногоБаннера(). С помощью этого метода можно указать место отображения рекламы или
отключить отображение рекламы.
При отображении полноэкранной рекламы или видеообъявления предоставляется возможность установить обработчик оповещения о
завершении отображения.
4. При отображении рекламной информации могут наблюдаться временные задержки, вызванные загрузкой необходимого блока рекламы.
Можно уменьшить эти задержки, выполняя загрузку рекламных блоков заранее:
После окончания загрузки будут вызван соответствующий обработчик. В этом обработчике, с помощью параметра метода, можно определить
статус загрузки рекламы и выполнить необходимые действия.
Предварительная загрузка рекламной информации не является обязательной. Вызов метода отображения рекламы автоматически загрузит
нужный рекламный блок.
Чтобы понять статус конкретного рекламного блока (по идентификатору рекламного блока) предназначен метод ПолучитьСтатусРекламы().
При установке идентификаторов рекламы, следует использовать идентификаторы, которые получены в веб-интерфейсе системы (подробнее см.
здесь).
Реклама, отображаемая в мобильном приложении, должна соответствовать Правилам рекламного сервиса AdMob (https://support.google.com
/admob/answer/6128543). Особое внимание стоит уделить следующим разделам Правил:
Google AdMob
3. Если приложение собрано с использованием сборщика приложений для мобильных устройств и ранее выполнялось тестирование этого
приложения (см. здесь), то ничего делать не надо. Идентификаторы рекламных блоков должны быть указаны в нужных местах прикладного
решения. В мобильном приложении, собранном с помощью сборщика, должна отображать реальная рекламная информация.
4. Добавить новое приложение. Для этого следует выбрать в меню команду Приложения ‑ Добавить приложение.
5. Добавление приложение различается для приложения, уже опубликованного в магазине приложений и там не опубликованного. Данный
выбор осуществляется при ответе на вопрос Вы уже разместили свое приложение в Google Play или App Store?
● На следующей странице необходимо ввести фрагмент названия приложения и нажать кнопку Найти.
● На следующей странице необходимо ввести название приложения и указать, под управлением какой операционной системы оно
работает. Если мобильное приложение (для которого настраивается отображение рекламы) будет работать под управлением ОС Android
и iOS, то следует создать два приложения AdMob.
6. На странице Настройки приложения следует запомнить значение поля Идентификатор приложения. Это значение будет необходимо
указать сборщику мобильных приложений.
7. После создания приложения следует перейти на страницу Рекламные блоки этого приложения.
8. При создании рекламного блока необходимо указать, какой рекламный блок будет создан: Баннер, Межстраничное объявление
(полноэкранный рекламный баннер) или С вознаграждением (видеообъявление с вознаграждением). Для этого необходимо нажать кнопку
Выбрать у нужного вида рекламного блока.
9. Затем формируется название (одноименное свойство) и указываются (при необходимости) другие параметры рекламного блока.
10. Нажатие кнопки Создать рекламный блок завершает операцию создания. Кнопка будет недоступна, если введены не все параметры,
необходимые для создаваемого рекламного блока.
11. На странице Рекламный блок создан будет представлено два вида идентификаторов. Первый идентификатор ‑ это идентификатор
приложения, а второй идентификатор следует запомнить для использования во встроенном языке. Этот же идентификатор потом можно
найти в свойствах рекламного блока, в качестве значения поля Идентификатор рекламного блока.
4. Теперь можно создавать и настраивать нужные рекламные блоки. В свойствах каждого рекламного блока будет доступен идентификатор
этого блока, необходимый для использования во встроенном языке.
Идентификаторы, полученные при создании рекламных блоков, следует использовать в качестве параметров методов
ОтображениеРекламы.УстановитьИндентификаторРекламногоБаннера()и
ОтображениеРекламы.УстановитьИндентификаторПолноэкраннойРекламы().
Google AdMob
Общую схему тестирования отображения рекламной информации, при использовании системы Google AdMob, можно представить следующим
образом:
● Для тестирования отображения рекламной информации не требуется публикации мобильного приложения в магазине приложений.
● Для тестирования необходимы только идентификаторы рекламных блоков, для создания которых (рекламных блоков) необходимо
зарегистрировать разрабатываемое приложение в сервисе Google AdMob.
● После регистрации приложения в Google AdMob, необходимо создать рекламные блоки. Их идентификаторы будут использоваться в
разрабатываемом мобильном приложении и при тестировании и при реальной эксплуатации.
● Пока приложение работает на мобильной платформе разработчика, рекламные блоки отображают тестовое содержимое. После того, как
приложение собрано сборщиком приложений для мобильных устройств ‑ оно начнет показывать реальную рекламную информацию.
Мобильная версия «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. На устройстве должна быть установлена актуальная версия приложения Google Play.
При реализации покупок внутри мобильного приложения следует помнить, что предметы покупок ограничиваются владельцами магазинов
приложений (компании Apple, Google, Microsoft).
В общем случае, покупки внутри приложений должны полностью соответствовать требованиям владельцев сервисов:
● ОС Android: https://support.google.com/googleplay/android-developer/answer/6151557.
● Разрешено продавать:
● Запрещено продавать:
Чтобы использовать покупки, следует для разрабатываемого мобильного приложения установить разрешение Встроенные покупки (см. здесь).
Общая схема работы со встроенными покупками, в мобильном приложении, выглядит следующим образом:
1. Необходимо настроить работу используемых сервисов встроенных покупок (см. здесь) для взаимодействия с разрабатываемым мобильным
приложением. Во время настройки сервисов может потребоваться загрузить в магазин приложений разрабатываемое мобильное приложение,
для которого включена возможность использования встроенных покупок. При этом загружаемое мобильное приложение может не содержать
в себе функциональность работы с покупками. Загружаемое приложение необходимо для работы механизмов сервисов покупок. Однако
полный идентификатор загружаемого приложения должен быть в точности таким, каким он будет для финальной версии мобильного
приложения с возможностью совершения встроенных покупок.
2. После настройки сервисов необходимо создать необходимые покупки (в каждом из сервисов) и зафиксировать идентификаторы и типы
покупок.
3. В мобильном приложении необходимо проверить, доступно или нет на данном устройстве совершение покупок. Для этого следует
использовать метод ВстроенныеПокупки.ПодерживаютсяПокупки().
4. Если покупки поддерживаются, то следует обновить список совершенных и доступных покупок с помощью метода
ВстроенныеПокупки.ОбновитьИнформациюОПриобретении(). Без выполнения этой операции будет невозможно в дальнейшем совершить
покупку.
Операцию обновления информации о приобретении рекомендуется выполнять регулярно, т. к. список совершенных покупок может
изменяться не только на текущем устройстве.
5. Для определения возможности расходования покупок средствами встроенного языка следует использовать метод
ВстроенныеПокупки.ПоддерживаетсяРасходованиеПокупок(). Если метод возвращает значение Истина, то это означает, что имеется
возможность расходовать встроенные покупки. Такая возможность доступна при работе под управлением ОС Android и Windows.
6. Для осуществления покупки предназначен метод ВстроенныеПокупки.НачатьПриобретение(). В качестве параметра метода следует
передать идентификатор покупки (как он указан в соответствующем сервисе) или объект ВстроеннаяПокупка, который можно получить с
помощью метода ВстроенныеПокупки.ПолучитьСписок().
После вызова метода, управление будет передано интерфейсу выполнения покупок, который предоставляется операционной системой и не
может быть переопределен на уровне мобильного приложения.
После завершения покупки управление возвращается в мобильное приложение (в метод обработки оповещения о завершении покупки).
Одним из параметров метода будет выступать статус покупки: если в обработчик передано значение Истина, значит покупка совершена
успешно. В противном случае покупка не совершена по любой из причин: отсутствует связь с магазином приложений, пользователь отменил
покупку в интерфейсе магазина приложений, цифровая подпись квитанции о покупке не прошла проверку и т. д.
7. Расходование покупок следует выполнять с помощью метода ВстроенныеПокупки.ИзрасходоватьПокупку(). После выполнения метода
выполняется запрос к сервису работы с покупками, в котором указывается, что покупка израсходована и доступна для повторного
приобретения.
При осуществлении покупки, в мобильном приложении выполняется проверка того, что покупка действительно выполнена. Однако
информационная система (включающая мобильное приложение) может выполнить проверку более тщательно.
Метод ПолучитьКвитанцииВстроенныхПокупок() (на стороне мобильного устройства) возвращает список квитанций совершенных покупок по
переданному набору идентификаторов покупок. Полученные квитанции покупок можно передать на сторону приложения для персонального
компьютера и там выполнит проверку квитанций встроенных покупок с помощью метода
ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупки(). Проверка выполняется полностью аналогично мобильной платформе.
Разница заключается в том, что при проверке с сервера прикладного решения для персонального компьютера используются другие каналы
связи с сервисом покупок (и другое окружение проверяющей системы). При проверке квитанции покупки выполняются следующие действия:
● ОС 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).
В тоже время, проверить квитанцию встроенной покупки бывает необходимо и на мобильном устройстве. Для этого следует использовать метод
ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупкиНаМобильномУстройстве().
Если прикладной разработчик считает, что и этого недостаточно, то предоставляется возможность выполнять дополнительные проверки,
которые базируются на содержимом полей квитанции о покупке. К таким проверкам можно отнести проверку уникальности идентификатора
квитанции о покупке, адекватности даты покупки и т. д. Для этого можно воспользоваться объектом ДанныеКвитанцииВстроеннойПокупки. Этот
объект позволяет получить доступ к данным квитанции встроенной покупки, которые присутствуют во всех поддерживаемых сервисах
встроенных покупок, так и получить доступ к оригинальным данным квитанции с помощью реквизита
ДанныеКвитанцииВстроеннойПокупки.ИсходныеДанные. Для получения данных квитанции встроенных покупок можно использовать метод
ПолучитьДанныеКвитанцийВстроенныхПокупок(). Для этого метода требуются массив квитанций встроенных покупок и соответствующий набор
идентификаторов покупок.
Общая информация
Информацию об особенностях конкретных типов покупок и поведения системы при работе с покупками следует искать в документации к
соответствующей операционной системе.
4. Зарегистрировать iOS App ID для приложения (если оно еще не зарегистрировано в Member Center). При этом регистрируемый
идентификатор должен совпадать с полным идентификатором мобильного приложения, в которое планируется встраивать работу с
встроенными покупками. При создании iOS App ID следует убедиться, что разрешен сервис In-App Purchase.
5. Если планируется использовать мобильную платформу разработчика для работы со встроенными покупками, следует выполнить
следующие действия:
4. Указать в качестве App ID именно тот iOS App ID, который создан на предыдущем шаге. Нельзя указывать на этом шаге iOS Wildcard
AppID.
5. Созданный профиль обеспечения в дальнейшем будет необходимо использовать в сборщик приложений для мобильных устройств.
8. Принять соглашение Paid Application. При этом необходимо указать информацию о банковском счете, на который будут перечисляться
заработанные средства.
11. Новая встроенная покупка добавляется с помощью кнопки «+», расположенной справа от заголовка списка Встроенные покупки.
2. Создать или найти мобильное приложение, в котором планируется реализовать работу с встроенными покупками. На данном этапе следует
собрать мобильное приложение, для которого установлено разрешение Встроенные покупки, но может отсутствовать функциональность
работы с покупками. Сборку необходимо выполнять с помощью сборщика приложений для мобильных устройств. Собранное приложение
необходимо загрузить в магазин приложений (в статусе альфа-версии).
4. На странице приложения, в разделе Службы и API необходимо запомнить значение поля ЛИЦЕНЗИОННЫЙ КЛЮЧ ДЛЯ ЭТОГО
ПРИЛОЖЕНИЯ. Это значение будет необходимо для выполнения проверки квитанции встроенной покупки на стороне прикладного решения
для персонального компьютера.
6. Новая встроенная покупка добавляется с помощью кнопки + Добавить продукт. Будьте внимательны при добавлении продуктов! Их
невозможно удалить!
3. Перейти на страницу необходимого приложения. На странице найти заголовок Надстройки, здесь нажать на кнопку Создание новой
надстройки. Откроется новая страница Создание новой надстройки.
4. На странице представлено несколько типов покупки. Для использования с мобильной версией «1С:Предприятие» подходят следующие
типы:
После выбора типа, в поле Код продукта ввести уникальный идентификатор покупки. Этот идентификатор будет использоваться для работы
со встроенными покупками к коде конфигурации. Далее, нажать на кнопку Создать надстройку. Откроется страница только что созданной
покупки.
5. На странице нажать на пункт Начать отправку. Откроется страница, на которой можно заполнить данные о покупке: Свойства, Цены и
доступность, Возрастные категории и Описание в Store (на разных языках).
В разделе Свойства свойствах можно указать время существования покупки (если это постоянная покупка) и тип контента поставляемый с
этой покупкой.
В разделе Цены и доступность указывается цена покупки и отмечается возможность поиска покупки в магазине или доступность покупки для
приобретения.
Для начала рекомендуется установить цену в «бесплатно», что бы при тестировании покупок не взымалась плата. После тестирования цену
необходимо будет выставить в желаемое значение.
В разделе Описание в Store указывается заголовок и описание покупки на всех поддерживаемых языках, при желании можно добавить
иконку для покупки.
Общая информация
Данный раздел содержит рекомендации по тестированию работы со встроенными покупками. Рекомендации касаются особенностей
взаимодействия мобильного приложения (мобильной платформы) и сервиса встроенных покупок.
Для ОС iOS
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС iOS можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные
покупки. Это тестирование выполняется с помощью мобильной платформы разработчика и сервиса Apple In-App Purchase, работающего в
специальном (тестовом) режиме.
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине
приложений. Покупки будут выполняться через реальный сервис Apple In-App Purchase, но фактического списания денежных средств
выполняться не будет. Для тестирования используется специальная программа TestFlight.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует
указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки
сервиса см. здесь.
После выполнения настроек необходимо собрать мобильную платформу разработчика, указав при ее сборке идентификатор мобильного
приложения, который использовался при настройке сервиса. Подробнее о создании мобильной платформы разработчика см. здесь.
Затем необходимо указать аккаунты пользователей, которые смогу тестировать встроенные покупки в «песочнице» (sandbox). Для этого
необходимо выполнить следующее:
4. На данной странице следует добавить электронную почту тех пользователей, которые будут выполнять роль тестировщиков.
5. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта с использованием платформы
разработчика.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует
указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки
сервиса см. здесь.
5. Загрузить мобильное приложение, собранное с помощью сборщика приложений для мобильных устройств.
9. Укажите, кто из внутренних тестировщиков будет заниматься тестированием выбранного мобильного приложения.
10. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта.
Для ОС Android
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС Android можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные
покупки. Это тестирование выполняется с помощью мобильной платформы разработчика и сборщика приложений для мобильных устройств
(который предоставляет эмулятор системы Google Play In-App Billing).
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине
приложений. Покупки будут выполняться через реальный сервис Google Play In-App Billing, но фактического списания денежных средств
выполняться не будет.
На платформе разработчика
Платформа разработчика предоставляет возможность выполнять тестирование работы с покупками без необходимости выполнять сборку
мобильного приложения. Для этого в свойствах информационной базы, на которой будет осуществляться тестирование, следует заполнить
свойства Адрес сервера покупок и Идентификатор пользователя.
Инструменты, предоставляемые компанией Google, для тестирования работы с покупками не позволяют использовать для этой цели мобильную
версию «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. При настройке следует
указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки
сервиса см. здесь.
3. В разделе Аккаунты Gmail тестировщиков указать адреса электронной почты тех прикладных разработчиков, которые будут тестировать
работу со встроенными покупками. Указанные тут разработчики (или тестировщики) смогут выполнять покупки без выполнения реальной
оплаты, однако, при выполнении тестовой покупки будет необходимо указывать данные реальной, платежеспособной банковской карты. С
этой карты будет выполнено тестовое списание (с последующим возвратом) небольшой суммы (примерно 1 доллар США) для проверки
корректности указанных данных.
Для ОС Windows
Платформа разработчика предоставляет возможность выполнять тестирование работы с покупками без необходимости выполнять сборку
мобильного приложения. Для этого в свойствах информационной базы, на которой будет осуществляться тестирование, следует заполнить
свойства Адрес сервера покупок и Идентификатор пользователя.
Тестирование мобильных покупок выполняется аналогично таковому для приложения, работающего под управлением ОС Android. Подробное
описание этого процесса см. здесь.
После того, как мобильное приложение разработано и выпущена первая версия этого приложения, начинают возникать различные вопросы. В
числе прочих, в списке могут присутствовать следующие вопросы:
● На каких устройствах и под управлением каких версий операционных систем чаще всего используется мобильное приложение?
● И т. д.
Для того чтобы помочь найти ответы на эти (и подобные) вопросы ‑ предназначены сервисы аналитики мобильных приложений. Сразу
предупредим, что данный материал не является документацией (или, тем более, учебником) по сервисам аналитики. Данный материал
предназначен только для того, чтобы описать возможности мобильной версии «1С:Предприятие» по взаимодействию с поддерживаемыми
сервисами аналитики.
1. В прикладное решение подключается файл преобразования (или встраивается программный код), который будет выполнять генерацию
событий для сервиса аналитики. При этом рекомендуется предварительно проанализировать, ответы на какие вопросы вы хотите получить.
Это связано с тем, что многие сервисы аналитики являются платными инструментами, и если вы включите для своего приложения отправку в
сервис аналитики всех возможных событий ‑ это может оказать не очень бюджетным решением.
2. В сборщике мобильных приложений необходимо указать, какой сервис аналитики (из списка поддерживаемых) будет использоваться в
мобильном приложении, и указать настройки этого сервиса. Использование сервиса статистики в мобильной версии «1С:Предприятие» для
разработчика требует несколько других настроек и будет описано отдельно.
4. Приложение начнет отправлять статистику использования в сервис, а аналитик компании-разработчика мобильного приложения ‑ начнет
анализ получаемой информации.
Для работы с сервисом статистики служит свойство глобального контекста СтатистикаИспользованияПриложения. В документации, для
упрощения, будет опускаться префикс метода СтатистикаИспользованияПриложения.. В примерах и реальных приложениях, очевидно, такие
пропуски недопустимы.
● AppSee (для ОС Android и iOS). Запись видео доступна только при работе под управлением ОС Android.
Для того чтобы использовать сервис статистики, необходимо использовать или мобильную версию разработчика или собрать мобильное
приложение с указанием на то, что приложение будет использовать сервис статистики. Если приложение на мобильном устройстве может
взаимодействовать с сервисом статистики, то управление фактическим взаимодействием с сервисом статистики управляется с помощью флажка
в настройках мобильного приложения и с помощью файла настроек.
Мобильное приложение отправляет в сервис статистики информацию о том, какие события происходят в мобильном приложении. С точки зрения
сервиса статистики, события делятся на две большие группы:
● События. Событие ‑ это любое взаимодействие пользователя с интерфейсом мобильного приложения на мобильном устройстве.
● Экраны (страницы). Экран ‑ это частный случай события. Экран ‑ это смена активной формы в анализируемом приложении. Термин «экран»
используется по той причине, что некоторые сервисы статистики используют понятие экранов для формирования различной отчетности.
В документации события и экраны будут упоминаться под общим термином «события». Если эти термины будет необходимо разделить ‑ это
будет делаться явно. Мобильная версия «1С:Предприятия» разделяет события на два подкласса:
● Исходные события ‑ это те события, которые генерирует сама мобильная версия (или код на встроенном языке).
● Отправляемые событие ‑ это события, которое создаются на основе исходных событий и которые фактически отправляются в сервис
аналитики.
Для преобразования исходного события в отправляемое событие предназначены специальные настройки. Они представляют собой XML-файл
специального формата. Преобразование выглядит следующим образом:
● Провайдер статистики (модуль мобильной версии, отвечающий за преобразование событий и взаимодействие с самим сервисом)
мобильного приложения загружает файл настроек. Это происходит при старте мобильного приложения, до того момента, как
инициализируется мобильная конфигурация.
● Провайдер статистики, по правилам, указанным в файле настроек, преобразует исходные события в отправляемые события.
XML-файл настроек можно предоставить мобильному приложению тремя способами (в порядке повышения приоритета):
● С помощью сборщика мобильных приложений, указав этот файл во время настройки собираемого приложения и не указав адрес
обновления этого файла. В этом случае в собранной версии будет действовать ровно тот набор правил преобразования исходных событий в
отправляемые события. Сменить набор правил можно только выпустив новую версию мобильного приложения. Это рекомендуемый способ.
● Аналогичен предыдущему способу, но в сборщике также указывается адрес обновления, откуда мобильное приложение сможет получить
новый файл правил преобразования событий. В этом случае предоставляется возможность обновлять состав отправляемых событий, не
выпуская новую версию мобильного приложения. Это также является рекомендованным способом.
● Реализовать всю (или часть) работу с помощью встроенного языка системы «1С:Предприятие». Так, получение и установка настроек будет
выполняться с помощью методов ПолучитьНастройки()/УстановитьНастройки(). Аналогичные методы есть для отправки исходных и
отправляемых сообщений. Это не рекомендованный способ. Причиной является тот факт, что для отключения работы с сервисом
статистики потребуется не только пересборка мобильного приложения, но и изменение исходных текстов прикладного решения. Изменение
исходных текстов потребуется для того, чтобы исключить вызовы встроенного языка, которые будут недоступны в том случае, когда
мобильное приложение собрано без поддержки сервиса статистики.
Таким образом, самым оптимальным вариантом подключения сервиса статистики к мобильному приложению ‑ это использование сборщика
мобильного приложения и не использование встроенного языка.
Таким образом, для включения отправки событий в сервис аналитики необходимо выполнить следующие действия:
2. В сборщике мобильных приложений указать, какой сервис статистики будет использоваться мобильным приложением, настроить
провайдер статистики, загрузить в сборщик файл настроек.
При использовании сервиса статистики следует помнить о юридических аспектах использования такого рода сервисов. Разработчик приложения
с использованием сервиса статистики должен контролировать содержание отсылаемой в сервис информации и соблюдать правила тех сервисов
статистики, которые он использует, а также магазинов, через которые распространяется данное приложение. Кроме того, необходимо
выполнять следующие особенности:
1. По умолчанию считается, что все пересылаемые данные обезличены и нет никакой возможности, исходя из них, как-то связать эти данные
с конкретной копией приложения. В этом случае, достаточно, чтобы разработчик предупредил пользователя об использовании
статистических сервисов в Пользовательском соглашении приложения.
2. Если приложение пересылает в сервис какие-либо идентификаторы, которые впоследствии могут быть связаны с конкретной копией
приложения (если это не нарушает правил используемых сервисов), то в этом случае, как правило, требуется показ отдельного диалога
пользователю, с которым он явным образом соглашается или не соглашается.
Разработчик приложения с использованием механизма статистики использования приложения обязан соблюдать все региональные законы в
сфере регистрации пользовательских данных. В частности, при использовании приложения на территории Российской Федерации необходимо
соблюдать требования статьи 138.1 Уголовного кодекса Российской Федерации, которая регламентирует незаконный оборот специальных
технических средств, предназначенных для негласного получения информации.
Мобильная версия «1С:Предприятие» позволяет взаимодействовать с провайдером статистики с помощью встроенного языка. Данный способ
является не рекомендуемым.
● Метод ПолучитьТекущиеНастройки() всегда возвращает те настройки, которые в данный момент используются для преобразования
исходных событий в отправляемые события. Для данного метода совершенно неважно, откуда поступили настройки: из мобильного
приложения (установлены в сборщике), в результате обновления настроек через Интернет-ресурс или с помощью методов строенного
языка.
● Пара методом ПолучитьНастройки()/УстановитьНастройки() предназначена для установки настроек из встроенного языка. Вызов метода
УстановитьНастройки() с конкретным файлом настроек приведет к тому, что настройки будут переустановлены. После такой установки
метод ПолучитьТекущиеНастройки() вернет только-что установленные настройки. Если вызвать метод УстановитьНастройки(), передав
ему в качестве параметра значение Неопределено, то метод ПолучитьТекущиеНастройки() начнет опять возвращать настройки, указанные
в сборщике (или полученные через Интернет-сервис).
● Методы ОтправитьСобытие()/ОтправитьЭкран() выполняют передачу событий и экранов непосредственно в сервис статистики, минуя
механизм преобразования.
● Метод ВызватьИсходноеСобытие() генерирует исходное событие, которое будет подано на вход механизм преобразования событий с
помощью файла настроек. Можно сказать, что данный метод (в некотором смысле) является аналогом интерактивного действия
пользователя.
● Методы НачатьВидеозаписи()/ЗакончитьВидеозапись() служат для управления механизмом регистрации действий пользователя как
видеоролик низкого разрешения. Поддерживается не всеми сервисами статистики. Для корректной работы данного механизма требуется
правильно указать настройки используемого сервиса статистики в сборщике мобильных приложений.
Одновременно может вестись только одна запись видео. Однако наличие условий включения/выключения в настройках регистрации и
использование методов НачатьВидеозаписи()/ЗакончитьВидеозапись() может привести к конфликтам записи.
При каждом срабатывании условия включения видео или вызове метода НачатьВидеозапись() происходит суммирование попыток включения.
Фактически запись будет выключена только после вызова соответствующего числа раз метода ЗакончитьВидеозапись() или срабатывания
условия выключения записи.
Условие автоматического (по таймауту) выключения видео записи ‑ это время, рассчитанное как самый поздний момент времени от
установленных таймаутами отдельных включений. Вызов метода НачатьВидеозапись() начинает бесконечную запись.
Любое срабатывание условия выключения записи или вызов ЗакончитьВидеозапись() игнорируется при фактически выключенной записи.
Для настройки преобразования исходных событий в отправляемые события предназначен файл настроек. Этот файл в формате XML описывает
правила преобразования одних событий в другие. Формат файла описывается схемой (в формате XSD), который поставляется в дистрибутиве
мобильной версии «1С:Предприятие».
<events>
<sourceEvent name="ApplicationStart">
</sourceEvent>
<sourceEvent name="FormOpen">
<eq property="Имя" value="ФормаЗаказа"/>
<targetEvent name="Order" param1="%ПолноеИмя%" type="screen"/>
</sourceEvent>
<sourceEvent name="Press_1">
<targetEvent name="PressButton" param1="%параметр события Press_1%"/>
</sourceEvent>
<sourceEvent name="Press_2">
<targetEvent name="PressButton" param1="%параметр события Press_2"/>
</sourceEvent>
</events>
<videoSettings>
<visibleItems>
<object name="ОбщаяФорма.ФормаТовара.ФотоТовара"/>
<object name="ОбщаяФорма.ФормаТовара.СтоимостьТовара"/>
</visibleItems>
<hiddenItems>
<object name="ОбщаяФорма.ФормаКонтрагента"/>
</hiddenItems>
</videoSettings>
</applicationUsageStatistics>
Файл состоит из двух основных разделов: описание преобразования событий (элемент <events>) и настройки записи видео (элемент
<videoSettings>). Рассмотри эти элементы подробнее.
Элемент events
Данный элемент описывает, каким образом исходные события будут конвертироваться в отправляемые события. Каждое исходное событие
описывается с помощью вложенного элемента <sourceEvent>.
Элемент sourceEvent
Данный элемент описывает одно исходное событие и правила его (исходного события) преобразования в отправляемое событие. Имя исходного
события указывается в атрибуте name элемента <sourceEvent>. Для задания правил предназначены элементы eq (равно), ne (не равно), gt
(больше), ge (больше или равно), lt (меньше), le (меньше или равно), like (подобно). Для указания отправляемого события предназначен
элемент <targetEvent>.
● name ‑ в этом атрибуте указывается имя параметра, значение которого будет проверяться. Имена (и набор) параметров зависят от
исходного события.
Все условия, указанные для одного исходного события, объединяются «по И». Имена исходных событий и их параметров не чувствительны к
регистру символов.
● Параметры отсутствуют.
● Параметры отсутствуют.
● Параметры отсутствуют.
● Параметры отсутствуют.
● Произвольный идентификатор исходного события, которое формируется из встроенного языка. В этом случае состав и назначение
параметров события определяется параметрами метода ВызватьИсходноеСобытие().
Если в файле настроек указано свойство <sourceEvent>, которое не содержит подчиненных элементов, то это означает, что данное исходное
событие будет передано в сервис статистики, но имя отправляемого события будет сформировано как Объект_ИмяИсходногоСобытия. Здесь
Объект ‑ это полное имя объекта конфигурации, вызвавшего исходное событие (с точностью до настроек мобильного приложения в сборщике).
Если на одном устройстве создано несколько информационных баз из одной конфигурации одного мобильного приложения ‑ события из этих
информационных баз будут неразличимы.
targetEvent
● name ‑ содержит имя отправляемого события. Если имя не указано ‑ оно будет сгенерировано автоматически.
● param1 и param2 ‑ параметры отправляемого события. Суть параметров определяется с точки зрения сервисов статистики или с точки
зрения пользовательского события.
● event ‑ событие будет отправлено в сервис статистики как «событие». Это значение атрибута по умолчанию.
● maxDurationVideo ‑ определяет максимальную длину записываемого видеоролика, в секундах. Значение по умолчанию равно 300 секунд.
Атрибут имеет смысл только тогда, когда для атрибута type указано значение startVideo.
videoSettings
Данный элемент указывает настройки записи видеороликов для отправки в сервисы статистики. При формировании видеороликов необходимо
скрывать персональную информацию в записываемом ролике. Это необходимо делать для соблюдения законов о защите персональных данных.
В частности, следует скрывать следующую информацию: пароли, номера платежных инструментов (карт, банковских счетов и т. д.), ФИО
пользователей, названия компаний и их идентификационные данные и т. д.
Сервис Appsee реализует автоматическое закрашивание приватных полей, но библиотеке сервиса необходимо указать список скрываемых
полей. Для этого мобильная версия платформы реализует следующее поведение по скрытию полей при записи видеороликов:
● Поле формы, для которого свойство РежимПароля установлено в значение Да или Авто.
● Содержимое клавиатура.
● Содержимое оповещений.
● Поле.
● Таблица.
● Кнопка.
● Декорация.
Если элемент формы указан одновременно и в элементе <hiddenItems> и в элементе <visibleItems>, то он будет скрыт в видеоролике. В
каждом из упомянутых элементов может содержать один или несколько элементов <object>, который имеет один обязательный атрибут name. В
данном атрибуте указывается полное имя скрываемого или отображаемого элемента формы.
Общая информация
Информацию об особенностях настройки и работы с конкретными сервисами статистики следует искать в документации этих сервисов. Данный
раздел содержит информацию, которая необходима только для того, чтобы подключить соответствующий сервис аналитики к мобильной версии
«1С:Предприятие».
AppMetrica
1. Войти в сервис AppMetrica (https://appmetrica.yandex.ru/) от имени пользователя, который будет анализировать результаты работы
(разработчика приложения).
● Если приложение опубликовано в магазине, в разделе Ссылка на приложение следует указать ссылку на опубликованное приложение.
● На шаге Детали нужно указать текущий часовой пояс и подтвердить дополнительные условия обработки данных в поле GDPR (если это
необходимо).
4. После нажатия кнопки Добавить приложение ‑ создаваемое приложение будет добавлено в сервис. На последней странице вам необходимо
сохранить данные, которые указаны в поле API key. Это значение будет необходимо использовать для заполнения поля Идентификатор
приложения в сервисе статистики в диалоге настройки провайдера статистики в сборщике мобильных приложений.
Firebase Analytics
Следующие действия необходимо выполнять от имени пользователя, который будет анализировать результаты работы (разработчика
приложения):
2. Необходимо создать проект (кнопка Создать проект). При создании проекта следует указать название проекта. Название проекта должно
содержать только латинские символы. После ввода наименования проекта следует нажать кнопку Продолжить.
3. На странице с описанием свойств создаваемого проекта можно указать необходимость включения Google Аналитики в проекте. По
умолчанию данный флажок установлен. Затем необходимо нажать кнопку Далее.
4. На последнем шаге создания проекта следует указать страну, в которой расположена организация, владеющая создаваемым проектом.
Затем следует согласиться со всеми условиями сервиса и нажать кнопку Создать проект. После того, как проект создан ‑ нажмите кнопку
Далее.
5. На странице проекта необходимо добавить мобильное приложение для ОС Android или iOS. Для этого предназначены две кнопки под
заголовком Добавьте сервис Firebase в свое приложение. Для добавления приложения:
● ОС Android:
● В поле Название пакета Android укажите полный идентификатор приложения из сборщика мобильных приложений.
● ОС iOS:
● В поле Идентификатор пакета iOS укажите полный идентификатор приложения из сборщика мобильных приложений.
6. Файл, скачанный при регистрации приложения в сервисе, будет необходимо загрузить в сборщик мобильных приложений при настройке
параметров сборки для соответствующей мобильной ОС.
При использовании мобильного приложения часто возникают задачи обмена информацией с внешней системой через Интернет. При этом может
возникать задача выполнения обмена только через определенные виды интернет-соединения или только в том случае, если интернет-
соединение обладает достаточной пропускной способностью (скорость) для выполнения обмена.
Мобильная версия «1С:Предприятия» позволяет определить параметры интернет-соединения, которое в данный момент используется на
мобильном устройстве. Получить эти параметры можно с помощью свойства глобального контекста ИнформацияОбИнтернетСоединении.
Важной особенностью инструментов работы с интернет-соединением в мобильной версии является возможность подключить специальный
обработчик, который будет срабатывать в следующих случаях:
1. При смене типа интернет-соединения. К такому случаю также относится ситуация, когда на мобильном устройстве отключается любой
доступ в Интернет, например пользователь перевел устройство в «режим полета».
2. При изменении ожидаемой скорости интернет-соединения при подключении с помощью мобильного интернета. В этом случае фиксируется
изменения используемого стандарта мобильной сотовой связи, например, переход с сети стандарта 2G на сеть стандарта 3G и т. д.
Для подключения (или отключения) обработчика изменения интернет-соединения следует использовать методы
ПодключитьОбработчикИзмененияИнтернетСоединения() (ОтключитьОбработчикИзмененияИнтернетСоединения()) объекта
ИнформацияОбИнтернетСоединении.
В приложении, работающем на мобильном устройстве, могут возникать ситуации, когда требуется проверить, что в данный момент устройством
пользуется именно владелец устройства. Например, выбирается функция, доступа к которой не должен предоставляться всем пользователям,
которые получили разблокированное мобильное устройство в руки. Также может потребоваться хранить на мобильном устройстве
конфиденциальные данные, например параметры доступа (логин и пароль) к какому-либо удаленному сервису.
Во всех перечисленных случаях, прикладному решению необходимо выполнить идентификацию пользователя каким-либо образом ‑ пароль,
графический ключ, отпечаток пальца и т. д. Эту проверку можно выполнить с помощью объектов глобального контекста
ДополнительнаяПроверкаПользователя и БезопасноеХранилище. Работа с данными свойствами будет описана далее, в этом разделе.
Говоря о дополнительной проверке пользователя, необходимо понимать, что такая проверка не является средством аутентификации
пользователя. Т.е. с помощью дополнительной проверки невозможно утверждать, что устройством пользуется конкретный человек. Можно
говорить лишь о том, что пользователь, который здесь и сейчас пользуется устройством, знает способ разблокировать телефон. Т.е. можно
говорить о возможности идентифицировать владельца телефона (с учетом оговоренных условностей). Например, если вы сообщили своему
бизнес-партнеру способ разблокировки (пин-код или графический ключ) телефона, то программа в телефоне не сможет определить, кто
пользуется телефоном: вы или ваш бизнес-партнер.
Свойство глобального контекста ДополнительнаяПроверкаПользователя предназначено для того, чтобы прикладное решение, работающее на
мобильном устройстве, запросило дополнительную проверку пользователя с целью убедиться, что с мобильным устройством (и мобильным
приложением) в данный момент работает законный владелец. Свойство ДополнительнаяПроверкаПользователя предоставляет доступ к объекту
МенеджерДополнительнойПроверкиПользователя. Для получения доступа к какому-либо свойству или методу менеджера, необходимо
использовать запись вида ДополнительнаяПроверкаПользователя.Метод(). При описании методов (для упрощения) префикс
ДополнительнаяПроверкаПользователя. будет игнорироваться. В примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Прежде, чем начать проверку, необходимо убедиться, что на данном устройстве поддерживается возможность дополнительной проверки. Это
следует сделать с помощью метода ПоддерживаетсяПроверка(). В качестве параметра передается способ дополнительной проверки, работу с
которым необходимо проверить. Если проверка поддерживается на устройстве ‑ можно выполнить собственно проверку (идентификацию)
пользователя.
Для идентификации пользователя предназначен метод НачатьПроверку(). В данный метод передается способ дополнительной проверки,
описание обработчика, который будет вызван после окончания проверки и текст, который платформа отобразит пользователю. Текст должен
описывать, зачем и почему от пользователя требуются какие-то действия. Очевидно, что способ проверки, указанный в методе
НачатьПроверку(), должен совпадать со способом проверки, который использовался при определении поддержки дополнительной проверки
устройством.
Если на мобильном устройстве используется биометрическая идентификация пользователя, то узнать, какой способ используется в данный
момент, можно с помощью метода ТекущийСпособБиометрическойПроверки(). Результат работы данного метода можно использовать в разных
целях, например:
● Для определения, что надежность используемого способа проверки устраивает разработчика приложения.
В общем случае, пример дополнительной проверки пользователя мобильного приложения может выглядеть следующим образом:
Копировать в буфер обмена
Процедура ПроверитьПользователя()
СпособПроверки = СпособДополнительнойПроверкиПользователя.ТолькоБиометрическая;
Если Не ДополнительнаяПроверкаПользователя.ПоддерживаетсяПроверка(СпособПроверки) Тогда
Возврат;
КонецЕсли;
ТекущаяБиометрия = ДополнительнаяПроверкаПользователя.ТекущийСпособБиометрическойПроверки();
Если ТекущаяБиометрия <> СпособБиометрическойПроверки.РаспознаваниеОтпечаткаПальца Тогда
Возврат;
КонецЕсли;
Сообщение = "Отсканируйте отпечаток пальца";
Обработчик = Новый ОписаниеОповещения();
ДополнительнаяПроверкаПользователя.НачатьПроверку(СпособПроверки, Сообщение, Обработчик);
КонецПроцедуры
Процедура ОбработкаРезультатовПроверки(ОтмененоПользователем, ДополнительныеПараметры) Экспорт
Если Не ОтмененоПользователем Тогда
// пользователь подтвержден
КонецЕсли;
КонецПроцедуры
Свойство глобального контекста БезопасноеХранилище предназначено для того, чтобы прикладное решение, работающее на мобильном
устройстве, получило доступ к безопасному хранилищу конфиденциальных данных. Свойство БезопасноеХранилище предоставляет доступ к
объекту МенеджерБезопасногоХранилища. Для получения доступа к какому-либо свойству или методу менеджера, необходимо использовать
запись вида БезопасноеХранилище.Метод(). При описании методов (для упрощения) префикс БезопасноеХранилище. будет игнорироваться. В
примерах и реальных приложениях, очевидно, такие пропуски недопустимы.
Безопасное хранилище позволяет хранить данные, для доступа к которым предназначен некоторый текстовый ключ. В рамках приложения ключ
является уникальным значением. В хранилище могут использовать данные любого типа, который поддерживает XDTO-сериализацию. Нельзя
поместить в безопасное хранилище значение Неопределено. При помещении данных в хранилище указывается способ защиты доступа к
безопасному хранилищу (одно из значений системного перечисления СпособЗащитыДоступаБезопасногоХранилища):
● ТребуетсяРазблокировкаЭкрана. В этом случае считается, что приложение имеет доступ к защищенному хранилищу в том случае, если
пользователь разблокировал устройство (получил доступ к рабочему столу устройства).
● Нет. В этом случае для получения доступа к защищенному хранилищу не нужны дополнительные проверки. Мобильная операционная
система гарантирует, что доступ к защищенному хранилищу будет получен только в том случае, если мобильное устройство успешно
запустилось.
● Для доступа к значению будет требоваться именно тот способ проверки, который указан при помещении значения.
● Если на мобильном устройстве будет отключен требуемый способ защиты доступа ‑ данные, которые были помещены в безопасное
хранилище с указанием отключенного способа защиты, будут удалены из хранилища и получить к ним доступ будет невозможно.
Безопасное хранилище данных имеет ряд особенностей, которые зависят от используемой мобильной операционной системы:
● ОС Android:
● ОС macOS:
● ОС Windows:
Прежде, чем начать использование безопасного хранилища, необходимо убедиться, что на данном устройстве поддерживается эта возможность.
Это следует сделать с помощью метода ПоддерживаетсяЗащитаДоступа(). В качестве параметров передается способ защиты доступа к
хранилищу и способ дополнительной проверки пользователя.
Если на данном экземпляре мобильного устройства подерживается безопасное хранилище, приложение может выполнять операции помещения
и получения данных. Поддерживаются стандартный набор операций:
● Проверить, что в хранилище есть данные с указанным ключом. Используется метод СодержитКлюч().
Подробнее рассмотрим особености работы с хранилищем. При помещении данных в хранилище, кроме собственно ключа и помещаемых данных,
необходимо указать, каким образом будут защищены помещаемые данные. Это определяется параметрами СпособЗащитыДоступа и
СпособПроверки метода НачатьПомещениеДанных(). Параметр СпособЗащитыДоступа имеет тип СпособЗащитыДоступаБезопасногоХранилища и
особенности этого типа были рассмотрены чуть раньше, в данном разделе. Если параметр СпособЗащитыДоступа установлен в значение
СпособЗащитыДоступаБезопасногоХранилища.ТребуетсяДополнительнаяПроверкаПользователя, то необходимо указать значение параметра
СпособПроверки. Этот параметр имеет тип системного перечисления СпособДополнительноПроверкиПользователя и позволяет указать, каким
образом будет выполняться дополнительная проверка пользователя.
Для получения данных (метод НачатьПолучениеДанных()), кроме указания ключа доступа к данным, необходимо указать текст, который будет
показан пользователю при необходимости дополнительной проверки. Пользователь может отказаться от получения данных из безопасного
хранилища. Для прикладного решения это равноценно невозможности получить какие-то данные. Прикладное решение должно корректно
отрабатывать невозможность получения данных из безопасного хранилища.
Методы работы с хранилищем, в большинстве, являются не блокирующими работы приложения. Результат работы методов передается в
соответствующий обработчик обратного вызова, который передается одним из параметров метода при его (метода) вызове. В случае
возникновения ошибки управление передается в обработчик ошибок, который также должен быть указан при создании объекта
ОписаниеОповещения.
Синхронным является только метод проверки существования в хранилище некоторого значения для указанного ключа (метод СодержитКлюч()).
Также следует обратить внимание на то, что методы проверки при доступе к безопасному хранилищу не гарантируют присутствие у какого-то
конкретного пользователя. Эти методы гарантируют, что како-то человек обладает возможностью разблокировать телефон с помощью
требуемого метода, например, знать пин-код или графический узор для разблокировки телефона.
Смотри также:
Мобильные операционные системы предоставляют встроенные инструменты резервного копирования данных приложений, работающих на
мобильных устройствах. В зависмости от используемой операционной системы, для резервного копирования используются следующие сервисы:
● ОС Android: сервис Google Drive или специализированные программы резервного копирования, работающие на персональном компьютере.
Для того чтобы на мобильном устройстве выполнялось резервное копирование средствами операционной системы, необходимо установить
разрешение Резервное копирование средствами ОС в списке свойств Требуемые разрешения мобильного приложения. Если для приложения
требуется выключить возможность резервного копирования средвами мобильной операционной системы ‑ разрешение Резервное копирование
средствами ОС следует выключить.
Никаких дополнительных действий на устройстве выполнять не требуется. Данное разрешение оказывает воздействие только на мобильное
приложение, которое собирается с использованием сборщика мобильных приложений.
Использование фонарика
При использовании мобильного приложения может возникнуть необходимость осветить какой-либо объект. В том случае, если мобильное
устройство, используемое в этот момент, имеет вспышку основной камеры, то можно использовать эту вспышку в роли фонарика.
Для проверки, что эта возможность поддерживается устройством, служит метод СредстваУстройства.ПоддерживаетсяФонарик(). Если метод
вернул Истина, то можно включать фонарик с помощью вызова метода СредстваУстройства.ВключитьФонарик(Истина). Выключение фонарика
выполняется с помощью вызова метода СредстваУстройства.ВключитьФонарик(Ложь).
Установка приложений
Мобильное приложение может устанавливать на мобильное устройство различные сторонние приложения, необходимые для работы собранного
мобильного приложения. Эта возможность может противоречить требованиям безопасности, которые предъявляются к мобильным приложениям.
Управление возможностью установки сторонних приложений осуществляется с помощью разрешения Установка приложений. Данное
разрешение оказывает воздействие только на мобильное приложение, которое собирается с использованием сборщика мобильных приложений.
В мобильном приложении допускается использовать только компоненты, разработанные по технологии Native API, которые могут быть как
отдельными файлами, так и упакованными в zip-архивы особого вида.
Во внешних компонентах, разработанных для использования совместно с мобильным приложением, запрещается использовать работу с
пользовательским интерфейсом.
Внешняя компонента должна быть скомпилирована с учетом всех процессоров, архитектуру и операционных систем, используемых на
мобильных устройствах. Рекомендуется функциональные модули внешней компоненты реализовывать платформонезависимым образом.
Если внешняя компонента использует дополнительные модули, это рекомендуется указывать в документации к компоненте. Используемые не
системные библиотеки должны быть статически включены в результирующий файл внешней компоненты.
Расположение внешних компонент зависит от используемого клиентского приложения и мобильной операционной системы:
● ОС iOS:
● Мобильное приложение:
● Мобильное приложение для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована
отлаживаемая конфигурация.
● Мобильное приложение для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● Мобильный клиент:
● Мобильный клиент для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована
информационная база.
● Мобильный клиент для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● ОС Android:
● Мобильное приложение для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована
отлаживаемая конфигурация.
● Мобильное приложение для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения.
● Мобильный клиент:
● Мобильный клиент для разработчика ‑ внешние компоненты загружаются через веб-сервер, на котором опубликована
информационная база.
● Мобильный клиент для магазина приложений ‑ внешние компоненты включаются в состав собранного мобильного приложения, однако
могут быть загружены через веб-сервер, на котором опубликована информационная база в случае, если в информационную базу
загружена новая версия внешней компоненты.
● ОС Windows:
При работе с мобильным клиентом следует учитывать следующую особенность: если мобильный клиент (в варианте для магазина приложений)
одновременно позволяет работать с информационными базами, которые используют разные версии одной и той же внешней компоненты, это
может привести к возникновению проблемой. Проблема связана с тем, что собранное мобильное приложение может содержать внешние
компоненты только одной версии (для одной внешней компоненты). В связи с этим рекомендуется разрабатывать внешние компоненты с
безусловным соблюдением совместимости снизу-вверх, так, чтобы любая внешняя компонента версии N+1 поддерживала работоспособность с
прикладным решением, которое ожидает только версию внешней компоненты версии N. В тоже время, работа под управлением ОС Android не
приведет к таким проблемам, т. к. мобильный клиент автоматически загрузит ту версию внешней компоненты, которая используется в
конкретной информационной базе.
Отладка прикладного решения, с применением внешних компонент, различается для разных мобильных ОС:
● Для ОС iOS ‑ отладка возможна с использованием мобильной версии «1С:Предприятия» для разработчика, путем публикации прикладного
решения (подробнее см. здесь) или информационной базы на веб-сервере.
● Для ОС Android ‑ отладка возможна с использованием мобильной версии «1С:Предприятия» для разработчика, путем публикации
прикладного решения (подробнее см. здесь) или информационной базы на веб-сервере или при работе через Android Debug Bridge
(подробнее см. здесь).
● Для ОС Windows ‑ допустимо использование только собранного мобильного приложения (с помощью сборщика приложений для мобильных
устройств).
Для того чтобы использовать внешнюю компоненту с мобильным приложением, необходимо загрузить ее в конфигурацию, в макет с типом
Внешняя компонента (см. здесь). Кроме того, если приложение будет работать только под управлением ОС Android, внешние компоненты можно
загружать из макета с типом Двоичные данные, реквизита справочника, временного хранилища и объекта файловой системы.
Для того чтобы собрать мобильное приложение с включением внешних компонент, необходимо выгружать конфигурацию в виде zip-архива
(1cema.zip). Если конфигурация содержит внешние компоненты, то при выполнении команды Главное меню ‑ Конфигурация ‑ Мобильное
приложение ‑ Записать в файл или Главное меню ‑ Конфигурация ‑ Мобильный клиент ‑ Записать в файл, будет автоматически предложен
именно такой вариант сохранения. Сборщик приложений для мобильных устройств автоматически будет учитывать наличие внешних компонент
при загрузке мобильной конфигурации и последующей сборке мобильного приложения.
Данный раздел содержит информацию, которую следует учитывать при разработке приложений на мобильной платформе.
● Независимое от каких-либо прикладных решений на удаленной системе. В этом случае структура данных приложения на мобильной
платформе определяется только областью применения приложения. Скорее всего, никакой обмен данными не потребуется.
● Автономное рабочее место некоторого прикладного решения, расположенного на удаленной системе. В этом случае структура данных в
основном определяется прикладным решением, но будут изменения, определяемые как областью применения, так и особенностями
приложения на мобильной платформе. Протокол обмена данными, скорее всего, будет разработан специально для обмена конкретного
прикладного решения с конкретным приложением на мобильной платформе. Вероятнее всего, этот протокол не будет поддерживать обмен
с другими прикладными решениями.
● Универсальное автономное рабочее место. В этом случае структура данных должна учитывать специфику всех прикладных решений, с
которыми должно взаимодействовать приложение на мобильной платформе. Также необходимо учитывать особенности приложения на
мобильной платформе. Протокол обмена должен быть достаточно универсальным и стандартизированным.
● Уточняется, разрабатываемое приложение должно работать только на мобильном устройстве или оно также может работать и на
персональном компьютере (например, на ноутбуке).
● Выполняется реализация приложение на мобильной платформе и его отладка на персональном компьютере (включая механизмы обмена
данными). При этом необходимо понимать, что мобильная платформа имеет ряд отличий и особенностей, в силу чего невозможно полностью
проверить работоспособность разрабатываемого приложения на персональном компьютере. Однако код на встроенном языке можно
отлаживать с использованием персонального компьютера.
● На мобильном устройстве (одном или нескольких) выполняется окончательная проверка и отладка интерфейса и функциональности
приложения.
СОВЕТ. Рекомендуется выбирать для разработки вариант автономного рабочего места, которое может функционировать и на мобильном
устройстве и на персональном компьютере.
При разработке механизма обмена данными необходимо учитывать, что обмениваться данными должны приложения с разными версиями
интерфейса обмена. Это не должно вызывать проблем при обмене. Связано это с тем, что обновление приложения сразу для всей
инфраструктуры практически невозможно. Также следует отметить, что синхронизация данных по устаревшей версии протокола обмена может
использоваться для выполнения операций резервного копирования перед обновлением конфигурации мобильного приложения.
При разработке приложения на мобильной платформе необходимо учитывать ограничения, которые накладывает мобильная платформа по
сравнению с платформой «1С:Предприятие» для персонального компьютера:
● Упрощенная реализация некоторых механизмов (например, права доступа или начальная страница);
Также следует учитывать, что мобильная платформа и платформа для персонального компьютера, при совпадении версий различаются по
предоставляемой функциональности. Ниже приведено функциональное соответствие версий платформы для мобильного устройства и
персонального компьютера:
8.3.12 8.3.12
8.3.11 8.3.11
8.3.10 8.3.10
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/.
29.4.3.1. Отчеты
● Реализация на мобильной платформе некоторой формы, с помощью которой можно задать параметры формирования отчета (отборы и т.
д.), а само формирование передать в удаленную систему, которая вернет табличный документ для отображения на мобильном устройстве.
● Содержит или нет информационная база мобильного приложения все данные, которые необходимы для построения отчета;
● И т. д.
Если принято решение формировать отчет на мобильном устройстве, то необходимо помнить об особенностях мобильной платформы (см. здесь).
Для получения данных доступны выборки, а для построения отчета доступно программное формирование табличного документа (на основании
макета) и диаграмм (если таковые требуются).
Если для мобильного приложения доступны постоянные высокоскоростные каналы связи с удаленной системой, которое обладает всеми
необходимыми данными для формирования требуемого отчета, то возможным вариантом может служить реализация на мобильном приложении
только интерфейсной части отчета (задание отборов, обработка расшифровки и т. д.). Собственно формирование отчета в этом случае будет
происходить в удаленном приложении, а возвращаться будет готовый отчет для отображения на устройстве.
При этом возможны и все промежуточные варианты, например, если реализован периодический обмен, можно настройки отчета сформировать
на мобильном устройстве и передать на удаленную систему во время сеанса обмена, а обратно получить сформированный отчет для
отображения.
Для взаимодействия с удаленным приложением можно использовать Web-сервис (который предоставляет удаленное приложение), обмен
данными с помощью плана обмена и т. д.
При необходимости реализации расшифровки отчета, нужно понимать, что мобильное приложение самостоятельно может выполнить только
просмотр значений, указанных в качестве расшифровки ячейки отчета. Остальные действия необходимо реализовывать на встроенном языке,
включая получение нового варианта отчета с учетом наложенных отборов и т. д.
При работе с ролями в мобильном приложении следует помнить, что из всех прав доступа, которые предоставляет платформа для
персонального компьютера, на мобильной платформе доступен только ограниченный набор. Этот набор прав призван обеспечить
функционирование различных механизмов, обеспечивающих интерфейс мобильного приложения. Права, которые могут использовать на
мобильной платформе, отмечены символом «*» в полном списке прав (см. здесь).
Также имеется возможность выполнять ролевую настройку формы (см. здесь), настраивать ролевую видимость командного интерфейса (см.
здесь).
ВНИМАНИЕ! Права для доступа к данным (Чтение, Добавление, Изменение, Удаление и т. д.) не поддерживаются мобильной платформой.
Методы управления привилегированным режимом в мобильной платформе используются для совместимости с платформой для персонального
компьютера. Сами вызовы методов работы с привилегированным режимом мобильной платформой игнорируются и никаких действий мобильная
платформа не выполняет.
При определении прав пользователя действует стандартная схема: если в информационной базе не заданы пользователи, то для определения
прав доступа используется свойство конфигурации ОсновныеРоли (см. здесь). Если для доступа к данным мобильного приложения используется
пользователь, то права доступа определяются по составу ролей этого пользователя.
Мобильная платформа имеет ограниченный набор средств работы с пользователями информационной базы:
● В информационной базе может существовать только один пользователь. Попытка создать более одного пользователя приводит к генерации
исключения.
● Пользователь может быть создан только с помощью программного кода. Интерактивное создание пользователей в конфигураторе не
приведет к передаче пользователя на мобильное устройство.
● Мобильная платформа не предлагает средств аутентификации при старте мобильного приложения. Если пользователь указан в списке
пользователей, то этот пользователь автоматически будет установлен в качестве пользователя текущего сеанса.
В результате можно рекомендовать следующую схему работы от лица пользователей с разными правами:
1. Выполняется создание пользователя с нужным набором ролей или выполняется изменение набора ролей у существующего пользователя.
Данный раздел содержит информацию, которую следует учитывать при разработке приложений, работающих в мобильном клиенте.
Как известно, приложение на мобильной платформе содержит копию используемой конфигурации и работает только с ней. В то же время,
мобильный клиент должен работать с той версией конфигурации, которая в данный момент находится в информационной базе, к которой
мобильный клиент подключен. Однако магазины приложений могут требовать, чтобы приложение, опубликованное в магазине, не изменяло
свою функциональность после установки на устройство пользователя. В некотором смысле данные требования являются взаимоисключающими.
Для того чтобы приложение мобильного клиента могло быть опубликовано в магазине приложений, необходимо выполнить несколько
требований:
1. Мобильный клиент может работать только с теми конфигурациями, которые указаны перед сборкой. Одно мобильное приложение может
работать с несколькими информационными базами.
2. Каждая конфигурация имеет собственную электронную подпись (включающая характеристику метаданных конфигурации), благодаря
которой отсутствует возможность полной замены конфигурации в информационной базе.
Соблюдение данных требований позволяет собранному приложению мобильного клиента быть опубликованным в магазине приложений и
удовлетворить требованиям этого магазина.
Мобильный клиент взаимодействует с информационной базой по протоколу HTTP/HTTPS. Это означает, что мобильный клиент не поддерживает
прямое подключение и может работать только с теми информационными базами, которые опубликованы на веб-сервере. При работе с помощью
мобильного клиента не требуется обеспечивать точное соответствие версии мобильного клиента и версии расширения веб-сервера или сервера
«1С:Предприятие». Совместимость обеспечивается не в рамках номера версии системы «1С:Предприятие», а в рамках версии протокола
взаимодействия. В том случае, если протокол взаимодействия будет существенно изменен, на мобильных устройствах будет необходимо
обновить приложение тонкого клиента.
В отличие от приложения на мобильной платформе, которое, по сути, является самостоятельным и отдельным приложением, приложение для
мобильного клиента является адаптацией обычного приложения, которое работает в тонком клиенте или веб-клиенте. Но для корректной
работы этого приложения в мобильном клиенте, платформе необходимо «подсказать», как нужно строить интерфейс в мобильном клиенте. Для
Для того чтобы конфигурация была работоспособна в мобильном клиенте, необходимо выполнить некоторый набор действий:
● Выполнить адаптацию форм конфигурации, с учетом особенностей отображения этих форм на мобильных устройствах.
● В модулях на встроенном языке необходимо использовать директиву компиляции #Если НЕ МобильныйКлиент Тогда … #КонецЕсли везде,
где требуется отметить код, который может работать только на мобильном устройстве.
Смотри также:
Как уже было сказано, приложение мобильного клиента не может произвольно изменять свои функциональные возможности после загрузки на
мобильное устройство пользователя. Данное требование накладывают магазины приложений на мобильные приложения, которые загружают
свой код с внешних ресурсов. Чтобы выполнить это требование, каждая конфигурация, которая может работать в мобильном клиенте, содержит
некоторую вспомогательную информацию, позволяющую отследить существенное изменение конфигурации.
● В начале разработки конфигурации (в конфигураторе) формируется закрытый ключ для формирования подписи разрабатываемой
конфигурации.
ВНИМАНИЕ! Каждая конфигурация обязана иметь уникальный закрытый ключ. Использование одного и того же закрытого ключа для
нескольких конфигураций ‑ не допускается.
● При необходимости опубликовать конфигурацию в мобильном клиенте формируется подпись конфигурации. При выполнении этого
действия создается дайджест конфигурации, который подписывается закрытым ключом.
● При выгрузке конфигурации для сборщика приложений для мобильных устройств, в файл помещается открытый ключ (для
использованного закрытого ключа), с помощью которого можно проверить цифровую подпись.
● При попытке подключения мобильного клиента к информационной базе, сервер «1С:Предприятия» передает мобильному клиенту
цифровую подпись конфигурации и текущий дайджест конфигурации.
● Мобильный клиент выполнит подключение только в том случае, если имя конфигурации (свойство конфигурации Имя) не изменялось с
момента сборки мобильного приложения и переданная цифровая подпись соответствует переданному дайджесту. Проверить это возможно
потому, что мобильное приложение содержит открытый ключ, с использованием которого и выполняется проверка.
Если в приложение мобильного клиента, работающего под управлением ОС iOS, информационная база добавляется с помощью начальной
страницы, то проверка возможности работы с таким приложением осуществляется с использованием цифровой подписи всех конфигураций,
которые добавлены в собранное приложение мобильное клиента во время сборки.
В том случае, если необходимо, чтобы платформа автоматически проверяла соответствие конфигурации и созданной цифровой подписи,
следует открыть диалог Главное меню ‑ Конфигурация ‑ Мобильный клиент ‑ Настройка использования мобильного клиента. В диалоге
установить флажок Проверять подпись мобильного клиента при обновлении конфигурации базы данных и нажать кнопку ОК. После этого, при
выполнении команды Обновить конфигурацию базы данных, будет выполняться проверка соответствия сохраняемой конфигурации и
существующей цифровой подписи.
Дайджест конфигурации предназначен для проверки возможности работы мобильного клиента с информационной базой, к которой он
подключается. В состав дайджеста конфигурации входит следующая информация:
● Справочники;
● Документы;
● Планы обмена;
● Перечисления;
● Бизнес-процессы.
● Регистры сведений;
● Регистры накопления;
● Регистры бухгалтерии;
● Регистры расчета.
Изменение объектов конфигурации, входящих в состав дайджеста конфигурации, означает необходимость заново подписать разрабатываемую
конфигурацию.
Таким образом, в зависимости от того, кто дорабатывает конфигурацию мобильного клиента, различаются действия, которые необходимо
предпринять при изменении конфигурации:
● Автор конфигурации: при изменении дайджеста конфигурации необходимо повторно подписать конфигурацию, не изменяя
опубликованного приложения мобильного клиента. В этом случае не придется заново публиковать приложение мобильного клиента.
● Другие специалисты, не имеющие доступ к закрытому ключу конфигурации. В этом случае представляется возможным выполнить одно из
следующих действий:
● Обратиться к разработчику оригинальной конфигурации с просьбой заново подписать ваш экземпляр доработанной конфигурации.
● Собрать (с помощью сборщика мобильных приложений) и опубликовать свой экземпляр мобильного приложения, предназначенного для
эксплуатации доработанной конфигурации. В этом приложении можно будет сохранить возможность работы с оригинальной
конфигурацией. При этом следует помнить, что публикация в магазине мобильных приложений будет осуществляться от лица компании,
доработавшей оригинальную конфигурацию, со всеми вытекающими последствиями (регистрация как разработчика в магазине
приложений, сертификаты и т. д.).
Таким образом, использование для подписи конфигурации нового закрытого ключа автоматически означает, что использовать такую
конфигурацию можно будет только с тем мобильным приложением, которое обладает открытым ключом для проверки дайджеста.
Следовательно, обновление опубликованного мобильного приложения должно быть выполнено до того, как обновленная конфигурация станет
доступна на используемой информационной базе.
В том случае, если на форме существуют данные, связанные с текущей строкой таблицы (одной или нескольких), то рекомендуется сделать
следующее:
● Все данные формы, связанные с текущими данными таблиц следует разделить по группам таким образом, чтобы одна группа отображала
данные, связанные с текущей строкой только одной таблицы.
● Для каждой такой группы следует установить свойства Использование текущей строки (ИспользованиеТекущейСтроки) и Используемая
таблица (ИспользуемаяТаблица) по аналогии с командной формы. Из этого следует, что одна группа может отображать данные только одной
таблицы. Именно поэтому выше приводится рекомендация связанные данные размещать в разные группы, по количеству используемых
таблиц.
● Для таблиц, которые используются в качестве источников данных для вспомогательных данных, следует установить свойство
Использование текущей строки в значение Выбор.
В мобильном клиенте на форме не будет групп, у которых свойство Использование текущей строки установлено в значение Использовать.
Для того чтобы увидеть связанные данные, необходимо открыть контекстное меню на выбранной строки и выбрать специальную команду,
выбор которой откроет окно с данными. Название команды формируется как имя скрытой группы. Если в данной таблице текущие данные
отображаются в нескольких группах ‑ название команды будет сформировано из заголовков всех групп, объединенных символом «,».
Данный раздел содержит описание особенностей разработки конфигурации, которая должна работать в мобильном клиенте с автономным
режимом.
При рассмотрении мобильного клиента с автономным режимом будут использоваться следующие термины:
● Основной сервер ‑ кластер серверов прикладного решения, с которым работает мобильный клиент с автономным режимом. Кластер
работает на персональном компьютере.
● Автономный сервер ‑ серверная часть мобильного клиента с автономным режимом, которая работает на мобильном устройстве.
● Автономный режим ‑ под этим термином будем понимать такой режим работы мобильного приложения, когда соединение с основной
информационной базой отсутствует.
● Обычный режим ‑ под этим термином будем понимать возможность мобильного приложения использовать и основной и автономный
сервер.
● Автономная конфигурация ‑ часть основной конфигурации, которая предназначена для работы на мобильном устройстве, в автономном
режиме.
● Внешние ссылки ‑ ссылки на данные информационной базы, типы которых которые не включены в состав автономной конфигурации, но
сами эти данные ‑ используются в объектах автономной конфигурации.
Мобильный клиент позволяет работать только при наличии соединения мобильного устройства и веб-сервера, на котором опубликовано
приложение. Приложение на мобильной платформе вообще не требует какой-то внешней (по отношению к мобильному устройству) базы
данных. Это приложение работает полностью с базой данных, расположенной на мобильном устройстве. Мобильный клиент с автономным
режимом объединяет в себе обе этих особенности. Когда между мобильным устройством и информационной базой существует канал связи:
мобильный клиент с автономным режимом работает в обычном режиме. В том случае, когда канал нарушается: мобильное приложение
переходит в автономный режим, когда используются только те данные (и та конфигурация), которые определены для использования в
автономном режиме.
Доступность данных и форм в автономном режиме определяется во время настройки состава автономной конфигурации (подробнее см. здесь).
При этом указывается не только список объектов и форм, доступных в автономном режиме, но и то, какие данные (реквизиты и табличные
части) будут в автономных объектах.
Для форм, входящих в состав автономной конфигурации, имеется возможность реагировать на изменение доступности основного сервера. С
помощью такого механизма разработчик получает возможность адаптировать форму на мобильном устройстве под изменяющиеся условия:
доступность или недоступность основного сервера (подробнее см. здесь).
Для начального заполнения базы данных мобильного клиента с автономным режимом следует использовать планы обмена (подробнее см.
здесь).
В общем случае, при разработке мобильного клиента с автономным режимом следует ориентироваться на следующие основные сценарии
работы:
● Объекты автономной конфигурации используются в соответствии с приоритетами, указанными при настройке автономной конфигурации.
● При пропадании канала связи с информационной базой происходит переход в автономный режим. При этом:
● Мобильный клиент с автономным режимом пытается восстановить соединение с основной информационной базой.
● Для работы используется автономная информационная база, состав которой определяется во время настройки состава автономной
конфигурации, а объем данных ‑ параметрами плана обмена с точностью до последней синхронизации.
● При восстановлении канала связи мобильный клиент с автономным режимом должен синхронизировать данные и (при необходимости)
выполнить переоткрытие форм приложения.
● Включается принудительно, в диалоге свойств информационной базы мобильного приложения или в диалоге свойств пользователя.
● Мобильный клиент с автономным режимом в этом режиме не пытается автоматически восстановить соединение с основной
информационной базой.
● Включается принудительно, в диалоге свойств информационной базы мобильного приложения или в диалоге свойств пользователя.
● Режим работы, похожий на обычный режим работы, но объекты, включенные в состав автономной конфигурации, используют
автономный сервер (вне зависимости от заданного приоритета), а остальные объекты используют основной сервер.
● Мобильный клиент с автономным режимом пытается восстановить соединение с основной информационной базой. После восстановления
соединения становятся доступными объекты, не входящие в состав автономной конфигурации.
В зависимости от заданных приоритетов и наличия соединения с основной информационной базы, можно следующим образом описать, какой
сервер будет использоваться при выполнении действий на мобильном устройстве:
Далее будут более подробно рассмотрены особенности разработки мобильного клиента с автономным режимом, которые упоминались в данном
разделе.
Для настройки состава автономной конфигурации предназначено свойство Состав автономной конфигурации. Данное свойство является
свойством всей конфигурации.
Как видно на рисунке, предоставляется возможность указать доступность в автономной конфигурации следующих объектов:
● Собственно объекты конфигурации. В состав автономной конфигурации могут входить все объекты конфигурации, которые
поддерживаются мобильной платформой системы «1С:Предприятие».
● Общие модули.
● Планы обмена.
● Подписки на события.
● Общие формы.
● Общие команды.
● Константы.
● Справочники.
● Документы.
● Журнал документов.
● Перечисления.
● Отчеты.
● Обработки.
● Регистры сведений.
● Регистры накопления.
● Основной сервер ‑ в этом случае система «1С:Предприятие» старается использовать для доступа к объекту основной сервер системы.
● Автономный сервер ‑ в этом случае система «1С:Предприятие» старается использовать для доступа к объекту конфигурации автономный
сервер.
● Авто ‑ данное значение трактуется как Основной сервер для типообразующих объектов конфигурации и как значение типообразующего
объекта ‑ если описывается объект, подчиненный типообразующему объекту.
Если для объекта конфигурации, например, справочник Товары указан приоритет Автономный сервер, а для формы элемента этого справочника
указан приоритет Авто, то на реальном мобильном устройстве для формы элемента будет использоваться приоритет Автономный сервер. Если
для справочника Товары изменить значение приоритета на значение Основной сервер ‑ приоритет для формы изменится автоматически.
Если для автономной конфигурации задан неполный состав метаданных, то в автономном режиме это может привести к возникновению
конфликтов. Эти конфликты разрешаются следующим образом:
● Если отсутствующие метаданные используются в объектах автономной конфигурации, то вместо ссылок на такие объекты будут внешние
ссылки в следующих местах автономной конфигурации:
● В общих реквизитах.
● В константах.
● Если ссылки на отсутствующие объекты конфигурации используются в каких-либо других механизмах системы, то такая ссылка будет
удалена из следующих механизмов системы:
● Состав подсистемы.
● Движения документов.
Кроме ручного выделения объектов, которые будут входить в состав автономной конфигурации, в диалоге управления составом автономной
конфигурации доступны следующие команды:
● Подобрать связанные ‑ команда доступна для объекта основной конфигурации, выбранного в состав автономной конфигурации. Данная
команда выбирает объекты основной конфигурации, которые используются в качестве типов реквизитов в выбранном объекте конфигурации.
После окончания работы команды отображается диалог, в котором перечислены (и выбраны) выбраны все требуемые объекты. Если этот
список устраивает ‑ нажатием кнопки ОК весь список будет добавлен в состав автономной конфигурации.
Если выполнить команду рекурсивно, то будут выбраны не только объекты конфигурации, которые используются непосредственно в текущем
объекте, но и все объекты, которые используются в используемых объектах и т. д. Если команда выполнена не рекурсивно, значит, будут
отобраны только те объекты, которые используются только в том объекте, для которого выполнена команда.
● Подобрать связанные для всех ‑ команда доступа в том случае, если есть хотя-бы один объект, включенный в состав автономной
конфигурации. В этом случае для каждого объекта автономной конфигурации выполняется команда Подобрать связанные. В результате
отображается диалог, включающий все подобранные объекты.
Особенностью мобильного клиента с автономным режимом является возможность использования в работе сразу двух серверных частей
прикладного решения: автономный сервер и основной сервер. При вызове система анализирует ряд параметров системы, и на основании
анализа принимает решение, какой сервер будет использоваться для выбора. Анализируется приоритет использования того или иного объекта,
а также заданные режимы работы клиентского приложения. Анализ выполняется как для явного вызова сервера (например, при вызове метода
серверного общего модуля), так и для неявного серверного вызова (например, при открытии формы).
Если серверный вызов инициируется со стороны клиентского приложения, то сервер определяется в момент вызова. Если «внутри» этого
серверного вызова продолжаются серверные вызовы, то сервер не изменяется. Проиллюстрируем сказанное примерами.
Допустим, существует форма справочника Товары, для которой установлен приоритет использования Автономный сервер. Существует
серверный общий модуль СМ1 с приоритетом Основной сервер. Существует серверный модуль СМ2, который не включен в состав автономной
конфигурации.
Давайте рассмотрим, какой сервер будет использоваться при выполнении различных действий:
● Клиентское приложение выполняет открытие формы справочника Товары. Т.к. у формы выбран приоритет Автономный сервер, то для
открытия формы будет выбран автономный сервер. Данные для отображения формой также будут получаться с автономного сервера.
● Если в форме элемента справочника Товары вызывается любой (контекстный или внеконтекстный) серверный метод модуля формы ‑ он
будет исполнен на автономном сервере.
● Если в форме элемента справочника Товары, из клиентского метода модуля формы вызывается метод общего модуля СМ1, то будет вызван
основной сервер или сгенерировано исключение. Вызов будет выполнен, если автономное мобильное приложение подключено к основному
серверу, т. к. у общего модуля СМ1 установлен приоритет Основной сервер.
● Если вызов метода общего модуля СМ1 будет выполнен из серверного метода формы элемента справочника Товары, то будет использоваться
автономный сервер. Это происходит потому, что серверный вызов из серверного вызова использует сервер, который выбран для самого
первого серверного вызова (в нашем примере это автономный сервер).
● Если в форме элемента справочника Товары, клиентский метод пытается вызвать метод общего модуля СМ2, то, аналогично общему модулю
СМ1, вызов будет выполнен только при наличии подключения. Причиной этого будет являться то, что общий модуль СМ2 не указан в составе
автономной конфигурации.
Несмотря не все вышесказанное, могут возникать ситуации, когда необходимо изменить сервер, который будет использоваться для вызова.
Система «1С:Предприятие» позволяет выполнить такую «замену» в некоторых случаях:
● Необходимость вызвать серверный метод основного сервера из метода, который выполняется на стороне автономного сервера. В этом
случае можно использовать свойство глобального контекста ОсновнойСервер. С помощью данного свойства на автономном сервере доступны
серверные общие модули основного сервера. В этом случае вызов будет выглядеть следующим образом:
ОсновнойСервер.ИмяСереверногоОбщегоМодуля.ИмяМетодаОбщегоМодуля().
● Необходимо на стороне клиентского приложения выполнить серверный вызов, который будет использовать строго основной или строго
автономный сервер, вне зависимости от текущих параметров. Для этого существует метод глобального контекста
УстановитьИспользуемыйОсновнойСервер(). В этом случае полезным также может оказаться метод ОсновнойСерверДоступен(), который
позволяет узнать доступность основного сервера.
● На форме клиентского приложения существует реквизит, тип которого не включен в состав автономной конфигурации. В этом случае
открытие формы выбора (или формы элемента) приведет к тому, что будет использован основной сервер, вне зависимости от того, с
использованием какого сервера открыта форма, в которой отображается реквизит.
При разработке формы прикладного решения, которая должна работать в мобильном клиенте с автономным режимом, необходимо учитывать
общие особенности поведения формы на мобильном устройстве, так и некоторые особенности поведения формы в мобильном клиенте с
автономным режимом.
В том случае, если во время работы с открытой формой меняется доступность основного сервера, то поведения системы зависит от того, с
какого сервера выполнялось открытие этой формы:
● Для формы остается доступной команда Закрыть. Если у формы есть аналог в автономной конфигурации ‑ становится доступной команда
Открыть автономно.
● Элементы, ведут себя в зависимости от значения свойства элемента формы ПоведениеПриНедоступностиОсновногоСервера. Свойство
может принимать следующие значения:
● ОтключатьДоступность ‑ элементы с таким значением свойства становятся недоступными после того, как основной сервер становится
недоступным.
● НеИзменятьПоведение ‑ элементы с таким значением свойства остаются доступными. Для элементов, связанных с внешней ссылкой,
при обращении к ним поведение определяется автономной конфигурацией. Стандартная обработка выбора будет приводить к ошибке.
В тоже время стандартная обработка может быть переопределена.
В том случае, если в интерфейсе формы нажимается кнопка Открыть автономно (или вызывается метод ПереоткрытьСДругогоСервера()),
выполняются следующие действия:
● У текущей формы (в которой нажата кнопка) вызывается обработчик события ПередПереоткрытиемСДругогоСервера. В обработчик события
передаются все параметры, которые использовались при открытии текущей формы. Разработчик может модифицировать список параметров.
Если при выходе из события параметр Отказ установлен в значение Истина ‑ форма не будет переоткрыта.
● Создается новая (автономная) форма. При этом срабатывают все серверные события создаваемой формы.
● У новой (только что созданной) формы вызывается обработчик события ПриПереоткрытииСДругогоСервера. В обработчик события
передается переоткрываемая форма и параметры заполнения. Если параметр СтандартнаяОбработка обработчика события установлен в
значение Истина ‑ платформа выполнит перенос данных из «старой» формы в новую форму, опираясь на значение параметра
ПараметрыЗаполнения. Если параметр СтандартнаяОбработка установлен в значение Ложь, это означает, что разработчик самостоятельно
должен выполнить перенос данных из «старой» формы. Для формирования списка копируемых реквизитов можно использовать объект
ПараметрыЗаполненияПриПереоткрытииФормы, а для заполнения данных «новой» формы из данных «старой» ‑ метод
ЗаполнитьПриПереоткрытииСДругогоСервера().
● Вызывается обработчик события ПриОткрытии новой формы и все остальные события, в соответствии с протоколом открытия формы.
● Независимая форма ‑ будет закрыта сразу после завершения открытия новой формы. При этом обработчик события ПриЗакрытии
вызывается, обработчик ПередЗакрытием не вызывается. Если для «старой» формы установлено свойство ОписаниеОповещенияОЗакрытии,
то значение этого свойства будет передано новой форме. Оповещение будет вызвано при закрытии уже новой формы.
● Блокирующая форма ‑ будет закрыта после закрытия новой формы. При этом обработчик события ПриЗакрытии вызывается, обработчик
ПередЗакрытием не вызывается.
● Форма размещена на начальной странице ‑ форма останется на начальной странице. Новая форма будет открыта в независимом режиме.
● Диаграмма,
● Табличный документ,
● Планировщик.
● Данные следующих типов переносятся в том случае, если они (данные) полностью загружены в оперативную память:
● Табличная часть,
● Список значений,
● Таблица значений,
● Дерево значений.
Мобильный клиент с автономным режимом должен выполнять регулярный обмен данными между основной и автономной частями прикладного
решения. При работе системы требуется синхронизация:
● Данные из основной информационной базы должны передаваться в автономную базу. Эти данные должны передаваться в объеме,
достаточном для заполнения данных объектов автономной конфигурации.
● Данные из автономной информационной базы в основную информационную базу. Это те данные, которые вносились в информационную
базу во время автономной работы мобильного приложения.
С точки зрения синхронизации лучше рассматривать обе части решения (автономная и основная части) как разные узлы механизма обмена
данными системы «1С:Предприятие». Тогда требования обмена ложатся на готовую и известную инфраструктуру:
● Для передачи данных между автономной и основной частями информационной базы служит стандартная инфраструктура сообщений или
стандартные инструменты доступа к списку зарегистрированных изменений.
Состав плана обмен должен включать те объекты, которые отмечены в составе автономной конфигурации. Для каждой информационной базы
автономного мобильного приложения, в основной информационной базе должен существовать соответствующий элемент плана обмена.
● Первый запуск мобильный клиента с автономным режимом всегда осуществляется при наличии соединения с основным сервером.
● При первом запуске мобильный клиент с автономным режимом получается с основного сервера автономную конфигурацию и выполняет
инициализацию локальной информационной базы.
● В процессе первого запуска мобильный клиент с автономным режимом должен обратиться к основному серверу и выполнить следующие
действия:
● В автономной информационной базе создать узел обмена, относящийся к основной информационной базе.
● Выполнить первоначальное заполнение автономной информационной базы данными из основной информационной базы.
● Периодически выполнять синхронизацию данных между автономной и основной информационными базами. Данная синхронизация
выполняется по мере необходимости и при возможности. Под «мерой необходимости» понимается такая частота обмена, которая
обеспечивает нужную актуальность данных при сохранении объема передаваемых данных, в одной порции синхронизации, адекватных
используемому каналу связи. Под «возможностью» понимается физическое наличие канала связи между мобильным устройством и
основной информационной базой.
1. При первоначальном заполнении автономной информационной базы не требуется использовать метод СоздатьНачальныйОбраз()
менеджера плана обмена. Необходимо на стороне основной информационной базы сформировать список объектов, которые должны
оказаться в нужном узле плана обмена (фактически ‑ экземпляре автономного мобильного приложения) и вернуть данные на мобильное
приложение. Код автономной конфигурации должен сохранить эти данные в информационную базу (при необходимости сохраняя протокол
работы системы при обмене данными).
1. Штатный механизм обмена данными (с использованием сообщений обмена данными на базе XML-файлов).
2. Вариант обмена данными, когда автономное мобильное приложение само инициирует получение данных из основной информационной
базы, и записывает их в автономную информационной базу, без привлечения файлового механизма сообщений.
Механизм, реализованный с помощью файлов, является более простым для реализации, но обладает определенными накладными расходами:
формирование и передача больших файлов сообщений между мобильным устройством и персональным компьютером. Большой объем
передаваемых данных, ограниченность накопителя мобильного устройства и т. д. ‑ все эти проблемы нужно будет решать разработчику
конфигурации.
Вариант прямого получения данных также имеет некоторые особенности: на все время синхронизации требуется наличие постоянного
канала связи, синхронизация может занимать существенное время и т. д.
Таким образом, в каждом конкретном случае, разработчик должен самостоятельно принимать решение о том, каким образом выполнять
синхронизацию данных между автономной и основной информационными базами.
3. Еще одним важным моментом является тот факт, что при синхронизации используется стандартный механизм XDTO-сериализации. При
этом если при указании состава автономной конфигурации, для какого-либо объекта указано, что состав реквизитов в автономной
конфигурации отличается от состава реквизитов основной информационной базы, то это означает, что механизм
сериализации/десериализации необходимо полностью реализовать самостоятельно. Штатные механизмы сериализации платформы
«1С:Предприятие» в этом случае работать не смогут.
В процессе работы мобильного клиента с автономным режимом могут использовать одновременно и автономный и основной сервер. Прикладное
решение может определить доступность основного сервера, может вызвать основной сервер из кода, выполняющегося на автономном сервере,
но не может вызвать автономный сервер из кода, выполняющего на основном сервере.
Для определения доступности основного сервера предназначен метод глобального контекста ОсновнойСерверДоступен().
При нахождении на автономном сервере, предоставляется возможность вызвать метод основного сервера, который доступен в серверном общем
модуле основного сервера. Для этого существует свойство глобального контекста ОсновнойСервер. Вызов будет выглядеть следующим образом
ОсновнойСервер.ИмяОбщегоМодуля.ИмяМетода(). Если основной сервер недоступен ‑ будет выброшено исключение.
Когда клиентской части автономного мобильного приложения требуется вызвать сервер, то вызов будет выполнен в соответствии с
установленными приоритетами автономной конфигурации. Однако система предоставляет возможность явно указать используемый сервер с
помощью метода УстановитьИспользуемыйСервер().
● Если при вызове метода явно указывается используемый сервер ‑ устанавливается использование. Под явным указанием сервера
понимаются значения системного перечисления ИспользуемыйСервер.
● Если при вызове метода указано значение Неопределено ‑ устанавливается тот режим вызова сервера, который был до последней
установки используемого сервера.
● При выходе из метода, в котором изменялся используемый сервер ‑ устанавливается использование того сервера, который был до входа в
метод.
Рассмотрим пример:
Копировать в буфер обмена
УстановитьИспользуемыйСервер(ИспользуемыйСервер.Основной); // строка 1
УстановитьИспользуемыйСервер(ИспользуемыйСервер.Автономный); // строка 2
УстановитьИспользуемыйСервер(Неопределено); // строка 3
После строки строка 1, в качестве используемого сервера будет установлен основной сервер. После строки строка 2, в качестве используемого
сервера будет установлен автономный сервер.
После строки строка 3 будет использован сервер, который был до использования последней установки сервера. Таким образом, будет
установен основной сервер, т. к. предпоследняя установка используемого сервера (строка 1) выбирала основной сервер.
Первый запуск мобильного клиента с автономным режимом невозможен в автономном режиме. Для первого запуска всегда требует устойчивый
канал связи с основной информационной базой, т. к. при первом запуске выполняется загрузка автономной конфигурации.
Далее, при каждом запуске клиентского приложения, а также при создании/восстановлении соединения между мобильным приложением и
основным сервером, выполняется проверка наличия обновления автономной конфигурации. Могут наблюдаться один из следующих сценариев:
2. До подключения к основному серверу, клиент работал в автономном режиме с возможностью подключения к основному серверу:
● Если пользователь соглашается с предложением, то обновление автономной конфигурации скачивается на мобильное устройство,
клиентское приложение перезапускается и после перезапуска выполняется обновление автономной информационной базы скачанной
конфигурацией.
● Если пользователь отказывается от обновления, то клиентское приложение продолжает работу со старой версией автономной
конфигурации, без возможности подключения к основному серверу (фактически ‑ в автономном режиме).
3. Если обновление конфигурации обнаруживается во время очередного подключения к основному серверу (без автономной работы), то
выполняется завершение текущего сеанса и дальнейшая работа выполняется по предыдущему сценарию работы.
Внешние ссылки ‑ это ссылки на объекты, которые не включены в состав автономной конфигурации, но сами эти ссылки используются в
автономных объектах. В качестве внешних ссылок могут выступать ссылки на любые объекты конфигурации, в том числе и на те, которые не
доступны на мобильном устройстве. На мобильном устройстве не поддерживается какая-либо работа с автономными ссылками: получение
значений реквизитов, получение объекта и т. д. Фактически, внешние ссылки предназначены для отображения представления реальных данных
в соответствующих полях формы. В результате пользователь не будет волноваться из-за «потери» данных.
Если поле формы отображает данные, которые являются внешней ссылкой, то:
● Если сохраненного представления внешней ссылки нет на мобильном устройстве, то в виде представления выступает сообщение о
недоступности информации.
Если команда не выбрана в состав автономной конфигурации, то такая команда будет недоступна в автономном режиме. Если команда
включена в состав автономной конфигурации, то в ее (команды) доступность в автономном режиме определяется свойством команды Поведение
при недоступности основного сервера. Если это свойство установлено в значение Авто, то это трактуется как значение Не изменять поведение.
Если для команды недоступно редактирование свойств, то для них используется значение Не изменять поведение.
29.6.7.4. Пользователи
Мобильный клиент с автономным режимом не поддерживает работу с пользователями. В то же время, при запуске приложения выполняется
запрос пользователя и пароля. Аутентификация будет выполняться основным сервером. Если при следующем запуске приложения будет указан
пользователь, отличающийся от пользователя, который был указан при первом (после создания информационной базы) входе в базу, то будет
выдано сообщение об ошибке. Таким образом, если на одном мобильном устройстве с одной основной информационной базой работают
несколько пользователей ‑ для каждого пользователя необходимо создать собственную информационную базу (приложение) на мобильном
устройстве.
Если у пользователя, от имени которого выполняется вход в основную базу, был изменен пароль, то автономная часть узнает об этом, только
после успешной аутентификации на основном сервере.
29.6.7.5. История
История хранится в информационной базе и на основном сервере и на автономном. Если мобильное устройство имеет доступ к основному
серверу ‑ история сохраняется сразу в обоих информационных базах. Если мобильное устройство не имеет доступ к основному серверу ‑
история сохраняется только в автономной информационной базе. После получения доступа к основному серверу выполняется объединение
историй и сохранение их в обоих информационных базах.
29.6.7.6. Избранное
Избранное хранится в информационной базе и на основном сервере и на автономном. Если мобильное устройство имеет доступ к основному
серверу ‑ избранное сохраняется сразу в обоих информационных базах. Если мобильное устройство не имеет доступ к основному серверу ‑
избранное сохраняется только в автономной информационной базе. После получения доступа к основному серверу выполняется объединение
списка избранного и сохранение его в обоих информационных базах.
● Через фирменный магазин приложений 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С:Предприятия» для разработчика автоматически обновит конфигурацию на мобильном устройстве.
● Мобильный клиент разработчика в случае разработки приложения, которое работает в мобильном клиенте.
Собственно алгоритмы формирования инструментов разработчика одинаковы и для мобильной платформы и для мобильного клиента. Различия
присутствуют только в именах файлов, которые необходимо использовать в том или ином случае. Так, если для подготовки мобильной
платформы разработчика для ОС iOS необходимо из дистрибутива мобильной версии «1С:Предприятия» (файл mobile.zip) получить файл
prjios.zip, то в случае мобильного клиента следует использовать файл prjios_client.zip.
В таблице приведено соответствие имен файлов для мобильной платформы и мобильного клиента.
Android
Мобильная платформа 1cem-arm.apk
1cem-arm64.apk
1cem-x86.apk
1cem-x86_64.apk
Мобильный клиент 1cem-client-arm.apk
1cem-client-arm64.apk
1cem-client-x86.apk
1cem-client-x86_64.apk
Мобильный клиент с автономным режимом 1cem-standalone-arm.apk
1cem-standalone-arm64.apk
1cem-standalone-x86.apk
1cem-standalone-x86_64.apk
iOS
prjios_sim.zip
prjios_client_sim.zip
prjios_standalone_sim.zip
Windows
1cem-x64.appx
1cem-x86.appx
Мобильный клиент 1cem-client-arm.appx
1cem-client-x64.appx
1cem-client-x86.appx
1cem-standalone-x64.appx
1cem-standalone-x86.appx
В данной таблице:
● суффикс -arm, -arm64, -x86, -x64, -x86_64 означает архитектуру используемого процессора;
● суффикс -sim означает вариант, предназначенный для использования в эмуляторе устройства (только для разработки под ОС iOS).
Для разработки мобильного приложения для ОС iOS необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера фирмы Apple (далее ‑ Mac) с установленной операционной системой OS X
10.8 и выше.
● На компьютере Mac должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● На этом компьютере необходимо установить средство разработки Xcode версии 4.5 и выше (https://developer.apple.com/xcode/).
● Для работы необходимо мобильное устройство на iOS, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной версии «1С:Предприятия» для разработчика на мобильное устройство, работающее под управлением iOS, необходимо
выполнить следующие действия:
● Открыть проект мобильной версии «1С:Предприятия» для разработчика в системе Xcode (двойным щелчком мыши по файлу 1cem.xcodeproj
или выбрать файл 1cem.xcodeproj с помощью команды File ‑ Open в системе Xcode);
● В открывшемся окне, в панели слева выбрать подключенный телефон (отмечен зеленым маркером);
● Средство Organizer запросит необходимые для телефона сертификаты и provisioning profile с сайта Apple и установит их на телефон
автоматически. Потребуется ввести пароль разработчика, полученный при регистрации в iOS Developer Program.
● С помощью команды меню Xcode Product ‑ Edit Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся
диалоге:
● Мобильная версия «1С:Предприятия» будет передана на мобильное устройство, запущена и ее иконка появится в списке установленных
приложений мобильного устройства.
● Мобильное устройство можно отключить от компьютера Mac и далее запускать мобильную версию «1С:Предприятия» нажатием на иконку
«1С:Предприятие» в списке приложений мобильного устройства. Если в момент отключения на мобильном устройстве была запущена
мобильная версия «1С:Предприятия» для разработчика, которая запущена с помощью Xcode, то она будет остановлена.
Для разработки мобильного приложения для ОС Android необходимо выполнить следующие требования:
● Проверить, что нужные компоненты установлены, можно с помощью Android Studio. Для этого в стартовом окне необходимо выбрать
Configure ‑ SDK Manager. Для удобства работы можно включить флажок Show Package Details в открывшемся окне.
● На закладке SDK Platforms можно проверить наличие нужных версий Android SDK.
● Затем на закладке SDK Tools необходимо указать Android SDK Build-Tools, Android SDK Platform-Tools и Android SDK Tools. Рекомендуется
устанавливать все инструменты (Tools) и собственно SDK согласованно. В этом случае все версии будут совместимы друг с другом.
● После выполненных установок нажатие кнопки OK или Apply приведет к запуску процесса установки необходимых компонентов. Перед
началом процесса установки Android Studio запросит подтверждение установки выбранных компонентов (с указанием всего списка).
● На компьютере должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● Для работы необходимо мобильное устройство на Android, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной версии «1С:Предприятия» для разработчика на мобильное устройство, работающее под управлением Android,
необходимо выполнить следующие действия:
● Неизвестные источники;
Где, Каталог платформы ‑ каталог, в котором расположен соответствующий файл с мобильной версией «1С:Предприятия». Если мобильная
версия «1С:Предприятия» уже установлена на мобильное устройство, то данная команда выполнит ее переустановку.
● Мобильная версия «1С:Предприятия» будет передана на мобильное устройство и ее иконка появится в списке установленных приложений.
● Мобильное устройство можно отключить от компьютера и далее запускать систему нажатием на иконку «1С:Предприятие» в списке
приложений мобильного устройства.
Для установки мобильной версии «1С:Предприятия» для разработчика можно воспользоваться командой конфигуратора:
● Для мобильной платформы: Главное меню ‑ Конфигурация ‑ Мобильное приложение ‑ Использование Android debug bridge ‑ Установить
мобильную платформу.
● Для мобильного клиента: Главное меню ‑ Конфигурация ‑ Мобильный клиент ‑ Использование Android debug bridge ‑ Установить мобильный
клиент.
В этом случае надо будет выполнить дополнительную настройку конфигуратора (подробнее см. здесь). Установку мобильной платформы можно
выполнить или на физическое мобильное устройство, подключенное к компьютеру или на эмулятор устройства, созданный с помощью
менеджера виртуальных устройств Android. Менеджер виртуальных устройств может быть запущен из Android Studio: Главное меню ‑ Tools ‑
Android ‑ AVD Manager.
Для разработки мобильного приложения для ОС Windows необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера с установленной операционной системой Windows 8.1 и выше.
● Для работы необходимо устройство на Windows (планшет или компьютер с сенсорным экраном), соответствующее системным требованиям
(подробнее см. здесь).
Для установки мобильной версии «1С:Предприятия» для разработчика на устройство, работающее под управлением Windows, необходимо
выполнить следующие действия:
● Извлечь из файла поставки мобильной версии «1С:Предприятия» файл с необходимым дистрибутивом нужной архитектуры.
● Выполнить команду:
Копировать в буфер обмена
Show WindowsDeveloperLicenseRegistration
● Выполнить команду:
Копировать в буфер обмена
Add AppxPackage <Каталог>\<имя файла>.appx
При этом:
ВНИМАНИЕ! При работе с мобильным клиентом, действия, указанные в данном разделе, выполнять не требуется.
Чтобы мобильное приложение было доступно мобильной платформе, необходимо выполнить публикацию мобильного приложения на веб-
севере. Фактически, публикация делится на две части:
● Подготовка инфраструктуры для работы и начальная выгрузка конфигурации мобильного приложения ‑ выполняется один раз.
Для подготовки инфраструктуры служит команда Конфигурация ‑ Мобильное приложение ‑ Публиковать…. В открывшемся диалоге следует
указать флажок Создавать виртуальный каталог на веб-сервере. Если флажок не установлен, то будут недоступны реквизиты Имя и Каталог, а
также при нажатии кнопки Опубликовать не будет выполняться создание виртуального каталога на веб-сервере.
● Имя ‑ определяет имя виртуального каталога. Это имя будет участвовать в URL конфигурации мобильного приложения для указания на
мобильном устройстве при создании информационной базы.
● Веб-сервер ‑ определяет используемый веб-сервер. Если используется веб-сервер Microsoft Internet Information Services, то становится
возможным указание флажка Использовать аутентификацию операционной системы на веб-сервере.
● Каталог ‑ указывает физический каталог на диске, в котором будет находиться файл конфигурации мобильного приложения в виде xml-
файла и куда будет отображен виртуальный каталог веб-сервера.
Флажок Обновлять мобильное приложение при обновлении конфигурации базы данных управляет возможностью автоматического обновления
конфигурации мобильного приложения при обновлении конфигурации базы данных. Если флажок установлен ‑ обновление будет выполняться.
Операцию обновления конфигурации также можно выполнить принудительно, с помощью команды Конфигурация ‑ Мобильное приложение ‑
Обновить публикуемое приложение. Если к моменту вызова данной команды публикация мобильного приложения не выполнялась ‑ будет
открыт диалог публикации, описанный выше.
Для выполнения собственно публикации необходимо нажать кнопку Опубликовать. При этом выполняются следующие действия:
● Если установлен флажок Создавать виртуальный каталог на веб-сервере, то создается виртуальный каталог на веб-сервере;
● Предлагается выгрузить конфигурацию мобильного приложения в каталог (указанный в реквизите Каталог диалога публикации);
● Если конфигурация информационной базы не соответствует редактируемой конфигурации ‑ предлагается выполнить обновление
конфигурации базы данных. Однако эту операцию можно не выполнять, если требуется опубликовать именно конфигурацию базы данных;
● Если ошибок нет, то выполняется выгрузка конфигурации информационной базы в файл, в противном случае выгрузка не производится.
Файл с конфигурацией мобильного приложения, выгруженный с помощью команды Публиковать…, имеет фиксированное имя 1cema.xml. Поиск
(и обновление) именно этого файла выполняется при выполнении команды Обновить публикуемое приложение. При создании виртуального
каталога, файл конфигурации (1cema.xml) устанавливается в качестве его (каталога) страницы по умолчанию. Это позволяет в диалоге
создания информационной базы на мобильном устройстве указывать URL в сокращенном виде.
Кнопка Отключить диалога публикации мобильного приложения выполняет отмену публикации: удаляет виртуальный каталог на веб-сервере и
физический каталог.
● 1Cv8.1CM ‑ файл, предназначенный для ускорения создания информационной базы. Данный файл содержит собственно конфигурацию.
● Если конфигурация содержит внешние компоненты, то в каталоге публикации создается структура каталогов следующего вида (все
каталоги и файлы являются необязательными):
● 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.
● .1CM ‑ application/octet-stream.
● .so ‑ application/octet-stream.
● .apk ‑ application/octet-stream.
Запуск мобильного приложения осуществляется непосредственно на мобильном устройстве или из конфигуратора. На устройстве должна быть
установлена мобильная версия «1С:Предприятия» для разработчика.
Запуск из конфигуратора возможен при одновременном выполнении двух условий: разработка выполняется с использованием ОС Android и
выполнена соответствующая настройка конфигуратора (см. здесь).
Если мобильное приложение запущено с помощью мобильной платформы разработчика и для приложения установлен флажок Перезапуск из
конфигуратора (см. здесь), то существует возможность перезапускать мобильное приложение из конфигуратора. Это можно сделать с помощью
команды главного меню Отладка ‑ Начало отладки ‑ Мобильное приложение: начать отладку или Отладка ‑ Начало отладки ‑ Мобильный клиент:
начать отладку.
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация
отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует
выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы
данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
Используемые в конфигурации внешние компоненты также будут размещены в каталоге, на который отображается виртуальный каталог веб-
сервера. Будут копироваться только те файлы внешней компоненты, которые предназначены для использования на ОС Android и iOS (если
таковые существуют в составе архива с внешней компонентой).
Мобильное приложение выполняет проверку обновления при открытии в том случае, если установлен флажок Перезапуск из конфигуратора в
свойствах мобильного приложения на мобильном устройстве. Если этот флажок сброшен, то при открытии наличие обновлений не проверяется.
Однако такую проверку можно выполнить вручную (см. здесь).
29.7.4.3. Запуск и перезапуск мобильного приложения при использовании Android debug bridge
Запуск и перезапуск мобильного приложения можно выполнять с помощью конфигуратора. Это можно сделать с помощью команды главного
меню Отладка ‑ Начало отладки ‑ Мобильное приложение: начать отладку или Отладка ‑ Начало отладки ‑ Мобильный клиент: начать отладку.
Чтобы при этом использовался Android Debug Bridge, конфигуратора должен быть соответствующим образом настроен (см. здесь). Кроме того,
конфигурация должна быть опубликована в файловой системе (публикация на веб-сервере в этом случае не является обязательной) (см.
здесь).
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация
отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует
выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы
данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
При работе с помощью Android Debug Bridge, используемые в конфигурации внешние компоненты также будут скопированы на используемое
мобильное устройство. Будут копироваться только те файлы внешней компоненты, которые предназначены для использования на ОС Android
(если таковые существуют в составе архива с внешней компонентой).
После перезапуска мобильной платформы разработчика будет обнаружена новая конфигурация и будет выдано предложение выполнить
обновление.
Отладка прикладного решения на мобильном устройстве возможна только при использовании протокола отладки HTTP. Мобильное приложение,
функционирующее под управлением ОС Android, можно запускать в режиме отладки непосредственно из конфигуратора, с использованием
Android Debug Bridge (см. здесь). Мобильное приложение, функционирующее под управлением ОС iOS или ОС Windows, нельзя запустить в
режиме отладки непосредственно из конфигуратора. Подробное описание настройки мобильных приложений см. здесь.
Для отладки приложения используются два параметра в свойствах информационной базы мобильного приложения:
● Отладка разрешена ‑ указывает, будет в данном мобильном приложении разрешена отладка или не будет.
● Информационная база запускается непосредственно из конфигуратора ‑ в этом случае в качестве адреса сервера отладки выступает
адрес конфигуратора, выполняющего запуск мобильного приложения, применимо только для работы через Android Debug Bridge;
● Для конфигурации установлен флажок Перезапуск из конфигуратора ‑ в этом случае адрес сервера отладки получается из публикации
мобильного приложения.
● В открывшемся окне ввести URL веб-сервера, на котором опубликовано мобильное приложение (см. здесь) в поле Адрес;
● При необходимости, следует указать имя пользователя и пароль для авторизации на веб-сервере, на котором опубликовано мобильное
приложение и нажмите кнопку Загрузить;
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в
список приложений следует выбрать команду Список приложений в главном меню приложения.
Свойства приложения изменяются в специальном окне. В зависимости от операционной системы, доступ к этой команде выполняется по-
разному:
● Для ОС iOS: в правой части строки с именем нужного приложения нажмите картинку с изображением знака больше.
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном
меню выберите команду Изменить.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном
меню выберите команду Изменить.
В открывшемся окне можно изменять свойства приложения, которые указывались при его создании: наименование приложения, URL
расположения конфигурации, имя и пароль пользователя для доступа к веб-серверу, на котором располагается конфигурация мобильного
приложения.
● Проверить наличие новой версии конфигурации мобильного приложения на веб-сервере. Для этого необходимо нажать кнопку Проверить
обновления. В случае наличия новой версии конфигурации будет предложено выполнить обновление мобильного приложения.
● Настроить возможность автоматического обновления и перезапуска мобильного приложения в случае, если на веб-сервере будет
обнаружена новая версия конфигурации (см. здесь). Для этого следует изменить состояние флажка Перезапуск из конфигуратора.
● Настроить возможность отладки (флажок Отладка разрешена) и указать адрес отладчика (в поле Адрес отладчика). Подробнее про отладку
см. здесь.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в
список приложений следует выбрать команду Список приложений в главном меню приложения.
Для удаления приложения следует выбрать команду Удалить и подтвердить свое действие. В зависимости от операционной системы, доступ к
этой команде выполняется по-разному:
● Для ОС iOS: нажмите кнопку Изменить, затем нажмите картинку в левой части строки с именем удаляемого приложения. Затем в правой
части этой же строки нажмите кнопку Удалить.
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном
меню выберите команду Удалить.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном
меню выберите команду Удалить.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в
список приложений следует выбрать команду Список приложений в главном меню приложения.
Для того, чтобы опубликовать мобильное приложение в магазине приложений, его необходимо собрать с использованием сборщика мобильных
приложений. Мобильную версию системы «1С:Предприятие» для разработчика нельзя опубликовать в магазине приложений.
Подробное описание настройки и использования сборщика мобильных приложений см. здесь. Описание публикации мобильного приложения в
магазине приложений с использованием сборщика мобильных приложений см. здесь (только для ОС iOS и Android). Описание процесса
публикации мобильного приложения вручную необходимо получить в документации разработчика соответствующего магазина приложений.
Сборщик приложений для мобильных устройств предназначен для хранения и компиляции различных артефактов мобильного приложения в
единый файл, пригодный для публикации в магазине приложений или непосредственного использования на устройстве. В состав этих
артефактов входят:
● Графическая информация.
● Мультимедийная информация.
● Внешние компоненты.
Сборщик позволяет собирать как мобильные приложения, так и приложения мобильных клиентов. В обоих случаях одно собранное мобильное
приложение позволяет использовать несколько конфигураций.
Сборщик приложений для мобильных устройств функционирует только под управлением ОС Windows. Работа под управлением других
операционных систем не поддерживается.
Сборка поддерживается для всех платформ, на которых работает мобильная версия системы «1С:Предприятие», при этом предоставляется
возможность отключать сборку под операционные системы, которые не требуются в каждом конкретном случае. Однако в рамках одной
операционной системы вариативность сборки не поддерживается. Это означает, что для ОС Android и Windows всегда собираются все
архитектуры, без возможности управлять этим.
● ОС iOS: файл проекта для самостоятельной сборки в Xcode, исполняемый файл (.ipa-файл) и мобильное приложение для работы в
эмуляторе iOS. Возможность сборки .ipa-файла регулируется настройкой.
● ОС Android: исполняемые файлы (.apk-файлы) для архитектур ARM, ARM64, x86 и x86-64.
Настройка сборщика состоит из нескольких этапов, самыми важными из которых являются настройка параметров сборочной инфраструктуры и
параметров поставщика прикладных решений. Если все этапы настройки не выполнены ‑ выполнить сборку мобильного приложения будет
невозможно.
4. Загружаются файлы с профилями обеспечения (provisioning profile) в том случае, если планируется использовать push-уведомления для ОС
iOS (см. здесь).
5. Загружается один или несколько вариантов различной аудиоинформации для мобильных приложений (см. здесь).
6. Загружается один или несколько вариантов различной графической информации для мобильных приложений (см. здесь).
7. Загружаются мобильные конфигурации, из которых будут собираться мобильные приложения (см. здесь).
После выполнения всех шагов можно выполнять сборку мобильных приложений (см. здесь) и публикацию их в магазинах приложений (см.
здесь).
Первым этапом следует сформировать необходимое окружение на компьютере, на котором будет выполняться сборка приложений для
мобильных устройств. В дальнейшем этот компьютер будет называться сборочный сервер.
Окружение формируется в зависимости от того, для каких операционных систем будет выполняться сборка:
● Общие требования:
● ОС Android:
● Не поддерживается использование версий SDK и необходимых компонентов (Tools, Build tools), которые не достигли стадии релиза (beta,
release candidate и т. д.).
● ОС Windows:
● Windows SDK.
● В случае необходимости собирать приложения для работы на ОС Windows, сборочный сервер должен функционировать под управлением
ОС Windows 8.1 и старше.
После установки всех необходимых компонент, необходимо настроить параметры сборщика с помощью диалога Сервис ‑ Настройки параметров
сборщика.
Параметр Рабочий каталог и кеш сборщика указывает путь к каталогу, который используется для собственно сборки и хранения кешей
используемых компонентов. Каталог может занимать существенный объем дискового пространства ‑ несколько гигабайт. Очистка этого каталога
(между процессами сборки) не влияет на результат сборки. Каталог следует указывать такой, чтобы путь содержал только латинские
символы. Пользователь, от имени которого работает сервер «1С:Предприятия», используемый для сборки, должен иметь полный доступ в
рабочий каталог сборщика.
Требуемая версия Android SDK определяется той версией мобильной платформы, которая используется для сборки. Версия используемая для
сборки, определяется по значению атрибута Android:targetSdkVersion элемента uses-sdk файла AndroidManifest.xml используемой мобильной
версии «1С:Предприятия». Сборщик позволяет собирать мобильные приложения для ОС Android с использованием Gradle, при этом также
возможна сборка с использованием Apache Ant. Мобильная версия «1С:Предприятия» версии 8.3.10 и старше может быть собрана только с
использованием Gradle.
● Параметры Android SDK (версия 25 и младше), а также параметр Apache ANT (для SDK версии 25 и младше) необходимо указывать только в
том случае, если для сборки используется мобильная версия «1С:Предприятия», которая может быть собрана только с помощью Apache ANT
(версия 8.3.9 и младше). Информация об этом доступна в карточке загруженной мобильной версии «1С:Предприятия» в поле Сборка для
Android выполняется с помощью. Там же присутствует указание на минимальную версию Android SDK, которая требуется при сборке
приложения, работающего с указанной мобильной версией «1С:Предприятия». Если мобильная версия «1С:Предприятия» требует для своей
сборки:
● Gradle ‑ мобильное приложение, использующее такую версию, невозможно собрать с использованием Android SDK версии 25 и младше.
● Apache Ant ‑ мобильное приложение, использующее такую версию, невозможно собрать с использованием Android SDK версии 26 и
старше.
● Для универсальной сборки (и с использованием Gradle и с использованием Apache Ant) настройку следует выполнять следующим образом:
● параметр Android SDK (версия 26 и старше) должен указывать на каталог, в который установлен Android SDK из состава Android Studio.
● параметр Android SDK (версия 25 и младше) должен указывать на каталог, в который установлен «старый» вариант Android SDK.
Параметр Apache ANT (для SDK версии 25 и младше) должен быть указан только в случае указания параметра Android SDK (версия 25 и
младше).
● Следует помнить, что «старый» вариант Android SDK Tools (работающий с помощью Apache Ant) может быть получен только с помощью
прямой ссылки (http://dl-ssl.ggle.cm/Android/repsitry/tls_r25.2.5-Windows.zip).
Если требуется собирать исполняемый файл для работы на ОС iOS, то следует установить флажок Собирать пакет приложения (.ipa) на
компьютере Apple и задать параметры доступа к этом компьютеру. Корректность указания параметров можно проверить с помощью гиперссылки
Проверить подключение. Если все настройки выполнены корректно, то после нажатия на гиперссылку откроется окно, в котором указана версия
операционной системы на компьютере Apple. Если флажок Собирать пакет приложения (.ipa) на компьютере Apple сброшен, то результатом
сборки для ОС iOS будет архив проекта для самостоятельной сборки приложения с помощью Xcode и мобильное приложение для работы в
эмуляторе.
Для того чтобы сборщик приложений для мобильных устройств мог выполнять какие-либо действия на стороне компьютера Apple, этот
компьютер необходимо настроить. Для этого необходимо выполнить следующие действия:
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) компьютера Apple доступен для компьютера, на котором функционирует серверная
часть сборщика приложений для мобильных устройств.
Сборщик мобильных приложений позволяет собирать мобильные приложения, которая работают как под управлением ОС Windows версии 8.1
(включая Windows Phone) так и под управлением Windows 10.Поддерживаемые ОС определяются версией платформы «1С:Предприятие»,
которая используется для сборки:
● Версия 8.3.13 и младше ‑ поддерживается ОС Windows 8.1, Windows Phone 8.1 и Windows 10.
Соответственно, скачивать и устанавливать Windows SDK необходимо только те, которые реально будут использоваться для сборки мобильных
приложений. Оба параметра (Путь к Windows 8.1 SDK и Путь к Windows 10 SDK) необходимо указывать только в том случае, когда планируется
выполнять сборку мобильных приложения, которые используют весь спектр мобильных версий «1С:Предприятия». В противном случае
рекомендуется устанавливать только Windows 10 SDK (и заполнять только один параметр настроек сборщика ‑ Путь к Windows 10 SDK).
В силу того, что файлы мобильной версии «1С:Предприятия» и собранных мобильных приложений занимают существенный объем, реализована
возможность автоматической очистки информационной базы от устаревших версий как мобильной версии, так и собранных приложений. Для
этого сборщик фиксирует дату загрузки (для мобильной версии «1С:Предприятия») и последней сборки (для мобильного приложения). Затем
вычисляются даты удаления (отдельно для файлов мобильной версии «1С:Предприятие» и результатов сборки) и удаляются все объекты, дата
изменения которых меньше получившейся даты удаления. Время хранения объектов настраивается отдельно для файлов мобильной версии
«1С:Предприятие» и файлов результатов сборки. Эта настройка выполняется с помощью следующих параметров:
● Продолжительность хранения файлов мобильной версии, дней. Значение по умолчанию ‑ 180 дней.
Если любой из параметров, описывающих продолжительность хранения, будет установлен в значение 0, то для соответствующих объектов
автоматическое удаление не будет использоваться.
● Файлы мобильной версии «1С:Предприятия» можно повторно загрузить из файла mobile.zip соответствующей версии.
Следующим этапом является настройка параметров поставщика собираемых мобильных приложений. Для этого необходимо открыть диалог
Сервис ‑ Настройка параметров поставщика.
Вначале следует указать, для каких мобильных операционных систем будут собираться приложения в сборщике. Для этого предназначена
группа флажков Новые прикладные решения данного поставщика собирать. Установка каждого флажка делает доступной закладку с
параметрами для соответствующей операционной системы.
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет
формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения.
Для сборки мобильного приложения необходимо создать (или импортировать) ключ разработчика (группа Ключ разработчика). С помощью этого
ключа подписывается собранное приложение.
Если собранное мобильное приложение будет публиковаться в магазин приложений непосредственно из сборщика, с помощью команд группы
Доступ к консоли разработчика следует получить требуемый доступ.
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет
формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения.
На закладке Сертификаты необходимо указать те сертификаты, которые будут использоваться для подписи собранного приложения (.ipa-
файла). При нажатии кнопки Добавить происходит загрузка списка сертификатов с компьютера Apple. В связи с этим, если не настроено
подключение к компьютеру Apple, добавить сертификат будет невозможно. Сертификаты используются только в том случае, если сборка
выполняется с помощью пакета Xcode версии 8 и младше.
Закладка Доступ к iTunes Connect описывает имена пользователей и пароли доступа в iTunes Connect. Эти параметры используются при
необходимости загрузки собранных приложений в магазин приложений (AppStore).
На закладке Группы разработчиков позволяет указать идентификаторы групп разработчиков, соответствующих учетным записям на портале
https://developer.apple.com/. Для каждой группы разработчиков предоставляется возможность указать способ распространения приложений по
умолчанию. Указанное значение будет использоваться при настройке параметров собираемых мобильных приложений для ОС iOS.
Необходимо указать префикс идентификатора мобильного приложения. В дальнейшем полный идентификатор мобильного приложения будет
формироваться из префикса, который указывается в параметрах поставщика и собственно идентификатора приложения. Следует помнить, что
префикс назначается магазином Windows Store, а не вводится вручную. Для получения данного префикса следует нажать на ссылку Перейти к
Windows Store и получить идентификатор с помощью веб-интерфейса магазина приложений.
Поле Идентификатор поставщика в Windows Store автоматически заполняется при установке сертификата разработчика. Поле Имя поставщика в
Windows Store можно получить из поля Пакет/Свойства/Отображаемое имя издателя. Данное поле доступно в описании любого приложения, с
помощью команды Управление приложениями ‑ Удостоверение приложения.
Установка сертификата разработчика выполняется с помощью команды Установить ключи разработчика. Перед выполнением команды
необходимо ввести пароль для доступа к ключу в поле Пароль для приватного ключа разработчика. Должны быть выбраны и будут загружены
два файла: с расширением «.cer» (собственно сертификат) и с расширением «.pvk» (приватный ключ для этого сертификата). Информацию по
получению ключа разработчика можно здесь: https://msdn.microsoft.com/en-us/library/windows/desktop/jj835832(v=vs.85).aspx (на английском
языке).
Сборка мобильного приложения выполняется на стороне сервера. На компьютере (или компьютерах), на котором исполняется серверная часть
«1С:Предприятия» сборщика мобильных приложений, должно быть установлено следующее программное обеспечение (по необходимости):
4. Пакет PuTTY (используются утилиты pscp и plink). Пакет можно скачать отсюда: http://www.chiark.greenend.org.uk/~sgtatham/putty
/download.html.
Для того, чтобы собрать любое мобильное приложение, необходимо загрузить в сборщик требуемую мобильную версию «1С:Предприятия».
Мобильная версия распространяется в файлах mobile_A_B_C_D.zip. Где A_B_C_D ‑ это полный номер мобильной версии. Так, для версии
8.3.12.64 имя файла будет выглядеть следующим образом ‑ mobile_8_3_12_64.zip. Для загрузки необходимо использовать именно этот файл.
Сборщик загрузит только те файлы, которые требуются для сборки. Фактический номер загружаемой версии определяется по файлу version.txt,
который расположен в корне архива.
Сборщик мобильных приложений поддерживает как полную, так и частичную загрузку мобильной версии. В процессе загрузки определяется
следующая информация:
● Требуемый номер версии Android SDK, который будет использоваться при сборке для ОС Android.
Таким образом, уже при загрузке мобильной версии становится ясно, что и каким образом можно собрать с помощью загруженной версии.
В данном примере загружена версия 8.3.12.64, для сборки под Android, с использованием данной версии, будет требоваться Android SDK версии
27 и сборка будет выполняться с помощью Gradle. Также, данная мобильная версия может быть использована для сборки как мобильных
приложений, так и мобильных клиентов для всех поддерживаемых операционных систем.
В любой момент времени можно повторно загрузить мобильную версию с помощью команды Загрузить платформу. При повторной загрузке не
проверяется, что загружается та же версия, что и была загружена ранее. Поэтому такую загрузку следует выполнять аккуратно.
Если мобильная версия платформы устарела и удалена, то в нижней части формы будет присутствовать надпись Файлы мобильной платформы
удалены (устарели). В форме списка также будет присутствовать флажок, оповещающий об этом.
При загрузке мобильной версии в сборщик мобильных приложений рекомендуется следовать следующим рекомендациям:
● Выполнять загрузку в точности того файла, который загружен с ресурсов фирмы «1С». Никакой предварительной обработки файла
mobile_<номер версии>.zip не требуется. Сборщик загрузит только те файлы, которые ему требуются.
● При смене третьей цифры номера мобильной версии, загружать файл новой мобильной версии рекомендуется только после обновления на
ту версию сборщика, который поставляется в дистрибутиве версии. Если сборщик не будет обновлен ‑ его поведение, в общем случае, будет
неопределено. Например, мобильная версия 8.3.13 поставляется со сборщиком версии 2.0.9. Мобильная версия 8.3.14 поставляется со
сборщиком 2.0.10. Загружать мобильную версию 8.3.14 следует только после того, как сборщик мобильных приложений обновлен до версии
2.0.10.
Профили обеспечения (provisioning profiles) ‑ это специальные файлы, которые обеспечивают доступ мобильному приложению к некоторым
возможностям iOS. Загруженные профили обеспечения используются для сборки .ipa-файлов. Загруженный профиль обеспечения также можно
загрузить повторно через форму элемента и команду Загрузить профиль обеспечения.
29.8.3.1.3. Аудиоинформация
Данный справочник хранит аудиоинформацию, которая будет использоваться при сборке мобильных приложений. Разработчик может загрузить
несколько наборов аудиоинформации. Сборщик не накладывает каких-либо ограничений на сочетание набора аудиоинформации и различных
мобильных приложений. Для загрузки необходимо использовать команду Загрузить аудиоинформацию.
В загружаемом архиве должно располагаться каталоги: iOS, Android и Windows (регистр символов важен). Имена файлы в этих каталогах
должны состоять только из символов ".", "_", цифр и латинских букв в нижнем регистре. Для iOS поддерживаются только файлы с
расширениями WAV, CAF и AIFF, остальные файлы при сборке мобильного приложения пропускаются.
Аудиоинформацию можно в любой момент времени загрузить повторно. Если потребуется ‑ предоставляется возможность выгрузить весь набор
обратно, в виде архива. Для этого необходимо использовать команду Еще ‑ Выгрузить аудиоинформацию.
Данный справочник хранит графическую информацию, которая будет использоваться при сборке мобильных приложений. Разработчик может
загрузить несколько наборов графической информации. Сборщик не накладывает каких-либо ограничений на сочетание набора графической
информации и различных мобильных приложений. Для загрузки графической информации следует воспользоваться командой формы Загрузить
графическую информацию.
При загрузке графической информации система ожидает, что графическая информация будет представлена zip-файлом со следующей
структурой (регистр имени файла и каталога ‑ важен!):
● icon-36x36.png;
● icon-48x48.png;
● icon-72x72.png;
● icon-96x96.png;
● icon-144x144.png.
● splash-320x480.png;
● splash-480x854.png;
● splash-640x960.png;
● splash-768x1024.png;
● splash-800x1280.png;
● splash-854x480.png;
● splash-1024x768.png;
● splash-1242x2208.png;
● splash-1280x800.png;
● splash-1536x2048.png;
● splash-2048x1536.png;
● splash-2208x1242.png.
● pushsmallicon-18x18.png;
● pushsmallicon-24x24.png;
● pushsmallicon-36x36.png;
● pushsmallicon-48x48.png;
● pushsmallicon-72x72.png;
● pushlargeicon-36x36.png;
● pushlargeicon-48x48.png;
● pushlargeicon-72x72.png;
● pushlargeicon-96x96.png;
● pushlargeicon-144x144.png.
● icon-29x29.png;
● icon-40x40.png;
● icon-50x50.png;
● icon-57x57.png;
● icon-58x58.png;
● icon-72x72.png;
● icon-76x76.png;
● icon-80x80.png;
● icon-87x87.png;
● icon-100x100.png;
● icon-114x114.png;
● icon-120x120.png;
● icon-144x144.png;
● icon-152x152.png;
● icon-167x167.png;
● icon-180x180.png;
● icon-1024x1024.png.
● splash-320x480.png;
● splash-640x1136.png;
● splash-640x960.png;
● splash-750x1334.png;
● splash-768x1024.png;
● splash-1024x768.png;
● splash-1242x2208.png;
● splash-1536x2048.png;
● splash-2048x1536.png;
● splash-2208x1242.png.
● icon-50x50.png;
● icon-150x150.png;
● icon-30x30.png.
● splash-620x300.png;
● splash-1208x800.png;
● splash-2048x1536.png.
В архиве могут находиться не все картинки, перечисленные выше. В этом случае будут использовать стандартные иконки и заставки из состава
мобильной версии «1С:Предприятие». При сборке мобильного приложения в журнале сборки будет указано, какая картинка взята из
установленной графической информации, а какая осталась стандартной. Переименование картинки из формата, используемого для загрузки в
сборщик мобильных приложений, в формат, используемый для конкретной мобильной операционной системы, выполняется сборщиком
автоматически. В журнале сборки отображается информация о соответствии имени картинки из архива графической информации и реального
имени картинки.
Для проверки того, что загруженный набор картинок содержит все необходимые файлы служит команда Проверить состав картинок. В
результате проверки отображается диалог, который содержит список картинок, отсутствующих в загруженном архиве.
Графическую информацию можно в любой момент времени загрузить повторно. Если потребуется ‑ предоставляется возможность выгрузить весь
набор обратно, в виде архива. Для этого необходимо использовать команду Еще ‑ Выгрузить графическую информацию.
29.8.3.2. Конфигурации
Для хранения конфигураций предназначен специальный справочник Мобильные конфигурации. Конфигурации должны храниться
исключительно в группах. Группа конфигураций предназначена для хранения различных версий одного прикладного решения. Настоятельно
не рекомендуется смешивать в одной группе разные приложения.
Для определения способа сборки служит поле группы Тип конфигурации. После того, как в группу загружена хотя-бы одна конфигурация,
сменить тип конфигурации в группе становится невозможно.
После того, как создана группа, можно войти в группу и загрузить собственно конфигурацию. Сборщик контролирует, что в группу загружается
корректная конфигурация:
● Конфигурация для сборки приложения мобильного клиента: файлы с расширением 1cemca.xml и 1cemca.zip.
В сборщике мобильных приложений предоставляется возможность изменять только комментарий к загруженной конфигурации. Остальные
В любой момент времени имеется возможность повторной загрузки конфигурации. Кроме того, имеется возможность выгрузить конфигурацию в
файл на диск. Для этого предназначена команда Еще ‑ Выгрузить конфигурацию. Особого смысла данное действие не имеет, т. к. по результату
выгрузки восстановить конфигурацию для последующего изменения не получится.
Конфигурация, загружаема в сборщик, должна быть предварительно выгружена из конфигуратора. В зависимости от используемого вида
приложения, различаются команды для выгрузки и форматы этой выгрузки:
● Для мобильной платформы. Используется команда Главное меню ‑ Конфигурация ‑ Мобильное приложение ‑ Записать в файл. Формат: zip-
файл 1cema.zip. Выгрузка содержит собственно файл конфигурации и различная сопутствующая информация, например, внешние
компоненты, которые в конфигураторе загружены в макеты типа Внешняя компонента.
● Для мобильного клиента. Используется команда Главное меню ‑ Конфигурация ‑ Мобильный клиент ‑ Записать в файл. Формат: xml-файл
1cemca.xml или zip-файл 1cemca.zip. Если конфигурация содержит внешние компоненты ‑ выгрузка выполняется только в формате zip-
файла. Если конфигурация не содержит внешних компонент ‑ выгрузка всегда выполняется в формате xml-файла.
Сборщик мобильных приложений умеет загружать конфигурации любых форматов, которые могли быть использованы на момент выпуска
соответствующей версии сборщика. Следует помнить, что загрузку в сборщик следует выполнять в точности в том виде, в котором
конфигурация выгружена из конфигуратора. Никаких дополнительных действий с файлом выгрузки предпринимать не требуется. «Упрощение»
получившейся выгрузки может привести к тому, что конфигурация будет успешно загружена в сборщик, но выполнить сборку будет
невозможно.
Рекомендуется при обновлении мобильной версии вначале обновлять версию сборщика, а затем повторять выгрузку конфигурации с помощью
конфигуратора новой версии, даже если в самой конфигурации ничего не менялось. Это обеспечит максимальную совместимость выгрузки
конфигурации и новой мобильной версии «1С:Предприятия».
Структура хранения мобильных приложений организована аналогично хранению конфигураций. Вначале создается группа, которая описывает
общие параметры собираемого мобильного приложения, затем, в этой группе, для каждой версии мобильного приложения создается свой
элемент с уникальными настройками.
Параметры собираемого мобильного приложения могут задаваться как в группе приложений, так и непосредственно в элементе. В общем случае
используется схема «наследования» параметров: в элемент приложения переносятся практически все настройки, заданные в группе (с
небольшими особенностями, описанными отдельно). В элементе приложения можно точечно изменить настройки или сохранить те значения,
которые «унаследованы» от группы. В результате разработчику предосталвяется возможность один раз настроить основные параметры
собираемого приложения и затем только создавать новый экземпляр приложения при выпуске очередной версии одной или нескольких
конфигураций.
Группа мобильных приложений описывает общие параметры, которые будут использоваться для сборки приложений и начальной установки
параметров конкретного приложения. Перед созданием приложения необходимо ознакомиться с лицензионной политикой фирмы «1С»,
описывающей правила лицензирования мобильных приложений. Для ознакомления с лицензионной политикой следует выполнить переход по
ссылке из группы мобильного приложения (или через меню Сервис ‑ Лицензионная политика) и затем установив соответствующий флажок.
Во-первых, группа определяет, какой вид приложений будет собираться в данной группе: мобильное приложение или мобильный клиент.
Собирать в одной группе и мобильные приложения и мобильные клиенты невозможно. Изменять тип сборки можно только до тех пор, пока в
группе не создано ни одного конкретного приложения. После создания поле Собирать становиться недоступным для изменения. Если в поле
Собирать указано Для мобильного клиента, то становится возможным выбрать, в каком режиме сборщик будет собирать приложение: как
мобильный клиент или как мобильный клиент с автономным режимом. За этот выбор отвечает поле автономный режим (подробнее про
автономный режим см. здесь). В отличие от поля Собирать, указание необходимости собираться приложение, которое работает в автономного
режиме, доступно в любое время (кроме уже собранного приложения). Таким образом, существует возможность для каждой версии
конфигурации собирать и приложение мобильного клиента и приложение мобильного клиента с автономным режимом. Для такой сборки будет
необходимо создать две приложения, которые будут различаться только значением свойства автономный режим (и номером сборки).
Во-вторых, необходимо определить, для каких мобильных операционных систем будут собираться приложения по умолчанию. Для этого
предназначена группа Собирать мобильное приложение на закладке Общие настройки.
Затем указывается мобильная версия «1С:Предприятие», которая будет использоваться для сборки приложений группы. Если указана
конкретная версия ‑ всегда будет использоваться именно она, до тех пор, пока в группе не выберут новую версию. Если поле Мобильная
платформа будет оставлено пустым, то сборщик при создании нового элемента в данной группе будет выбирать мобильную версию
«1С:Предприятие» с максимальным номером (из списка загруженных в сборщик). Таким образом, становится возможным автоматически
использовать самую «свежую» мобильную версию при сборке нового приложения.
Затем следует указать аудиоинформацию и набор графических файлов, которые будут использоваться приложениями в данной группе.
Значения свойств Графические ресурсы и Аудиоресурсы будут «наследоваться» при создании нового мобильного приложения.
В группе Идентификаторы мобильных приложений необходимо задать идентификатор мобильного приложения, которое будет собираться в
данной группе. Здесь указывается вторая часть идентификатора (первая указана при настройке свойств поставщика мобильных приложений).
После указания идентификаторов сборщик автоматически сформирует полные идентификаторы приложений для мобильных операционных
систем, отмеченных для сборки в группе Собирать мобильное приложение. Следует помнить, что идентификатор мобильного приложения для
ОС Windows следует получать в магазине приложений этой ОС, а не придумывать.
Полный идентификатор мобильного приложения для каждой мобильной ОС формируется по следующему алгоритму: поле Префикс
идентификатора приложения из соответствующего свойства поставщика, символ "." и поле Идентификатор решения (для соответствующей ОС).
Данное поле обязательно для заполнения. Идентификатор решения может состоять из символов латинского алфавита, цифр и символов "." и
"_". Никакая часть идентификатора решения (в то числе идущая после любого символа ".") не может начинаться с цифры.
Для проверки, что в базе сборщика уже нет приложений с получающимися идентификаторами, предназначена команда Проверить уникальность
идентификаторов. Глобальной проверки данная команда не выполняет.
Если мобильное приложение планирует использовать сервис статистики, то необходимо выполнить ряд настроек в сборщике мобильных
приложений. Настройки выполняются только в группе приложений.
Первым шагом в поле Статистика использования приложения необходимо выбрать используемый сервис статистики. Затем необходимо
настроить параметры выбранного провайдера в диалоге, который открывается нажатием кнопки Параметры….
● В поле Режим использования указывается, как будет выполняться включение сервиса статистики:
● Включить, не запрашивая разрешения пользователя ‑ это означает, что после установки мобильного приложения сервис статистики
будет включена без явного оповещения об этом пользователя.
● Включить, запрашивая разрешения пользователя ‑ это означает, что после установки мобильного приложения пользователь будет
проинформирован, что приложение будет использовать сервис аналитики. При этом у пользователя будет запрошено разрешение на это
использование. Пользователь может отказаться без потери функциональных возможностей приложения. Текст, который будет показан
пользователю, задается с помощью поля Текст запроса разрешения (ниже в диалоге).
● Идентификатор приложения в сервисе статистики ‑ позволяет указать идентификатор приложения в том сервисе статистики, который
выбран для данного приложения. Значение параметра зависит от используемого сервиса.
● Период отправки данных ‑ определяет интервал времени, по истечении которого, провайдер сервиса статистики будет пытаться отправить
данные в сервис.
● Не включать имя конфигурации в имена событий ‑ отключает указание имени конфигурации в исходных событиях мобильного приложения.
Используется для укорачивания имен событий/экранов, если приложение, например, работает только с одной конфигурацией.
● Собирать информацию об аварийном завершении приложения ‑ разрешает отправлять в сервис статистики информацию об аварийном
завершении работы мобильного приложения.
● Собирать информацию о покупках ‑ разрешает передачу в сервис статистики информации о покупках в мобильном приложении.
● Адрес обновления настроек регистрации ‑ содержит URL, откуда мобильное приложение может загрузить файл с настройками
преобразования событий.
● XML-файл с настройками провайдера статистики ‑ позволяет загрузить (гиперссылка Загрузить) или удалить (гиперссылка Удалить) XML-
файл с начальными настройками преобразования событий.
На закладке Конфигурации и версия указывается версия приложения в формате A.B.C (поле Версия приложения) и номер сборки (поле Номер
сборки). Оба эти параметра, совместно, обеспечат полный номер версии приложения в формате A.B.C.D, где D ‑ номер сборки. Если в списке
конфигураций указан одна конфигурация, то номер версии можно получать автоматически из этой конфигурации. Если используется несколько
конфигураций, то номер версии приложения лучше задавать самостоятельно. Ниже свойства Версия приложения указывается, что будет
использоваться в качестве версии приложения.
В списке, расположенном ниже номера версии, указываются конфигурации, которые будут использоваться при сборке мобильного приложения.
В данной таблице указываются группы из справочника мобильных конфигураций. Конкретные элементы здесь указать невозможно.
Формирование списка конкретных конфигураций, которые будут размещены в собираемом приложении, будет выполнено при создании
конкретного приложения.
В зависимости от того, для каких ОС будет собираться мобильное приложение, в группе становятся доступными закладки, позволяющие указать
параметры для каждой из используемых ОС:
● Для ОС Android. Если мобильное приложение будет работать с картами Google, то необходимо получить соответствующий ключ с помощью
личного кабинета разработчика на сайте Google. Для получения ключа следует использовать данные, представленные в поле Параметр
получения ключа для работы с картами Google. Полученный ключ необходимо указать в поле Ключ для работы с картами Google. Подробнее
описание получения ключа для карты Google см. здесь.
● Для ОС iOS. Если мобильное приложение будет использоваться на устройствах с ОС iOS и для мобильного приложения планируется
собирать пакет приложения (.ipa), то, в зависимости от используемой версии Xcode, должны быть установлены следующие параметры:
● Xcode 8 и старше: в поле Группа разработчиков следует указать группу разработчиков с нужным идентификатором (настройка
выполняется в параметрах поставщика). В поле Способ распространения можно изменить способ распространения для текущего
мобильного приложения. В Xcode должны быть сконфигурированы и установлены все необходимые сертификаты.
● Xcode 7 и младше: в поле Сертификат для сборки следует указать сертификат, которым будет выполняться цифровая подпись пакета
приложения.
Фактически, содержимое поля Группа разработчиков, сообщает сборщику, с помощью какой версии Xcode будет выполняться сборка. Надо
понимать, что если поле Группа разработчиков очищено, но на компьютере Apple установлен Xcode версии 8 и старше ‑ сборка будет
невозможна.
Если в мобильном приложении используются push-уведомления, то в поле Профиль обеспечения (provisioning profile) следует указать
соответствующий профиль, который необходим для системы Xcode для сборки пакета приложения.
В поле Идентификатор в AppStore следует ввести числовой идентификатор, соответствующий собираемому приложению в магазине
приложений компании Apple.
● Для ОС Windows. Имеется возможность указать цвет фона (в 16-ричном виде) стартового экрана.
Если собирается приложение для мобильного клиента, то для настройки становится доступной закладка Мобильный клиент. На этой закладке
выполняется настройка приложения мобильного клиента.
На закладке Список приложений формируется список информационных баз, с которыми может работать создаваемое мобильное приложение.
Чтобы добавить информационную базу, следует нажать кнопку Добавить, затем в поле Тип указать Информационная база, выбрать
конфигурацию и ее представление в списке мобильного клиента и указать URL, по которому расположена опубликованная информационная
база с указанной конфигурацией. Последним действием можно указать (поле С.) будет данная информационная база сразу отображаться в
списке приложений мобильного клиента или для ее отображения нужно будет вручную указать это уже в собранном мобильном клиенте. Это
может потребоваться в том случае, если собираемое приложение мобильного клиента включает доступ к информационной базе, которая нужна
не очень большому количеству пользователей (относительно общего количества пользователей приложения). В этом случае пользователи,
которым требуется такая информационная база, смогут добавить ее в свой список, а другие пользователи эту базу не увидят вовсе.
Следует отметить, что можно не указывать URL информационной базы. В этом случае в сборщике будет отображаться текст << Любая ссылка
>> и для работы с информационной базой ее адрес нужно будет явным образом ввести на мобильном устройстве. Одна конфигурация может
быть добавлена в список несколько раз. В этом случае можно указать для каждой записи свой URL публикации информационной базы.
Кроме задания адресов информационных баз, имеется возможность указания адресов различных веб-страниц. Так, если приложение
мобильного клиента запускается с пустым списком информационных баз, то будет автоматически открыта веб-страница, адрес которой указан в
поле Адрес начальной веб-страницы сборщика мобильных приложений. Также эту веб-страницу можно открыть в любой момент командой
Начало работы меню формы со списком информационных баз. С помощью данной страницы можно реализовать несколько операций:
● Регистрацию пользователя в информационной базе (или сервисе). Такая возможность может потребоваться в том случае, если
информационная база требует указания имени пользователя и пароля, а пользователь еще не зарегистрирован. Если для приложения
мобильного клиента, которое используется для доступа к корпоративным информационным базам, регистрацию пользователя может
выполнить администратор этой информационной базы, то для информационной базы, доступной публично, такую регистрацию можно сделать
с помощью специальной веб-страницы. Адрес этой страницы необходимо указать в свойстве Адрес начальной веб-страницы.
● Добавить в приложение мобильного клиента ссылку на веб-сервис, предоставляющий список общих информационных баз. Работа системы
в этом случае аналогично поведению платформы для персонального компьютера (см. здесь). Для этого на веб-странице должна
располагаться гиперссылка, сформированная особым образом (с помощью схемы e1c:// и команды AddToStartCfg). После добавления ссылки
на веб-сервис, мобильный клиент автоматически выполнит получение списка информационных баз и отобразит полученный список.
● Запустить необходимую информационную базу, без добавления ее в список информационных баз приложения мобильного клиента. Для
этого на веб-странице должна располагаться гиперссылка, сформированная особым образом (с помощью схемы e1c:// и команды WS).
2. При необходимости, после успешной регистрации ссылка на веб-сервис получения списка общих информационных баз добавляется в
приложение мобильного клиента.
3. Выполняется запуск необходимой информационной базы. При этом пользователь использует для авторизации в информационной базе имя
и пароль, полученные на первом шаге данного сценария.
Сборщик также предоставляет возможность указать адрес веб-страницы в списке информационных баз. Для этого следует нажать кнопку
Добавить, затем в поле Тип указать Web-страница, в поле Представление указать, как данная веб-страница будет представлена в списке
информационных баз, а в поле Адрес веб-сервера указать URL добавляемой веб-страницы. Поле С. (как и для информационной базы)
определяет начальную видимость записи в списке приложений мобильного клиента.
Веб-страница, указанная в списке, предполагает задание страницы, на которой выполняются действия, для доступа к которым требуется
авторизация, но эти действия не реализованы (по любым причинам) в информационной базе (или базах), доступ к которым имеет пользователь.
В качестве примера такого действия можно привести оплату доступа к информационной базе или сервису (если доступ является платным).
Веб-страницы, которые указываются в поле Адрес начальной веб-страницы и в списке информационных баз, будут открываться в приложении
мобильного клиента, а не веб-браузером по умолчанию на используемом мобильном устройстве. На этих страницах допустимо указание
гиперссылок, использующих схему e1c://. Нажатие по таким ссылкам обрабатывается непосредственно мобильным клиентом и позволяет
добавлять информационные базы в список приложений мобильного клиента.
На закладке Список общих информационных баз сборщик позволяет указать, на основании каких ресурсов приложение мобильного клиента
будет формировать список общих информационных баз. Флажок Использовать произвольный адрес списка общих информационных баз
предоставит возможность пользователю добавить адрес веб-сервиса, который возвращает список общих информационных баз. В том случае,
если адреса веб-сервисов списков общих информационных баз известны на момент создания мобильного приложения, то их можно указать в
списке на этой закладке. Необходимо помнить, что мобильный клиент использует тот же веб-сервис получения списка общих информационных
баз, что и интерактивная программа запуска платформы для персонального компьютера. Описание этого веб-сервиса см. здесь.
Флажок Разрешить добавлять информационные базы, используя QR-коды включает или выключает одноименную возможность. Следует
понимать, что включение флажка не означает получение такой возможности в собранном приложении. Использование QR-кодов в собранном
приложении (при условии включения флажка) будет доступно при выполнени одного из следующих условий:
● Разрешено использовать произвольный адрес списка общих информационных баз (установлен флажок Использовать произвольный адрес
списка общих информационных баз).
● В списке информационных баз и веб-страниц присутствует хотя-бы одна строка с пустым адресом веб-сервера (колонка Адрес веб-
сервера).
А том случае, когда собранное приложение получает поддержку сканирования QR-кодов для добавления информационных баз, в список
разрешения приложения добавляют разрешение, необходимое для использования камеры устройства, а в интерфейсе мобильного приложения
появляется команда Добавить с помощью QR-кода.
Состояние флажка Разрешить добавлять информационные базы, используя QR-коды можно изменять как в группе, так и в настройках
конкретного мобильного приложения, но окончательно «решение» принимается во время сборки приложения.
В том случае, если поле Адрес веб-сервера в списке Адреса информационных баз и веб-страниц или Пути к спискам общих информационных
баз, содержит URL, который начинается со строки «https://», то сборщик дает возможность указать способ проверки сертификата сервера и
клиентский сертификат:
● В поле Способ проверки сертификата сервера можно указать, откуда взять корневой сертификат для проверки сертификата сервера:
● Не проверять ‑ означает, что сертификат сервера проверяться не будет, но соединение мобильного клиента с сервером будет
шифроваться.
● Хранилище сертификатов ОС ‑ означает, что для проверки сертификата сервера будут использоваться корневые сертификаты,
размещенные в хранилище сертификатов устройства, на котором будет работать собираемое мобильное приложение. Соединение
мобильного клиента и сервера будет шифроваться.
● Указанный сертификат ‑ означает, что для проверки сертификата сервера будет использоваться корневой сертификат, указанный в поле
Сертификат сервера. Соединение мобильного клиента и сервера будет шифроваться.
● В поле Сертификат сервера указывается корневой сертификат, который используется для проверки сертификата сервера. Поле доступно
только в том случае, если в поле Способ проверки сертификата сервера выбрано значение Указанный сертификат.
● В поле Клиентский сертификат указывается сертификат, который используется для удостоверения клиентского приложения.
В полях Сертификат сервера и Клиентский сертификат указываются сертификаты, предварительно загруженные в справочник Сертификаты для
работы по HTTPS. Загруженные сертификаты (для удобства применения) разделяются на корневые сертификаты (с установленным флагом Для
проверки сертификата сервера) и клиентские сертификаты.
Описание команд
На веб-страницах, которые указываются в свойстве Адрес начальной веб-страницы и в записи типа Web-страница (в самом сборщике и в списке
общих информационных баз), допускается указание URL (например, в элементе <a>), который принадлежит схеме e1c.
Такой адрес будет обрабатываться непосредственно мобильным клиентом. В адресе имеется возможность указать команды (и параметры)
командной строки запуска мобильного клиента.
● Команда AddToStartCfg. Эта команда предназначена для добавления в приложение мобильного клиента ссылки на веб-сервис (или файл)
получения списка общих информационных баз. Сервис описывается параметрами команды. Команда имеет следующий вид:
Копировать в буфер обмена
AddToStartCfg[&N=<пользователь>][&P=<пароль>][&Title=<заголовок>][[&InternetService=<URL>]|[&CommonInfoBases=<URL>]]
● N=<пользователь> ‑ позволяет указать пользователя, от имени которого будет выполнен доступ к сервису.
● Title=<заголовок> ‑ представление веб-сервиса в списке интернет-сервисов получения списков общих информационных баз
мобильного клиента.
● InternetService=<URL> ‑ URL сервиса получения списка общих информационных баз. После добавления мобильный клиент выполнит
получение списка, который возвращает данный сервис. В одной команде может использоваться или параметр InternetService или
CommonInfoBases.
● CommonInfoBases=<URL> ‑ содержит полное имя файла со списком общих информационных баз (файл .v8i). После добавления мобильный
клиент выполнит получение списка, который содержится в заданном файле. В одной команде может использоваться или параметр
InternetService или CommonInfoBases.
● Команда AddByQRCode. Команда запускает сканирование QR-кода. Команда имеет следующий вид:
Копировать в буфер обмена
AddByQRCode[&SkipDetails]
● Команда AddInfoBase. Команда выполняет добавление информационной базы в список информационных баз текущего мобильного
приложения. Команда имеет следующий вид:
Копировать в буфер обмена
AddInfoBase[&WS=<строка соединения>][&Run][&DisplayAuthDialog][&DisableUseBiometrics][&UseBiometrics[-|+]][&DisableRememberMe]
[&RememberMe[-|+]]
● WS=<строка соединения> ‑ описывает строку соединения с информационной базой, которую требуется добавить в список
информационных баз.
Смотри также:
Содержимое QR-кода
Для того чтобы QR-код был успешно распознан мобильной версией «1С:Предприятие», в нем должна быть закодирована конкретная
информация. В зависимости от того, для использования каким клиентским приложением предназначен QR-код, в нем может кодироваться
различная информация.
1. URL расположения конфигурации. Данный URL получается в результате публикации мобильного приложения на веб-сервере.
2. Строка соединения с информационной базой в виде ws=URL. На следующих строках допускается указание команд WSN и WSP. Эти команды
задают параметры аутентификации на веб-сервере, где расположена конфигурация (подробнее о параметрахсм. здесь).
Мобильный клиент
1. URL информационной базы. По такому URL может быть выполнено обращение с помощью тонкого клиента платформы для персонального
компьютера или с помощью веб-браузера.
2. Элемент файла списка информационных баз (*.v8i), описывающий информационную базу (описание формата см. здесь). При этом
допускается использовать команды N, P, WSN,
WSP, DisplayAuthDialog, DisableRememberMe, RememberMe, DisableUseBiometrics, UseBiometrics. Команды N, P описывают параметры
аутентификации в приложении «1С:Предприятия». Команды WSN, WSP описывают параметры аутентификации на веб-сервере, где
опубликовано приложение.
Если в сформированном QR-коде будут присутствовать команды, которые не поддерживаются мобильным клиентом, эти команды будут
пропущены.
3. Элемент файла списка информационных баз (*.v8i), описывающий список общих информационных баз (описание формата см. здесь). При
этом допускается использовать команды N, P, WSN, WSP. Команды N, P описывают параметры аутентификации в приложении
«1С:Предприятия». Команды WSN, WSP описывают параметры аутентификации на веб-сервере, где опубликовано приложение.
Примеры
В данном разделе будут рассмотрены примеры различных ссылок. При этом следует учитывать, что ссылки будут приведены в виде,
максимально удобном для чтения, а не для размещения в реальном атрибуте href. Для размещения в атрибуте следует привести строку к
корректному виду.
Копировать в буфер обмена
<a href="e1c://?AddToStartCfg&Title="Прикладное решение"&N=User1C&InternetService=https://my.site.com/is/hs/">
Переход по этому адресу приведет к добавлению в приложение мобильного клиента сервиса получения списка общих информационных баз, для
доступа к которому будет использоваться пользователь User1C.
Копировать в буфер обмена
<a href="e1c://?WS=https://test.app-site.com/app-name">
Переход по этому адресу приведет к подключению мобильным клиентом к прикладному решению, которое опубликовано по адресу
https://test.app-site.com/app-name. При этом это приложение не будет добавлено в список информационных баз мобильного клиента.
Копировать в буфер обмена
<a href="e1c://?AddToStartCfg&InternetService= https://my.site.com/is/hs/&WS=https://test.app-site.com/app-name">
1. В приложение мобильного клиента будет добавлен интернет-сервис получения списка общих информационных баз, опубликованный по
адресу https://my.site.com/is/hs/ и начнется получение этого списка.
2. После выполнения этого действия будет выполнено подключение мобильного клиента к информационной базе, опубликованной по адресу
https://test.app-site.com/app-name.
Для того чтобы получить конкретное приложение, необходимо в созданной ранее группе создать конкретное приложение. При создании
приложения будут заполнены все поля, которые могут быть заполнены автоматически или могут быть «унаследованы» из родительской группы.
В подавляющем большинстве «наследование» выполняется путем установки в нужное поле значения, указанного в группе.
● Мобильная версия, используемая для сборки. Если в родительской группе указана конкретная версия ‑ в приложении будет использоваться
указанная версия. Если поле Мобильная платформа в группе не указана, то сборщик попытается подобрать мобильную версию с
максимальным номером, которая соответствует следующим условиям: не помечена на удаление, не удалена из информационной базы и
подходит для текущего режима сборки (поле Собирать). Если в базе сборщика нет подходящих версий, то пользователь может попробовать
сам указать нужную версию. Если нужно версии подобрать не получилось ‑ сборка будет невозможна.
● Конфигурации, используемые для сборки. Для каждой группы конфигураций, которые указаны в родительской группе (закладка
Конфигурации и версия) выполняется поиск самой новой загруженной конфигурации, которая будет соответствовать следующим условиям:
не помечена на удаление, принадлежит выбранной группе конфигураций и подходит для текущего режима сборки (поле Собирать).
Считается, что чем больше код элемента, тем более «свежая» версия у конфигурации. Сборщик выбирает конфигурацию с самым большим
кодом. В результате при создании нового приложения в него попадут самые свежие конфигурации (из необходимых), загруженные в
сборщик.
● На закладках, соответствующих используемым мобильным операционным системам, устанавливаются полные идентификаторы приложений.
В конкретном приложении изменить полный идентификатор приложения невозможно. Изменение возможно только через изменение
идентификаторов приложений в группе и будет действовать только для вновь собираемых приложений.
● Для мобильного приложения определяется и указывается версия и номер сборки мобильного приложения.
На закладке Конфигурации и представления имеется возможность указать, какие конфигурации будут включены в собираемое приложение, а
также каким будет представление собираемого приложения на всех поддерживаемых языках. Кроме автоматически добавленных конфигураций,
на закладке Конфигурации приложения, можно добавить произвольный список конфигураций.
● Определяются все языки локализации, которые присутствуют во всех используемых конфигурациях данного мобильного приложения.
● Для каждого языка локализации формируется представление. Представление конфигурации на конкретном языке будет представление той
конфигурации, в которой язык встретился первый раз (по порядку обхода).
● Затем анализируется список Представление приложения группы мобильных приложений. Для совпадающих языков представление
заполняется из группы.
Затем на закладке Представления мобильного приложения можно отредактировать представления для всех найденных языков. Язык
представления всего приложения по умолчанию (название иконки приложения на мобильном устройстве) выбирается в поле Язык. Если
необходимо изменить представление приложения на постоянной основе ‑ рекомендуется это делать в списке Представление приложения группы
мобильных приложений.
Остальные параметры собираемого приложения, при необходимости, могут быть изменены относительно настроек, указанных в группе.
Поле Дата и время сборки мобильного приложения содержат дату и время последней успешной сборки текущего мобильного приложения. Поля
Дата последней выгрузки в … содержат дату и время, когда выполнялась выгрузка собранного приложения в соответствующий магазин
приложений (поддерживается Google Play и Apple AppStore).
Ниже, в таблице, приводится список артефактов, которые были сформированы во время последней сборки. Для каждого артефакта указывается
его тип и наличие собственно приложения и журнала сборки. Если запись отображается бледным цветом ‑ значит она устарела и все файлы
удалены из базы данных. Всего доступны следующие артефакты сборки:
● Для ОС Android:
● Для ОС iOS:
● Журнал сборки для мобильного приложения/мобильного клиента и проекта для Xcode является общим. Журнал сборки для эмулятора
является отдельным.
● Для ОС Windows:
На данной закладке предоставляется возможность получить из базы сборщика все результаты сборки (и приложения и журналы сборки) одним
архивом. Для этого необходимо выполнить команду формы Еще ‑ Получить приложения. В результате будет сформирован .zip-архив, который
содержит все файлы, полученные в результате сборки. Этот архив предлагается сохранить на клиентский компьютер. Архив имеет следующую
структуру:
● В папке Android расположены файлы приложений для ОС Android. Суффикс имени файла определяет архитектуру процессора для каждого
файла.
● В папке iOS расположены файлы приложений для ОС iOS. Файл с расширением .zip содержит архив проекта для самостоятельной сборки с
помощью Xcode. Файл с расширением .ipa содержит исполняемый файл, пригодный для отправки на устройство или в магазин приложений.
Файл, имя которого оканчивается на «-simul.zip», является мобильным приложением для работы на эмуляторе.
● В папке Windows расположены файлы приложений для ОС Windows. Суффикс имени файла определяет архитектуру процессора для
каждого файла и вариант реализации (телефон или гибридное устройство). У этих файлов будет расширение .appx.
● Именем каждого файла (включая файлы журналов сборки) выступает полный идентификатор приложения для соответствующей
операционной системы.
При необходимости, можно загрузить из информационной базы каждый артефакт сборки. Для этого необходимо встать на нужную строку
результатов сборки и нажать кнопку Получить приложение. Если необходимо посмотреть журнал сборки для этого артефакта ‑ следует в той же
строке нажать кнопку Показать журнал.
Сборка мобильного приложения начинается по команде Собрать приложение. Данная команда доступна как в форме конкретного приложения,
так и в списке мобильных приложений.
● Проверяется, что в собираемом приложении указана хотя-бы одна мобильная операционная система.
● Проверяется наличие нужного набора файлов для выбранной мобильной версии «1С:Предприятия» (мобильное приложение или
мобильный клиент).
3. Формируется кеш для используемой мобильной версии «1С:Предприятие». Кеш формируется в каталоге platform каталога, указанного в
качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
4. Формируется кеш используемой графической информации. Кеш формируется в каталоге pictures каталога, указанного в качестве рабочего
каталога и кеша сборщика в настройках параметров сборщика.
5. Формируется кеш используемых аудиофайлов. Кеш формируется в каталоге sounds каталога, указанного в качестве рабочего каталога и
кеша сборщика в настройках параметров сборщика.
6. Формируется кеш внешних компонент, используемых в мобильном приложении. Кеш формируется в каталоге external-components
каталога, указанного в качестве рабочего каталога и кеша сборщика в настройках параметров сборщика.
7. Фактическая выгрузка в кеш выполняется только в том случае, если необходимых файлов нет на диске или они не соответствуют файлам в
базе данных.
Если выполняется сборка для ОС Android, то происходит выбор компонентов, которые будут использоваться для сборки. Алгоритм подбора
выглядит следующим образом:
2. Если установленные версии ниже версии, которая указана в требованиях к используемой мобильной версии ‑ сборка становится
невозможной. Если в используемой версии не указана требуемая версия, то минимальной версией SDK для сборки с помощью Apache Ant
является 24, а для сборки с помощью Gradle ‑ 26.
5. Определяется, какую технологию сборки использует выбранный SDK (API Level): Apache Ant или Garadle.
Вышеуказанный алгоритм выполняется для каждой из двух настроек путей доступа к Android SDK, которые указаны в настройках параметров
сборщика. Затем определяется, какая технология сборки требуется используемой мобильной версией «1С:Предприятие» (та версия, которая
указана в настройках собираемого приложения). Если указанная мобильная версия «1С:Предприятие» может быть собрана в рамках указанной
в настройках инфраструктуры, то сборка продолжается. Если инфраструктура настроена неадекватно ‑ сборка блокируется.
Также в рамках подготовительных действий проверяется наличие инструментов сборки, нужных в случае сборки мобильных приложений для
конкретных мобильных операционных систем. В общем случае выполняются следующие проверки:
● Возможность собрать требуемый вид мобильного приложения с использованием указанной мобильной версии «1С:Предприятие». Другими
словами, невозможно собрать приложение мобильного клиента с использованием мобильной версии «1С:Предприятие» младше 8.3.12.
Тексты запросов разрешений, необходимых мобильному приложению, задаются для приложения вцелом. Однако каждая конфигурация,
используемая в составе мобильного приложения, может иметь собственные тексты запросов разрешений. Сборщик использует следующий
алгоритм определения списка текстов запросов разрешений (на различных языках), который будет использоваться для собираемого мобильного
приложения:
● На основании всех конфигураций собираемого приложения формируется список языков собираемого мобильного приложения.
● Для каждого языка получается текст запроса разрешения. Для этого сборщик обходит используемые конфигурации в порядке
расположения в списке и пытается получить текст запроса разрешения. Для приложения будет использоваться первый непустой текст
запроса для каждого языка.
● Затем для каждого разрешения удаляются все языки, где текст запроса разрешения не указан. Для таких языков будет использоваться
текст из платформы на этом языке (если удаленный язык входит в состав языков локализации мобльной версии) или английский текст (если
удаленный язык не входит в состав языков локализации мобильной версии).
● Если в состав мобильного приложения входят конфигурации с указанием текстов запросов разрешений и конфигурации без указания таких
текстов, то для формирования результирующего текста запросов будут использоваться только те конфигурации, где тексты запросов
разрешений есть.
● Если все конфигурации мобильного приложения не используют текстов запросов разрешений ‑ все тексты запросов разрешений будут
взяты из платформы.
Каждая внешняя компонента, используемая в собираемом мобильном приложении, должна быть собрана для всех операционных систем, для
которых собирается мобильное приложение. Если мобильное приложение собирается для ОС iOS и Android, то и внешняя компонента должна
быть собрана для ОС iOS и Android. Однако могут возникать ситуации, когда внешняя компонента пишется только для одной мобильной
операционной системы. В этом случае сборщик мобильных приложений будет записывать в журнал сборки мобильного приложения
предупреждение о том, что определенная мобильная компонента не собрана для определенной мобильной операционной системы. Но сборка
все равно будет продолжена. При попытке использования отсутствующей внешней компоненты на мобильном устройстве (в собранном
приложении) будет сформировано исключение.
После выполнения всех подготовительных действий запускается сборка всех требуемых артефактов. Каждый артефакт собирается своим
фоновым заданием. Количество одновременно запущенных фоновых заданий определяется количеством процессорных ядер на компьютере,
который исполняет роль сервера «1С:Предприятие» сборщика мобильных приложений. Если количество фоновых заданий, которые необходимо
запустить, превышает количество ядер, то количество запущенных фоновых заданий будет равно числу ядер, а остальные фоновые задания
будут ожидать в очереди завершения уже запущенных сборочных заданий. Ожидающие фоновые задания будут запускаться по мере
завершения ранее запущенных фоновых заданий. Если для какой-либо мобильной операционной системы сборка не заказывалась (не
установлен соответствующий флажок в настройках мобильного приложения), то соответствующие фоновые задания не запускаются.
Во время сборки приложения для ОС iOS, сборка .ipa-файла на компьютере Apple выполняется только в том случае, если в настройках сборщика
указаны параметра подключения к компьютеру Apple. На компьютере Apple, указанном в настройках сборщика, должен быть установлен и
корректно настроен пакет Xcode.
При сборке приложений для ОС Android с использованием Gradle, в рабочем каталоге сборщика формируется каталог gradle. Он занимает
существенный объем (несколько гигабайт), однако удалять его после каждой сборки не рекомендуется, т. к. при следующей сборке он опять
будет формироваться заново, а кроме того, наличие этого кеша существенно ускоряет процесс сборки приложения.
Во время сборки на экран выводится окно, отображающее время, которое уже заняла сборка и состояние каждого из запущенных сборочных
процессов.
Каждое фоновое задание создает в рабочем каталоге сборщика свой собственный рабочий каталог. Имя этого каталога является текстовым
представлением уникального идентификатора, полученного средствами платформы. Это значит, что имя рабочего каталога каждого фонового
задания является уникальным при каждом выполнении. После окончания работы соответствующего фонового задания ‑ рабочий каталог этого
фонового задания удаляется.
Если сборка для всех требуемых артефактов завершилась успешно ‑ собранное мобильное приложение становится недоступным для изменений.
Его можно только пересобрать и посмотреть параметры, которые использовались для сборки. Это сделано для минимизации возможности
получить уже собранное мобильное приложение, которое отличается от параметров, которые были заданы при его сборке.
Рабочий каталог сборщика может быть очищен полностью в произвольный момент времени (если только в этот момент не выполняется сборка
мобильного приложения). После этого следующие несколько процессов сборки могут выполняться большее время (пока сборочный кеш опять
не будет заполнен необходимой информацией).
Журнал сборки может оказать помощью при решении проблем со сборкой или работой приложения. В этом журнале присутствует как
информация собственно сборщика мобильных приложений, так и информация тех утилит, которые запускаются сборщиком в процессе работы. В
журнал попадает стандартный вывод (stdout) и стандартный вывод ошибок (stderr) запускаемых утилит.
ВНИМАНИЕ! При обращении в фирму «1С» с проблемами, связанными с работой сборщика мобильных приложений, журнал сборки
следует прикладывать сразу и полностью. Это существенно облегчит и упростит диагностику проблем.
Для собранных приложений сборщик предоставляет возможность загрузки в магазин приложений. Поддерживается работа с Google Play и Apple
AppStore.
Загрузку можно выполнить по команде Загрузить в магазины из конкретного приложения или списка мобильных приложений. Непосредственно
выгрузка выполняется из диалога, внешний вид которого показан выше.
Чтобы выгрузка была возможна, необходимо выполнение следующих условий (для каждого магазина):
● в карточке поставщика (Рабочий стол ‑ Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС iOS ‑ Доступ к iTunes Connect).
● настроены параметры доступа к компьютеру Apple (Рабочий стол ‑ Сервис ‑ Настройка параметров сборщика, группа параметров
доступа к компьютеру Apple)
● Для Google Play: в карточке поставщика (Рабочий стол ‑ Сервис ‑ Настройка параметров поставщика ‑ Параметры для ОС Android ‑ Доступ
к консоли разработчика).
Если загрузка по каким-то причинам невозможна ‑ эти причины будут сформированы в поле Диагностика для каждого магазина приложений.
Для магазина Google Play можно указать, какая конфигурация приложения загружается в магазин (поле Конфигурация).
Нажатие кнопки Загрузить приложение запускает процесс загрузки. Если загрузка завершилась неудачей, то нажатие кнопки Журнал для …
позволит посмотреть журнал загрузки. Следует помнить, что журнал загрузки можно посмотреть только сразу после попытки загрузки. После
закрытия формы Загрузить в магазины приложений журналы будут утеряны.
Фирмой «1С» реализован вспомогательный сервис для отправки уведомлений. Подробное описание назначения и работы с сервисом см. здесь.
Этот сервис имеет собственный пользовательский интерфейс. В тоже время, сборщик мобильных приложений позволяет выполнять ряд
операций без посещения сайта. К этим операциям относятся:
● Подключить к зарегистрированному приложению возможность получать уведомления через поддерживаемые сервисы: APNs, GCM, FCM,
WNS.
Для доступа к форме работы с сервисом необходимо открыть форму редактирования группы мобильных приложений и в этой форме нажать
кнопку Работа с сервисом "1С". В результате будет открыта форма работы с сервисом.
Для подключения к сервису фирмы «1С» необходимо ввести имя пользователя и пароль. Для этого следует нажать кнопку Указать параметры
доступа к сервису. Для каждого пользователя сборщика необходимо регистрировать свои параметры доступа к сервису.
Если у пользователя нет доступа к сервису фирмы «1С», то имеется возможность зарегистрироваться в сервисе непосредственно из сборщика.
Для этого в форме регистрации параметров доступа необходимо нажать кнопку Зарегистрироваться в сервисе "1С".
В процессе регистрации необходимо указать действующий номер мобильной радиотелефонной связи для получения код подтверждения, затем
ввести в форму полученный код и остальные параметры.
Диалог предоставляет возможность выполнить регистрацию мобильного приложения, которое будет получать уведомления. Для регистрации
необходимо нажать кнопку Зарегистрировать приложение. В качестве наименования приложения будет использован текст из поля диалога
Описание приложения. По умолчанию данное поле заполняется наименованием группы мобильных приложений.
Если использование приложения через сервис фирмы «1С» больше не планируется, то необходимо нажать кнопку Удалить регистрацию
приложения. Следует помнить, что удаление регистрации невозможно восстановить. Даже если повторно выполнить регистрацию, то с точки
зрения сервиса, это будет новое приложение и ранее заданные данные для сервисов отправки уведомлений придется устанавливать заново.
После выполнения регистрации приложения в сервисе, можно выполнить подключение к приложению сервисов отправки уведомлений. Текущий
статус подключения отображается в нижней части диалога.
Нажатие кнопки Подключить … приводит к тому, что сборщик выполняет попытку подключения соответствующего сервиса. В зависимости от
подключаемого сервиса, может потребоваться ввод некоторой дополнительной информации. Подробнее об этом см. здесь.
Описание отладки работы механизма встроенных покупок с помощью сборщика мобильных приложений см. здесь.
Подготовка приложения для размещения в магазине приложений делается аналогично проверке мобильного приложения перед публикацией в
магазине приложений.
Перед отправкой приложения в Apple AppStore необходимо создать приложение в портале iTunes Connect и заполнить всю требуемую
информацию о приложении. Затем следует нажать кнопку Ready to Upload Binary, при этом статус вашего приложения в iTunes Connect должен
измениться на Waiting For Upload.
После формирования файла с архивом приложения для ОС iOS следует скопировать файл архива на компьютер Mac и выполнить следующие
действия:
● Открыть проект мобильной платформы разработчика в системе Xcode (двойным щелчком мыши по файлу 1cem.xcodeproj или выбрать файл
1cem.xcodeproj с помощью команды File ‑ Open в системе Xcode).
● С помощью команды меню Xcode Product ‑ Edit Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся
диалоге:
Необходимо открыть элемент списка мобильных приложений, для которого необходимо выполнить загрузку приложения, и выбрать команду
Загрузить в магазины…. Сборщик проведет анализ выбранного мобильного приложения и сообщит пользователю о возможности или
невозможности выполнить загрузку. Если загрузка доступна (установлен флажок Загрузить в 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 файл. Для
Первую загрузку приложения в магазин Google Play следует выполнять вручную. Последующие загрузки можно выполняться с помощью
сборщика приложений для мобильных устройств.
Необходимо открыть элемент списка мобильных приложений, для которого необходимо выполнить загрузку приложения, и выбрать команду
Загрузить в магазины…. Сборщик проведет анализ выбранного мобильного приложения и сообщит пользователю о возможности или
невозможности выполнить загрузку. Если загрузка доступна (установлен флажок Загрузить в Google Play), то необходимо указать
конфигурацию, в которую будет помещено приложение в поле Конфигурация, а затем нажать кнопку Загрузить. Сборщик попытается выполнить
загрузку. Выполняется загрузка исполняемых файлов обеих архитектур: ARM и x86. Для доступа к Google Play, используются параметры,
которые можно задать в диалоге настройки параметров поставщика на закладке Параметры для ОС Android. Эту настройку может выполнить
только администратор сборщика. Алгоритм получения доступа описан в справке сборщика приложений для мобильных устройств.
По окончанию загрузки сборщик сообщит состояние загрузки. Если загрузка закончилась неудачно ‑ рекомендуется нажать кнопку Журнал для
Google Play. Будет открыт документ, в котором находится журнал загрузки. Журнал не сохраняется в информационной базе и будет утерян
после закрытия окна загрузки.
Вручную
Для выкладки приложения в Google Play необходимо создать приложение на портале Google Play, заполнить требуемую информацию о
приложении и загрузить .apk-файл(ы).
При создании приложения следует выбрать Prepare Store Listing. После заполнения информации о приложении необходимо перейти на закладку
APK и переключиться в расширенный режим, нажав кнопку Switch to advanced mode. Далее, для каждой архитектуры процессора (ARM и x86)
следует нажать Upload new APK to Production, и выбрать соответствующий файл приложения. Только расширенный режим позволяет загружать
файлы приложений для различных архитектур процессоров. В результате оба приложения появятся в списке с соответствующими
архитектурами ARM и x86. Теперь необходимо нажать кнопку Publish now.
Сборщик приложений для мобильных устройств не поддерживает публикацию приложений в магазин Windows Store.
Вручную
Прежде чем выполнять сборку приложения в сборщике приложений для мобильных устройств, необходимо зарезервировать идентификатор
вашего приложения в магазине Windows Store. Для этого необходимо зайти в информационную панель магазина (https://appdev.microsoft.com
/StorePortals/).
Для создания приложения следует выбрать + Создать новое приложение. Теперь необходимо ввести планируемый идентификатор приложения
и нажать гиперссылку Проверить доступность. Если введенное имя занято, то зарезервировать данное имя будет невозможно, о чем будет
сообщено справа от поля с идентификатором приложения. Если имя доступно, то следует нажать кнопку Зарезервировать имя приложения.
После сборки мобильного приложения следует загрузить получившиеся файлы в созданное приложение из информационной панели. Для этого в
информационной панели следует нажать мышью на созданное приложение и в левом меню выбрать пункт Отправки, а затем нажать кнопку
Начать отправку.
В открывшейся форме необходимо установить свойства приложения, цены, описание продукта, его возрастной ценз и т. д. Затем следует
нажать гиперссылку Пакеты и загрузить файлы .appx, созданные сборщиком приложений для мобильных устройств. Если загрузка прошла
успешно ‑ следует нажать кнопку Сохранить. После заполнения всех параметров отправки следует нажать кнопку Отправить в Магазин и
ожидать результатов проверки.