При разработке мобильных приложений на платформе 1С:Предприятие часто возникает задача оперативной доставки изменений пользователям. В отличие от настольных версий, где обновление может происходить в рамках локальной сети, мобильные устройства работают через интернет и требуют надежных механизмов проверки актуальности версии. Разберем подробно, как реализовать оповещение об обновлениях и как заблокировать работу пользователя до тех пор, пока он не установит новую версию конфигурации.
Для начала проанализируем возможности, которые предоставляет сама мобильная платформа без написания сложного программного кода. В свойствах информационной базы мобильного приложения существует встроенная настройка проверки обновлений.
Рассмотрим, как это работает: при публикации мобильного приложения на веб-сервере формируется специальный файл манифеста и файл конфигурации. В настройках мобильного клиента на устройстве, в разделе редактирования свойств информационной базы, существует команда проверки обновления. Если активировать опцию «Проверять обновление при запуске», платформа будет автоматически обращаться к веб-серверу перед началом сеанса.
Однако у этого метода есть существенный минус: он не позволяет гибко управлять процессом. Пользователь может проигнорировать уведомление или столкнуться с тем, что платформа просто предложит обновиться, но позволит работать дальше в старой версии, что может привести к ошибкам синхронизации данных. Выясним, как сделать этот процесс контролируемым.
Чтобы реализовать полноценный сценарий Hard Update (принудительное обновление), нам потребуется написать собственный алгоритм. Идея заключается в том, что приложение при старте должно сравнить свою текущую версию с версией, доступной на сервере.
Посмотрим на пример логики, которую можно разместить в модуле управляемого приложения в обработчике ПриНачалеРаботыСистемы. Для реализации нам понадобится внешний ресурс (например, простой текстовый файл или JSON на веб-сервере), содержащий номер актуальной версии.
Разберем по шагам создание такого механизма:
version.json с содержимым вида: {"version": "1.0.0.5", "url": "http://server.com/mobile/update.zip"}.Метаданные.Версия.Проанализируем пример кода для выполнения такой проверки:
Процедура ПроверитьОбновлениеПриЗапуске()
Соединение = Новый HTTPСоединение("ваш_сервер.ru");
Запрос = Новый HTTPЗапрос("/version.json");
Попытка
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
ДанныеОбновления = ПрочитатьJSON(ЧтениеJSON);
Если ДанныеОбновления.version <> Метаданные.Версия Тогда
// Вызываем процедуру обновления
ВыполнитьОбновлениеКонфигурации(ДанныеОбновления.url);
КонецЕсли;
КонецЕсли;
Исключение
// Обработка отсутствия интернета
КонецПопытки;
КонецПроцедуры
В мобильной платформе 1С предусмотрен специализированный метод для программного запуска процесса обновления — СредстваМобильнойПлатформы.ОбновитьКонфигурацию(). Рассмотрим его подробнее.
Этот метод принимает в качестве параметра URL-адрес, по которому платформа может скачать новую конфигурацию. Использование этого метода позволяет нам миновать стандартные диалоги настроек и сразу перевести пользователя к процессу загрузки. Важно понимать, что после вызова этого метода приложение будет перезапущено для применения изменений.
Важный нюанс: для того чтобы обновление прошло успешно, по указанной ссылке должен находиться корректно сформированный файл мобильной конфигурации (обычно это .1cmc или опубликованный ресурс).
Если задача стоит жестко — «не давать работать, пока не обновится», — нам нужно изменить логику открытия начальных форм. Рассмотрим ситуацию: если проверка версии в ПриНачалеРаботыСистемы выявила несоответствие, мы не должны давать приложению открывать основной интерфейс.
Разберем, как это реализовать структурно:
ЗакрыватьПриЗавершенииРаботыСистемы и сделаем ее модальной (или открывающейся поверх всех окон).ОткрытьФорму() и прерываем дальнейшее выполнение кода инициализации.Таким образом, пользователь увидит окно, которое невозможно закрыть и которое не позволяет перейти к документам или отчетам. Это гарантирует, что в базе не появятся данные, созданные на устаревшей логике кода.
В обсуждениях часто предлагают сравнивать дату создания файла конфигурации на сервере. Однако проанализируем причины, почему это плохая практика. При простом копировании файла или обновлении веб-сервера дата изменения файла может обновиться, даже если сам код не менялся. Это вызовет ложные срабатывания у всех пользователей приложения.
Рекомендуется использовать один из двух надежных способов:
Необходимо четко различать два типа обновлений, так как они требуют разных подходов:
1. Обновление конфигурации: Это изменение ваших объектов (справочников, документов, модулей). Оно выполняется методами, описанными выше, через HTTP-запрос и загрузку файла конфигурации.
2. Обновление мобильного клиента (APK/IPA): Если вам нужно обновить саму «оболочку» (движок 1С), то метод ОбновитьКонфигурацию() не поможет. В этом случае нам нужно использовать метод ЗапуститьПриложение(). Выясним, как это выглядит:
// Пример для Android
ПерейтиПоСсылке("https://play.google.com/store/apps/details?id=com.e1c.mobile");
// Или прямая загрузка APK
ЗапуститьПриложение("https://mysite.ru/apps/my_app_v2.apk");
При использовании прямых ссылок на APK-файлы помните, что на устройствах пользователя должна быть разрешена установка приложений из неизвестных источников.
Мы рассмотрели различные подходы к обновлению мобильных приложений на платформе 1С. Подведем итог: наиболее профессиональным решением является комбинированный подход. Используйте фоновую проверку версии через JSON-файл при запуске. Если версия критически устарела — блокируйте интерфейс специальной формой. Если обновление минорное — выводите ненавязчивое уведомление с предложением обновиться в удобное время. Это обеспечит стабильность работы вашей системы и лояльность пользователей.