Prometeus2011

В работе класса 1с ЗапускПриложенияМобильногоУстройства есть еще такой очень важный и иногда неприятный нюанс.
Все методы запуска (Запустить, ЗапуститьАсинх, ЗапуститьБезОжидания), принадлежащие этому классу, запускают приложение в контексте процесса ЗАПУСКАЮЩЕГО приложения (без флага FLAG_ACTIVITY_NEW_TASK). Со всеми вытекающими...
Визуально это выглядит как запуск другого приложения прямо в окне запускающего приложения. Т.е. новое "окно" в карусели окон не создается. Одно из неприятных последствий такого поведения - то, что если в запускаемом приложении есть баг и андроид его крашит, то крашится "Ваш" процесс (т.е. тот, который запустил сбойный пакет). Пример другого последствия: отсутствие этого флага в запускающем Намерении (Intent'е - в терминологии Андроида) не позволяет запускать активити (окна) системных настроек - например, запрашивать внесение приложения в белый список по питанию или открывать список wi-fi соединений и т.д. (правда, в случае с 1с это итак не получится, поскольку желание запуска таких окон надо еще в манифесте приложения прописать, а 1с не дает прямой доступ к манифесту МП).
Наблюдал еще и другие артефакты в поведении 1с МП - при запуске в контексте запускающего процесса.
Это обычно меняется установкой флага "FLAG_ACTIVITY_NEW_TASK" через метод "setFlags", применяемый к объекту намерения, но как устанавливать произвольные флаги намерения в 1с - я не нашел.

Но да... есть способ как заставить 1с создавать новый процесс при запуске приложения - через использование Deep Linking (https://wonderland.v8.1c.ru/blog/zapusk-mobilnykh-prilozheniy-1s-iz-vneshnikh-istochnikov/?sphrase_id=322051).

Заметка написана, на мой взгляд, слегка сумбурно, но если выкинуть там часть, которая говорит, что Вам следует поднять свой сайт(!!!), то все работает. То-есть: если создавать класс ЗапускПриложенияМобильногоУстройства с указанием глубокой ссылки: Новый ЗапускПриложенияМобильногоУстройства("android.intent.action.VIEW", "myapp://testPath?key1=1"), а не Новый ЗапускПриложенияМобильногоУстройства("android.intent.action.VIEW"), то операционка создает новый процесс. Единственное, что - запускаемое приложение в манифесте должно объявлять свою способность обрабатывать конкретные схемы deeplink (это то, что до двоеточия и двойного слеша ("myapp")).

(32) Если хотите кого-то обмануть, то советую попробовать курить в сторону sikulix. Возможно, не так быстро и надёжно работает, но универсально.

Порядок действий примерно такой: Сикуля (Глаз Бога))) выполняет задачу по имитации действий пользователя по сохранению нужных вам страниц в каталог, а скрипт на 1с или любом другом языке - их парсит.

(5) Так и есть. С 26 версии getDeviceId deprecated). Вначале это было проблемой, но потом клиент с большим количеством устройств перешёл на использование Headwind MDM и проблема отпала. При работе с компаниями поменьше используется просто ФИО последнего авторизовавшегося пользователя.

(3)Тоже программный. Спасибо.

Не подскажете, как реализовано у вас получение и хранение идентификатора устройства? В смысле, что используется в качестве идентификатора?

Насчёт RabbitMQ: коротко заказчик отказался, хотя идея на поверхности. Причина не банальна: Компания использует проксирование всех входящих хттп запросов (через nginx). Данные тела запросов хардкорно складываются в СУБД в текстовом виде и потом их можно оттуда столь-же хардкорно выбрать обычным sql-запросом.
Какой бонус в таком олдскульном подходе? Это отсутствие жёсткого вендор-лока на чужие сервисы. Ну, например, можно взять любого тестировщика, который способен написать селект и сказать ему: "встань и иди! ")) И он пойдёт) В смысле выберет данные из БД в любом удобном для себя виде и может сделать с ними всё, что угодно.
Вначале тоже не понимал скрытого великолепия такого решения, но потом понравилось.
Понятно, что всё это хорошо, когда заказчик могуч в плане собственного ИТ и имеет инфраструктуру достаточной мощности.
Хотя к RabbitMQ прикоснуться тоже хочется, но пока задач нет.

Невозможность выполнением нескольких фоновиков (регламентных заданий, на 18 версии мп нет) и вытекающие из этого проблемы управления исполнением приложения, привели к решению по разработке шлюза, который поднимает хттп сервер на локалхосте и берёт на себя всю логику по обмену. В 1с только прикладной уровень разработки и все обмены сводятся к 2м методам: плюнул данные в локалхост и если надо-прочитал из него-же состояние отправки. Причём, пользователи очень просили видеть состояние получения больших данных (базы марок по 300 мб могут грузиться долго). Шлюз позволил это реализовать со статусбаром, прерыванием пользователем и всеми другими бананами.
Шлюз разработали на Qt 6.x. Фреймворк
очень мощный, заточён под встроенные системы и имеет удобные и очень быстрые либы практически для всего, чего только можно, а если не хватает, то можно найти кучу сторонних библиотек.
Логи клиент императивно просил писать на его сервера. Был прямой запрет на использование сторонних сервисов.
С инженерной точки зрения отдельных инженерных решений обмен данными устроен очень близко к тому, что вы описываете. Максимальное количество устройств: 300+.
Бэк: node.js, визуализация данных - 1с.

(65) Вы ведь сейчас говорите про онлайн обработку данных со сканера в бэке?
По предложенному Вами инженерному решению, сразу видно, что вы поверхностно занимаетесь вопросом.
Нет сети в момент нахождения человека, например, в холодильнике с ТСД. Ни вай-фай ни мобильной сети.
Суть мп в том, что это автономная и надёжная в части хранения и передачи сделанной оператором работы, система - со своим набором данных. Потому-что доступ к данным, которые надо собрать, у заказчика может быть сопряжён со многими сложностями и происходить в неприятной обстановке)

Если у вас чёткий, надежный онлайн 24/7 по всей площади использования устройства-это самый простой кейс. Он для пресс-релиза. В полях всё ломается и надо быть готовым, что связь будет кусками и самая плохая, а данные нужны в бэке - чем быстрее-тем лучше. За это готовы много платить.

А, да, кстати, на мобильной платформе и с хттп-клиентом тоже беда. Работает он хуже, чем, допустим, на Qt (стабильность соединения ниже, программный интерфейс класса очень беден).

+ вы знали, что у мп 1с только один фоновый поток (как у файловой настольной БД), так-что все ваши фоновики выполняются строго последовательно?

Циферка предполагает вариант. Этот вариант - такой себе вариант, что и не вариант совсем). Вот и постарался указать на это.

Да что тут я всё это пишу-то. Обычно не ввязываюсь в холивары. Каждый инструмент-для своих задач. 1с-гениальная платформа для учёта. Всё, пожалуй.

(45) Вы не разработаете полноценное мобильное приложение для промышленного использования только на 1с. Ни по быстродействию ни по взаимодействию с ОС 1с не достаточно. Простой пример: есть у вас база марок по алкоголю на 150 тысяч строк. Длина марки до 150 символов со всеми криптохвостами. 1с на современном промышленном устройстве (которое можно отремонтировать,заменить, которое не глючит с запуска), например от атолла, которое вы сможете купить массово за разумные деньги (это от 20к) ложит 1с при поиске марки секунды на 4. Это фиаско. Sqlite такую задачу перемалывает за миллисекунды. 1с с скульлайт не работает никак.
Дальше. Фореграунд-сервисы, асинхронная отправка и получение данных. Логи действий пользователя (пользователи всегда врут-надо за ними следить) и т.д.
В общем, поделку сделать можно, мощное промышленное приложение, которым можно пользоваться - нет.

Пару лет назад у них 'сохранять куда-нибудь туда' считалось нарушением условий бесплатного использования сервиса)

1. Сразу показалось, что объем операций у Компании не очень большой, т.к. вся вот эта тема с переносом цен из одной колонки в другую скорости работе не добавляют. По причине не большой интенсивности транзакций в базе всё это как-то работало.

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

3. Вообще, 1с программист - это очень многогранное искусство. Именно искуство. И досрочная пенсия с санаториями было-бы кстати), т.к. к сорока годам психика уже расшатана, а здоровье подорвано сидячим образом жизни.