При разработке мобильных приложений на платформе 1С:Предприятие программисты часто сталкиваются с неприятной особенностью: при обновлении конфигурации через механизм быстрой отладки или при использовании режима «Перезапуск из конфигуратора» внешние компоненты (например, драйверы из состава БПО — Библиотеки подключаемого оборудования) на мобильном устройстве не обновляются. При этом новые, ранее не использовавшиеся компоненты подгружаются без проблем, а уже задействованные библиотеки продолжают работать в старых версиях. Интересно, что в финальной сборке (внутри готового APK-пакета) такой проблемы не наблюдается — там всё обновляется корректно с первого раза.
В этой статье мы подробно разберем, почему возникает такое различие в поведении платформы разработчика и собранного приложения, а также рассмотрим несколько эффективных способов решения этой проблемы — от настройки веб-сервера до безопасной программной очистки кэша мобильного устройства.
Для того чтобы решить проблему, нам необходимо проанализировать внутреннюю логику работы мобильной платформы 1С в различных режимах. Различие в поведении функции НачатьУстановкуВнешнейКомпоненты кроется в способе доставки исполняемых файлов на мобильное устройство:
.so для ОС Android) физически упаковываются внутрь самого APK-пакета при сборке. При обновлении приложения происходит полная переустановка APK, операционная система Android обновляет все связанные файлы «с нуля», и старые версии библиотек просто перезаписываются новыми.НачатьУстановкуВнешнейКомпоненты обращается к локальному кэшу устройства и запускает уже имеющийся там файл, игнорируя наличие обновленной версии на веб-сервере публикации.Давайте разберем по шагам практические способы решения этой проблемы.
Самым надежным и удобным способом является автоматизация процесса очистки кэша средствами самой платформы 1С. Поскольку мобильное приложение обладает полными правами на чтение и запись внутри собственной директории (песочницы), мы можем программно удалять закэшированные файлы внешних компонент при запуске приложения в режиме разработки.
На ОС Android установленные внешние компоненты хранятся в специальном каталоге files/1C/ExtCompT. Мы можем написать процедуру, которая будет проверять, запущено ли приложение под платформой разработчика, и в случае подтверждения — полностью очищать эту папку перед вызовом методов подключения драйверов.
Рассмотрим пример реализации такого механизма в модуле управляемого приложения:
// Функция определяет, запущено ли приложение в режиме разработчика/отладки
&НаКлиенте
Функция ЭтоМобильнаяПлатформаРазработчика()
СистемнаяИнфо = Новая СистемнаяИнформация;
ИмяПриложения = ВРег(СистемнаяИнфо.ИмяПриложения);
// Платформа разработчика обычно содержит в имени "DEVELOPER" или "RUNNER"
Если Найти(ИмяПриложения, "DEVELOPER") > 0 Или Найти(ИмяПриложения, "RUNNER") > 0 Тогда
Возврат Истина;
КонецЕсли;
Возврат Ложь;
КонецФункции
// Процедура производит безопасную очистку папки с внешними компонентами
&НаКлиенте
Процедура ОчиститьКэшВнешнихКомпонентНаУстройстве()
#Если МобильноеПриложениеКлиент Тогда
Если ЭтоМобильнаяПлатформаРазработчика() Тогда
// Формируем путь к локальной папке хранения внешних компонент
ПутьККаталогуКэша = ОбъединитьПути(КаталогДокументов(), "../files/1C/ExtCompT");
ОбъектКаталог = Новый Файл(ПутьККаталогуКэша);
Если ОбъектКаталог.Существует() Тогда
Попытка
// Удаляем все файлы из каталога кэша компонент
УдалитьФайлы(ПутьККаталогуКэша, "*.*");
ЗаписьЖурналаРегистрации("ВнешниеКомпоненты", УровеньЖурналаРегистрации.Информация, , ,
"Локальный кэш внешних компонент успешно очищен для принудительного обновления.");
Исключение
ЗаписьЖурналаРегистрации("ВнешниеКомпоненты", УровеньЖурналаРегистрации.Предупреждение, , ,
"Не удалось очистить кэш компонент: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецЕсли;
#КонецЕсли;
КонецПроцедуры
Эту процедуру достаточно вызывать в обработчике события ПриНачалеРаботыСистемы. Таким образом, при каждом запуске конфигурации в режиме отладки кэш будет гарантированно чистым, и метод НачатьУстановкуВнешнейКомпоненты будет вынужден скачать свежую версию компоненты с веб-сервера публикации.
Еще один архитектурный подход заключается в изменении типа хранения макета внешней компоненты в самой конфигурации 1С. По умолчанию в БПО часто используются макеты с типом «Внешняя компонента». При публикации конфигурации такие макеты выгружаются в виде отдельных файлов в подкаталоги публикации (например, в папку Android на веб-сервере), что может приводить к сбоям при их скачивании раннером.
Если мы упакуем ZIP-архив внешней компоненты в макет с типом «Двоичные данные», поведение системы изменится:
1Cv8.1CM.Для подключения из двоичных данных используется стандартный метод инициализации, где в качестве источника передается путь к временно сохраненному файлу двоичных данных или сам поток.
Если в вашей конфигурации принципиально важно использовать макеты типа «Внешняя компонента», то узким горлышком может стать настройка веб-сервера (IIS, Apache или Nginx), на котором опубликована база для мобильного устройства.
При вызове метода установки компоненты мобильное приложение пытается скачать файлы библиотек по сети. Если на веб-сервере не зарегистрированы соответствующие расширения файлов, сервер вернет ошибку HTTP 404 (Не найдено) или HTTP 403 (Запрещено), из-за чего мобильное приложение оставит старую версию компоненты из кэша.
Проанализируем список расширений, для которых на веб-сервере обязательно должен быть настроен MIME-тип application/octet-stream:
.so — динамические библиотеки для операционной системы Android..apk — вспомогательные пакеты ресурсов и служб Android..dylib — динамические библиотеки для iOS..a — статические библиотеки для компиляции под iOS.Убедитесь, что ваш системный администратор добавил эти типы в конфигурационный файл веб-сервера. Например, в файле конфигурации Apache (httpd.conf) или Nginx должны быть соответствующие инструкции, разрешающие отдачу этих бинарных файлов клиентам без ограничений.
Платформа 1С определяет необходимость обновления компоненты на основе метаданных. Внутри ZIP-архива любой внешней компоненты обязательно присутствует файл описания — MANIFEST.XML.
Проанализируем типичную ошибку разработчиков внешних компонент: при внесении изменений в код библиотеки (файл .so) разработчики часто забывают увеличить номер версии в самом манифесте. Метод НачатьУстановкуВнешнейКомпоненты считывает манифест, видит, что версия на сервере совпадает с локальной (например, 1.0.0.1), и прекращает процесс установки.
При обновлении драйверов всегда проверяйте содержимое архива внешней компоненты:
MANIFEST.XML в текстовом редакторе.version у тега компоненты увеличен (например, изменен с 1.0.1.2 на 1.0.1.3).Иногда проблема кроется не на мобильном устройстве, а на стороне персонального компьютера разработчика. Среды разработки (особенно часто этим грешит 1С:EDT при быстром обновлении конфигурации) могут оптимизировать процесс сборки и перезаписывать только основной манифест конфигурации 1cema.xml.
При этом физические файлы внешних компонент (те самые файлы .so) во временной папке публикации веб-сервера на ПК (которая обычно располагается по пути вида %temp%\1cedt\...) могут не обновляться. Мобильное устройство запрашивает обновление, но веб-сервер на ПК отдает ему старые файлы из неперезаписанной временной папки.
Для исправления этой ситуации выполните следующие шаги:
%TEMP%).Применение этих практических подходов позволит вам выстроить комфортный процесс разработки и тестирования мобильных решений 1С, избавив вас от необходимости тратить время на ручные манипуляции с файловой системой мобильных устройств.