Практика разработки мобильного приложения 1С 8.3 (часть 1)
В данной статье речь пойдет о том, что довелось перепробовать и на какие грабли наступить, прежде чем удалось сделать более-менее нормальное приложение для планшетников. Приложение изначально затачивалось только под Андроид, за основу взята конфигурация 1С: Заказы, и мобильное приложение для разработки.
Изначально был выбран «неправильный» подход с компилированием приложения и закидыванием его на планшетник вручную. Напомню, что для сборки мобильных приложений используется «Помощник создания мобильного приложения» (MobileAppWizzard). Затем на одном из форумов было найдено красивое решение с использованием мобильного приложения для разработки. Это приложение входит в комплект установки мобильной платформы. На момент разработки использовалась платформа версии 8.3.3.24. В папке «Android» можно найти файл 1cem.apk. Это и есть мобильное приложение для разработки. Его огромнейший плюс, сэкономивший нам уйму времени — в том, что можно опубликовать мобильное приложение на веб-сервере, а на планшетнике указать путь вида http://[Адрес веб-сервера]/[Имя мобильного приложения].
На планшетном ПК, в настройках добавленного приложения можно отметить флажок «Обновлять из конфигуратора», и при каждом запуске приложение будет пытаться подключиться к веб-серверу и проверять обновления.
После того, как мобильное приложение было развернуто, начался процесс его доработки.
Что требовалось:
1. Настроить обмен между центральной базой и мобильным устройством.
2. Организовать асимметричную синхронизацию: из центральной базы выгружать данные о номенклатуре, контрагентах, остатках товаров на складе и взаиморасчетах, а из мобильного приложения загружать только заказы покупателей.
3. Реализовать простой интерфейс для менеджеров, где они смогут быстро просмотреть остатки, цены и взаиморасчеты.
На этапе тестирования использовалась промежуточная база «Управляемое приложение», ввиду того что демо-приложение 1С:Заказы изначально заточено на обмен именно с Управляемым приложением.
Первый блин вышел комом. В прямом смысле. Для обмена с центральной базой был использован v82.ComConnector. Не буду вдаваться в подробности его настройки, об этом есть куча отдельных материалов. Пройдусь только по тем трудностям, с которыми столкнулся.
1. Использование com-объектов на 64-битной серверной ОС. Для решения проблемы была использована обертка COM+ Applications, которая настраивается в Component Services.
2. Удаленный вызов Com с другого сервера. Вызываемый сервер должен иметь роль Application Server, и у него должно быть настроено COM+ Network Access. Кроме того, сервер Apache должен иметь соответствующие права (т. е. запускаться как сервис от имени авторизованного пользователя)
Намучившись с Ком-соединениями, решили переводить рабочую базу на web-сервисы.
О публикации веб-сервисов также написано очень много, но там написано о том, как работает. Как НЕ работает, поделюсь ниже.
Рабочая база развернута на платформе 8.2, мобильное приложение, соответственно, на 8.3.
При публикации вначале приложения 8.3, а затем 8.2. периодически выхватывали глюк «Ошибка формата потока» в веб-клиенте 8.3, либо сообщение об ошибке «различаются версии платформы клиента и сервера». Перепубликация не помогает, равно как и перезапуск Apache. А вот отключение публикации и подключение заново — помогает.
Далее, поймал забавную ошибку при авторизации пользователя (при создании wsОпределения). При тестировании на компьютере, авторизация с длинным ФИО проходит легко. При попытке авторизации этого же пользователя с планшетника под управлением Android, авторизация заканчивалась, не начавшись. Экспериментальным путем удалось вычислить, что кириллицей длина логина ограничена 22 символами. При этом сочетание кириллических символов и цифр дало авторизоваться с логином длиной 27 символов. Есть подозрение, что это связано с преобразованием кириллических символов. Так, например, в браузере Firefox строка из Википедии «http://ru.wikipedia.org/wiki/Пиво» преобразуется в «http://ru.wikipedia.org/wiki/%D0%9F%D0%B8%D0%B2%D0%BE».
Технологически, мобильная платформа 8.3.3 на текущий момент имеет ряд ограничений. Самое ожидаемое, на мой взгляд, нововведение — это поддержка запросов. Но, поскольку произвольные запросы в динамических списках мобильная платформа пока не поддерживает, пришлось «пойти другим путем».
Для решения задачи отображения справочника номенклатуры с ценами и остатками был использован следующий подход:
1. В форме справочника номенклатуры созданы две таблицы. Первая — динамический список, собственно сам справочник. Фильтр динамического списка настроен так, чтобы выводились только группы. Вторая таблица — собственно остатки и цены. При активизации строки динамического списка, на сервере происходит заполнение таблицы значений, которая затем и выводится во вторую таблицу. При получении цен и остатков использовалась объектная модель. Все эти танцы с бубном были исполнены только потому, что привычного по толстому клиенту метода «при выводе строки» или «при получении данных» нет, и динамически нарисовать цифры в колонке нельзя.
Аналогичный подход использовался и в форме подбора
2. Для вывода строки с текущими ценами отлично подошла ФорматированнаяСтрока.
Ниже — пример кода.
&НаСервереБезКонтекста
Функция ОстаткиПриАктивизацииСтрокиНаСервере(ном)
НаборЗаписей = РегистрыСведений.ЦеныТоваров.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Товар.Значение = ном;
НаборЗаписей.Отбор.Товар.Использование = Истина;
НаборЗаписей.Прочитать();
МассивФорматированныхСтрок = Новый Массив;
Для Каждого СтрокаНабора Из НаборЗаписей Цикл
МассивФорматированныхСтрок.Добавить(Новый ФорматированнаяСтрока(СтрокаНабора.ВидЦен.Наименование,,WebЦвета.Синий));
МассивФорматированныхСтрок.Добавить(Новый ФорматированнаяСтрока(" " + Строка(СтрокаНабора.Цена) + " "));
КонецЦикла;
Возврат Новый ФорматированнаяСтрока(МассивФорматированныхСтрок);
// Вставить содержимое обработчика.
КонецФункции
3. Для загрузки справочников, остатков и цен в мобильное приложение был использован веб-сервис, который на входе получает структуру параметров, а на выходе возвращает хранилище значения. Еще одним неприятным открытием стал вылет обмена при слишком длительной обработке на стороне сервера. Сложилось впечатление, что имеется какой-то таймаут, после которого приложение «считает», что связь прервана (хотя на самом деле все еще идет обработка данных в рабочей базе через ws-соединение), и прекращает обмен с ошибкой.
Чтобы этого избежать, было принято решение дробить полный обмен на порции с возвратом фокуса обратно в мобильное приложение. Т.е. вначале синхронизировать номенклатуру, затем контрагентов, затем остатки, и т. п.
4. Для получения отчетов оставлен тот же подход, что и в конфигурации 1С: Заказы. Вызывается веб-сервис с параметрами, на стороне сервера рабочей базы формируется табличный документ, и затем уже готовый табличный документ возвращается в мобильное приложение.
