← На главную

При разработке мобильных приложений на платформе 1С программисты часто сталкиваются с неприятной особенностью поведения компонента ПолеHTMLДокумента. Представим классическую задачу: мы разместили на управляемой форме две страницы. На первой странице находится основной набор элементов интерфейса (таблицы, кнопки), а на второй — поле HTML, в которое загружена Яндекс Карта. Карта успешно отрисовывается при инициализации, но как только мы переходим на первую страницу и возвращаемся обратно, карта загружается и отрисовывается заново!

Рассмотрим, какие стандартные действия программисты пытаются предпринять для решения этой проблемы, и почему они не работают в мобильном клиенте:

1. Программное управление видимостью: Если просто скрыть элемент (установить видимость в Ложь), а затем снова включить, содержимое поля перерисовывается.
2. Использование сворачиваемых групп: Помещение поля HTML в сворачиваемую группу дает тот же результат — при разворачивании группы происходит полная перезагрузка контента.

Самое обидное в этой ситуации то, что в "настольном" тонком или толстом клиенте 1С все работает прекрасно — карта "стоит как вкопанная" при любых переключениях вкладок. Проанализируем ситуацию и выясним истинную причину такого странного поведения мобильной платформы.

Разберем технические причины выгрузки компонента

В мобильной платформе 1С ПолеHTMLДокумента реализуется не внутренними средствами самой 1С, а через встроенные нативные компоненты операционной системы (WebView для Android и WKWebView для iOS). Полноценный браузерный движок — это очень "тяжелый" компонент, требующий значительных ресурсов оперативной памяти и графического буфера.

Мобильные операционные системы спроектированы так, чтобы максимально агрессивно управлять ресурсами. Как только тяжелый визуальный элемент скрывается из активной области видимости экрана (при переключении страницы, сворачивании группы или отключении видимости), платформа 1С или сама мобильная ОС выгружают его для экономии памяти.

Соответственно, когда мы возвращаем компонент на экран, он инициализируется "с нуля". Происходит новая загрузка HTML-кода, отработка скриптов и полная перерисовка содержимого (в нашем случае — тяжелой Яндекс Карты).

Почему открытие новой формы решает проблему?

В ходе тестирования можно заметить интересную деталь: если сначала отрисовать поле HTML, а затем поверх этой формы открыть любую другую (например, форму выбора или настроек) и вернуться обратно, то перерисовки не происходит. Посмотрим, почему так происходит.

Это связано с базовой концепцией мобильной разработки (например, архитектурой Activity в ОС Android). При открытии новой формы поверх текущей, старый экран не уничтожается по частям. Вся форма целиком переводится в фоновый режим и "замораживается" в стеке экранов. Платформа понимает, что пользователь планирует вернуться к предыдущему экрану (нажав кнопку "Назад"), поэтому состояние WebView бережно сохраняется. Когда верхняя форма закрывается, нижняя выходит из фона ровно в том виде, в котором была оставлена.

Практические подходы к решению проблемы

Поскольку мы не можем напрямую отключить жесткий механизм экономии памяти в мобильной платформе 1С, рассмотрим рабочие архитектурные подходы, которые позволяют элегантно обойти это ограничение.

Подход 1: Использование отдельных форм вместо страниц

Самый простой и нативный способ решения проблемы — отказаться от вкладок и страниц на главном экране. Основной интерфейс (таблицы, списки, кнопки действий) мы оставляем на главной форме. Вместо переключения на другую страницу, мы создаем кнопку "Открыть карту".

Посмотрим на логику работы:

1. Пользователь нажимает кнопку "Открыть карту".
2. Мы программно открываем новую отдельную форму, на которой на весь экран развернуто ПолеHTMLДокумента.
3. На карте выполняются необходимые действия (например, выбор точки, установка балуна).
4. Пользователь закрывает форму с картой, и выбранные данные передаются обратно на главную форму (например, через оповещения).

При таком сценарии операционная система будет корректно управлять стеком экранов, и лишних перерисовок в рамках работы с самой картой не возникнет.

Подход 2: Сохранение и восстановление состояния (State Management)

Если интерфейс жестко требует переключения вкладок на одной форме, мы можем смириться с перезагрузкой, но сделать ее незаметной для бизнес-логики приложения. Для этого необходимо реализовать сохранение состояния карты.

Разберем алгоритм по шагам:

1. Перед тем как пользователь уходит со страницы с картой (или перед скрытием поля), мы через JavaScript запрашиваем у Яндекс Карты текущие координаты центра, уровень масштабирования (zoom) и список установленных балунов.
2. Передаем эти данные из JavaScript в 1С и сохраняем их в переменные формы.
3. Когда пользователь возвращается на вкладку с картой, 1С генерирует HTML-код, сразу внедряя в него сохраненные параметры.
4. Карта неизбежно загрузится заново, но отцентрируется ровно на том же месте и в том же масштабе, создавая иллюзию непрерывной работы.

Подход 3: Single Page Application (Полный интерфейс внутри HTML)

Если постоянные перерисовки критичны, а открытие новых форм ломает пользовательский опыт, разработчики используют самый радикальный метод — перенос большей части интерфейса внутрь HTML. В этом случае мы растягиваем ПолеHTMLДокумента на всю площадь мобильной формы, а стандартные элементы 1С вообще не используем.

Проанализируем этот метод:

1. Скрываемые списки, меню и кнопки рисуются поверх карты с помощью CSS и JavaScript прямо в HTML-документе.
2. Все переключения "вкладок" происходят внутри движка WebView с помощью JS без выгрузки самой карты.
3. Связь интерфейса с базой 1С осуществляется путем генерации фиктивных ссылок (например, перехват событий навигации) или через двусторонний обмен сообщениями между JS и 1С.

Важное примечание: При работе с мобильным клиентом прямой доступ к DOM-модели (через Элементы.ПолеHTML.Документ) может быть сильно ограничен по сравнению с десктопом. Поэтому всё взаимодействие, установку балунов и прокладку маршрутов нужно изначально планировать через инъекцию JavaScript функций или текстовый обмен событиями.

Используя эти знания об архитектуре мобильной платформы, вы сможете проектировать надежные и удобные интерфейсы, избегая проблем с неожиданной перерисовкой тяжелых компонентов.