При разработке мобильных решений на платформе 1С программисты часто сталкиваются с классической задачей: когда мобильное приложение инициирует сеанс связи с центральной базой, всё проходит гладко — отправляется обычный HTTP- или SOAP-запрос. Но как быть, если изменения произошли в центральной базе (например, менеджер изменил статус заказа или выписал новый документ) и нам нужно мгновенно «толкнуть» эту информацию на мобильное устройство пользователя? Рассмотрим и проанализируем основные архитектурные подходы, их достоинства, недостатки и конкретные примеры реализации.
Прежде чем выбирать технологию связи, разберем ключевую сложность мобильной разработки. Современные операционные системы (Android и iOS) жестко контролируют энергопотребление. Если пользователь заблокировал экран или свернул приложение, операционная система «усыпляет» его процессы. Любые попытки держать постоянное TCP-соединение или запускать фоновые опросы по таймеру раз в минуту будут быстро пресечены механизмами энергосбережения ОС, либо это приведет к быстрому разряду батареи смартфона. Поэтому архитектура связи «Сервер -> Клиент» строится на базе специализированных технологий.
Push-уведомления — это стандартный и наиболее эффективный способ разбудить мобильное приложение или сообщить пользователю важную информацию в режиме реального времени. Платформа 1С предоставляет для этого встроенный объект ДоставляемоеУведомление.
Схема работы push-уведомлений выглядит следующим образом:
Важная особенность: изменение идентификаторов устройств (токенов). Как справедливо отмечают разработчики, идентификаторы устройств имеют свойство меняться. Это происходит при переустановке приложения, обновлении операционной системы или сбросе настроек. Поэтому в центральной базе необходимо реализовать логику обновления токенов при каждом сеансе синхронизации мобильного клиента с базой.
Для упрощения работы фирма 1С предоставляет бесплатный облачный сервис «1С:Центр уведомлений». С его помощью центральной базе не требуется напрямую обращаться к серверам Google или Apple. Достаточно отправить сообщение на адрес сервиса 1С, который сам выполнит маршрутизацию.
Пример программного создания и отправки push-уведомления из центральной базы:
// Создаем объект уведомления
Уведомление = Новый ДоставляемоеУведомление;
Уведомление.Текст = "Поступил новый заказ №125!";
Уведомление.ЗвуковоеОповещение = ЗвуковоеОповещение.Стандартное;
Уведомление.ПриложениеВФоне = РежимПолученияДоставляемогоУведомления.ЗапуститьПриложение;
// Получаем токен устройства из нашей базы данных
ИдентификаторПриемника = ПолучитьТокенУстройстваПользователя(ТекущийПользователь);
// Отправляем уведомление через встроенный механизм платформы
ДоставляемыеУведомления.Отправить(ИдентификаторПриемника, Уведомление);
Если пуш-уведомления по каким-то причинам не подходят (например, работа ведется в закрытом контуре предприятия без доступа к интернету и серверам Google/Apple/1C) или требуется стопроцентная гарантированная доставка данных, приходится использовать периодический опрос веб-сервиса центральной базы со стороны мобильного приложения.
Постоянный запрос больших объемов данных при опросе раз в минуту создаст колоссальную нагрузку на сервер и быстро исчерпает мобильный трафик пользователя. Чтобы минимизировать нагрузку, применим метод хэширования состояний (например, алгоритм MD5).
Разберем этот алгоритм по шагам:
Пример реализации проверки хэша на мобильном клиенте:
// Опрос веб-сервиса для проверки обновлений
Соединение = Новый HTTPСоединение("server.company.com", , "Пользователь", "Пароль");
Запрос = Новый HTTPЗапрос("/hs/sync/get_state_hash");
Попытка
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ХешСервера = Ответ.ПолучитьТелоКакСтроку();
ХешЛокальный = ПолучитьЛокальныйХешДанных();
Если ХешСервера <> ХешЛокальный Тогда
// Обнаружены изменения, запускаем полную синхронизацию данных
ВыполнитьЗагрузкуДанных(Соединение);
СохранитьЛокальныйХеш(ХешСервера);
КонецЕсли;
КонецЕсли;
Исключение
ЗаписатьВЛог("Ошибка связи с сервером при опросе хэша.");
КонецПопытки;
Ни один из методов в отдельности не идеален. Пуш-уведомления могут теряться из-за нестабильного мобильного интернета, а частый опрос быстро разряжает батарею устройства и не работает в фоновом режиме. Наиболее надежным архитектурным решением является их комбинация.
Мы настраиваем мобильное приложение таким образом, что:
Если ваше мобильное приложение разработано в виде мобильного клиента 1С, отличным современным решением станет использование встроенного механизма платформы — Системы взаимодействия.
Этот инструмент позволяет отправлять мгновенные сообщения между пользователями и сервером без необходимости ручной настройки push-сервисов и написания низкоуровневых HTTP-интеграций. Платформа сама регистрирует мобильного клиента на сервере взаимодействия (например, бесплатном «1С:Диалог» или корпоративном 1С:CS) и обеспечивает мгновенную доставку сообщений и оповещений прямо в интерфейс мобильного приложения.
В современных версиях платформы 1С реализована нативная поддержка протокола WebSockets. Этот протокол позволяет держать одно постоянное открытое сетевое соединение между мобильным приложением и сервером.
Как только в центральной базе происходит изменение, сервер мгновенно отправляет данные в открытый сокет клиента. Это работает намного быстрее и экономнее обычного опроса (HTTP polling), так как исключает накладные расходы на постоянное установление HTTP-соединений. Однако помните, что WebSockets подходят только для активного (запущенного) приложения — при сворачивании программы операционная система смартфона неизбежно разорвет сокет-соединение. Для офлайн-режима пуши по-прежнему остаются единственным выходом.
Выяснив особенности работы каждого механизма, мы можем составить оптимальный план проектирования архитектуры: