Как реализовать ввод адреса по адресному классификатору в мобильном приложении 1С

При разработке мобильных решений на платформе 1С часто возникает задача стандартизированного ввода контактной информации клиентов или контрагентов. В типовых конфигурациях для настольной платформы за это отвечает подсистема адресного классификатора из состава БСП (Библиотеки стандартных подсистем), оперирующая базами ГАР и ФИАС. Однако прямое перенесение этого механизма в автономное мобильное приложение невозможно из-за ограничений мобильной платформы. Разберем причины этих ограничений и проанализируем основные архитектурные варианты реализации адресного классификатора на мобильных устройствах.

Технические ограничения мобильной платформы 1С

Попытка загрузить полноценный адресный классификатор напрямую в мобильное приложение сталкивается со следующими барьерами:

1. Объем базы данных и архитектура СУБД: Локальная база мобильного приложения функционирует на базе встроенной СУБД SQLite. Полный объем актуального классификатора ГАР/ФИАС содержит десятки миллионов записей. Хранение такого массива на мобильном устройстве приводит к гигантскому размеру установочного пакета и резкому падению производительности при выполнении поисковых запросов.
2. Зависимости подсистемы БСП: Код адресного классификатора в настольной БСП рассчитан на использование тяжелых серверных механизмов, фоновых заданий и специфических форм десктопного интерфейса, которые не поддерживаются мобильной платформой без полной переработки логики.

Рассмотрим рабочие способы интеграции классификатора в зависимости от требований к онлайн-доступу и автономности.

Вариант 1. Реализация собственного HTTP-сервиса на стороне центральной базы 1С

Если мобильное приложение имеет стабильный доступ к интернету или корпоративной сети, наиболее эффективным и бесплатным решением является вынос поиска адресов на сторону центральной информационной базы. В настольной базе уже развернут и регулярно обновляется стандартный классификатор БСП.

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

1. В центральной конфигурации создается объект метаданных HTTPСервис с шаблоном URL (например, /get_address).
2. На стороне сервера 1С реализуется метод поиска по адресному классификатору (через вызовы процедур БСП или прямые запросы к регистрам адресных сведений), возвращающий массив подходящих адресов в формате JSON.
3. В мобильном приложении в обработчике события АвтоПодбор или ОкончаниеВводаТекста поля ввода отправляется асинхронный HTTP-запрос к серверу (обычно при вводе от 3 символов).
4. Полученный ответ десериализуется в список выбора элемента формы мобильного приложения.

Посмотрим на пример отправки запроса и обработки результата на стороне мобильного приложения:

Соединение = Новый HTTPСоединение("server.company.ru", 443, , , , 10, Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/base/hs/address/search?query=" + КодироватьСтроку(СтрокаПоиска, СпособКодированияСтроки.КодировкаURL));

Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    Результат = ПрочитатьJSON(ЧтениеJSON);
    ЧтениеJSON.Закрыть();
    
    СписокАдресов.Очистить();
    Для Каждого СтрАдрес Из Результат Цикл
        СписокАдресов.Добавить(СтрАдрес.Представление, СтрАдрес.ЗначениеJSON);
    КонецЦикла;
КонецЕсли;

Вариант 2. Использование внешних специализированных API

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

Особенности данного подхода:

1. Быстрота внедрения: Не требуется дорабатывать конфигурацию центральной базы и публиковать HTTP-сервисы на веб-сервере.
2. Качество подсказок: Сервисы подсказок автоматически исправляют опечатки, определяют структуру адреса и возвращают уникальные идентификаторы ФИАС (GUID).
3. Ограничения: Бесплатные тарифы внешних сервисов, как правило, имеют суточный лимит на количество запросов. При интенсивной работе большого штата мобильных пользователей потребуется коммерческая подписка.

Вариант 3. Хранение усеченного классификатора для автономной работы (Offline)

Для сценариев, когда мобильное приложение должно работать без постоянного подключения к интернету, классификатор переносится локально, но в существенно сокращенном виде.

Проанализируем правила оптимизации локальной адресной базы:

1. Фильтрация по регионам: В локальную базу мобильного приложения загружаются адресные сведения только тех субъектов РФ, в которых непосредственно работают мобильные сотрудники.
2. Ограничение уровня детализации: В мобильную базу загружаются адресные элементы только до уровня городов, населенных пунктов и улиц. Номера домов, корпусов, строений и квартир вводятся пользователем вручную в свободной форме.
3. Полнотекстовый поиск: Для быстрого поиска по SQLite в мобильном приложении используется встроенный механизм полнотекстового поиска платформы. Для этого создается специализированный справочник с составным наименованием (индекс, регион, город, улица), по которому строится полнотекстовый индекс.

Вариант 4. Переход на Мобильный клиент или Мобильный клиент с автономным режимом

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

1. Мобильный клиент: Выполняет интерфейс и бизнес-логику непосредственно на сервере 1С. В этом случае все модальные формы БСП, стандартизированные поля ввода контактной информации и проверки по классификатору работают «из коробки» без изменения программного кода.
2. Мобильный клиент с автономным режимом: Позволяет выполнять основные операции онлайн с прямым доступом к полному классификатору базы, кэшируя локально только необходимые данные для временной автономной работы.

Формат хранения и передача адреса

Независимо от выбранного способа подбора адреса, для корректной последующей синхронизации с центральной базой адресные данные в мобильном приложении рекомендуется хранить не простой текстовой строкой, а сериализованной JSON-структурой, содержащей канонические поля и идентификаторы ГАР/ФИАС (GUID адресных объектов, почтовый индекс, коды ОКАТО, ОКТМО и структурированные элементы адреса).