Глава 26. Разработка решений для мобильной платформы
страницаГлава 26. Разработка решений для мобильной платформы
26.1. Общая информация
Система программ «1С:Предприятие» позволяет разрабатывать приложения, функционирующие на мобильных устройствах (смартфоны, планшетные компьютеры). Мобильное приложение – прикладное решение, предназначенное для выполнения на мобильной платформе «1С:Предприятия». Мобильная платформа – это специальная версия «1С:Предприятия», предназначенная для исполнения мобильных приложений на мобильных устройствах, которые функционируют под управлением операционных систем iOS (http://www.apple.com/ios/), Android (http://www.android.com/) и Windows (https://www.windowsphone.com). Для ОС Windows обеспечивается функцонирование как на мобильных телефонах (ОС Windows Phone), так и на других устройствах с сенсорным экраном (ОС Windows). В дальнейшем при использовании термина «ОС Windows» будут пониматься обе эти операционные системы, если явно не указана конкретная ОС. Мобильная платформа реализована в архитектуре тонкого клиента, работающего с файловым вариантом информационной базы, расположенной на мобильном устройстве. Для функционирования мобильного приложения не требуется наличие постоянного канала связи с каким-либо компонентом внешней сетевой инфраструктуры. В случае необходимости, можно реализовать внешнее взаимодействие с помощью различных механизмов мобильной платформы.
Разработку мобильного приложения можно условно разбить на следующие этапы:
● Принимается решение, каким будет мобильное приложение:
● Независимо от каких-либо прикладных решений на удаленной системе. В этом случае структура данных мобильного приложения определяется только областью применения приложения. Скорее всего, никакой обмен данными не потребуется.
● Автономное рабочее место некоторого прикладного решения, расположенного на удаленной системе. В этом случае структура данных в основном определяется прикладным решением, но будут изменения, определяемые как областью применения, так и особенностями мобильного приложения. Протокол обмена данными, скорее всего, будет представлять собой специализированный протокол обмена конкретного прикладного решения с конкретным мобильным приложением. Протокол обмена не ориентирован на обмен с другими решениями.
● Универсальное автономное рабочее место. В этом случае структура данных должна учитывать специфику всех прикладных решений, с которыми должно взаимодействовать мобильное приложение. Также необходимо учитывать особенности мобильного приложения. Протокол обмена должен быть достаточно универсальным и стандартизированным.
● Уточняется, мобильное решение должно работать только на мобильном устройстве или оно также может работать и на персональном компьютере (например, на ноутбуке).
● Выполняется реализация мобильного приложения и его отладка на персональном компьютере (включая механизмы обмена данными). При этом необходимо понимать, что мобильная платформа имеет ряд отличий и особенностей, в силу чего невозможно полностью проверить работоспособность мобильного приложения на персональном компьютере. Однако код на встроенном языке можно отлаживать только на персональном компьютере.
● На мобильном устройстве (одном или нескольких) выполняется окончательная проверка и отладка интерфейса и функциональности приложения.
Совет. Рекомендуется выбирать для разработки вариант автономного рабочего места, которое может функционировать и на мобильном устройстве и на персональном компьютере.
При разработке механизма обмена данными необходимо учитывать, что обмениваться данными должны приложения с разными версиями интерфейса обмена. Это не должно вызывать проблем при обмене. Связано это с тем, что обновление приложения сразу для всей инфраструктуры практически невозможно. Также следует отметить, что синхронизация данных по устаревшей версии протокола обмена может использоваться для выполнения операций резервного копирования перед обновлением конфигурации мобильного приложения.
При разработке мобильного приложения необходимо учитывать ограничения, которые накладывает мобильная платформа по сравнению с платформой «1С:Предприятие» для персонального компьютера:
● Ограниченный перечень доступных объектов конфигурации и механизмов;
● Ограниченный набор свойств реквизитов;
● Ограниченный набор элементов управляемых форм;
● Упрощенная реализация некоторых механизмов (например, права доступа или начальная страница);
● Отсутствие обычных форм и обычного режима запуска;
● Отсутствие средств отладки мобильного приложения;
● Полный список особенностей см. здесь.
Также следует учитывать, что мобильная платформа и платформа для персонального компьютера, при совпадении версий различаются по предоставляемой функциональности. Ниже приведено функциональное соответствие версий платформы для мобильного устройства и персонального компьютера:
|
Мобильная платформа |
Платформа для персонального компьютера |
|
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/.
26.2. Интерфейс приложения
Интерфейс приложения является аналогом интерфейса Такси, с возможностью переключения между окнами с помощью главного меню приложения. Навигация в приложении зависит от того, какая форма активна в данный момент:
● Форма, для которой не установлен владелец и не сохраняющая данные.
● Например: форма списка, форма обработки.
● Форма открывается командой из меню функций – в левой части заголовка окна находится кнопка открытия главного меню приложения. Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства или специальной кнопки.
● Форма открывается другими командами или из встроенного языка – в левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была вызвана команда открытия закрываемой формы. Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Форма с установленным владельцем.
● Например: форма выбора, форма объекта, открытая из списка.
● При последовательно открытии таких окон образуется цепочка открытых окон, в которой пользователю доступна только самая последняя открытая форма. При этом закрытие текущей формы приводит к активизации предыдущей формы цепочки, т. е. той формы, откуда была открыта закрываемая форма. Следует понимать, что возврат может произойти не в ту форму, в которой пользователь находился до того, как переключился на закрываемую форму.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Форма, для которой не установлен владелец и сохраняющая данные.
● Например: форма создания объекта, вызванная из главного меню приложения или с помощью встроенного языка.
● При закрытии такой формы будет активизирована та форма, которая была активной в тот момент, когда была вызвана команда открытия закрываемой формы.
● В левой части заголовка окна находится кнопка возврата в предыдущее окно (<). При этом текущее окно будет закрыто.
● Главное меню приложения доступно с помощью жеста с левой стороны экрана устройства.
● Формы, блокирующие интерфейс.
● Например: форма, для которой свойство Режим открытия окна установлено в значение Блокировать окно владельца или Блокировать весь интерфейс.
● В заголовке окна находится кнопка, связанная с командой формы:
● При наличии сохраняемых данных (признак реквизита Сохраняемые данные) – стандартная кнопка Отмена.
● При отсутствии сохраняемых данных – стандартная кнопка Закрыть.
● Если форма содержит команду Отмена, Закрыть, Нет – отображается эта команда.
● Главное меню приложения недоступно для формы, блокирующей весь интерфейс. Для формы, блокирующей окно владельца, главное меню приложения доступно с помощью жеста с левой стороны устройства.
При запуске мобильного приложения отображается полноэкранная картинка, заданная разработчиком приложения. В определенный момент времени в нижней части экрана появляется логотип и копирайт фирмы «1С», перекрывая часть заставки:
● В портретной ориентации – примерно 10% площади экрана.
● В ландшафтной ориентации – примерно 15% площади экрана.
26.3. Особенности использования
26.3.1. Глобальный командный интерфейс
Интерфейс мобильной платформы ориентирован на то, что в один момент времени на экране отображается одна форма. Под нее освобождается максимум свободного места на экране. Поэтому, команды, которые на персональном компьютере формируют командный интерфейс основного раздела (панели навигации и действий), собраны в главное меню приложения. Также это меню содержит команду возврата на начальную страницу, список разделов (команды каждого раздела отображаются в виде подменю), а также команды отображения информации о программе и перехода к списку приложений. Вызов главного меню приложения осуществляется жестом с левой стороны экрана (если доступно) или с помощью специальной кнопки ≡, расположенной в левой части заголовка окна.
Совет. При разработке командного интерфейса рекомендуется ориентироваться на возможности мобильной платформы.
Существует возможность настраивать ролевую видимость командного интерфейса (см. здесь).
26.3.2. Начальная страница
На начальной странице поддерживается отображение только одной формы. Выбор этой формы выполняется по следующим правилам:
● Из списка форм, указанных в настройках рабочей области начальной страницы исключаются формы, которые недоступны в соответствии с правами доступа;
● Затем из оставшегося списка исключаются формы, которые отключены функциональными опциями;
● Из оставшихся форм выбирается первая видимая форма, при этом обход форм рабочего стола идет сверху вниз, вначале левая колонка, затем правая (если задано расположение форм начальной страницы в две колонки).
Кроме формы, на начальной странице может располагаться командный интерфейс основного раздела. Состав командного интерфейса основного раздела на мобильной платформе аналогичен таковому на платформе для персонального компьютера (кроме группы См.также). Он отображается в виде матрицы кнопок (каждая кнопка связана с одной командой), сгруппированной по страницам. Картинка на кнопке получается из связанной команды. Если команда не обладает настраиваемой картинкой, используется стандартная картинка для данной группы команд.
Команды выводятся так чтобы максимально заполнить рабочую область окна. Группы команд размещается на страницах так, чтобы избежать переноса между страницами, т. е. если после одной группы команд вторая не помещается полностью в оставшееся место, то она начинается с новой страницы. Если все команды не помещаются на экран, то они размещаются на нескольких страницах, которые можно пролистывать.
26.3.3. Сообщения пользователю
Отображение сообщений пользователю зависит от того, сколько не просмотренных сообщений имеется в настоящий момент. Первое не просмотренное сообщение отображается в виде диалога с текстом сообщения и кнопкой ОК. После прихода второго сообщения в диалоге дополнительно появляется кнопка Все сообщения. В кнопке Все сообщения имеется подпись с полным количеством пришедших сообщений.
По нажатию на кнопку Все сообщения открывается панель сообщений, которая содержит все непрочитанные сообщения. Если в диалоге нажата кнопка ОК или закрывается панель сообщений, то список сообщений очищается. Нажатие на сообщение приводит к активации элемента формы, если сообщение связано с таковым. Для повторного открытия списка сообщений следует повторно вызвать действие, приводящее к открытию списка.
26.3.4. Форма
26.3.4.1. Общая информация
Для тех механизмов или объектов конфигурации, которые не поддерживаются мобильной платформой, будут недоступны свойства элементов формы, связанные с этим механизмом или объектом. Например, свойство Сочетание клавиш или события, связанные с перетаскиванием.
Принципы и правила формирования формы для мобильной платформы в основном совпадают с таковыми для тонкого клиента, однако, есть некоторые особенности, которые следует учитывать при разработке форм мобильного приложения:
● Экраны смартфонов, в основном, ориентированы на вертикальное расположение (портретная ориентация), поэтому форма существенно ограничена по своей ширине и слабо ограничена по высоте.
● Для мобильных устройств не принята прокрутка формы по горизонтали, т. к. полосы прокрутки на мобильных устройствах не отображаются постоянно, поэтому пользователь может не обратить внимания на то, что форма (отчет или таблица) показывают только фрагмент информации. В связи с этим, при формировании форм, разработчик обязан сам предпринимать усилия для того, чтобы все элементы формы помещались в ней по ширине, например, используя группы с группировкой Горизонтальная если возможно. Если таких усилий не предпринято, то форма будет ограниченно работоспособна, т. к. горизонтальная полоса прокрутки в формах на мобильной платформе не поддерживается.
26.3.4.2. Доступные элементы формы
В форме мобильного приложения можно использовать следующие элементы формы:
● Поля следующих видов:
● Поле ввода;
● Поле надписи;
● Поле переключателя;
● Поле картинки;
● Поле флажка;
● Поле индикатора;
● Поле полосы регулирования;
● Поле диаграммы;
● Поле табличного документа.
● Кнопка;
● Таблица;
● Декорация: надпись и картинка;
● Группы всех видов.
26.3.4.3. Расположение элементов формы
Группы, включая саму форму, и большая часть элементов формы, отображаются в виде списков, как это принято в мобильных интерфейсах. Элементы формы условно делятся на три типа:
1. Обязательно располагаются в строке списка. В эту группу входят следующие элементы:
1. Поле ввода;
2. Поле надписи;
3. Поле переключателя;
4. Кнопка;
5. Поле диаграммы.
2. Могут располагаться в строке списка. В группу входит декорация.
3. Не могу располагаться в строке списка. В эту группу входят все остальные элементы.
Под фразой «отображение списком» понимается следующее:
● Группа имеет фон, отличающийся от цвета формы.
● Строкой списка выступает либо элемент формы, либо группа с горизонтальной группировкой элементов.
● Элементы, расположенные в группе с горизонтальной группировкой, располагаются в одной строке.
● Элементы, расположенные в группе с вертикальной группировкой, располагаются каждый на своей строке.
● Если в группе с вертикальной группировкой находятся элементы, которые не могут располагаться в строке списка, то в списке отображается разрыв.
● Если группа обладает отображаемым заголовком, то перед группой формируется отступ.
● Визуальными разделителями строк являются горизонтальные линии, отображением которых нельзя управлять.
Особенностью поведения элементов 2 типа является то, что они располагаются в строке списка, только если сгруппированы с элементами 1 типа. Сами по себе элементы 2 типа в список не оформляются.
Многие элементы формы не имеют рамок (поля ввода и кнопки, у которых цвет рамки установлен в значение Авто). В связи с этим, выравнивание полей ввода на форме (как на платформе для персонального компьютера) не имеет практического смысла. Вместо него используется алгоритм выравнивания значений в полях ввода. В зависимости от наличия и расположения заголовка у поля ввода, информация в нем выравнивается по-разному:
● Заголовок поля отсутствует или отображается не слева, то числовые значения выравниваются вправо, а остальные – влево.
● Заголовок поля находится слева:
● В полях с редактированием текста – текст выравнивается влево.
● Числовые значения выравниваются вправо.
● Выравнивание полей остальных типов зависит от того, есть в группе с этими полями поле для редактирования текста или нет. Если такое поле есть, то выравнивание остальных полей осуществляется аналогично выравниванию этого поля. В противном случае – вправо.
Заголовок формы отображается только в заголовке окна и не дублируется на самой форме.
26.3.4.4. Особенности отображения элементов формы
26.3.4.4.1. Общие особенности
На форме не отображается отметка незаполненного как для элементов, расположенных на форме, так и для элементов, расположенных в таблице.
Заголовки полей выводятся без символов ":" в конце текста.
26.3.4.4.2. Форма
Свойство ТекущийЭлемент позволяет получить и установить текущий элемент формы. Однако установка текущего элемента формы не приводит к переходу этого элемента в режим редактирования и никак не отображается визуально.
Если при открытии формы выполняются какие-либо действия, то следует учитывать тот факт, что до окончания работы всех обработчиков формы не будет выполняться обновления экрана мобильного устройства.
26.3.4.4.3. Поле ввода
Для облегчения работы с полем ввода с помощью сенсорных экранов мобильных устройств, во всех полях, кроме полей ввода текста и полей, где используется автоподбор, редактирование значения непосредственно в поле ввода не предполагается. Поле ввода ведет себя как кнопка, заголовок которой отображает представление текущего значения, а нажатие этой кнопки открывает специализированный редактор. В том случае, если в поле ввода используется автоподбор, имеется возможность очистить значение с помощью кнопки Очистить, расположенной в левой части заголовка окна.
Длинное нажатие в поле ввода приводит к появлению контекстного меню, которое состоит из стандартных команд системы и команд, которые добавлены в это меню во время разработки.
Для отображения кнопок очистки, открытия и регулирования, следует установить в значение Да соответствующее свойство поле ввода. Кнопка выбора всегда не отображается, при этом событие НачалоВыбора срабатывает в момент нажатия на само поле ввода. Если для редактирования значения поля используется отдельная форма, то рядом с полем размещается специальный маркер (>), нажатие на который приведет к открытию этой формы. Расположение и внешний вид редакторов отличается на планшете и телефоне.
Многострочное поле ввода всегда работает в режиме ввода текста. Такое поле ввода не поддерживает выбор значений и автоподбор. Если поле ввода связано с данными, отличными от типа Строка, то для такого поля ввода игнорируется значение флажка МногострочныйРежим. Многострочное поле ввода может отображаться тремя различными способами:
1. Автоматическая подстройка высоты поля под высоту текст (чтобы избежать прокрутки). Происходит когда поле занимает всю ширину формы, не указана высота поля (свойство Высота) и поле может растягиваться по вертикали (свойство РастягиватьПоВертикали).
2. Поле имеет заданную высоту и допустима вертикальная прокрутка внутри поля. Происходит когда указана высота поля (свойство Высота) и поле не может растягиваться по вертикали (свойство РастягиватьПоВертикали).
3. Поле занимает максимально возможное место на форме. Происходит когда указана высота поля (свойство Высота) и поле может растягиваться по вертикали (свойство РастягиватьПоВертикали).
Значение свойства Подсказка ввода не отображается в многострочном поле ввода.
26.3.4.4.4. Поле флажка
Флажок может отображать только два состояния. При работе под управлением ОС iOS флажок всегда отображается в виде тумблера.
26.3.4.4.5. Поле переключателя
Поле переключателя вида Переключатель всегда выводится в отдельной вертикальной группе (количество колонок не настраивается). Поле переключателя вида Переключатель не комбинируется с другими элементами в одной строке.
Поле переключателя вида Тумблер всегда выводится в одной строке (количество колонок не настраивается).
26.3.4.4.6. Кнопка
В том случае, когда кнопка расположена в вертикальной группе, она растягивается до ширины родительской группы. Текст внутри кнопки выравнивается по центру кнопки, кроме случая, когда цвет рамки кнопки отличается от значения по умолчанию – в этом случае текст выравнивается по левому краю кнопки.
26.3.4.4.7. Группа
При отображении групп управляемой формы поддерживается только отступ для групп с режимом отображения Обычное выделение и Сильное выделение.
26.3.4.4.8. Страницы
Группа вида Страницы позволяет реализовать несколько вариантов панели с закладками. Вид панели (и ее поведение) зависит от значения свойства Отображение закладок:
● Закладки сверху.
● Закладки отображаются в виде тумблера. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в конце текст отображается символ …. Картинки в заголовках не отображаются.
● Страницы расположены внутри группы под списком закладок.
● Активная закладка отображается инверсией заголовка.
● Закладки снизу.
● Закладки отображаются в виде панели кнопок. Если текст заголовка не помещается в отведенное место, то он сокращается так, что в конце текст отображается символ …. Картинки в заголовках отображаются, при этом текст всегда отображается под картинкой.
● Страницы расположены внутри группы над списком закладок.
● Если на экране не хватает места для отображения заголовков всех страниц группы, то в конец списка добавляется кнопка Еще. Нажатие на эту кнопку открывает список заголовков всех страниц группы.
● Закладки слева.
● Закладки выводятся в виде списка. Нажатие на закладку приводит к открытию нового окна с содержимым закладки, которое замещает текущую форму (со списком закладок). Для возврата к списку закладок служит специальная кнопка (<), расположенная в левой верхней части заголовка страницы.
● Пролистывание.
● Закладки выводятся в виде точек под страницами. Текст и картинки не отображаются. Переключение между страницами выполняется жестом слева-направо или справа-налево в области страниц.
● Страницы расположены внутри группы над точками, описывающими количество закладок.
● В платформе для персонального компьютера данное значение интерпретируется как значение Закладки слева.
● Закладки справа.
● Не поддерживается мобильной платформой.
26.3.4.4.9. Таблица
Главным отличием таблицы в мобильном приложении от таблицы в платформе для персонального компьютера является работа с текущей строкой. В таблице на платформе для персонального компьютера всегда существует текущая строка. На мобильной платформе текущая строка появляется только на время обработки интерактивного действия пользователя, которое выполняется с этой таблицей. Это отличие обуславливает большинство различий в поведении мобильной платформы, которые описаны далее.
Свойства ТекущаяСтрока, ТекущийЭлемент, ТекущиеДанные определены только во время выполнения:
● обработчика контекстной команды;
● событий активизации строки или ячейки;
● событий редактирования строки.
В остальное время эти свойства таблицы имеют значение Неопределено.
Свойство ТекущийРодитель определено в следующих случаях:
● в иерархических списках – всегда;
● при отображении дерева – только в тех случаях, когда определено свойство ТекущаяСтрока.
При выборе строки одиночным нажатием на нее, вызываются события активизации (строки, ячейки, поля). Если при этом свойство таблицы РежимВыбора установлено в значение Истина, то после события активизации строки также вызывается событие ВыборЗначения.
Таблица в мобильной платформе никогда не имеет горизонтальной прокрутки. В связи с этим:
● игнорируется фиксация колонок в таблице;
● значение свойства ГоризонтальнаяПолосаПрокрутки игнорируется;
● колонки, которые не помещаются в видимой части таблицы, не отображаются.
Таблица в мобильном приложении может отображаться в трех режимах:
● основной режим;
● режим выбора нескольких строк;
● режим сортировки строк.
Основной режим аналогичен режиму отображения таблицы на платформе для персонального компьютера, за исключением отображения текущей и выбранных строк. В мобильной платформе эти строки не отображаются. Исключением служит кратковременная подсветка текущей строки таблицы при открытии формы. Таблица формы автоматически подстраивается под размер содержимого в том случае, если одновременно выполняются следующие условия:
● таблица занимается всю ширину формы;
● не задана фиксированная высота таблицы;
● таблица растягивается по вертикали;
● в объекте, который отображается таблица, содержится менее 100 строк данных. Если строк более 100 – будет доступна прокрутка.
Режим выбора нескольких строк характеризуется специальной колонкой с флажками, с помощью которых и выполняется выбор. Колонка всегда отображается самой первой. В этом режиме контекстные команды таблицы доступны и действуют на все выделение сразу.
Режим сортировки строк характеризуется наличием специальной колонки с маркером, за который можно таскать строку. Эта колонка всегда отображается самой последней. В этом режиме недоступны контекстные команды таблицы.
Режим множественного выделения в таблице (свойство РежимВыделения установлено в значение Множественный) на мобильной платформе визуально никак не отображается. Признаком его существования служит специальная команда Выбор нескольких, которая доступна в командной панели, связанной с таблицей. При выборе этой команды таблица переходит в режим выбора нескольких строк.
Если установлен режим множественного выбора (свойство МножественныйВыбор установлено в значение Истина), то таблица сразу находится в режиме выбора нескольких строк, при этом команда перехода в этот режим в командной панели отсутствует.
Если в таблице доступно изменение порядка строк (например, табличная часть документа), то для активизации этого режима необходимо выполнить специальную команду Перестановка строк, которая доступна в командной панели, связанной с таблицей. В этом случае таблица переходит в режим сортировки строк, и сбрасываются выделенные строки (если они были).
Для таблицы поддерживаются только два режима ввода строк (свойство РежимВводаСтрок): в конце списка и в конце окна. Всегда используется режим выделения строки – Строка (свойство РежимВыделенияСтроки). Фактическое значение свойства игнорируется.
Таблица формы поддерживает использование контекстного меню, которое открывается жестом от правой границы таблицы или длительным нажатием на строку.
Заполнение командной панели и контекстного меню имеет важные отличия от платформы для персонального компьютера. На платформе для персонального компьютера вопрос распределения команд между командной панелью и контекстным меню – это вопрос дизайна формы. На мобильной платформе (в силу отсутствия текущей строки) это вопрос функциональной модели. Если команда использует свойства таблицы, связанные с текущей строкой, то такая команда должна располагаться в контекстном меню. Если такая команда размещена разработчиком в другом месте, то система может принудительно переместить ее в контекстное меню. Исключением из этого правила выступает случай, когда команда может выполнять свою работу как в связи с текущей строкой, так и без таковой. В качестве примера можно привести команду Создать динамического списка, отображающего данные иерархического справочника. Внеконтекстное использование команды предполагает создание элемента в корне справочника, а контекстное – в текущей группе.
Для того чтобы указать системе, что команда оперируется данными текущей строки, предназначено свойство команды формы ИспользованиеТекущейСтроки. Для того чтобы связать команду формы с таблицей, чьи данные она должна обрабатывать, служит свойство команды ИспользуемаяТаблица. Использование данного свойства означает, что на мобильной платформе невозможно реализовать команду, оперирующую одновременно данными более одной таблицы. Для управления размещением команды существует свойство команды ОтображениеВКонтекстномМеню:
● Авто – команда, которая использует данные текущей строки, всегда располагается в контекстном меню. Команда, которая не использует данные текущей строки – всегда располагается в командной панели таблицы.
● ТолькоВКонтекстномМеню – команда всегда расположена в контекстном меню.
● ДополнительноВКонтекстномМеню – команда располагается в контекстном меню и в командной панели таблицы.
● Нет – команда располагается только в командной панели таблицы.
Управление расположением строки поиска также отличается от платформы для персонального компьютера. В зависимости от значения свойства таблицы ПоложениеСтрокиПоиска, возможно следующее поведение:
● Авто – строка поиска доступна по нажатию кнопки командной панели;
● Верх, Командная панель – строка поиска расположена над таблицей;
● Нет – строка поиска отсутствует.
Обновление данных, отображаемых таблицей, можно осуществлять в стиле, принятом на мобильных устройствах: путем попытки потянуть список вниз или вверх при достижении первой или последней (соответственно) строки отображаемых данных (pull to refresh). Для управления данной возможностью предназначено свойство таблицы ЗапросОбновления:
● Нет – обновление можно выполнить только через команду командной панели таблицы;
● Любое другое значение означает, что обновление можно инициировать попыткой потянуть список в соответствующую сторону. При этом в области таблицы за пределами данных отображается анимация вращающейся звезды.
При выполнении обновления списка, таким образом, будет вызван обработчик таблицы ОбработкаЗапросаОбновления. В том случае, если таблица адаптируется под содержимое (условия адаптации описаны выше в данном разделе), то обработчик таблицы ОбработкаЗапросаОбновления вызываться не будет.
Если динамический список, связанной с таблицей, не содержит отображаемых данных, то внутри таблицы отображается надпись Нет данных для отображения. Таблица, не связанная с динамическим списком, не отображает никакого текста при отсутствии данных для отображения.
При прокрутке таблицы, связанной с динамическим списком, в ее верхней и нижней частях появляются полупрозрачные кнопки, нажатие на которые приводит к переходу в начало или конец списка.
26.3.4.4.10. Отображение строк таблиц
Вместо редактирования данных в строке таблицы, связанной с табличной частью или таблицей значений, мобильная платформа предоставляет специальную системную форму. Эта форма содержит все отображаемые на родительской форме колонки текущей строки таблицы. При использовании этой формы необходимо помнить о следующих особенностях:
● Колонки, для которых установлено свойство Только просмотр, отображаются в системной форме также без возможности редактирования;
● В системной форме не отображаются поля типа картинка и надпись;
● На системную форму действует условное оформление формы;
● Вызываются все обработчики событий;
● Системная форма не редактируется в конфигураторе и ее нельзя модифицировать из встроенного языка.
После возврата из режима редактирования, редактируемая строка кратковременно подсвечивается.
26.3.4.5. Динамический список
Динамический список, используемый в мобильной платформе, имеет следующие особенности:
● Поддерживается управление настройками динамического списка с помощью встроенного языка. Для интерактивной настройки необходимо самостоятельно реализовать соответствующие формы настройки.
● Не поддерживается интерактивный вывод списка;
● Имеется возможность выполнять сортировку по нажатию на заголовок. По нескольким колонкам таким образом сортировать нельзя.
26.3.4.6. Панели формы
Панель навигации формы реализована с помощью специального меню, которое отображается в нижней части формы в виде переключателя. Нажатие кнопки переключателя приводит к открытию соответствующей формы.
Командная панель формы:
● В режиме отображения сверху:
● Командная панель находится в заголовке формы, правее текста.
● Если командная панель содержит стандартные пары команд ОК-Отмена и Да-Нет, то кнопка с отрицательным действием переносится в левую часть заголовка формы, а положительная отображается в командной панели формы. В меню Еще присутствуют все команды, кроме команды с отрицательным действием, которая была перенесена в заголовок формы.
● Если командная панель не содержит вышеуказанных пар команд, но содержит стандартную команду формы Отмена, Нет или Закрыть, то кнопка с такой командой переносится в панель в заголовке слева.
● Команда, которая размещена в левой части заголовка формы, будет отображаться специальным символом (<), но будет выполнять свою изначальную функцию.
● При отображении кнопки в командной панели формы учитывается свойство Отображение этой кнопки. Свойства команды, связанной с этой кнопкой, игнорируются при определении режима отображения кнопки.
● Если командная панель содержит кнопку по умолчанию, то она всегда отображается в заголовке первой.
● Если свободного места в правой части заголовка достаточно для отображения оставшихся команд – они отображаются там. В противном случае отображается кнопка Еще и система пытается сделать так, чтобы кнопка Еще не была единственной: если команда, отображаемая в правой части заголовка еще не определена, то ей станет первая команда из списка оставшихся команд, а остальные будут расположены в меню Еще.
● В режиме отображения снизу:
● Фиксируется при прокрутке формы.
● При появлении клавиатуры не отображается.
В список стандартных команд не включаются команды непосредственного удаления (для объектов ссылочного типа), вызова справки, вывода списка, изменения формы. Стандартные команды Записать и закрыть и Провести и закрыть отображаются в командных панелях с заголовком Готово.
Для прикладных решений, работающих под управлением ОС iOS, необходимо помнить о том, что системные механизмы закрытия формы не задают пользователю вопрос о необходимости сохранения данных в том случае, когда закрывается форма с модифицированными данными.
Командная панель, связанная с таблицей, располагается сверху или снизу таблицы и по ширине не превышает ширины самой таблицы. При прокрутке таблицы командная панель всегда остается в видимой области.
26.3.5. Работа с файлами
Все приложения на мобильных устройствах работают в рамках специального механизма, обеспечивающего безопасное исполнение программ («песочница», sandbox). В рамках этого механизма, приложениям предоставляется ограниченный доступ к файловой системе мобильного устройства. При разработке мобильного приложения может требоваться доступ к файловой системе, например для промежуточного хранения данных или записи документов, сформированных в системе, для последующего обмена с другими компьютерами.
Для получения доступа к таким местам файловой системы предназначены специальные функции:
● КаталогВременныхФайлов() – возвращает каталог временных файлов данного приложения. При необходимости может быть очищен операционной системой;
● РабочийКаталогДанныхПользователя() – возвращает каталог, в котором рекомендуется хранить «долговременные» данные пользователя.
● КаталогДокументов() – каталог документов, которые предназначены для обмена с внешним (по отношению к мобильному приложению) окружением.
Вне зависимости от реальных возможностей мобильной ОС, не рекомендуется использовать для работы любые другие каталоги файловой системы мобильного устройства из соображений безопасности, а также требований разработчиков мобильных ОС к прикладным приложениям.
26.3.6. Отчеты
Формирование отчетов на мобильной платформе возможно двумя разными способами:
● Обработка существующих данных и формирование собственно отчета на встроенном языке;
● Реализация на мобильной платформе некоторой формы, с помощью которой можно задать параметры формирования отчета (отборы и т. д.), а само формирование передать в удаленную систему, которая вернет табличный документ для отображения на мобильном устройстве.
Выбор одного из этих вариантов зависит от некоторого набора факторов:
● Содержит или нет информационная база мобильного приложения все данные, которые необходимы для построения отчета;
● Наличие и качество канала связи между мобильным устройством и удаленной системой;
● Какова сложность отчета;
● Каким образом построен обмен с удаленной системой;
● Каким образом предполагается работа с отчетом;
● И т. д.
Если принято решение формировать отчет на мобильном устройстве, то необходимо помнить об особенностях мобильной платформы (см. здесь). Для получения данных доступны выборки, а для построения отчета доступно программное формирование табличного документа (на основании макета) и диаграмм (если таковые требуются).
Если для мобильного приложения доступны постоянные высокоскоростные каналы связи с удаленной системой, которое обладает всеми необходимыми данными для формирования требуемого отчета, то возможным вариантом может служить реализация на мобильном приложении только интерфейсной части отчета (задание отборов, обработка расшифровки и т. д.). Собственно формирование отчета в этом случае будет происходить в удаленном приложении, а возвращаться будет готовый отчет для отображения на устройстве.
При этом возможны и все промежуточные варианты, например, если реализован периодический обмен, можно настройки отчета сформировать на мобильном устройстве и передать на удаленную систему во время сеанса обмена, а обратно получить сформированный отчет для отображения.
Для взаимодействия с удаленным приложением можно использовать Web-сервис (который предоставляет удаленное приложение), обмен данными с помощью плана обмена и т. д.
При необходимости реализации расшифровки отчета, нужно понимать, что мобильное приложение самостоятельно может выполнить только просмотр значений, указанных в качестве расшифровки ячейки отчета. Остальные действия необходимо реализовывать на встроенном языке, включая получение нового варианта отчета с учетом наложенных отборов и т. д.
26.3.7. Работа с картинками
Мобильное приложение работает на различных мобильных устройствах. Одной из отличительных особенностей этих устройств является разрешение и физический размер их (устройств) экранов. Это отличие характеризуется понятием dpi (или ppi) – количеством точек на дюйм размера экрана. Чем больше значение dpi, тем меньшее физическое место будет занимать картинка с фиксированными физическими размерами.
Чтобы картинка лучше соответствовала различным экранам, существует возможность указывать картинку набором, в котором каждая картинка соответствует определенному интервалу dpi экрана мобильного устройства. При этом мобильная платформа автоматически подбирает нужную картинку (из набора), опираясь на параметры конкретного физического устройства. Прикладной программист не должен предпринимать никаких действий, чтобы была показана нужная картинка.
Набор картинок представляет собой архив zip-формата, который содержит картинки, описание которых приводится в файле манифеста (manifest.xml), расположенной в этом же архиве. Картинка может относиться к одному из вариантов разрешения экрана:
● lpdi – соответствует экранам с разрешением менее 140 dpi;
● mdpi – соответствует экранам с разрешением от 140 до 180 dpi;
● hdpi – соответствует экранам с разрешением от 180 до 270 dpi;
● xdpi – соответствует экранам с разрешением более 270 dpi.
Имя каждой картинки может быть любым, а соотношение между именем картинки и разрешением указывается в манифесте. Соотношение размеров картинок в архиве можно выразить следующим соотношением: m=1,5*l, h=2*l, x=3*l. Т.е. если размер картинки на панель инструментов равен 16 точкам, то в наборе должны быть картинки следующих размеров: ldpi=16, mdpi=24, hdpi=32, xdpi=48 точек.
Также в архиве могут находиться так называемые шаблонные картинки. Это картинки, информативная часть которых присутствует только в альфа-канале модели RGBA. Значения остальных каналов в такой картинке должны формировать белый цвет (R=255, G=255, B=255). Шаблонную картинку рекомендуется формировать в формате PNG (32 бита на пиксель). При отображении такой картинки поле, отведенное под картинку, будет заполняться текущим цветом фона, а цветом текста (с соответствующей интенсивностью) будут отображаться те места картинки, для которых в альфа-канале установлены значения, отличающиеся от полной прозрачности (A=0).
В архиве обязательно должна присутствовать картинка для разрешения ldpi (базовая картинка). Остальные картинки являются необязательными. В случае отсутствия нужной картинки, система будет использовать ближайшую подходящую.
Архив с картинками может быть помещен:
● в библиотеку картинок;
● в реквизиты объектов конфигурации, имеющие тип Картинка;
● в объект Картинка,ХранилищеЗначения,ДвоичныеДанные, созданный во встроенном языке.
При создании архива рекомендуется использовать картинки формата .png. Если в архив помещаются картинки, которые используют сжатие (png, jpg и т. д.), то не рекомендуется создавать архив со сжатием. В противном случае рекомендуется создавать архив со сжатием.
Базовая картинка используется в следующих случаях:
● в прикладном решении, работающим под управлением «1С:Предприятия» для персонального компьютера;
● при экспорте картинки в другие форматы данных;
● при передаче данных с сервера на клиент.
Для устройств на ОС iOS используются следующие картинки из набора:
● обычные экраны – картинка mdpi;
● экраны Retina – картинки xdpi.
Для устройств на ОС Android используются картинки, соответствующие разрешению экрана используемого устройства.
Манифест (manifest.xml) должен соответствовать следующей схеме:
<xs:complexType name="PictureVariant"> xs:sequence </xs:sequence> <xs:attribute name="name" type="xs:Name" use="required"/> <xs:attribute name="screenDensity" type="tns:PictureVariantScreenDensity" use="required"/> <xs:attribute name="isTemplate" type="xs:boolean" default="false"/> </xs:complexType> <xs:simpleType name="PictureVariantScreenDensity"> <xs:restriction base="xs:string"> <xs:enumeration value="ldpi"/> <xs:enumeration value="mdpi"/> <xs:enumeration value="hdpi"/> <xs:enumeration value="xdpi"/> </xs:restriction> </xs:simpleType>
Если картинка с вариантами создавалась в конфигураторе, то при ее выгрузке в файл, манифест может иметь такой вид:
26.3.8. Работа с ролями и пользователями
При работе с ролями в мобильном приложении следует помнить, что из всех прав доступа, которые предоставляет платформа для персонального компьютера, на мобильной платформе доступен только ограниченный набор. Этот набор прав призван обеспечить функционирование различных механизмов, обеспечивающих интерфейс мобильного приложения. Права, которые могут использовать на мобильной платформе, отмечены символом «*» в полном списке прав (см. здесь).
Также имеется возможность выполнять ролевую настройку формы (см. здесь), настраивать ролевую видимость командного интерфейса (см. здесь).
Внимание! Права для доступа к данным (Чтение, Добавление, Изменение, Удаление и т. д.) не поддерживаются мобильной платформой.
Методы управления привилегированным режимом в мобильной платформе используются для совместимости с платформой для персонального компьютера. Сами вызовы методов работы с привилегированным режимом мобильной платформой игнорируются и никаких действий мобильная платформа не выполняет.
При определении прав пользователя действует стандартная схема: если в информационной базе не заданы пользователи, то для определения прав доступа используется свойство конфигурации ОсновныеРоли (см. здесь). Если для доступа к данным мобильного приложения используется пользователь, то права доступа определяются по составу ролей этого пользователя.
Мобильная платформа имеет ограниченный набор средств работы с пользователями информационной базы:
● В информационной базе может существовать только один пользователь. Попытка создать более одного пользователя приводит к генерации исключения.
● Пользователь может быть создан только с помощью программного кода. Интерактивное создание пользователей в конфигураторе не приведет к передаче пользователя на мобильное устройство.
● Мобильная платформа не предлагает средств аутентификации при старте мобильного приложения. Если пользователь указан в списке пользователей, то этот пользователь автоматически будет установлен в качестве пользователя текущего сеанса.
В результате можно рекомендовать следующую схему работы от лица пользователей с разными правами:
1. Выполняется создание пользователя с нужным набором ролей или выполняется изменение набора ролей у существующего пользователя.
2. Выполняется перезапуск мобильного приложения с помощью конструкции ЗавершитьРаботуСистемы(Ложь, Истина);.
26.3.9. Полнотекстовый поиск
Описание особенностей использования полнотекстового поиска в мобильной платформе см. здесь.
26.4. Специальные возможности
26.4.1. Работа с телефонией
Мобильная платформа предоставляет набор возможностей, которые позволяют выполнять звонки из мобильных приложений. Звонки можно выполнять как с подтверждением пользователя, так и без такового. Также система предоставляет доступ к журналу звонков. Прикладное решение может определить возможности по работе с телефонией. Для этого предназначены методы ПоддерживаетсяНаборНомера() и ПоддерживаетсяЖурналЗвонков() объекта СредстваТелефонии. При работе мобильного приложения на ОС iOS, невозможно получить доступ к журналу звонков.
Набор номера выполняется следующим образом:
Если СредстваТелефонии.ПоддерживаетсяНаборНомера() Тогда СредстваТелефонии.НабратьНомер(НомерТелефона, ВызватьСразу); КонецЕсли;
Параметр ВызватьСразу отвечает за то, как будет выполняться вызов абонента:
● Параметр равен значению Истина – в этом случае при выполнении метода номер начинает набираться автоматически. На экране появляется стандартный интерфейс программы работы со звонками.
● Параметр равен значению Ложь – в этом случае при выполнении метода будет открыто приложение работы со звонками, в котором будет установлен заданный номер. Пользователю останется только нажать кнопку начала вызова.
Мобильные устройства, функционирующие под управление ОС Android, предоставляют возможность доступа к журналу звонков. Имеется возможность перебрать записи журнала с установкой необходимого отбора. Для работы с журналом необходимо использовать метод ПолучитьЖурналЗвонков() объекта СредстваТелефонии.
Следующий пример демонстрирует получение списка всех пропущенных звонков на мобильном устройстве.
Если СредстваТелефонии.ПоддерживаетсяЖурналЗвонков() Тогда Журнал = СредстваТелефонии.ПолучитьЖурналЗвонков(); Отбор = Новый ОтборКомпоновкиДанных; НовыйЭлемент = Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных")); НовыйЭлемент.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("ТипЗвонка"); НовыйЭлемент.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно; НовыйЭлемент.ПравоеЗначение = ТипЗвонкаЖурналаЗвонков.Пропущенный; НовыйЭлемент.Использование = Истина; ЗаписиЖурнала = Журнал.НайтиЗаписи(Отбор); Для каждого Запись Из ЗаписиЖурнала Цикл // обработка списка звонков КонецЦикла; КонецЕсли;
При работе с журналом звонков следует помнить, что отбор журнала выполняется с помощью объекта ОтборКомпоновкиДанных.
26.4.2. Работа с сообщениями (SMS и MMS)
Мобильная платформа предоставляет набор инструментов, позволяющих работать с сообщениями (SMS и MMS). Предоставляется возможность отправлять и получать сообщения. Доступ к списку сообщений не предосталвяется. Отправка сообщений возможна как в интерактивном, так и в полностью программном режиме (не интерактивном режиме).
Платформа предоставляет средства для определения возможностей используемой мобильной ОС. Для этого у объекта глобального контекста СредстваТелефонии существуют методы ПоддерживаетсяОтправкаSMS(), ПоддерживаетсяПриемSMS() и ПоддерживаетсяОтправкаMMS(). В зависимости от используемой мобильной операционной системы, существуют следующие ограничения на работу с сообщениями:
● Для ОС iOS:
● Недоступна подписка на получение SMS/MMS;
● Недоступна не интерактивная отправка SMS/MMS.
● Для ОС Android:
● Недоступна не интерактивная отправка MMS.
Сообщение в «1С:Предприятии» представлено объектом SMSСообщение. Отправка сообщения выглядит следующим образом:
&НаКлиенте
Процедура ОтправитьСМС(Кому, Текст, ПослатьИнтерактивно)
СМС = Новый SMSСообщение();
СМС.Текст = Текст;
СтрокаПолучатели = СтрЗаменить(Кому, ",", Символы.ПС);
Для Счетчик=1 По СтрЧислоСтрок(СтрокаПолучатели) Цикл
СМС.Получатели.Добавить(СокрЛП(СтрПолучитьСтроку(СтрокаПолучатели, Счетчик)));
КонецЦикла;
СредстваТелефонии.ПослатьSMS(СМС, ПослатьИнтерактивно);
КонецПроцедуры
В качестве значения параметра Кому могут быть переданы несколько номеров телефонов, разделенных символом «,». Параметр ПослатьИнтерактивно определяет, как будет отправлено сообщение:
● Параметр имеет значение Истина – сообщение будет отправлено сразу;
● Параметр имеет значение Ложь – будет открыто приложение для работы с сообщениями (установленное по умолчанию для используемой мобильной ОС). В этом приложении будет открыта форма отправки сообщения с заполненными полями. В этом случае пользователю необходимо самому нажать кнопку отправки сообщения.
Система не предоставляет доступа к журналу сообщений, однако имеется возможность подписаться (если это позволяет используемая мобильная ОС) на оповещения о получении сообщений.
&НаКлиенте Процедура ПодключитьОбработчикПолученияСообщений() ПолучательСообщений = Новый ОписаниеОповещения("ПолучениеСообщения", ЭтотОбъект); СредстваТелефонии.ПодключитьОбработчикSMSСообщений(ПолучательСообщений); КонецПроцедуры &НаКлиенте Процедура ПолучениеСообщения(Сообщение, ДополнительныеПараметры) Экспорт Сообщить(Сообщение.Отправитель + " – " + Сообщение.Текст); КонецПроцедуры
При получении входящего сообщения, будет вызываться обработчик оповещения для обработки полученного сообщения. Сообщения, полученные с помощью установленного обработчика оповещения, также будут доступны и из системного приложения по работе с сообщениями.
Для того чтобы SMS-сообщение было преобразовано в MMS-сообщение, необходимо добавить вложения в сообщения. Это делается с помощью свойства Вложения объекта SMSСообщение. При этом в качестве значения свойства ТипСодержимого объекта MMSВложение следует указывать MIME-тип передаваемых данных, например, для jpeg-файла это будет image/jpeg.
26.4.3. Средства геопозиционирования
26.4.3.1. Общая информация
Большое количество мобильных устройств поддерживают определение координат, по которым располагается устройство. Также имеется возможно выполнять преобразование полученных координат в адрес и наоборот. Для доступа к этим функциям предназначен провайдер геопозиционирования. Каждый провайдер описывается именем и определенным набором параметров (возможностей). Конкретный провайдер геопозиционирования может поддерживать не все возможности.
Общая схема работы со средствами геопозиционирования выглядит следующим образом:
1. Выбирается необходимый провайдер геопозиционирования. В каждом случае следует выбирать тот провайдер, который максимально подходит для реализации поставленной задачи. В общем случае стоит выбирать провайдера, который обеспечивает минимальное энергопотребление и максимальную точность определения координат.
Пример:
// Определим провайдера, который не приводит к расходованию средств и // использует для определения координат сеть сотовой связи ИскомыйПровайдер = Неопределено; Провайдеры = СредстваГеопозиционирования.ПолучитьПровайдеров(); Для каждого Провайдер Из Провайдеры Цикл Если НЕ Провайдер.Платный и Провайдер.ИспользуетСотовуюСеть Тогда ИскомыйПровайдер = Провайдер; Прервать; КонецЕсли; КонецЦикла; Если ИскомыйПровайдер = Неопределено Тогда Сообщить("Требуемый провайдер не обнаружен"); Иначе Сообщить("Найден провайдер: " + ИскомыйПровайдер.Имя); КонецЕсли;
В случае необходимости получить самый энергоэффективный провайдер или самый точный провайдер, можно воспользоваться методами ПолучитьСамогоЭнергоЭкономичногоПровайдера() или ПолучитьСамогоТочногоПровайдера() (соответственно).
2. Выполняется определение координат с помощью выбранного провайдера геопозиционирования. Для получения координат используются два метода. Метод ПолучитьПоследнееМестоположение() возвращает последние данные о местоположении, полученные выбранным провайдером. Среди свойств объекта ДанныеМестоположения (который возвращает метод ПолучитьПоследнееМестоположение()), есть свойство Дата, которое описывает, когда были получены данные о местоположении. Если эти данные были получены очень давно, то необходимо вызвать метод ОбновитьМестоположение() для того, чтобы провайдер геопозиционирования заново определил данные о местоположении. Один из параметров метода определяет тайм-аут на определение местоположения. В том случае, если метод завершен по тайм-ауту, фактическое определение координат в данном случае зависит от особенностей реализации конкретной версии мобильной операционной системы.
Пример:
// Если местоположение на данном устройстве ни разу не выполнялось // или выполнено более часа назад – обновить местоположение и // получить определенные координаты Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера); Если Координаты = Неопределено ИЛИ ТекущаяДата()-Координаты.Дата > 3600 Тогда СредстваГеопозиционирования.ОбновитьМестоположение(ИмяПровайдера, 60); Координаты = СредстваГеопозиционирования.ПолучитьПоследнееМестоположение(ИмяПровайдера); КонецЕсли;
3. При необходимости, выполняется подписка на изменение координат. После того, как потребность в подписке отпала – можно отключить оповещение об изменении координат.
После получения данных о местоположении, имеется возможность выполнить несколько вспомогательных операций, связанных с полученным местоположением:
● Получить адрес по координатам. Для этого предназначен метод ПолучитьАдресПоМестоположению().
● Получить координаты места по адресу. Для этого предназначен метод ПолучитьМестоположениеПоАдресу().
● Показать карту, на которой отображены координаты одной (или нескольких) точки. Для этого предназначен метод ПоказатьНаКарте(). При этом на iOS всегда будет использовать приложение Карты фирмы Apple, а на ОС Android – приложение Карты фирмы Google.
Примечание. Для работы методов преобразования координат в адрес и обратно, на мобильном устройстве должен быть доступ в Интернет.
26.4.3.2. Получение ключа для работы с Google Maps
Внимание! Описание консоли разработчика приводится по состоянию на момент написания документации.
Для того чтобы мобильное приложение могло работать с геопозиционированием под управлением ОС Android, необходимо получить специальный ключ для работы с Google Maps. Для этого необходимо выполнить следующие действия:
1. Необходимо войти в консоль разработчика (Google Developers Console, https://console.developers.google.com/project).
2. Необходимо создать проект (кнопка Create Project).
3. После окончания создания проекта перейдите в свойства проекта (Projects – <Имя вашего проекта> – Overview).
4. Необходимо включить возможность использования сервиса Google Maps. Для этого необходимо выбрать пункт меню APIs & auth – APIs (в левой части окна веб-браузера). Затем необходимо найти Google Maps Android API v2 в списке Browse APIs и включить его (нажать кнопку Enable API).
5. Необходимо получить ключ программного интерфейса (API Key). Для этого следует выбрать пункт меню APIs & auth – Credentials (в левой части окна веб-браузера). В разделе Public``API``Access следует нажать кнопку Create``new``Key. В открывшемся диалоге выбрать кнопку Android key. Затем необходимо создать группу мобильного приложения в сборщике мобильных приложений (предварительно выполнив настройку сборщика мобильных приложений) и скопировать содержимое поля Параметр получения ключа для работы с картами Google. Скопированные данные необходимо ввести в форму на сайте Google, в поле ввода, расположенное в нижней части формы. Затем следует нажать кнопку Create.
6. После окончания формирования ключа, он будет отображен в поле API KEY. Получившееся значение необходимо указать в поле Ключ для работы с картами Google, находящееся в форме группы мобильного приложения. Затем необходимо сохранить группу мобильного приложения.
26.4.4. Работа с мультимедиа
Мобильные устройства обладают различными мультимедийными возможностями: сделать фотоснимок, сделать аудио– или видеозапись. Для различных мобильных устройств эти возможности могут быть доступны или нет. Для определения возможности выполнения той или иной операции предоставляются специальные функции: ПоддерживаетсяФотоснимок(), ПоддерживаетсяВидеозапись(), ПоддерживаетсяАудиозапись(). В том случае, если мобильное устройство поддерживает ту или иную возможность, можно воспользоваться методом глобального контекста, который активирует необходимое системное приложение для выполнения нужного действия: СделатьФотоснимок(), СделатьВидеозапись(), СделатьАудиозапись().
Выполнение программы на встроенном языке будет ожидать выполнения требуемого действия.
В связи с тем, что мобильные устройства могут обладать двумя камерами (передней и задней), платформа предоставляет мобильному приложению возможность работать с камерами по выбору. Для этого следует использовать системное перечисление ТипКамерыУстройства при определении возможностей мобильного устройства и при выполнении того или иного действия.
Передняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Передняя); Задняя = СредстваМультимедиа.ПоддерживаетсяФотоснимок(ТипКамерыУстройства.Задняя);
Вышеприведенный программный код позволяет определить, какая из двух камер устройства поддерживает фотосъемку. С помощью этих методов можно определять наличие той или иной камеры на устройстве. При выполнении фото– или видеосъемки, также имеется возможность указать используемую камеру. Если тип камеры указан как ТипКамерыУстройства.Авто, то на устройствах это будет обрабатываться следующим образом:
● На устройстве имеется две камеры – будет использована задняя камера;
● На устройстве имеется одна камера – будет использована эта камера (в зависимости от наличия).
Кроме того, при попытке сделать фотоснимок или выполнить видеосъемку, имеется возможность указать некоторые дополнительные параметры, влияющие на результат действия.
При попытке выполнить фотосъемку имеется возможность (кроме типа камеры) дополнительно указать:
● С каким разрешением необходимо выполнить съемку. Если указано разрешение, не поддерживаемое устройством, будет выбрано ближайшее подходящее разрешение. Перечень поддерживаемых разрешений можно получить с помощью метода ПолучитьПоддерживаемыеРазрешенияКамеры() объекта СредстваМультимедиа. Для устройств, работающих под управлением ОС iOS, данный параметр игнорируется.
● С каким качеством будет получен результирующий снимок. Фактически определяет степень сжатия jpeg-файла. 100 – означает максимальное качество.
● Какой снимок должен быть получен в результате: цветной или черно-белый. Для устройств, работающих под управлением ОС iOS, указание на необходимость получить черно-белый снимок, не влияет на интерфейс камеры (но сам снимок будет черно-белым).
При попытке выполнить видеосъемку, кроме указания типа камеры, имеется возможность указать качество получаемого ролика. Устройства, работающие под управлением ОС iOS, игнорируют этот параметр.
26.4.5. Сканирование штрихкодов
Мобильное устройство, обладающее камерой, позволяет выполнять функции сканирования штрихкодов. Для доступа к этой возможности платформа предоставляет специальный интерфейс.
Примечание. Для эффективного сканирования штрихкодов желательно, чтобы камера мобильного устройства обладала возможностью автоматической наводки объектива камеры на резкость (автофокусом). В противном случае сканирование штрихкодов будет затруднено.
Общая схема работы со сканером штрикодов выглядит следующим образом:
1. Определяется возможность работы с механизмом сканирования. Для этого необходимо использовать метод ПоддерживаетсяСканированиеШтрихКодов() объекта глобального контекста СредстваМультимедиа.
2. В том случае, если сканирование поддерживается, метод ПоказатьСканированиеШтрихКодов() объекта СредстваМультимедиа открывает специальный интерфейс по сканированию штрихкодов. При выполнении операции сканирования вызывается специальный обработчик, содержащий информацию о результате сканирования.
3. Закрыть интерфейс сканирования можно или вручную, с помощью стандартной кнопки перехода к предыдущей форме интерфейса ОС Android или программно, с помощью метода ЗакрытьСканированиеШтрихКодов() объекта СредстваМультимедиа.
Рассмотрим пример работы с данным механизмом. Для демонстрации будет использоваться простая форма, на которой расположена кнопка открытия интерфейса сканирования и признак закрытия этого интерфейса после однократного сканирования. Сканированный штрихкод будет выводиться в виде сообщения.
Примечание. Данный пример не является законченным инструментом. Он предназначены для демонстрации работы с механизмом сканирования штрихкодов.
В форме необходимо создать реквизит ЗакрытьИнтерфейс типа Булево и разместить его на форме. Также следует создать команду формы ОткрытьИнтерфейсСканирования, которую также следует разместить на форме. Модуль формы будет иметь следующий вид:
// Обработчик команды формы ОткрытьИнтерфейсСканирования &НаКлиенте Процедура ОткрытьИнтерфейсСканирования(Команда) ОбработчикСканирования = Новый ОписаниеОповещения("ОбработкаСканирования", ЭтотОбъект); ОбработчикЗакрытия = Новый ОписаниеОповещения("ОбработкаЗакрытияИнтерфейса", ЭтотОбъект); СредстваМультимедиа.ПоказатьСканированиеШтрихКодов("Наведите камеру на штрихкод", ОбработчикСканирования, ОбработчикЗакрытия); КонецПроцедуры &НаКлиенте Процедура ОбработкаСканирования(Штрихкод, Результат, Сообщение, ДополнительныеПараметры) Экспорт Если Результат Тогда Текст = "" + Штрихкод; Иначе Текст = "Ошибка: " + Сообщение; КонецЕсли; Если ЗакрытьИнтерфейс Тогда СредстваМультимедиа.ЗакрытьСканированиеШтрихКодов(); КонецЕсли; Сообщить(Текст); КонецПроцедуры &НаКлиенте Процедура ОбработкаЗакрытияИнтерфейса(ДополнительныеПараметры) Экспорт Сообщить("Закрывается интерфейс сканирования"); КонецПроцедуры &НаКлиенте Процедура ПриОткрытии(Отказ) Если НЕ СредстваМультимедиа.ПоддерживаетсяСканированиеШтрихКодов() Тогда ВызватьИсключение "Сканирование штрихкодов не поддерживается"; КонецЕсли; ЗакрытьИнтерфейс = Ложь; КонецПроцедуры
При открытии интерфейса сканирования в метод ПоказатьСканированиеШтрихКодов() передается два описания оповещения. Первое оповещение срабатывает (параметр <ОбработчикСканирования>) в том случае, когда система успешно распознала штрихкод, второе оповещение (параметр <ОбработчикЗакрытия>) срабатывает в том случае, когда закрывается оконо, предназначенное для сканирования штрихкода. Закрытие может быть как программное, так и интерактивное. Пример программного закрытия приведен в обработчике оповещения ОбработкаСканирования(), а интерактивное закрытие можно выполнить, нажав кнопку Назад в интерфейсе сканирования.
При открытии формы сканирования можно определить, на какие штрихкоды будет «реагировать» система: на линейные (например, EAN), на двухмерные (например, QR-код) или на все. Задается это с помощью параметра <ТипШтрихКода> метода ПоказатьСканированиеШтрихКодов(). При этом надо помнить, что указание на необходимость распознавать все типы штрихкодов снижает «производительность» сканирования, т. к. система будет тратить больше времени на поиск в изображении различных штрихкодов.
26.4.6. Работа с электронной почтой
Мобильная платформа предоставляет прикладному разработчику несколько способов работы с электронной почтой. Один способ позволяет реализовать полноценный почтовый клиент на платформе «1С:Предприятие» (объект ИнтернетПочта и связанные объекты), а другой способ позволяет реализовать только отправку почтовых сообщений с помощью приложения по работе с электронной почтой, установленное в системе по умолчанию (объект СредстваПочты).
При отправке почтовых сообщений типа ТипТекстаПочтовогоСообщения.HTML с помощью объекта СредстваПочты (под управлением ОС Android) выполняется конвертация текста сообщения в формат Spannable. Отправляемое письмо отображается большинством почтовым клиентов.
При использовании текстов почтовых сообщений с типом ТипТекстаПочтовогоСообщения.HTML (под управлением ОС Android) не рекомендуется использовать следующие возможности:
● каскадные таблицы стилей;
● встроенные таблицы;
● встроенные изображения;
● шрифты разных размеров.
Рекомендуется проверять отображение электронных писем на максимальном количестве устройств, чтобы минимизировать зависимость от различий реализации на разных ОС и в разных версиях почтовых программ.
Также следует помнить, что тип текстов почтовых сообщений ТипТекстаПочтовогоСообщения.РазмеченныйТекст не поддерживается объектом СредстваПочты.
26.4.7. Работа с контактами
Список контактов – это база данных, которая хранит информацию о субъектах, с которыми общается владелец мобильного устройства. Описание контакта содержит идентификационные данные контакта, адреса, телефоны и другую информацию, необходимую для связи с субъектом. Также, на мобильном устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор информации, которые пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На мобильном устройстве всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
Каждая запись в списке контактов связана с какой-либо одной учетной записью. Мобильная ОС может выполнять синхронизацию списка контактов с данными учетной записи (зависит от настроек ОС). Если контакт связан с локальной учетной записью, то синхронизация информации не выполняется и все данные расположены только на мобильном устройстве.
Основная информация о контакте хранится в объектах типа ДанныеКонтакта. Объекты данного типа содержат всю информацию о контакте, но не содержат связь контакта с учетной записью. В описании контакта есть несколько типов данных, которые могут содержать более одного значения. Такими данными являются номера телефонов, адреса, адреса электронной почты и другие. Для хранения таких данных предназначены массивы объектов типа ЭлементДанныхКонтакта. Для хранения списка идентификаторов в программах мгновенных сообщений предназначен массив объектов ЭлементДанныхКонтактаМгновенныеСообщения.
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта УчетнаяЗаписьКонтактов.
Связь между учетной записью контактов и собственно элементов списка контактов образует объект ДанныеКонтактаУчетнойЗаписи. Кроме информации о контакте и учетной записи, данный объект содержит также идентификатор, по которому выполняется синхронизация между списком контактов на мобильном устройстве и учетной записью. Можно сказать, что свойство ГлобальныйКлючКонтакта объекта ДанныеКонтактаУчетнойЗаписи является аналогом свойства Ссылка для прикладных объектов «1С:Предприятие».
Для идентификации контакта на мобильном устройстве существует объект ЛокальныйКлючКонтакта. Все операции с контактами (создание, изменение, удаление, поиск) выполняются с использованием данного объекта. Для выполнения операций с контактами следует использовать менеджер контактов (одноименный объект).
Следующий пример демонстрирует создание элемента списка контактов в локальной учетной записи:
&НаКлиенте Процедура СоздатьЭлементКонтакта(Имя, Отчество, Фамилия, ЭлектроннаяПочта, Телефон) ДанныеКонтакта = Новый ДанныеКонтакта; ДанныеКонтакта.Имя = Имя; ДанныеКонтакта.Отчество = Отчество; ДанныеКонтакта.Фамилия = Фамилия; ЭлементПочта = Новый ЭлементДанныхКонтакта(ТипАдресаЭлектроннойПочтыДанныхКонтакта.Рабочий, ЭлектроннаяПочта); ДанныеКонтакта.АдресаЭлектроннойПочты.Добавить(ЭлементПочта); ЭлементТелефон = Новый ЭлементДанныхКонтакта(ТипНомераТелефонаДанныхКонтакта.Рабочий, Телефон); ДанныеКонтакта.НомераТелефонов.Добавить(ЭлементТелефон); МК = Новый МенеджерКонтактов; ЛокальныеКонтакты = МК.ПолучитьЛокальнуюУчетнуюЗаписьКонтактов(); Контакт = Новый ДанныеКонтактаУчетнойЗаписи(ДанныеКонтакта, ЛокальныеКонтакты); МК.ДобавитьКонтакт(Контакт); КонецПроцедуры
26.4.8. Работа с календарем
На мобильных устройствах имеется возможность просмотра календаря и заведения в нем различных событий. События характеризуются некоторым набором характеристик, таких как дата и время начала и завершения, описание, занятые лица и т. д. Также, на мобильном устройстве могут быть зарегистрированы учетные записи различных сервисов. Под учетной записью понимается набор информации, которые пользователь использует для идентификации себя в каком-либо сервисе. Например, это имя пользователя и пароль. На мобильном устройстве всегда существует учетная запись, описывающая само устройство (локальная учетная запись).
На мобильном устройстве может быть несколько календарей (с разными именами). Каждый календарь связан с какой-либо одной учетной записью. Мобильная ОС может выполнять синхронизацию событий календарей с данными учетной записи (зависит от настроек ОС). Если события календаря связаны с локальной учетной записью, то синхронизация информации не выполняется и все данные расположены только на мобильном устройстве.
Основная информация о календаре хранится в объекте ДанныеКалендаря. События календаря описываются объектом ДанныеСобытияКалендаря. Данные объекты описывают характеристики календаря или события календаря, но не описывают, с какой учетной записью связан объект.
Учетные записи, зарегистрированные на данном мобильном устройстве для синхронизации контактов, описываются с помощью объекта УчетнаяЗаписьКалендарей.
Связь между данными календарей и событий и учетными записями образуется объектами ДанныеКалендаряУчетнойЗаписи и ДанныеСобытияКалендаряУчетнойЗаписи. Эти объекты, кроме информации о собственно данных и информации об учетной записи, хранят информацию значения ключей, по которым выполняется синхронизация между мобильным устройство и сервисом, с которым выполняется синхронизация. Для синхронизации данных о календарях используется ГлобальныйКлючКалендаря, для синхронизации данных о событиях календарей используется ГлобальныйКлючСобытияКалендаря.
Для идентификации данных календарей и событий на мобильном устройстве существует объекты ЛокальныйКлючКалендаря и ЛокальныйКлючСобытияКалендаря. Все операции с календарями и событиями (создание, изменение, удаление, поиск) выполняются с использованием данного объекта. Для выполнения операций с календарями и событиями следует использовать менеджер календарей (одноименный объект).
26.4.9. Ориентация экрана
Платформа предоставляет информацию о некоторых характеристиках экрана устройства, на котором выполняется клиентское приложение (персональный компьютер или мобильное устройство). Для этого служит метод ПолучитьИнформациюЭкрановКлиента(). В результате возвращается массив структур, описывающих экраны, подключенные к устройству.
Каждый элемент массива описывает один экран, подключенный к устройству. Параметры Высота и Ширина описывают, соответственно, высоту и ширину экрана в точках. При этом для мобильного устройства эти параметры зависят от ориентации устройства (если это разрешено в настройках), а платформы для персонального компьютера всегда возвращает канонические параметры подключенных экранов. Таким образом, на мобильном устройстве можно анализировать, в каком положении находится устройство и на основании этого принимать решения о трансформации интерфейса приложения. Для облегчения работы с ориентацией существует событие ПриИзмененииПараметровЭкрана, которое можно обработать в модуле управляемого приложения и в модуле управляемой формы.
В качестве примера рассмотрим изменение отображения формы, отображаемой на рабочем столе. В указанной форме есть два списка, которые отображают некоторую информацию. При портретной ориентации экрана (узкая сторона устройства – нижняя) списки будут отображаться друг под другом, а при ландшафтной (широкая сторона устройства – нижняя) ориентации – списки расположены рядом. Для реализации такого поведения в модуле формы, расположенной на рабочем столе, следует разместить обработчик события ПриИзмененииПараметровЭкрана следующего вида:
&НаКлиенте Процедура ПриИзмененииПараметровЭкрана() МассивИнформаций = ПолучитьИнформациюЭкрановКлиента(); Если МассивИнформаций[0].Ширина > МассивИнформаций[0].Высота Тогда ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Горизонтальная; Иначе ЭтаФорма.Группировка = ГруппировкаПодчиненныхЭлементовФормы.Вертикальная; КонецЕсли; КонецПроцедуры
26.4.10. Работа с уведомлениями
26.4.10.1. Общая информация
При работе информационной системы регулярно возникает необходимость оповестить пользователя о каком-либо событии. Событие может возникать как по расписанию, так и в случае возникновения другого события. Само событие может наступить как на мобильном устройстве, которым владеет пользователь, так и в каком-то другом месте информационной системы.
Для извещения пользователя о наступлении событий служат уведомления. Они могут создаваться локально или рассылаться с помощью push-сервисов. Локальные уведомления служат для информирования о событиях, которые происходят на устройстве пользователя. Обычно источником push-уведомлений выступает центральный узел информационной системы. С помощью push-уведомлений он информирует удаленных пользователей о том, что изменились данные, важные для пользователей. Однако это не единственный сценарий использования push-уведомлений. Push-уведомления могут рассылать специализированные сервисы, информирующие о курсах валюты, результатах спортивных состязаний, прогнозах погоды и т. д.
26.4.10.2. Локальные уведомления
Локальные уведомления служат для извещения о событиях, которые происходят непосредственно на мобильном устройстве. Локальные уведомления бывают моментальными и запланированными. Они используются для информирования о разных событиях и, кроме того, их отличает поведение на мобильном устройстве. Моментальные уведомления используются в том случае, когда необходимо «здесь и сейчас» оповестить пользователя о наступлении события, например завершении какого-либо процесса. Таким процессом может быть операция синхронизации с внешней системой. Запланированные уведомления позволяют в назначенное время напомнить пользователю о необходимости выполнить какую-либо операцию. Запланированное уведомление может быть однократным или периодическим. Однократное запланированное уведомление можно использовать, например, если в системе помечено, что какому-то контрагенту необходимо перезвонить в определенное время. Повторяемое запланированное уведомление можно использовать, например, в том случае, когда какая-то операция повторяется каждый день, вне зависимости от внешних событий.
Чтобы использовать локальные уведомления, следует установить разрешение Локальные уведомления (см. здесь). Сборщик мобильных приложений добавляет соответствующее разрешение для собираемого мобильного приложения. Следует учитывать, что мобильная платформа разработчика обладает всеми разрешениями для работы с локальными уведомлениями. Поэтому рекомендуется после окончания разработки механизма проверить его функционирование на обычной мобильной платформе. Для этого следует воспользоваться сборщиком мобильных приложений и проверить работоспособность получившегося мобильного приложения на мобильном устройстве.
Для работы с локальными уведомлениями используется менеджер доставляемых уведомлений (свойство глобального контекста ДоставляемыеУведомления) и объект ДоставляемоеУведомление. Объект описывает собственно уведомление (включая параметры его отображения), а с помощью менеджера выполняется управление механизмом уведомлений.
Рассмотрим создание локальных уведомлений более подробно.
&НаКлиенте Функция СоздатьУведомление(Заголовок, Текст, Данные = 0, ДатаСрабатывания, ИнтервалПовторения = 0) Уведомление = Новый ДоставляемоеУведомление; Уведомление.Заголовок = Заголовок; Уведомление.Текст = Текст; Уведомление.Данные = Данные; Уведомление.ДатаПоявленияУниверсальноеВремя = ДатаСрабатывания; Уведомление.ИнтервалПовтора = ИнтервалПовторения; Уведомление.ЗвуковоеОповещение = ЗвуковоеОповещение.ПоУмолчанию; Возврат Уведомление; КонецФункции &НаКлиенте Процедура ЗадатьУведомление(Команда) Уведомление = СоздатьУведомление("Заголовок", "Текст", 2014, '00010101'); ДоставляемыеУведомления.ДобавитьЛокальноеУведомление(Уведомление); КонецПроцедуры
При создании уведомления следует помнить о следующих особенностях:
● Дата и время первого отображения уведомления задается в формате универсального времени (UTC). Для перевода из локального времени можно использовать функцию глобального контекста УниверсальноеВремя().
● Если свойство ДатаПоявленияУниверсальноеВремя задано пустым значением (или не задано вовсе), то уведомление будет отображено сразу. Таким уведомлением можно извещать пользователя о том, что мобильное приложение завершило какую-то длительную операцию, например, завершило операцию синхронизации данных.
● Если необходимо, чтобы уведомление появлялось регулярно, следует использовать свойство ИнтервалПовтора объекта ДоставляемоеУведомление. В результате можно реализовать простой вариант безусловного таймера, который по истечении заданного интервала времени будет формировать уведомление. Значение, описывающее интервал повторения уведомления, зависит от используемой мобильной операционной системы. Особенности указания интервала описаны в синтакс-помощнике. Система не предоставляет возможности указать дату и время окончания срабатывания уведомления.
● При необходимости, имеется возможность установить наклейку – число, отображаемое в шторке уведомлений (ОС Android) или поверх иконки приложения (ОС iOS). Для этого служит свойство Наклейка. При работе под управлением ОС iOS имеется возможность устанавливать и получать значение наклейки с помощью методов УстановитьНаклейку() и ПолучитьНаклейку() менеджера доставляемых уведомлений.
● При отображении уведомления имеется возможность воспроизвести некоторую мелодию. Для указания воспроизводимой мелодии служит свойство ЗвуковоеОповещение объекта ДоставляемоеУведомление. Если в качестве значения этого свойства установлено значение системного перечисления ЗвуковоеОповещение.ПоУмолчанию, то будет воспроизводиться мелодия, установленная для уведомлений в используемой операционной системе. Если в качестве значения свойства ЗвуковоеОповещение указано имя файла, то будет воспроизведен именно этот файл. Однако на мобильной платформе разработчика отсутствует возможность подключать ресурсы (к которым относятся воспроизводимые файлы). Для того, чтобы указанный файл был прикреплен к мобильному приложению, следует воспользоваться возможностями сборщика мобильных приложений (см. здесь). В силу этого, проверить использование звуковых оповещений из файлов можно только на обычной мобильной платформе.
В ряде случаев может возникать необходимость удалять установленные (но еще не наступившие) уведомления. Такое может потребоваться в тех случаях, когда действие, для напоминания о котором установлено уведомление, уже выполнено. Для удаления уведомления можно использовать метод ОтменитьЛокальныеУведомления() менеджера доставляемых уведомлений. При этом следует помнить, что отменяются сразу все локальные уведомления, которые были установлены данным мобильным приложением, и время срабатывания которых еще не наступило.
После появления уведомления, нажатие на него приведет к запуску (или активизации) приложения. Однако этого может оказать недостаточно для полноценной обработки уведомления. В этом случае можно воспользоваться обработчиком уведомлений. Подключается этот обработчик с помощью метода ПодключитьОбработчикУведомлений() менеджера доставляемых уведомлений.
&НаКлиенте Процедура ПриОткрытии(Отказ) Обработчик = Новый ОписаниеОповещения("ОбработчикУведомлений", ЭтотОбъект); ДоставляемыеУведомления.ПодключитьОбработчикУведомлений(Обработчик); КонецПроцедуры &НаКлиенте Процедура ОбработчикУведомлений(Уведомление, Локальное, Показано, ДополнительныеПараметры) Экспорт // Важные и нужные действия КонецПроцедуры
В результате, после того, как пользователь мобильного приложения нажмет на уведомление, будет активизировано мобильное приложение, создавшее уведомление, и в этом приложении будет вызван обработчик уведомления. В рамках этого обработчика можно реализовать необходимую обработку уведомления. Следует помнить, что объект, который передается в параметре Уведомление, содержит реальные данные только в свойствах Текст и Данные. Остальные свойства заполнены значениями по умолчанию.
Также следует отметить, что уведомление может отображаться в шторке уведомлений, а может не отображаться. Для оповещения мобильного приложения об этом, в обработчик уведомлений передается параметр Показано. Так, если мобильное приложение запущено и активно, то локальное уведомление не будет отображено на экране, но обработчик уведомлений будет вызван, а параметр Показано будет установлен в значение Ложь. В этом случае задача привлечения внимания пользователя лежит на прикладном разработчике.
26.4.10.3. PUSH-уведомления
26.4.10.3.1. Общая информация
Push-уведомления (далее в этом разделе термины «уведомление» и «push-уведомление» используются равнозначно) предназначены для оповещения о событиях, которые произошли где-то в другом месте. Например, в корпоративной информационной системе изменились какие-то данные, важные для мобильных пользователей системы.
При работе с push-уведомлениями используются несколько различных систем:
1. Собственно мобильное приложение. Получает уведомления и реализует реакцию на них со стороны мобильного устройства.
2. Прикладное решение, которое занимается рассылкой уведомлений (отправитель). В роли отправителя выступает прикладное решение, созданное на платформе «1С:Предприятие».
3. Сервис доставки уведомлений. Этот сервис обеспечивает передачу уведомление от отправителя получателю (мобильному приложению). В качестве такого сервиса выступает Apple Push Notification Service (APNs, https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html, на английском языке) и Google Cloud Messaging (GCM, http://developer.android.com/intl/ru/google/gcm/index.html, на английском языке).
4. Фирмой «1С» разработан специальный вспомогательный сервис для отправки уведомлений. Этот сервис предназначен для облегчения реализации отправки уведомлений из тиражных прикладных решений. При работе под управлением iOS сервис позволяет изолировать получателей уведомлений одного отправителя, от других отправителей, которые работают с тем же мобильным приложением. Кроме того, сервис позволяет избежать публикации сертификата мобильного приложения (что необходимо при непосредственной работе с сервисом APNs). Особенности работы с этим сервисом будут описаны далее, в соответствующих разделах. Следует понимать, что сервис фирмы «1С» не может работать без использования APNs и GCM. Сервис расположен по адресу https://pushnotifications.1c.com.
В общем случае отправка уведомления выглядит следующим образом:
● Отправитель формирует уведомление;
● Отправитель определяет список получателей уведомления;
● Отправитель подключается к сервису уведомлений;
● Отправитель передает сервису уведомление и список получателей;
● Сервис обеспечивает доставку уведомлений на мобильные устройства;
● Мобильное приложение на устройстве обеспечивает обработку уведомлений.
Сервис доставки push-уведомлений не гарантирует доставки уведомления до мобильного устройства.
Чтобы использовать уведомления, следует установить разрешение Push-уведомления (см. здесь). Сборщик мобильных приложений добавляет соответствующее разрешение для собираемого мобильного приложения. Работа с мобильной платформой разработчика имеет некоторые особенности, которые будут рассмотрены ниже. В любом случае, рекомендуется после окончания разработки механизма проверить его функционирование на обычной мобильной платформе. Для этого следует воспользоваться сборщиком мобильных приложений и проверить работоспособность получившегося мобильного приложения с использованием всех сервисов доставки уведомлений.
Обработка push-уведомления мало отличается от обработки локального уведомления (см. здесь). Очевидно, что параметр Локальное будет иметь значение Ложь, если обработчик будет вызван для обработки push-уведомления.
26.4.10.3.2. Схема работы с сервисами рассылки уведомлений
Для понимания работы с push-уведомлениями, следует учитывать, что в процессе разработки и внедрения системы участвуют несколько различных ролей. В ряде случаев исполнители ролей могут объединяться, но само количество ролей остается неизменным:
● Разработчик мобильного приложения – занимается разработкой мобильного приложения (получателя уведомлений). Реализует всю необходимую функциональность приложения для получения уведомлений.
● Разработчик отправителя уведомлений – занимается разработкой информационной системы, которая занимается рассылкой уведомлений и механизма получения и хранения идентификаторов получателей уведомлений.
● Пользователь мобильного приложения – использует мобильное приложение. Настройка мобильного приложения также выполняется этим пользователем, поэтому настройки мобильного приложения должны быть максимально просты и понятны даже неподготовленному пользователю.
● Внедренец отправителя – занимается установкой и настройкой системы-отправителя уведомлений в сети пользователя системы.
При рассмотрении схем работы с тем или иным сервисом, описание действий будет происходить от лица носителя той или иной роли.
Схема работы содержит описание действий, которые надлежит выполнить представителю той или иной роли в момент выполнения своих действий. Порядок описания действий всегда будет одинаковый (разработчик мобильного приложения, разработчик отправителя, внедренец отправителя, пользователь мобильного приложения), однако это не означает, что физический порядок действий будет ровно таким же.
Кроме действий, описанных далее в разделе, реализация следующих этапов считается обязательной, и далее про них отдельно упоминаться не будет:
● Реализация реакции на уведомление – выполняет разработчик мобильного приложения;
● Реализация отправки уведомлений – выполняет разработчик отправителя.
Также считается, что мобильное приложение и отправитель «знают» о том, что они могут взаимодействовать друг с другом:
● Отправитель имеет некоторый публичный программный интерфейс (сервис обмена) для того, чтобы:
● Предоставить мобильному приложению номер проекта GCM (если таковой необходим для функционирования системы).
● Получить идентификатор получателя уведомления от мобильного приложения.
● Получатель (мобильное приложение) умеет использовать сервис обмена, который публикует отправитель для выполнения обеих действий.
Далее будут рассмотрены действия (по ролям), которые необходимо выполнить для работы с тем или иным сервисом отправки уведомлений. Пошаговые инструкций для выполнения конкретных шагов будут приведены далее в данном разделе.
APNs
Разработчик мобильного приложения должен:
● Зарегистрировать для мобильного приложения возможность получения push-уведомлений на сайте компании Apple. При регистрации следует получить специальный сертификат.
● Предоставить полученный сертификат отправителю уведомлений.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения сертификатов получателей уведомлений.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Загрузить в систему-отправителя сертификат мобильного приложения, которое будет получать уведомления.
● Сертификат должен быть получен у разработчика мобильного приложения.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
GCM
Разработчик мобильного приложения должен:
● Реализовать ввод и хранение номеров проектов тех экземпляров системы отправителя, уведомления от которых может получать мобильное приложение.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения ключа программного интерфейса (API KEY) и номера проекта для каждого экземпляра системы-отправителя уведомлений. Регистрацию конкретного экземпляра отправителя на сайте Google выполняет внедренец отправителя.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Выполнить регистрацию конкретного экземпляра отправителя на сайте Google. Получившийся ключ программного интерфейса (API KEY) и номер проекта указать в соответствующих настройках отправителя.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать выполнения команды (или команд) для получения номера проекта (который сохранен в информационной базе отправителя), создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
Сервис фирмы «1С»
В силу того, что прямое общение с сервисами APNs и GCM существенно различается, фирмой «1С» был реализован специальный сервис, который несколько упрощает процесс отправки и получения уведомления для тиражных решений.
Разработчик мобильного приложения должен:
● Выбрать, какие сервисы будут использоваться для доставки уведомлений на мобильное устройство:
● При необходимости указать в сервисе фирмы «1С», что мобильное приложение может получать уведомления с помощью сервиса APNs. Для этого следует выполнить регистрацию мобильного приложения на сайте Apple и предоставить полученный сертификат мобильного приложения сервису фирмы «1С».
● При необходимости указать в сервисе фирмы «1С», что мобильное приложение может получать уведомления с помощью сервиса GCM. Использовать специальный номер проекта 797785657074, если получать уведомления планируется только через сервис фирмы «1С». Если планируется получать уведомления от множества приложений, зарегистрированных на сайте Google, необходимо реализовать ввод и хранение номеров проектов тех экземпляров системы отправителя (например, с помощью сервиса обмена), уведомления от которых может получать мобильное приложение. Регистрацию конкретного экземпляра отправителя на сайте Google выполняет внедренец отправителя.
● Реализовать получение идентификатора получателя уведомлений и доставку получившегося объекта отправителю уведомлений.
Разработчик отправителя должен:
● Реализовать механизм ввода и хранения ключа программного интерфейса (API KEY Отправителя) для текущего экземпляра системы-отправителя уведомлений. Регистрацию конкретного экземпляра отправителя на сайте сервиса фирмы «1С» выполняет внедренец отправителя.
● Реализовать механизм получения и хранения идентификаторов получателей уведомлений.
Внедренец отправителя должен:
● Выполнить регистрацию конкретного экземпляра отправителя на сайте сервиса фирмы «1С». Получившийся ключ программного интерфейса (API KEY Отправителя) ввести в соответствующие настройки отправителя.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать команду создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
26.4.10.3.3. Работа с сервисом APNs
Для проверки работы механизма отправки уведомлений на ОС iOS, необходимо самостоятельно собрать собственную мобильную платформу разработчика. При сборке следует использовать специальный профиль обеспечения (provision profile), для которого разрешена возможность работать с push-уведомлениями. Кроме того, для «собственной» мобильной платформы разработчика необходимо указать новый идентификатор мобильного приложения, при этом идентификаторы com.e1c.mobile и com.e1c.mobile.ios использовать не смогут, т. к. они зарезервированы для использования фирмой «1С».
Для установки соединения с APNs, на отправляющем компьютере должен быть доступен удостоверяющий сертификат мобильного приложения получателя уведомлений. Сертификаты для APNs бывают двух видов Apple Development IOS Push Services (сертификат разработчика) и Apple Production IOS Push Services (сертификат публичного мобильного приложения). Сертификат разработчика предназначен для разработки мобильного приложения и его отладки. Его следует использовать, если приложение установлено на устройство с помощью средств разработки. Сертификат публичного мобильного приложения следует использовать, если мобильное приложение распространяется через магазин приложений.
В связи с этим, мобильная платформа предъявляет следующие требования к сертификату:
● Сертификат приложения должен быть предоставлен в формате .PEM.
● Сертификат должен содержать секцию Bag Attributes, в которой должен присутствовать атрибут friendlyName. По значению атрибута friendlyName платформа различает сертификат разработчика и сертификат публичного мобильного приложения. Сертификат без атрибута friendlyName будет отвергнут платформой «1С:Предприятие».
Внимание! Описание консоли разработчика приводится по состоянию на момент написания документации.
Для подготовки к рассылке уведомлений с использованием APNs, разработчик мобильного приложения должен выполнить следующие действия:
1. Необходимо войти в консоль разработчика (iOS Dev Center, https://developer.apple.com/devcenter/ios/index.action). Пользователь, от имени которого выполняется вход в консоль, должен иметь права администратора (в консоли разработчика).
2. В правой части окна веб-браузера необходимо выбрать пункт меню Certificates, Identifiers & Profiles в разделе iOS Developer Program.
3. Если у мобильного приложения, которое будет получать уведомления, отсутствует App ID, то его необходимо создать. Порядок создания описан ниже. Если App ID есть – следует пропустить этот пункт и перейти к следующему пункту.
1. В разделе iOS Apps выбрать пункт Identifiers.
2. Нажать кнопку + над списком iOS AppIDs. Если у пользователя недостаточно прав – кнопка создания будет недоступна.
3. В поле Name следует задать описание приложения (латинскими буквами). В разделе App ID Suffix выбрать пункт Explicit App ID. В поле Bundle ID следует указать полный идентификатор мобильного приложения (можно получить в сборщике мобильных приложений). В разделе App Services следует отметить пункт Push Notifications.
4. Для перехода к следующему экрану следует нажать Continue.
5. Следует проверить все указанные параметры и нажать кнопку Submit для подтверждения создания App ID.
6. Нажатие кнопки Done полностью завершает процесс создания App ID.
4. Необходимо создать профиль провизии (provision profile) для сборки мобильного приложения, которое может получать уведомления. Данный профиль провизии (provision profile) в дальнейшем должен быть использован в сборщике мобильных приложений.
1. Необходимо выбрать пункт меню Provisioning profiles – All в левой части экрана Certificates, Identifiers & Profiles.
2. Необходимо нажать кнопку + над списком iOS Provisioning Profiles.
3. Вид профиля выбирается в зависимости от того, для чего он создается. Если профиль провизии (provision profile) создается для разработки и отладки приложения, то в разделе Development необходимо выбрать пункт iOS App Development. Если профиль провизии (provision profile) создается для распространения приложения, то в разделе Distribution следует выбрать пункт App Store. В зависимости от выбранного типа профиля провизии (provision profile), дальнейшие шаги помощника создания профиля провизии (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. Не закрывайте окно веб-браузера с открытой консолью разработчика во время создания запроса сертификата.
1. Необходимо запустить утилиту Связка ключей.
2. Выбрать команду Связка ключей – Ассистент сертификации – Запросить сертификат у бюро сертификации.
3. В открывшемся диалоге необходимо заполнить поля, при этом в качестве значения поля E-mail пользователя рекомендуется указать тот адрес электронной почты, который указывался при регистрации в программе iOS Developer Program. В качестве значения свойства Запрос необходимо указать Сохранен на диске.
4. После нажатия кнопки Продолжить будет сформирован файл запроса сертификата *.certSigningRequest.
6. Формируем сертификат для отправителя уведомлений. Для этого необходимо вернуться в окно веб-браузера с открытой консолью разработчика.
1. Необходимо выбрать пункт меню Certificates – All в левой части экрана Certificates, Identifiers & Profiles.
2. Необходимо нажать кнопку + над списком iOS Certificates.
3. В зависимости от потребности, необходимо указать пункт Apple Push Notification service SSL (Sandbox) (если нужен сертификат для разработки и отладки приложения) или пункт Apple Push Notification service SSL (Production) (если нужен сертификат для распространяемого приложения). Затем следует нажать кнопку Continue.
4. Необходимо указать App ID используемого приложения и нажать кнопку Continue.
5. Необходимо нажать кнопку Continue. На данном экране предлагается создать файл запроса сертификата, который уже создан на предыдущем шаге.
6. Необходимо загрузить файл, сформированный на предыдущем шаге (с расширением .certSigningRequest) и нажать кнопку Generate.
7. После окончания формирования сертификата, его следует скачать с сайта с помощью кнопки Download.
7. Последним шагом необходимо выполнить конвертацию сертификата в необходимые форматы. Для этого необходим компьютер Mac, на котором формировался файл запроса сертификата:
1. Для конвертации также следует использовать программу Связка ключей.
2. Полученный на сайте сертификат загружается в Связку ключей.
3. Выполняется экспорт сертификата из Связки ключей в формате .P12.
4. Выполняется конвертация получившегося сертификата из формата .P12 в формат .PEM. Для этого следует в консоли OS X выполнить следующую команду:
openssl pkcs12 -in pushcert.p12 -out pushcert.pem -nodes -clcerts
Получившиеся сертификаты необходимы для:
● Сертификат в формате .P12 – необходим в том случае, если рассылка уведомлений выполняется с помощью сервиса фирмы «1С». Сертификат должен использовать разработчиком получателя для регистрации приложения-получателя уведомлений в сервисе фирмы «1С».
● Сертификат в формате .PEM – необходим в том случае, если уведомления будут отправляться непосредственно через сервис APNs, и в этом случае сертификат должен быть предоставлен разработчику отправителя или внедренцу отправителя (если интерфейс программы-отправителя уведомлений предусматривает возможность указания сертификата программы-получателя уведомлений).
26.4.10.3.4. Работа с сервисом GCM
Внимание! Описание консоли разработчика приводится по состоянию на момент написания документации.
Следующие действия должен выполнить внедренец приложения-отправителя во время развертывания и настройки приложения-отправителя в компьютерной сети заказчика:
1. Необходимо войти в консоль разработчика (Google Developers Console, https://console.developers.google.com/project).
2. Необходимо создать проект (кнопка Create Project).
3. После окончания создания проекта перейдите в свойства проекта (Projects – <Имя вашего проекта> – Overview). В верхней части формы, над надписью Project Dashboard, будет показан номер проекта (Project Number). Этот номер проекта необходим для того, чтобы мобильное устройство смогло сформировать идентификатор получателя.
4. Необходимо включить возможность использования сервиса GCM. Для этого необходимо выбрать пункт меню APIs & auth – APIs (в левой части окна веб-браузера). Затем необходимо найти Google Cloud Messaging for Android в списке Browse APIs и включить его (перевести переключатель Status в положение ON). После включения следует согласиться с тем, что вы принимаете соглашения об использовании, которые предлагаются консолью разработчика.
5. Необходимо получить ключ программного интерфейса (API Key). Для этого следует выбрать пункт меню APIs & auth – Credentials (в левой части окна веб-браузера). В разделе Public``API``Access следует нажать кнопку Create``new``Key. В открывшемся диалоге выбрать кнопку Server Key. Затем необходимо указать IP-адрес сервера, который будет выступать отправителем для вашего приложения. Другими словами в данном окне рекомендуется указать IP-адрес (или адреса) компьютера, с которого прикладное решение будет рассылать уведомления. Для тестовых проверок можно указать IP-адрес 0.0.0.0/0. Сменить список допустимых IP-адресов можно с помощью команды Edit allowed IPs.
6. После окончания формирования ключа, он будет отображен в поле API KEY. Получившееся значение необходимо использовать в качестве ключа аутентификации для отправки уведомлений (параметр ДанныеАутентификации метода Отправить() объекта МенеджерОтправкиДоставляемыхУведомлений). Рекомендуется относиться к данному ключу как к конфиденциальной информации. Получение данного ключа третьими лицами позволит им отправлять push-уведомления от вашего имени, например в случае, если при создании ключа не указывались конкретные значения IP-адресов.
Получившийся ключ программного интерфейса (API KEY) необходимо предоставить внедренцу приложения-отправителя для указания в настройках приложения. Вышеописанные действия не требуется выполнять, если рассылка уведомлений выполняется через сервис фирмы «1С».
26.4.10.3.5. Работа с сервисом фирмы «1С»
Разработчик мобильного приложения должен:
● Выполнить регистрацию в сервисе APNs (если он используется мобильным приложением).
● Необходимо зарегистрироваться на сайте сервиса https://pushnotifications.1c.com/signup. Для регистрации необходимо иметь действующий номер подвижной беспроводной радиотелефонной связи (мобильный номер). В процессе регистрации на него будет выслан код подтверждения регистрации. В контактных данных рекомендуется указывать данные ответственного лица разработчика мобильного приложения.
● Необходимо зарегистрировать мобильное приложение, которое будет выступать получателем уведомлений. Для этого следует выбрать пункт меню Доставляемые уведомления – Мобильные приложения и нажать кнопку Зарегистрировать приложение.
● Необходимо подключить созданное мобильное приложение к используемым сервисам (APNs и GCM). Для этого в списке Ваши мобильные приложения нажать ссылку Подключить к APNS и GCM. В зависимости от сервиса необходимо нажать кнопку + Подключить к APNS или + Подключить к GCM. В зависимости от используемого сервиса, необходимо предоставить следующие данные:
● Идентификатор мобильного приложения – для всех сервисов.
● Для APNs: сертификат мобильного приложения в формате .P12 (и его пароль).
Разработчик отправителя должен:
● Каких-либо действий не выполняется.
Внедренец отправителя должен:
● Необходимо зарегистрироваться на сайте сервиса https://pushnotifications.1c.com/signup. Для регистрации необходимо иметь действующий номер подвижной беспроводной радиотелефонной связи (мобильный номер). В процессе регистрации на него будет выслан код подтверждения регистрации. В контактных данных рекомендуется указывать данные администратора информационной системы.
● Зарегистрировать отправителя уведомлений. Для этого следует выбрать пункт меню Доставляемые уведомления – Отправители уведомлений и затем нажать кнопку Зарегистрировать отправителя. При регистрации рекомендуется указывать список IP-адресов, с которых будет допустимо рассылать уведомления с помощью данного сервиса. Если адреса не указаны – рассылка уведомлений допускается с любого компьютера, который может авторизоваться в сервисе.
Важно понимать, что регистрацию отправителя выполняет не разработчик отправителя, а внедренец отправителя в тот момент, когда выполняется настройка экземпляра системы-отправителя у пользователя.
● В результате регистрации будет сформирован специальный ключ доступа. Для сохранения этого значения следует нажать кнопку Скопировать Ключ доступа или нажать кнопку Редактировать и скопировать значение из поля Ключ доступа отправителя. Получившееся значение необходимо указать в настройках конкретного экземпляра приложения-отправителя. Оно будет использоваться в качестве ключа аутентификации для отправки уведомлений (параметр ДанныеАутентификации метода Отправить() объекта МенеджерОтправкиДоставляемыхУведомлений). Рекомендуется относиться к данному ключу как к конфиденциальной информации. Получение данного ключа третьими лицами позволит им отправлять push-уведомления от вашего имени, например в случае, если при создании отправителя не указывались конкретные значения IP-адресов.
Пользователь мобильного приложения должен:
● Указать мобильному приложению параметры сервиса обмена, который предоставляет приложение-отправитель.
● Инициировать выполнения команды для создания идентификатора получателя уведомлений и отправку его отправителю уведомлений.
26.4.10.3.6. Рассылка уведомлений
Действия по рассылке уведомлений практически не различаются для различных сервисов. Различия наблюдаются в значениях параметров метода отправки уведомлений. Собственно отправка происходит с помощью метода Отправить() менеджера доставки отправляемых уведомлений:
● При рассылке уведомлений в качестве данных аутентификации используется (параметр ДанныеАутентификации метода Отправить()):
● Сервис APNs – сертификат мобильного приложения, полученный из консоли разработчика. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Сервис GCM – ключ программного интерфейса приложения (API KEY), зарегистрированного в консоли разработчика. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Сервис фирмы «1С» – ключ программного интерфейса отправителя (Ключ доступа отправителя), который получен при регистрации отправителя на сайте сервиса. Рекомендуется относиться к данному ключу как к конфиденциальной информации.
● Если для отправки уведомлений используется сервис фирмы «1С», то параметр ИспользоватьПромежуточныйСервис должен быть установлен в значение Истина.
● Если отправка выполняется одновременно с использованием нескольких сервисов, то в качестве данных аутентификации может выступать соответствие, где ключом выступает вид сервиса (значение перечисления ТипПодписчикаДоставляемыхУведомлений), а в качестве значения – те данные, которые необходимы соответствующему сервису.
Следует понимать, что невозможно одновременно (в одном вызове метода Отправить()) отправлять уведомления с использованием APNs или GCM и сервиса фирмы «1С». Если у метода Отправить() значение параметра ИспользоватьПромежуточныйСервис установлено в значение Истина, то значением параметра ДанныеАутентфикации может быть только Ключ доступа отправителя, полученный у сервиса фирмы «1С».
● Перечень получателей уведомлений описывается с помощью свойства Получатели объекта ДоставляемоеУведомление, которое выступает значением первого параметра метода Отправить() менеджера доставки отправляемых уведомлений.
Для обеспечения отправки уведомлений с помощью APNs, на компьютере с системой-отправителем должны быть разрешены исходящие подключения по IP-портам 2195 и 2196.
26.4.10.4. Особенности обработки уведомлений мобильным приложением
Если обработчик уведомления не подключен, то уведомление сохраняется в памяти до окончания сеанса и будет передано обработчику уведомления после его подключения (в этом сеансе). Если до окончания сеанса обработчик не был подключен – уведомление теряется после завершения сеанса.
Также необходимо учитывать следующие особенности работы с уведомлениями в мобильном приложении:
● Если мобильное приложение активно, то уведомление сразу доставляется в мобильное приложение, при этом наклейка и звуковое оповещение игнорируются.
● Если мобильное приложение не активно в момент получения уведомления, то уведомление отображается операционной системой. Если пользователь нажал на уведомление, то будет запущено соответствующее приложение. Если пользователь удалил уведомление – приложение не будет проинформировано о существовании уведомления. В ОС iOS (версии 7 и младше) уведомление удаляется из центра уведомления либо явным действием пользователя, либо вытесняется другими уведомлениями данного приложения.
● Если мобильное приложение, в момент получения уведомления, работает в фоновом режиме и не активно, то работа с уведомлением выполняется по-разному на разных платформах:
● На платформе iOS уведомление будет передано в мобильное приложение только после того, как его выберет пользователь из панели уведомлений.
● На платформе Android уведомление сразу передается в мобильное приложение и одновременно отображается в панели уведомлений. После того, как пользователь выбрал уведомление в панели, происходит активизация приложения, но повторно уведомление в приложение не передается.
● В том случае, если в мобильном приложении развернуто несколько информационных баз, то пользователю предлагается переключиться, если в данный момент он работает с другой информационной базой. Если конкретную информационную базу определить не получается – выдается соответствующее диагностическое сообщение.
26.4.11. Работа с рекламой
26.4.11.1. Общая информация
Мобильная платформа предоставляет возможность показывать рекламную информацию в мобильном приложении. При необходимости воспроизведения рекламы, прикладной разработчик может настроить отображение рекламного баннера с использованием следующих рекламных сервисов:
● На платформе Apple iOS: сервис Apple iAd (http://advertising.apple.com/, на английском языке).
● На платформе Google Android: сервис Google AdMob (https://www.google.com/admob/, на английском языке).
Реклама отображается в виде специальных рекламных блоков графического или текстового вида, которые может отображаться на весь экран (полноэкранный блок) или в специально выделенной для этого части экрана мобильного устройства (для не полноэкранной рекламы).
Данная документация рассматривает только вопросы, касающиеся технических аспектов работы мобильного приложения с данными сервисами.
Общая схема работы при работе с рекламой выглядит следующим образом:
1. Зарегистрировать свое приложение в соответствующем сервисе.
2. Настроить рекламные блоки в используемых сервисах (при необходимости).
3. Реализовать программный интерфейс работы с рекламой, используя данные, полученные на предыдущих шагах.
Для управления отображением рекламной информации служит свойство глобального контекста ОтображениеРекламы. После старта мобильного приложения, система имеет следующие настройки по умолчанию:
● Реклама в мобильном приложении не используется.
● Идентификатор полноэкранной рекламы не установлен.
● Идентификатор рекламного баннера не установлен.
● Рекламная информация не отображается на экране.
Для того чтобы рекламная информация стала отображаться в приложении, должны одновременно выполняться следующие условия:
1. Использование рекламы в мобильном приложении должно быть разрешено с помощью метода ОтображениеРекламы.УстановитьИспользование(Истина);.
2. Установлен способ отображения рекламного баннера с помощью метода ОтображениеРекламы.УстановитьОтображениеРекламногоБаннера(). Данный метод задает способ отображения только неполноэкранной рекламы.
3. Установлен идентификатор рекламного баннера (в случае использования системы Google adMob) с помощью метода ОтображениеРекламы.УстановитьИндентификаторРекламногоБаннера().
4. Если в мобильном приложении используется межстраничное (полноэкранное) объявление, то его отображение осуществляется с помощью метода ОтображениеРекламы.ПоказатьПолноэкраннуюРекламу(). Вызов метода следует осуществлять именно в том месте, в котором планируется отображать межстраничное объявление.
В случае использования системы Google adMob, предварительно следует установить идентификатор полноэкранной рекламы с помощью метода ОтображениеРекламы.УстановитьИндентификаторПолноэкраннойРекламы(). При этом пункт 1 также обязательно должен быть выполнен.
5. Ротацию собственно рекламной информации обеспечивает рекламная сеть.
При использовании системы Google adMob, при установке идентификаторов рекламы, следует использовать идентификаторы, которые получены в веб-интерфейсе системы (подробнее см. здесь).
26.4.11.2. Настройка рекламных сервисов
26.4.11.2.1. Apple iAd
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
1. Войти в систему iTunes Connect (https://itunesconnect.apple.com) от имени пользователя с административными правами.
2. Зайти в раздел Соглашения, налоги и банковские операции.
3. Принять соглашение iAd App Network.
4. Затем перейти в консоль управления iAd (https://iadworkbench.apple.com/) или из iTunes Connect зайти в раздел iAd.
5. Для управления настройками рекламы необходимо, чтобы приложение с рекламой было опубликовано в магазине приложений к моменту начала управления настройками. Пока это условие не выполнено, переход в раздел Monetize – Track revenue and manage settings на портале iAd Workbench будет недоступен.
26.4.11.2.2. Google adMob
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для настройки рекламных блоков необходимо выполнить следующие действия:
1. Зарегистрироваться в системе Google adMob.
2. Войти в систему от имени зарегистрированного пользователя (https://apps.admob.com).
3. Если приложение собрано с использованием сборщика мобильных приложений и ранее выполнялось тестирование этого приложения (см. здесь), то ничего делать не надо. Идентификаторы рекламных блоков должны быть указаны в нужных местах прикладного решения. В мобильном приложении, собранном с помощью сборщика, должна отображать реальная рекламная информация.
4. Начать монетизацию нового приложения. Для этого следует нажать кнопку + Монетизировать новое приложение на закладке Главная.
5. На открывшейся странице следует ввести имя мобильного приложения и нажать кнопку Найти. После того, как ниже поля ввода сформировался список приложений, созданный по вашему поисковому запросу (имя приложения), следует найти именно ваше приложение и нажать кнопку +Выбрать справа от него.
6. На странице Монетизация нового приложения следует нажать кнопку Далее.
7. После добавления приложения требуется указать формат и название рекламного блока. Это делается на втором шаге (Выберите формат объявлений и укажите название рекламного блока). Рекламный блок может быть обычным баннером (отображаемым на части экрана) и межстраничным (полноэкранным) объявлением.
8. Нажатие любой кнопки (Баннер или Межстраничное объявление) приводит к необходимости настроить создаваемый формат блока. Редактирование рекламного блока завершается нажатием кнопки Сохранить.
9. Следует сохранить значение свойства Идентификатор рекламного блока, который необходим для использования из встроенного языка.
10. После окончания работы на странице Монетизация нового приложения следует нажать кнопку Готово.
Работу с рекламными блоками также можно выполнять следующим образом:
1. Войти в систему Google adMob (https://apps.admob.com).
2. Перейти на закладку Монетизация.
3. Под заголовком Все приложения выбрать требуемое приложение (левая колонка на странице).
4. На закладке Рекламные блоки имеется возможность создавать и настраивать рекламные блоки. На этой же закладке имеется возможность получить идентификатор рекламного блока.
26.4.11.3. Тестирование работы с рекламой
26.4.11.3.1. Apple iAd
Если мобильное приложение подписано отладочным сертификатом (в том числе и мобильная платформа разработчика), то при работе приложения используется тестовый рекламный баннер.
Если приложение подписано сертификатом, который используется для подписи приложения, публикуемого в магазине приложений, то в этом случае будут использоваться реальные рекламные баннеры.
26.4.11.3.2. Google adMob
Общую схему тестирования отображения рекламной информации, при использовании системы Google adMob, можно представить следующим образом:
● Для тестирования отображения рекламной информации не требуется публикации мобильного приложения в магазине приложений.
● Для тестирования необходимы только идентификаторы рекламных блоков, для создания которых (рекламных блоков) необходимо зарегистрировать разрабатываемое приложение в сервисе Google adMob.
● После регистрации приложения в Google adMob, необходимо создать рекламные блоки. Их идентификаторы будут использоваться в разрабатываемом мобильном приложении и при тестировании и при реальной эксплуатации.
● Пока приложение работает на мобильной платформе разработчика, рекламные блоки отображают тестовое содержимое. После того, как приложение собрано сборщиком мобильных приложений – оно начнет показывать реальную рекламную информацию.
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для настройки рекламной информации необходимо выполнить следующие действия:
1. Войти в систему Google adMob (https://apps.admob.com).
2. Перейти на закладку Монетизация.
3. Начать монетизацию нового приложения. Для этого следует нажать кнопку + Монетизировать новое приложение на закладке Главная.
4. На открывшейся странице следует перейти на закладку Добавить приложение вручную. В поле Название приложения следует ввести имя приложения так, как оно в дальнейшем будет отображаться в магазине приложений, в поле Платформа следует указать Android.
5. На странице Монетизация нового приложения следует нажать кнопку Добавить приложение.
6. После добавления приложения требуется указать формат и название рекламного блока. Это делается на втором шаге (Выберите формат объявлений и укажите название рекламного блока). Рекламный блок может быть обычным баннером (отображаемым на части экрана) и межстраничным (полноэкранным) объявлением.
7. Нажатие любой кнопки (Баннер или Межстраничное объявление) приводит к необходимости настроить создаваемый формат блока. Редактирование рекламного блока завершается нажатием кнопки Сохранить.
8. Следует сохранить значение свойства Идентификатор рекламного блока, который необходим для использования из встроенного языка.
9. После окончания работы на странице Монетизация нового приложения следует нажать кнопку Готово.
Идентификаторы, полученные при создании рекламных блоков, следует использовать в качестве параметров методов ОтображениеРекламы.УстановитьИндентификаторРекламногоБаннера()и ОтображениеРекламы.УстановитьИндентификаторПолноэкраннойРекламы().
26.4.12. Работа со встроенными покупками
26.4.12.1. Общая информация
Мобильная платформа предоставляет прикладному разработчику возможность реализации различных покупок внутри мобильного приложения (in-app purchase). Предоставляется возможность работы со следующими видами покупок:
1. Постоянная покупка. Используется на платформах iOS и Android. Приобретается однократно для учетной записи пользователя мобильного устройства. Распространяется на все мобильные устройства, работающие под одной учетной записью. Для распространения используется механизм восстановления покупок.
2. Расходуемая покупка. Используется на платформе iOS. Такая покупка может быть приобретена произвольное количество раз. Информация о приобретении такой покупки поступает на мобильное устройство только в момент запроса начала покупки. На платформе Android расходуемая покупка реализуется в прикладном решении с помощью специальных средств платформы (расходование постоянной покупки).
3. Подписка. Используется на платформах iOS и Android. Такая покупка приобретается как постоянная покупка, действующая в течение определенного времени. Имеется возможность установить автоматическое продление покупки по истечению срока подписки. При этом со счета платежного средства, привязанного к аккаунту пользователя, будет списываться стоимость подписки. Нельзя изменить стоимость подписки на платформе Android. На платформе iOS изменение стоимости подписки приведет к отключению автоматического продления подписки. Удаление приложения, через которое осуществлялась покупка, не приводит к отключению автоматического продления подписок. Управление подписками осуществляется с помощью Apple AppStore и Google Wallet. В мобильном приложении невозможно реализовать интерфейс управления подписками.
Покупки в мобильном приложении осуществляются с помощью внешних сервисов:
● для ОС iOS: Apple In-App Purchase.
● для ОС Android: Google Play In-App Billing. На устройстве должна быть установлена актуальная версия приложения Google Play.
При реализации покупок внутри мобильного приложения следует помнить, что предметы покупок ограничиваются владельцами магазинов приложений (компании Apple, Google).
В общем случае, покупки внутри приложений должны полностью соответствовать требованиям владельцев сервисов:
● для ОС iOS: https://developer.apple.com/app-store/review/guidelines/ (на английском языке).
● для ОС Android: https://support.google.com/googleplay/android-developer/answer/6151557.
В качестве примера можно привести следующие разрешенные и запрещенные виды контента:
● Разрешено продавать:
● функциональные возможности мобильных приложений;
● услуги, непосредственно связанные с мобильными приложениями.
● Запрещено продавать:
● товары и услуги, используемые за пределами мобильных приложений.
26.4.12.2. Схема использования
Чтобы использовать покупки, следует для разрабатываемого мобильного приложения установить разрешение Встроенные покупки (см. стр. здесь). Общая схема работы со встроенными покупками, в мобильном приложении, выглядит следующим образом:
1. Необходимо настроить работу используемых сервисов встроенных покупок (см. здесь) для взаимодействия с разрабатываемым мобильным приложением. Во время настройки сервисов может потребоваться загрузить в магазин приложений разрабатываемое мобильное приложение, для которого включена возможность использования встроенных покупок. При этом загружаемое мобильное приложение может не содержать в себе функциональность работы с покупками. Загружаемое приложение необходимо для работы механизмов сервисов покупок. Однако полный идентификатор загружаемого приложения должен быть в точности таким, каким он будет для финальной версии мобильного приложения с возможностью совершения встроенных покупок.
2. После настройки сервисов необходимо создать необходимые покупки (в каждом из сервисов) и зафиксировать идентификаторы и типы покупок.
3. В мобильном приложении необходимо проверить, доступно или нет на данном устройстве совершение покупок. Для этого следует использовать метод ВстроенныеПокупки.ПодерживаютсяПокупки().
4. Если покупки поддерживаются, то следует обновить список совершенных и доступных покупок с помощью метода ВстроенныеПокупки.ОбновитьИнформациюОПриобретении(). Без выполнения этой операции будет невозможно в дальнейшем совершить покупку.
Операцию обновления информации о приобретении рекомендуется выполнять регулярно, т. к. список совершенных покупок может изменяться не только на текущем устройстве.
5. Для определения возможности расходования покупок средствами встроенного языка следует использовать метод ВстроенныеПокупки.ПоддерживаетсяРасходованиеПокупок(). Если метод возвращает значение Истина, то это означает, что мобильное приложение исполняется на ОС Android с установленным приложением Google Play и имеется возможность расходовать постоянные покупки.
6. Для осуществления покупки предназначен метод ВстроенныеПокупки.НачатьПриобретение(). В качестве параметра метода следует передать идентификатор покупки (как он указан в соответствующем сервисе) или объект ВстроеннаяПокупка, который можно получить с помощью метода ВстроенныеПокупки.ПолучитьСписок().
После вызова метода, управление будет передано интерфейсу выполнения покупок, который предоставляется операционной системой и не может быть переопределен на уровне мобильного приложения.
После завершения покупки управление возвращается в мобильное приложение (в метод обработки оповещения о завершении покупки). Одним из параметров метода будет выступать статус покупки: если в обработчик передано значение Истина, значит покупка совершена успешно. В противном случае покупка не совершена по любой из причин: отсутствует связь с магазином приложений, пользователь отменил покупку в интерфейсе магазина приложений, цифровая подпись квитанции о покупке не прошла проверку и т. д.
7. Расходование покупок следует выполнять с помощью метода ВстроенныеПокупки.ИзрасходоватьПокупку(). После выполнения метода выполняется запрос к сервису работы с покупками, в котором указывается, что покупка израсходована и доступна для повторного приобретения.
26.4.12.3. Проверка квитанции встроенной покупки
При осуществлении покупки, в мобильном приложении выполняется проверка того, что покупка действительно выполнена. Однако информационная система (включающая мобильное приложение) может выполнить проверку более тщательно. Для этого предоставляется возможность передать квитанцию выполненной покупки в прикладное решение, развернутое на персональном компьютере. И тогда имеется возможность выполнить проверку квитанции со стороны прикладного решения для персонального компьютера. Для этого следует использовать метод ПроверкаВстроенныхПокупок.ПроверитьКвитанциюВстроеннойПокупки(). Проверка выполняется полностью аналогично мобильной платформе. Разница заключается в том, что при проверке с сервера прикладного решения для персонального компьютера используются другие каналы связи с сервисом покупок (и другое окружение проверяющей системы).
При проверке квитанции покупки выполняются следующие действия:
● для ОС iOS: отправляется запрос на сервер компании Apple для проверки полученной квитанции. Запрос отправляется по адресу https://buy.itunes.apple.com/verifyRecepient (https://sandbox.itunes.apple.com/verifyRecepient во время тестирования).
● для ОС Android: выполняется проверка электронной подписи квитанции выполненной покупки.
Если прикладной разработчик считает, что и этого недостаточно, то предоставляется возможность выполнять дополнительные проверки, которые базируются на содержимом полей квитанции о покупке. К таким проверкам можно отнести проверку уникальности идентификатора квитанции о покупке, адекватности даты покупки и т. д.
26.4.12.4. Настройка сервисов встроенных покупок
26.4.12.4.1. Общая информация
Информацию об особенностях конкретных типов покупок и поведения системы при работе с покупками следует искать в документации к соответствующей операционной системе.
26.4.12.4.2. Apple In-App Purchase
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
1. Войти в Member Center (https://developer.apple.com/membercenter/index.action) от имени разработчика.
2. Перейти в раздел Certificates, Identifiers & Profiles.
3. Перейти в раздел Identifiers.
4. Зарегистрировать iOS App ID для приложения (если оно еще не зарегистрировано в Member Center). При этом регистрируемый идентификатор должен совпадать с полным идентификатором мобильного приложения, в которое планируется встраивать работу с встроенными покупками. При создании iOS App ID следует убедиться, что разрешен сервис In-App Purchase.
5. Если планируется использовать мобильную платформу разработчика для работы со встроенными покупками, следует выполнить следующие действия:
1. Перейти в раздел Provisioning Profiles.
2. Создать новый профиль обеспечения (provisioning profile).
3. Указать, что этот профиль предназначен для iOS App Development.
4. Указать в качестве App ID именно тот iOS App ID, который создан на предыдущем шаге. Нельзя указывать на этом шаге iOS Wildcard AppID.
5. Созданный профиль обеспечения в дальнейшем будет необходимо использовать в сборщике мобильных приложений.
6. Войти в систему iTunes Connect (https://itunesconnect.apple.com).
7. Перейти в раздел Соглашения, налоги и банковские операции.
8. Принять соглашение Paid Application. При этом необходимо указать информацию о банковском счете, на который будут перечисляться заработанные средства.
9. Перейти на закладку Функции.
10. Перейти в раздел Встроенные покупки (открыт по умолчанию).
11. Новая встроенная покупка добавляется с помощью кнопки «+», расположенной справа от заголовка списка Встроенные покупки.
26.4.12.4.3. Google Play In-App Billing
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Для создания встроенных покупок следует выполнить следующие шаги:
1. Войти в консоль разработчика Google Play (https://play.google.com/apps/publish/).
2. Создать или найти мобильное приложение, в котором планируется реализовать работу с встроенными покупками. На данном этапе следует собрать мобильное приложение, для которого установлено разрешение Встроенные покупки, но может отсутствовать функциональность работы с покупками. Сборку необходимо выполнять с помощью сборщика мобильных приложений. Собранное приложение необходимо загрузить в магазин приложений (в статусе альфа-версии).
3. Перейти на страницу приложения.
4. На странице приложения, в разделе Службы и API необходимо запомнить значение поля ЛИЦЕНЗИОННЫЙ КЛЮЧ ДЛЯ ЭТОГО ПРИЛОЖЕНИЯ. Это значение будет необходимо для выполнения проверки квитанции встроенной покупки на стороне прикладного решения для персонального компьютера.
5. Перейти в раздел Контент для продажи.
6. Новая встроенная покупка добавляется с помощью кнопки + Добавить продукт. Будьте внимательны при добавлении продуктов! Их невозможно удалить!
26.4.12.5. Тестирование встроенных покупок
26.4.12.5.1. Общая информация
Данный раздел содержит рекомендации по тестированию работы со встроенными покупками. Рекомендации касаются особенностей взаимодействия мобильного приложения (мобильной платформы) и сервиса встроенных покупок.
26.4.12.5.2. Для ОС iOS
Общая информация
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС iOS можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные покупки. Это тестирование выполняется с помощью мобильной платформы разработчика и сервиса Apple In-App Purchase, работающего в специальном (тестовом) режиме.
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине приложений. Покупки будут выполняться через реальный сервис Apple In-App Purchase, но фактического списания денежных средств выполняться не будет. Для тестирования используется специальная программа TestFlight.
Дальше будут подробнее рассмотрены оба тестирования.
На платформе разработчика
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
После выполнения настроек необходимо собрать мобильную платформу разработчика, указав при ее сборке идентификатор мобильного приложения, который использовался при настройке сервиса. Подробнее о создании мобильной платформы разработчика см. здесь.
Затем необходимо указать аккаунты пользователей, которые смогу тестировать встроенные покупки в «песочнице» (sandbox). Для этого необходимо выполнить следующее:
1. Войти в систему iTunes Connect (https://itunesconnect.apple.com).
2. Перейти в раздел Пользователи и роли.
3. Перейти на закладку Тестировщики Sandbox.
4. На данной странице следует добавить электронную почту тех пользователей, которые будут выполнять роль тестировщиков.
5. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта с использованием платформы разработчика.
С помощью программы TestFlight
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Apple In-App Purchase. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
Затем выполнить следующие операции:
1. Войти в систему iTunes Connect (https://itunesconnect.apple.com).
2. Перейти в раздел Пользователи и роли.
3. Перейти в раздел Мои приложения.
4. Найти приложение, которое планируется тестировать.
5. Загрузить мобильное приложение, собранное с помощью сборщика мобильных приложений.
6. Перейти в свойства мобильного приложения.
7. Перейти в раздел TestFlight.
8. Перейти в раздел Внутреннее тестирование (открыт по умолчанию).
9. Укажите, кто из внутренних тестировщиков будет заниматься тестированием выбранного мобильного приложения.
10. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта.
26.4.12.5.3. Для ОС Android
Общая информация
Тестирование работы с покупками для мобильного приложения, работающего под управлением ОС Android можно разделить на две части:
1. Тестирование алгоритмов работы с покупками, их безошибочность и корректность реакции мобильного приложения на выполненные покупки. Это тестирование выполняется с помощью мобильной платформы разработчика и сборщика мобильных приложений (который предоставляет эмулятор системы Google Play In-App Billing).
2. Финальное тестирование, когда проверяется работа именно того мобильного приложения, которое будет размещаться в магазине приложений. Покупки будут выполняться через реальный сервис Google Play In-App Billing, но фактического списания денежных средств выполняться не будет.
Дальше будут подробнее рассмотрены оба тестирования.
На платформе разработчика
Платформа разработчика предоставляет возможность выполнять тестирование работы с покупками без необходимости выполнять сборку мобильного приложения. Для этого в свойствах информационной базы, на которой будет осуществляться тестирование, следует заполнить свойства Адрес сервера покупок и Идентификатор пользователя.
Инструменты, предоставляемые компанией Google, для тестирования работы с покупками не позволяют использовать для этой цели мобильную платформу разработчика. В связи с этим в сборщике мобильных приложений реализован сервис, который эмулирует Google Play In-App Billing.
Для того чтобы воспользоваться этим сервисом, необходимо опубликовать на веб-сервере HTTP-сервис PurchasesTest (подробнее про публикацию на веб-сервере см. здесь). Адрес опубликованного HTTP-сервиса необходимо указать в свойстве информационной базы Адрес сервера покупок.
В сборщике следует завести пользователя, для которого выбрана роль Проверка покупок. Затем в сборщике мобильных приложений следует открыть специальный инструмент для тестирования встроенных покупок (Рабочий стол – Сервис – Тестирование встроенных покупок).
В поле Мобильное приложение выбирается то мобильное приложения, для которого будет выполняться тестирование встроенных покупок. Содержимое остальных таблиц связано с выбранным приложением.
В таблице Тестовые пользователи предоставляется возможность указать несколько пользователей, от имени которых будет тестироваться выполнение встроенных покупок. Указание разных идентификаторов тестовых пользователей в свойствах информационной базы на мобильном устройстве (свойство Идентификатор пользователя) позволит быстро проверять работу с покупками от имени разных пользователей, работающих с мобильным приложением.
В таблице Доступные покупки необходимо создать ровно тот список покупок (особенно в части идентификаторов и типов покупок), который в дальнейшем будет создаваться в консоли разработчика Google Play. При указании валюты покупки следует использовать буквенный код валюты из стандарта ISO 4217 (http://www.iso.org/iso/ru/home/standards/currency_codes.htm).
В таблице Совершенные покупки имеется возможность создать необходимую конфигурацию тестового окружения: какой пользователь, какие покупки совершил, имеется возможность отключать приобретение покупки и т. д.
Собранное приложение
Внимание! Описание работы с веб-интерфейсом приводится по состоянию на момент написания документации.
Первым шагом следует выполнить все операции по предварительной настройке сервиса Google Play In-App Billing. При настройке следует указывать тот идентификатор мобильного приложения, который будет использовать для разрабатываемого приложения. Подробности настройки сервиса см. здесь.
1. Войти в консоль разработчика Google Play (https://play.google.com/apps/publish/).
2. Перейти в раздел Настройки (в левой части экрана).
3. В разделе Аккаунты Gmail тестировщиков указать адреса электронной почты тех прикладных разработчиков, которые будут тестировать работу со встроенными покупками. Указанные тут разработчики (или тестировщики) смогут выполнять покупки без выполнения реальной оплаты, однако, при выполнении тестовой покупки будет необходимо указывать данные реальной, платежеспособной банковской карты. С этой карты будет выполнено тестовое списание (с последующим возвратом) небольшой суммы (примерно 1 доллар США) для проверки корректности указанных данных.
4. Аккаунты, указанные в качестве тестировщиков, могут принимать участие в тестировании продукта.
26.5. Взаимодействие с мобильным устройством при разработке мобильного приложения
26.5.1. Общая информация
Помещение мобильного приложения на мобильное устройство возможно двумя способами:
● Через фирменный магазин приложений App Store (http://itunes.apple.com/ru/genre/ios) или Google Play (http://play.google.com). Данный способ используется для распространения публичных версий мобильных приложений. Описание подготовки прикладного решения к публикации см. здесь.
Подготовленное к публикации прикладное решение одобряется и публикуется по правилам соответствующего магазина приложений. Подробности этого процесса в данной книге не рассматриваются.
● С помощью версии мобильной платформы для разработчика. Используется для разработки мобильных приложений. Далее будет рассмотрен этот способ.
Для того чтобы начать использовать мобильное приложение, необходимо выполнить некоторые действия:
● На мобильное устройство должна быть установлена мобильная платформа разработчика;
● Мобильное приложение опубликовано на веб-сервере;
● На мобильном устройстве создана информационная база (приложение) на основе опубликованного мобильного приложения.
После выполнения этих операций получается готовая инфраструктура для разработки и исполнения мобильного приложения на мобильном устройстве. При этом система может быть настроена таким образом, что обновление конфигурации будет приводить к тому, что мобильная платформа для разработчика автоматически обновит конфигурацию на мобильном устройстве.
Далее будет более подробно рассмотрено каждое действие.
26.5.2. Установка мобильной платформы разработчика
26.5.2.1. Для ОС iOS
Для разработки мобильного приложения для ОС iOS необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера фирмы Apple (далее – Mac) с установленной операционной системой OS X 10.8 и выше.
● На компьютере Mac должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● На этом компьютере необходимо установить средство разработки Xcode версии 4.5 и выше (https://developer.apple.com/xcode/).
● Необходимо зарегистрироваться в программе iOS Developer Program (https://developer.apple.com/programs/ios/).
● Для работы необходимо мобильное устройство на iOS, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной платформы разработчика на мобильное устройство, работающее под управлением iOS, необходимо выполнить следующие действия:
● Подключить мобильное устройство к компьютеру Mac;
● Распаковать файл с проектом мобильной платформы prjios.zip на компьютере Mac;
● Открыть проект мобильной платформы разработчика в системе Xcode (двойным щелчком мыши по файлу 1cem.xcodeproj или выбрать файл 1cem.xcodeproj с помощью команды File – Open в системе Xcode);
● Открыть инструмент Organizer с помощью команды меню Xcode Window – Organizer;
● В открывшемся окне, в панели слева выбрать подключенный телефон (отмечен зеленым маркером);
● В панели снизу выбрать команду Add to Portal;
● Средство Organizer запросит необходимые для телефона сертификаты и provisioning profile с сайта Apple и установит их на телефон автоматически. Потребуется ввести пароль разработчика, полученный при регистрации в iOS Developer Program.
● С помощью команды меню Xcode Product – Edit Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся диалоге:
● В свойстве Scheme выбрать значение 1cem;
● В свойстве Destination выбрать подключенный телефон;
● В свойстве Build configuration выбрать значение Release;
● Нажать кнопку OK.
● Запустить проект с помощью команды меню Xcode Product – Run.
● Мобильная платформа будет передана на мобильное устройство, запущена и ее иконка появится в списке установленных приложений мобильного устройства.
● Мобильное устройство можно отключить от компьютера Mac и далее запускать мобильную платформу нажатием на иконку «1С:Предприятие» в списке приложений мобильного устройства. Если в момент отключения на мобильном устройстве была запущена мобильная платформа разработчика, которая запущена с помощью Xcode, то она будет остановлена.
26.5.2.2. Для ОС Android
Для разработки мобильного приложения для ОС Android необходимо выполнить следующие требования:
● Установить на компьютере Android SDK (http://developer.android.com/sdk/index.html). Для работы платформы разработчика необходимо, чтобы на компьютере был установлен Android``SDK``Platform-``tools версии не ниже 14.
● Проверить, что нужные компоненты установлены, можно с помощью утилиты SDK Manager.exe, которая находится в каталоге, в который был установлен Android SDK.
Рис. 450. Настройка Android SDK для разработчика
Для нормальной работы с платформой разработчика необходимо установить Android SDK Platform-tools (пример на рис.450). Версия инструмента можно посмотреть в колонке Rev. На рисунке будет выполнена установка версии 22, что удовлетворяет требованиям (версия не ниже 14). После выбора компонент следует нажать кнопку Install X package… и согласиться с лицензионным соглашением.
● На компьютере должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● Для работы необходимо мобильное устройство на Android, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной платформы разработчика на мобильное устройство, работающее под управлением Android, необходимо выполнить следующие действия:
● В настройках мобильного устройства необходимо установить следующие флажки:
● Неизвестные источники;
● Отладка через USB;
● Скачать с сайта производителя и установить на компьютер USB-драйвер мобильного устройства;
● Подключить мобильное устройство к компьютеру;
● С помощью интерпретатора командной строки ОС Windows выполнить команду:
Пример для ARM-платформы:
%ANDROID_SDK%\platform-tools\adb.exe install -r "<Каталог платформы>\1cem-arm.apk"
Пример для x86-платформы:
%ANDROID_SDK%\platform-tools\adb.exe install -r "<Каталог платформы>\1cem-x86.apk"
Где, Каталог платформы – каталог, в котором расположен соответствующий файл с мобильной платформой. Если мобильная платформа уже установлена на мобильное устройство, то данная команда выполнит ее переустановку.
● Мобильная платформа будет передана на мобильное устройство и ее иконка появится в списке установленных приложений.
● Мобильное устройство можно отключить от компьютера и далее запускать мобильную платформу нажатием на иконку «1С:Предприятие» в списке приложений мобильного устройства.
Для установки мобильной платформы разработчика можно воспользоваться командой конфигуратора Главное меню – Конфигурация – Мобильное приложение – Использование Android debug bridge – Установить мобильную платформу. В этом случае надо будет выполнить дополнительную настройку конфигуратора (подробнее см. здесь). С установку мобильной платформы можно выполнить или на физическое мобильное устройство, подключенное к компьютеру или на эмулятор устройства, созданный с помощью менеджера виртуальных устройств Android (AVD Manager.exe, входит в состав Android SDK).
26.5.2.3. Для ОС Windows
26.5.2.3.1. ОС Windows Phone
Для разработки мобильного приложения для ОС Windows необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера с установленной операционной системой Windows 8.1 и выше.
● На компьютере должен быть один свободный USB-порт, используемый для связи с мобильным устройством.
● Необходимо иметь учетную запись Microsoft (https://login.live.com/).
● На этом компьютере необходимо установить средство разработки Microsoft Visual Studio Commnunity 2013 with Update 4 и выше (https://dev.windows.com/en-us/downloads).
● Для работы необходимо мобильное устройство на Windows Phone, соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной платформы разработчика на мобильное устройство, работающее под управлением Windows, необходимо выполнить следующие действия:
● Подключить мобильное устройство к компьютеру;
● Запустить приложение Windows Phone Developer Registration 8.1;
● Выбрать подключенное устройство и нажать кнопку Register;
● Извлечь из файла поставки мобильной платформы (mobile.zip) файл с дистрибутивом платформы для мобильного телефона нужной архитектуры (файлы 1cem-phone-arm.appx или 1cem-phone-x86.appx);
● Запустить приложение Windows Phone Application Deployment 8.1;
● В запустившемся приложении следует выбрать подключенное устройство, файл с мобильной платформой и нажать кнопку Deploy.
● Мобильная платформа будет передана на мобильное устройство, запущена и ее иконка появится в списке установленных приложений мобильного устройства.
● Мобильное устройство можно отключить от компьютера и далее запускать мобильную платформу нажатием на иконку «1С:Предприятие» в списке приложений мобильного устройства.
26.5.2.3.2. ОС Windows на сенсорных устройствах
Для разработки мобильного приложения для ОС Windows необходимо выполнить следующие требования:
● Работа с мобильным устройством возможна только с компьютера с установленной операционной системой Windows 8.1 и выше.
● Необходимо иметь учетную запись Microsoft (https://login.live.com/).
● Для работы необходимо устройство на Windows (планшет или компьютер с сенсорным экраном), соответствующее системным требованиям (подробнее см. здесь).
Для установки мобильной платформы разработчика на устройство, работающее под управлением Windows, необходимо выполнить следующие действия:
● Скопировать на устройство файл поставки мобильной платформы (mobile.zip);
● Извлечь из файла поставки мобильной платформы (mobile.zip) файл сертификата (файл 1cem.cer);
● Установить сертификат в хранилище Доверенные люди на локальной машине;
● Извлечь из файла поставки мобильной платформы (mobile.zip) файл с дистрибутивом платформы для компьютера нужной архитектуры (файлы 1cem-x64.appx или 1cem-x86.appx);
● Запустить PowerShell от имени администратора (прав администратора системы недостаточно);
● Выполнить команду
Show-WindowsDeveloperLicenseRegistration
, а затем в открывшемся окне указать данные учетной записи Microsoft;
● Выполнить команду:
Add-AppxPackage <Каталог>\1cem-.appx
, где:
● <Каталог> – каталог, в который помещена мобильная платформа разработчика;
● <arch> – архитектура устройства (x86 или x64).
● В дальнейшем запускать мобильную платформу разработчика можно нажатием на иконку «1С:Предприятие» в списке приложений.
26.5.3. Публикация мобильного приложения на веб-сервере
Чтобы мобильное приложение было доступно мобильной платформе, необходимо выполнить публикацию мобильного приложения на веб-севере. Фактически, публикация делится на две части:
● Подготовка инфраструктуры для работы и начальная выгрузка конфигурации мобильного приложения – выполняется один раз.
● Обновление конфигурации мобильного приложения в подготовленной инфраструктуре.
Для подготовки инфраструктуры служит команда Конфигурация – Мобильное приложение – Публиковать…. В открывшемся диалоге следует указать флажок Создавать виртуальный каталог на веб-сервере. Если флажок не установлен, то будут недоступны реквизиты Имя и Каталог, а также при нажатии кнопки Опубликовать не будет выполняться создание виртуального каталога на веб-сервере.
Внимание! Для выполнения публикации требуются административные права.
Рис. 451. Публикация мобильного приложения
Затем указать свойства виртуального каталога веб-сервера:
● Имя – определяет имя виртуального каталога. Это имя будет участвовать в URL конфигурации мобильного приложения для указания на мобильном устройстве при создании информационной базы.
● Веб-сервер – определяет используемый веб-сервер. Если используется веб-сервер Microsoft Internet Information Services, то становится возможным указание флажка Использовать аутентификацию операционной системы на веб-сервере.
● Каталог – указывает физический каталог на диске, в котором будет находиться файл конфигурации мобильного приложения в формате .xml и куда будет отображен виртуальный каталог веб-сервера.
Флажок Обновлять мобильное приложение при обновлении конфигурации базы данных управляет возможностью автоматического обновления конфигурации мобильного приложения при обновлении конфигурации базы данных. Если флажок установлен – обновление будет выполняться.
Операцию обновления конфигурации также можно выполнить принудительно, с помощью команды Конфигурация – Мобильное приложение – Обновить публикуемое приложение. Если к моменту вызова данной команды публикация мобильного приложения не выполнялась – будет открыт диалог публикации, описанный выше.
Внимание! На веб-сервере публикуется конфигурация базы данных, а не редактируемая конфигурация.
Для выполнения собственно публикации необходимо нажать кнопку Опубликовать. При этом выполняются следующие действия:
● Если установлен флажок Создавать виртуальный каталог на веб-сервере, то создается виртуальный каталог на веб-сервере;
● Создается каталог на диске, в который отображается виртуальный каталог;
● Предлагается выгрузить конфигурацию мобильного приложения в каталог (указанный в реквизите Каталог диалога публикации);
● Проверяется, соответствует конфигурация базы данных редактируемой конфигурации или нет;
● Если конфигурация информационной базы не соответствует редактируемой конфигурации – предлагается выполнить обновление конфигурации базы данных. Однако эту операцию можно не выполнять, если требуется опубликовать именно конфигурацию базы данных;
● Выполняется проверка мобильного приложения (см. здесь);
● Если ошибок нет, то выполняется выгрузка конфигурации информационной базы в файл, в противном случае выгрузка не производится.
Файл с конфигурацией мобильного приложения, выгруженный с помощью команды Публиковать…, имеет фиксированное имя 1cema.xml. Поиск (и обновление) именно этого файла выполняется при выполнении команды Обновить публикуемое приложение.
Совет. При создании виртуального каталога, файл конфигурации (1cema.xml) устанавливается в качестве его (каталога) страницы по умолчанию. Это позволяет в диалоге создания информационной базы на мобильном устройстве указывать URL в сокращенном виде.
Кнопка Отключить диалога публикации мобильного приложения выполняет отмену публикации: удаляет виртуальный каталог на веб-сервере и физический каталог.
26.5.4. Запуск и перезапуск приложения на мобильной платформе
26.5.4.1. Общая информация
Запуск мобильного приложения осуществляется непосредственно на мобильном устройстве или из конфигуратора. На устройстве должна быть установлена мобильная платформа разработчика.
Запуск из конфигуратора возможен при одновременном выполнении двух условий: разработка выполняется с использованием ОС Android и выполнена соответствующая настройка конфигуратора (см. здесь).
26.5.4.2. Перезапуск мобильного приложения, опубликованного на веб-сервере
Если мобильное приложение запущено с помощью мобильной платформы разработчика и для приложения установлен флажок Перезапуск из конфигуратора (см. здесь), то существует возможность перезапускать мобильное приложение из конфигуратора. Это можно сделать с помощью команды главного меню Отладка – Начало отладки – Мобильное приложение: запустить.
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
Мобильное приложение выполняет проверку обновления при открытии в том случае, если установлен флажок Перезапуск из конфигуратора в свойствах мобильного приложения на мобильном устройстве. Если этот флажок сброшен, то при открытии наличие обновлений не проверяется. Однако такую проверку можно выполнить вручную (см. здесь).
26.5.4.3. Запуск и перезапуск мобильного приложения при использовании Android debug bridge
Запуск и перезапуск мобильного приложения можно выполнять с помощью конфигуратора. Это можно сделать с помощью команды главного меню Отладка – Начало отладки – Мобильное приложение: запустить. Чтобы при этом использовался Android debug bridge, конфигуратора должен быть соответствующим образом настроен (см. здесь). Кроме того, конфигурация должна быть опубликована в файловой системе (публикация на веб-сервере в этом случае не является обязательной) (см. здесь).
Если конфигурация была модифицирована (были произведены изменения), то конфигуратор выводит вопрос: Редактируемая конфигурация отличается от конфигурации базы данных. Произвести обновление конфигурации базы данных? Для сохранения внесенных изменений следует выбрать кнопку Да.
Если выбрана кнопка Нет, то мобильное приложение будет перезапущено без обновления конфигурации.
Если при публикации мобильного приложения был установлен флажок Обновлять мобильное приложение при обновлении конфигурации базы данных, то будет выполнено автоматическое обновление публикации конфигурации мобильного приложения.
После перезапуска мобильной платформы разработчика будет обнаружена новая конфигурация и будет выдано предложение выполнить обновление.
26.5.5. Отладка мобильного приложения
Отладка мобильного приложение возможна только при использовании протокола отладки HTTP. Мобильное приложение, функционирующее под управлением ОС Android, можно запускать в режиме отладки непосредственно из конфигуратора, с использованием Android Debug Bridge (см. здесь). Мобильное приложение, функционирующее под управлением ОС iOS или ОС Windows, нельзя запустить в режиме отладки непосредственно из конфигуратора. Подробное описание настройки мобильных приложений см. здесь.
Для отладки приложения используются два параметра в свойствах информационной базы мобильного приложения:
● Отладка разрешена – указывает, будет в данном мобильном приложении разрешена отладка или не будет.
● Адрес отладки – указывает расположение сервера отладки, если отладка разрешена.
● Вышеописанные параметры игнорируются в том случае, если информационная база запускается непосредственно из конфигуратора (в этом случае в качестве адреса сервера отладки выступает адрес конфигуратора, выполняющего запуск мобильного приложения, применимо только для работы через Android Debug Bridge) или для конфигурации установлен флажок Перезапуск из конфигуратора (в этом случае адрес сервера отладки получается из публикации мобильного приложения).
26.5.6. Управление приложениями на мобильной платформе разработчика
26.5.6.1. Создание приложения
Для того чтобы создать приложение на мобильной платформе разработчика, следует:
● Запустить «1С:Предприятие» на мобильном устройстве;
● Выбрать команду добавления приложения;
● В открывшемся окне ввести URL веб-сервера, на котором опубликовано мобильное приложение (см. здесь) в поле Адрес;
● При необходимости, следует указать имя пользователя и пароль для авторизации на веб-сервере, на котором опубликовано мобильное приложение и нажмите кнопку Загрузить;
● Затем следует указать имя приложения и нажать кнопку Готово;
● После закрытия окна будет создано приложение.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
26.5.6.2. Изменение свойств приложения
Свойства приложения изменяются в специальном окне. В зависимости от операционной системы, доступ к этой команде выполняется по-разному:
● Для ОС iOS: в правой части строки с именем нужного приложения нажмите картинку с изображением знака больше.
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Изменить.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Изменить.
В открывшемся окне можно изменять свойства приложения, которые указывались при его создании: наименование приложения, URL расположения конфигурации, имя и пароль пользователя для доступа к веб-серверу, на котором располагается конфигурация мобильного приложения.
Также в этом окне можно выполнить следующие действия:
● Запустить мобильное приложение. Для этого необходимо нажать кнопку Открыть.
● Проверить наличие новой версии конфигурации мобильного приложения на веб-сервере. Для этого необходимо нажать кнопку Проверить обновления. В случае наличия новой версии конфигурации будет предложено выполнить обновление мобильного приложения.
● Удалить приложение с помощью кнопки Удалить.
Внимание! После удаления приложения, данные информационной базы восстановить невозможно.
● Настроить возможность автоматического обновления и перезапуска мобильного приложения в случае, если на веб-сервере будет обнаружена новая версия конфигурации (см. здесь). Для этого следует изменить состояние флажка Перезапуск из конфигуратора.
● Настроить возможность отладки (флажок Отладка разрешена) и указать адрес отладчика (в поле Адрес отладчика). Подробнее про отладку см. здесь.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
26.5.6.3. Удаление приложения
Для удаления приложения следует выбрать команду Удалить и подтвердить свое действие. В зависимости от операционной системы, доступ к этой команде выполняется по-разному:
● Для ОС iOS: нажмите кнопку Изменить, затем нажмите картинку в левой части строки с именем удаляемого приложения. Затем в правой части этой же строки нажмите кнопку Удалить.
● Для ОС Android: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Удалить.
● Для ОС Windows: выполните длинное нажатие (или жест с правой стороны экрана) на нужном приложении. В открывшемся контекстном меню выберите команду Удалить.
Список приложений будет пропущен, и будет сразу запущено приложение, если оно в списке единственное. В этом случае для перехода в список приложений следует выбрать команду Список приложений в главном меню приложения.
Внимание! После удаления приложения, данные информационной базы восстановить невозможно.
26.5.7. Сборка мобильного приложения перед публикацией в магазине приложений
Мобильное приложение, предназначенное для публикации в магазине приложений, состоит из мобильной платформы и мобильного приложения и дополнительных файлов (иконок, логотипов и т. д.), «упакованные» в один контейнер. Этот файл можно установить на мобильное устройство.
Для формирования мобильного приложения предназначена специальная конфигурация (Сборщик мобильных приложений), которая входит в состав дистрибутива мобильной платформы. Конфигурация предоставляет следующие возможности:
● Хранить разные версии мобильных конфигураций;
● Хранить разные пакеты графической информации (иконки и заставки);
● Хранить разные версии мобильной платформы. Сборщик мобильных приложений работает с мобильной платформой версии 8.3.4 и старше. Работа с предыдущими версиями мобильной платформы не поддерживается;
● Собирать и хранить собственно мобильные приложения;
● Сборка для ОС Android выполняется как для архитектуры ARM, так и для архитектуры x86;
● При наличии компьютера Mac, подключенного к сети, в которой развернут сборщик мобильных приложений, имеется возможность выполнять полный цикл сборки мобильного приложения для ОС iOS – с автоматически созданием пакета приложения (.ipa);
● Сборка для ОС Windows выполняется как для ОС Windows Phone, так и для ОС Windows (приложение для распространения через Windows Store).
● Выполнять публикацию собранных мобильных приложений в соответствующих магазинах приложений непосредственно из сборщика.
Результатом работы сборщика выступают следующие объекты:
1. Мобильное приложение для ОС Android (архитектура ARM);
2. Мобильное приложение для ОС Android (архитектура x86);
3. Проект мобильного приложения для сборки на компьютере Apple (.zip-файл);
4. Пакет приложения для ОС iOS (.ipa-файл). Файл с пакетом приложения формируется в том случае, если в сборщике мобильных приложений настроены параметры соединения с компьютером Mac, который может выполнять сборку пакета приложений;
5. Мобильное приложение для ОС Windows Phone (архитектура ARM, .appx-файл);
6. Мобильное приложение для ОС Windows Phone (архитектура x86, .appx-файл);
7. Мобильное приложение для магазина приложений ОС Windows (архитектура x86, .appx-файл);
8. Мобильное приложение для магазина приложений ОС Windows (архитектура x64, .appx-файл).
Для того чтобы сборщик мобильных приложений мог выполнять какие-либо действия на стороне компьютера Mac, его необходимо настроить. Для этого необходимо выполнить следующие действия:
● Установить все доступные обновления OS X;
● Установить программу Xcode. Получить пакет можно здесь: https://developer.apple.com/xcode/;
● Скачать и установить в связку ключей Система сертификат Apple Worldwide Developer Relations (http://developer.apple.com/certificationauthority/AppleWWDRCA.cer);
● С помощью средств портала разработчика Apple создать и установить в связку ключей Система сертификат дистрибуции для Apple AppStore или для корпоративного распространения:
● Для этого потребуется создание личного ключа средствами связки ключей;
● Следует обратить внимание на то, что все личные ключи и сертификаты должны располагаться в связке Система;
● После создания личного ключа, на вкладке Доступ диалога свойств ключа установить настройку Разрешить всем программам получать доступ к этому объекту.
● С помощью вкладки Accounts настроек Xcode установить provisioning profile, соответствующий сертификату дистрибуции;
● В настройках Общий доступ, системных настроек компьютера Mac, необходимо разрешить режим Удаленный вход.
● Здесь же следует получить имя компьютера, которое затем указать в настройках сборщика мобильного приложения.
● Также следует убедиться, что IP-порт номер 22 (SSH) компьютера Mac доступен для компьютера, на котором функционирует серверная часть сборщика мобильных приложений.
Сборка мобильного приложения выполняется на стороне сервера. На компьютере (или компьютерах), на котором исполняется серверная часть «1С:Предприятия», должно быть установлено следующее программное обеспечение:
1. Пакет Android SDK. Пакет можно скачать отсюда: http://developer.android.com/sdk/index.html.
2. Пакет Java SDK. Пакет можно скачать отсюда: http://www.oracle.com/technetwork/java/javase/downloads/index.html.
3. Пакет Apache Ant. Пакет можно скачать отсюда: http://ant.apache.org/bindownload.cgi.
4. Пакет PuTTY (используются утилиты pscp и plink). Пакет можно скачать отсюда: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
5. Пакет Windows SDK. Пакет можно скачать отсюда: https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx.
Внимание! Сборка мобильного приложения для ОС Windows возможна только в том случае, если на компьютере, который выполняет сборку, установлена операционная система Windows 8.1 и выше.
После установки на компьютер с серверной частью «1С:Предприятия» Android SDK, необходимо проверить, что установлены следующие компоненты SDK:
● Версия Android SDK Tools – не ниже 20.0.3;
● Версия Android SDK Platform-tools – не ниже 14;
● Версия Android SDK Build tools – не ниже 19.0.0;
● Версия SDK Platform – API 17 и выше.
Проверить это можно с помощью утилиты SDK Manager.exe, которая поставляется вместе с SDK. Необходимые для работы сборщика компоненты отмечены на рис.452.
Рис. 452. Настройка Android SDK для сборщика
Не рекомендуется устанавливать ознакомительные или тестовые версии требуемых компонент. После выбора необходимых компонентов следует нажать кнопку Install … packages… и согласиться с лицензионным соглашением.
Также сборщик мобильных приложений содержит встроенную документацию (справка), которая содержит описание правил работы со сборщиком, системные требования и форматы архивов, которые будут загружаться в прикладное решение.
26.6. Публикация в магазине приложений
Подготовка приложения для размещения в магазине приложений делается аналогично проверке мобильного приложения перед публикацией в магазине приложений.
26.6.1. Для ОС iOS
Перед отправкой приложения в Apple AppStore необходимо создать приложение в портале iTunes Connect и заполнить всю требуемую информацию о приложении. Затем следует нажать кнопку Ready to Upload Binary, при этом статус вашего приложения в iTunes Connect должен измениться на Waiting For Upload.
26.6.1.1. Из архива проекта
После формирования файла с архивом приложения для ОС iOS следует скопировать файл архива на компьютер Mac и выполнить следующие действия:
● Распаковать файл с проектом мобильного приложения <ИдентификаторПриложения>.zip на компьютере Mac;
● Открыть проект мобильной платформы разработчика в системе Xcode (двойным щелчком мыши по файлу 1cem.xcodeproj или выбрать файл 1cem.xcodeproj с помощью команды File – Open в системе Xcode);
● С помощью команды меню Xcode Product – Edit Scheme… необходимо открыть диалог настроек текущей схемы запуска. В открывшемся диалоге:
● В свойстве Scheme выбрать значение 1cem;
● В свойстве Build configuration выбрать значение Release;
● Нажать кнопку OK.
● Создать архив приложения с помощью команды Xcode Product – Archive;
● Открыть инструмент Organizer с помощью команды меню Xcode Window – Organizer;
● В верхней панели переключится на архивы Archives;
● Выбрать созданный архив и нажать кнопку Distribute…;
● Следовать указаниям помощника.
26.6.1.2. Бинарный файл (.ipa)
С помощью сборщика мобильных приложений
Необходимо открыть элемент списка мобильных приложений, для которого необходимо выполнить загрузку приложения, и выбрать команду Загрузить в магазины…. Сборщик проведет анализ выбранного мобильного приложения и сообщит пользователю о возможности или невозможности выполнить загрузку. Если загрузка доступна (установлен флажок Загрузить в Apple AppStore), то нажав кнопку Загрузить, сборщик попытается выполнит загрузку. При этом используется имя пользователя и пароль доступа к iTunes Connect, который можно указать в диалоге настройки параметров поставщика на закладке Параметры для ОС iOS (если настройку выполняет администратор сборщика) или в диалоге Сервис – Параметры доступа к iTunes Connect (если публикацию может выполнять обычный пользователь).
Публикация выполняется с помощью компьютер Mac, на котором выполнялась сборка мобильного приложения.
По окончанию загрузки сборщик сообщит состояние загрузки. Если есть подозрение, что загрузка закончилась неудачно – рекомендуется нажать кнопку Журнал для AppStore. Будет открыт документ, в котором находится журнал загрузки. Журнал не сохраняется в информационной базе и будет утерян после закрытия окна загрузки.
Вручную
Отправка подготовленного пакета приложения (.ipa) в Apple App Store выполняется с помощью утилиты Application Loader, входящей в комплект средств разработки Xcode. Для запуска утилиты загрузчика приложений необходимо сначала запустить Xcode, затем выбрать меню Xcode – Open Developer Tool – Application Loader.
В загрузчике необходимо ввести данные вашей учетной записи в программе для разработчиков Apple. Затем необходимо выбрать Deliver Your App. В открывшемся диалоге выбрать приложение, которое вы хотите отправить. Если его нет в списке, значит в iTunes Connect для этого приложения не заполнена необходимая информация. Далее необходимо нажать Next, затем Choose, и выбрать требуемый .ipa файл. Для отправки файла необходимо нажать Send и дождаться завершения процесса.
26.6.2. Для ОС Android
С помощью сборщика мобильных приложений
Первую загрузку приложения в магазин 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.
26.6.3. Для ОС Windows
С помощью сборщика мобильных приложений
Сборщик мобильных приложений не поддерживает публикацию приложений в магазин Windows Store.
Вручную
Прежде чем выполнять сборку приложения в сборщике мобильных приложений, необходимо зарезервировать идентифкатор вашего приложения в магазине Windows Store. Для этого необходимо зайти в информаицонную панель магазина (https://appdev.microsoft.com/StorePortals/).
Для создания приложения следует выбрать + Создать новое приложение. Теперь необходимо ввести планируемый идентификатор приложения и нажать гиперссылку Проверить доступность. Если введенное имя занято, то зарезервировать данное имя будет невозможно, о чем будет сообщено справа от поля с идентификатором приложения. Если имя доступно, то следует нажать кнопку Зарезервировать имя приложения.
После сборки мобильного приложения следует загрузить получившиеся файлы в созданное приложение из информационной панели. Для этого информационной панели следует нажать мышью на созданное приложение и в левом меню выбрать пункт Отправки, а затем нажать кнопку Начать отправку.
В открывшейся форме необходимо установить свойства приложения, цены, описание продукта, его возрастной ценз и т. д. Затем следует нажать гиперссылку Пакеты и загрузить .appx-файлы созданные сборщиком мобильных приложений. Если загрузка прошла успешно – следует нажать кнопку Сохранить. После заполнения всех параметров отправки следует нажать кнопку Отправить в Магазин и ожидать результатов проверки.