При разработке мобильных решений на платформе 1С:Предприятие программисты часто сталкиваются с вопросом выбора конкретной версии платформы. Версии 8.3.15 и 8.3.16 долгое время существовали параллельно, и хотя на первый взгляд они кажутся идентичными, между ними существуют глубокие архитектурные различия. В этой статье мы подробно разберем ключевые изменения, проанализируем ситуацию с поддержкой оборудования и выясним, в каких случаях переход на 8.3.16 является критически необходимым, а когда стоит остаться на проверенной 8.3.15.
Разберем основной технологический прорыв версии 8.3.16. Если в версии 8.3.15 мобильный клиент представлял собой, по сути, "тонкий клиент" для смартфона, требующий постоянного и стабильного интернет-соединения, то в 16-й версии появилась концепция автономного режима. Рассмотрим подробнее, что это дает разработчику.
Ранее, если мы хотели обеспечить работу пользователя в условиях отсутствия связи, нам приходилось разрабатывать полноценное "Мобильное приложение". Это означало создание отдельной конфигурации, написание сложных механизмов обмена данными (через HTTP-сервисы, планы обмена или Web-сервисы) и ручную обработку конфликтов синхронизации. Проанализируем, как 8.3.16 меняет этот подход:
Для реализации этого функционала в 16-й версии используются специальные свойства объектов. Например, мы можем определить, какие метаданные будут доступны автономно, используя механизмы, похожие на работу с распределенными информационными базами, но на уровне мобильного клиента.
Выясним причину, по которой многие разработчики были вынуждены покинуть старые версии платформы (например, 8.3.12). Как отмечается в обсуждении, основным триггером стали требования Google Play. Рассмотрим хронологию событий:
Начиная с августа 2019 года, Google Play установил жесткое требование: все новые приложения и обновления должны поддерживать 64-разрядную архитектуру. Платформа 1С 8.3.15 стала первой версией, где работа с 64-битными сборками была доведена до стабильного состояния. Посмотрим на технические аспекты этого изменения:
Версия 8.3.15 позволила собирать APK-файлы, содержащие библиотеки как для armeabi-v7a (32-бит), так и для arm64-v8a (64-бит). Это критично для производительности, так как современные процессоры смартфонов работают эффективнее в 64-битном режиме, имея прямой доступ к большему объему оперативной памяти.
В 8.3.16 эти механизмы были оптимизированы, а стабильность работы с памятью на устройствах с 6–8 ГБ ОЗУ значительно повысилась. Если ваше приложение активно работает с изображениями или тяжелыми отчетами, использование 16-й ветки и выше становится оправданным шагом.
Проанализируем ситуацию с кастомизацией типовых решений (таких как ERP или Управление торговлей). В версии 8.3.15 возможности расширений в мобильном клиенте были ограничены. Многие изменения в формах или модулях просто не подхватывались мобильным устройством.
В версии 8.3.16 разработчики 1С существенно расширили применимость Расширений конфигурации. Теперь мы можем:
&НаКлиентеНаМобильномУстройстве более гибко.Это позволяет обновлять основную базу данных, не пересобирая каждый раз мобильное приложение в сборщике, так как логика расширений динамически транслируется на клиент.
Посмотрим на визуальную составляющую. Современные смартфоны обзавелись "челками", вырезами под камеру и скруглениями углов. В 8.3.15 разработчики часто сталкивались с тем, что элементы управления (кнопки, заголовки) "заползали" под системные индикаторы или вырезы экрана.
В 8.3.16 была внедрена полноценная поддержка Safe Area (Безопасной зоны). Платформа автоматически рассчитывает отступы таким образом, чтобы контент приложения всегда находился в видимой части дисплея. Разберем, как это работает на уровне свойств:
// В 8.3.16 интерфейс автоматически адаптируется,
// учитывая системные отступы (Insets) операционной системы.
// Программисту больше не нужно программно вычислять высоту строки состояния.
Это нововведение делает приложение визуально "родным" для систем iOS и Android, повышая лояльность пользователей.
Рассмотрим важный комментарий из обсуждения: "в 16 больше глюков, особенно с типовой". Это частое явление для переходных версий платформы. Разберем причины:
Версия 8.3.15 считается "стабильной и обкатанной" (working horse). Она идеально подходит для простых задач: сканирование штрихкодов, заполнение простых документов, просмотр остатков. В ней минимум экспериментальных функций, что обеспечивает предсказуемое поведение кода.
Версия 8.3.16, напротив, содержит в себе огромный пласт нового кода, связанного с автономным режимом. Это усложняет внутреннюю логику работы Мобильного клиента. Если вы не планируете использовать автономность, возможно, 8.3.15 действительно будет более надежным выбором для высоконагруженных систем.
Упомянутая в дискуссии 18-я версия платформы заслуживает отдельного внимания. В ней появились Обещания (Promises) и асинхронные методы. Это решает извечную проблему мобильной платформы — "фризы" (зависания) интерфейса при выполнении длительных операций.
Проанализируем пример того, как асинхронность меняет подход к разработке (на примере вызова камеры):
// Старый подход (синхронный/через описание оповещения):
СредстваМультимедиа.СделатьФотоснимок(ОписаниеОповещения);
// Новый подход в 8.3.18 (асинхронный):
Результат = Ждать СредстваМультимедиа.СделатьФотоснимокАсинх();
Хотя автор вопроса интересовался 15-й и 16-й версиями, понимание вектора развития (8.3.18) помогает осознать, что 8.3.16 была лишь промежуточным шагом к более совершенной архитектуре.
Выясним, на какой версии остановиться именно вам, подведя итоги нашего анализа:
Таким образом, разница между 8.3.15 и 8.3.16 заключается не в косметических изменениях, а в фундаментальном подходе к доступности данных. Переходя на 16-ю версию, вы получаете инструмент для создания отказоустойчивых мобильных систем, способных работать в любых условиях связи.