Добрый день! Меня зовут Дмитрий Воронцов. Несколько лет назад, я сделал небольшую локальную разработку под нужды своих 1С проектов (ERP, MES, WMS) — андроид клиент для ТСД и планшетов, который по сути являлся тонким клиентом для 1С и работал через HTTP сервис. Он был написан на Java и Android SDK и причина его создания была такая — нужен был легковесный и высокроизводительный клиент для работы с оборудованием и с возможностью быстрой разработки бизнес логики. Довольно простой бизнес‑логики, укладывающейся в рамки того, что обычно делается на ТСД. Он был достаточно примитивен и умел отрисовывать экраны на мобильном устройстве, а логика выполнялась на стороне 1С в рамках HTTP‑запроса. Постепенно он обрастал функционалом, добавились возможности для offline работы, добавился Python, CV‑функционал и многое другое. Им стали пользоваться кроме меня и моих коллег другие комманды разработчиков. И вот сегодня, в феврале 2023 я хочу подвести определенные и рассказать о том, во что превратился этот проект сейчас и что из себя представляет фреймфорк на текущий момент. Сейчас SimpleUI для Android — это бесплатный full‑app фреймворк для упрощенного создания широкого спектра бизнес‑приложений (клиентских приложений для ERP,WMS и других корпоративных систем, а также самостоятельных приложений). За счет особой архитектуры и принципов проектирования значительно сокращается время разработки, распространение и администрирование, поддержка.  SimpleUI для Android — не кроссплатформенная система, вместо этого этот фреймворк глубоко использует возможности Android и нативные подходы к разработке. Все реализовано с максимальным стандартным использованием Android SDK что позволяет создавать быстрые и легкие решения с максимальной производительностью и надежностью.  Приложение для Android запускает конфигурации (UI‑файлы) которые разрабатываются в «Конструкторе» и представляют из себя JSON‑файл, либо просто JSON‑строку каким либо образом переданную приложению (через файл на устройство, через веб‑севис и т. д.). Конфигурация включает в себя структуру процессов приложения, формы(экраны), обработчики событий и т. д. И собственно основная цель, ради которой это делалось — сделать процесс создания и поддержки решений максимально простым и быстрым. Ведь все тоже самое можно сделать на другом фреймворке, например, взять Android Studio и написать на Kotlin/Java. Лично я разработчик с большим опытом использования этих инструментов, но когда речь идет о том чтобы быстро накидать несколько АРМ(рабочих мест) для корпоративной системы — я выбираю Simple. Simple дает структуру для решений — некий унифицированный формат, возможность другому разработчику быстро присоединиться к проекту и знать где что лежит. Делая большие корпоративные системы так или иначе приходят к необходимости использования внутренних библиотек, унифицированных подходов внутри компании, так сказать внутренних фреймворков — вот это он и есть. Кроме того — низкий порог вхождения. Знаешь Python? Отлично, ты можешь создавать самостоятельные приложения для Android. Не знаешь Python, но знаешь к примеру 1С? Не беда, можно создавать те же самые приложения в онлайн‑режиме (еще с CV, AI‑штуками, графикой и многими другими плюшками) с обработчиками в бек‑системе. Конфигурация(ui‑файл) — это набор Процессов. Процессы чаще всего соответствуют какому то бизнес — процессу, например, «Приемка товара по заказу» и состоят из одно или нескольких экранов (в случае с ActiveCV вместо обычных экранов — видеопоток, но есть «шаги»). Также могут быть общие для всех процессов сущности, например, задание, выполняющееся по расписанию.  Экраны содержат элементы в контейнерах, т. е. разметка осуществляется с помощью контейнера (он как минимум один‑корневой). Это различные активные или декоративные визуальные элементы. Также невизуальные элементы — например, запуск камеры или сканирование штрихкода.  На экран или в систему в целом приходят события — нажатие кнопки, сканирование штрихкода и т. д. Эти события обрабатываются в обработчиках — синхронно либо асинхронно. Все управление начиная от возникновения собственно события, данных по событию до управляющих команд и вспомогательных переменных проходят через стек переменных. У процесса пока он существует свой стек переменных, есть также глобальные переменные на весь сеанс. В этот стек система помещает например, события, а обработчики пишут данные и команды.  На картинке выше происходит следующее: при нажатии кнопки, возникает событие onInput, в стек переменных записываются данные формы и переменная liatener, далее передается в обработчик на python где происходит вычисление inp_1+inp_2 и служебная команда ShowScreen для показа некоего другого экрана Обработчики могут быть на самом устройстве и работать локально, с локальными данными, но могут например, выполняться в бекенде. Все обработчики могут выполняться синхронно и асинхронно, последовательно друг за другом или параллельно. Например, система может работать сразу с бек‑системой и обрабатывать данные там, а по окончанию обработки что то выполнять на устройстве Например, система пишет в стек listener=barcode, barcode=22 001 221 112 — что означает что пользователь отсканировал штрихкод и в переменной barcode содержится сам штрихкод. Обработчик к примеру в бек‑системе находит по этому штрихкоду товар, например «Шоколад Ritter sport» и пишет в переменные переменную product_name «Шоколад Ritter sport» которую он хочет отобразить на экране  А в экране есть некая надпись в которой есть привязка переменной product_name через @  Вот таким образом все примерно и работает. Экраны поддерживают все визуальные элементы и много чего сверху — готовые блоки. Это позволяет делать яркие, выразительные приложения. Помимо традиционного способа проектирования приложений — с экранами, кнопками и т. д. есть альтернативный способ, который представляет огромное преимущество для бизнеса в некоторых случаях — режим работы в видеопотоке ActiveCV. Суть этого режима в том что вместо экрана включается камера с видеопотоком в которой происходит непрерывное распознавание объектов различными детекторами: штрихкоды, QR,  распознавание текста (OCR) чисел и дат (тоже OCR, но по шаблонам) автомобильных номеров лиц  , которое связано с обработчиками в которых реализуется некоторая логика по полученным с детекторов данных и в результате поверх объектов в видеопотоке выводятся данные — рисуется подсветка разными цветами, выводится текст и т. д. Примерно такие могут быть решаемые задачи: Показывать в кадре товары по которым проведена инвентаризация зеленым цветом, товары оп которым не провдена — желтым, а те, которых не должно быть на складе — красным.  Выводить рядом с товаром остаток и цену Показывать заказы по которым просрочена дата производства — красным цветом Показывать сотрудников смены зеленым цветом, а лишних на участке — красным  Ознакомиться с ActiveCV можно в этих видео: https://youtu.be/aLWSw9Rl-CA https://youtu.be/9Gwho6bWeKk https://youtu.be/Gwi2tEJnVfo https://youtu.be/N2nRmewAUAU Или в этом посте. Обратите внимание, что не смотря на то, что на экране в принципе можно вывести текст, всетаки больше внимания уделяется цветовой подсветке. Изначально эта технология проектировалась для задачи ускорения реального бизнес процесса (первая задача звучала так «Сотрудник заходит в кузов на X минут, ему нужно быстро проверить товар, ему нужно видеть уже посчитанный товар и тот, который не посчитан. Как можно ускорить этот процесс?». т. е. в принципе непрерывное сканирование можно сделать и на обычном экране — например, вывести таблицу и отмечать строки которые посчитаны цветом. Но подобная визуализация при наведении на объект дает преимущество ускорения самого процесса. Именно поэтому цветовая индикация более предпочтительна. И да, ActiveCV это больше не технология, а методология и организационная практика. И да, это не дополненная реальность, а «псевдо» дополненная реальность, т.к. настоящая на текущем уровне развития слишком прожорлива и ненадежна для реальных применений. С объектами на экране можно взаимодействовать — нажимать. Также есть вывод кнопок, общих надписей и т. д. Конечно, решения не обходятся без сервисных процедур по расписанию, работающих в фоне со своей периодичностью. Это может быть периодическая связь с сервером и т. д. Некоторые события могут работать не на экранах и даже кога приложение не запущено (не видно в списке приложений), потому что постоянно работает фоновый сервис, который отлавливает события и запускает обработчики. Например, это может быть сообщение от другой программы, или штрихкод или распознавание голоса. Ссылка. В рамках одной подсети симплу можно посылать различные HTTP‑запросы. Например, можно работать с SQL напрямую или выполнять свои кастомные обработчики: например, прислать заказ на устройство мгновенным способом или запросить активность. В системе есть единая точка входа для отлавливания всех общих для системы событий. Например, запись в SQL, приемка файла (кто то поделился файлом) и т. д.  Запуск фоновых задач периодических и однократных не зависимых от активного приложения с гарантированным выполнением Начиная с версии 11, работа с событиями и обработчиками максимально унифицирована.  События могут возникать в трех точках: Экраны ActiveCV Общие события системы На каждое событие можно подписать: Любое количество любых обработчиков. Т.е. можно например, выполнить Python, потом онлайн, потом снова Python …Которые будут запускать синхронно или асинхронно (да, в том числе онлайн обработчики можно теперь запускать в асинхронно, что нивелирует задержки) ...В случае асинхронного выполнения по завершении также можно назначить событие также синхронное либо асинхронное – т.е. рекурсивно    Обработчиками событий могут быть: Python (выполняемый локально) – получает стек переменных, записывает в стек свои переменные и комманды. Онлайн – код обработчика содержится на стороне бек-системы и когда условно пользователь нажимает на экране кнопку, в бек систему посылается запрос с стеком переменных, там выполняется обработчик, в ответ посылается этот же стек с переменными и новыми командами. Нативные обработчики. На текущий момент это SQL,HTTP и SET, которые непосредственно могут взаимодействовать с переменными, HTTP-соединениями, SQL-провайдером. Нюансы этого вида обработчиков лучше почитать в статье. Также в будущем возможно использование других интерпретаторов помимо Python и других нативных обработчиков. Обработчики и события могут быть объявлены в конфигурации (чаще всего) и также запущены вручную из кода. Для этого используется единый формат. Пример того как это выглядит в конфигурации Так и в коде: Организация хранения нужно если конфигурация не чисто онлайн, а может работать без связи с сервером. Тогда данные нужно где то сохранять.  Стандартным для Android является встроенный SQLite. Его преимущества в том, что это классическая реляционная СУБД — быстрая работа, SQL запросы, агрегирующие функции. Например, найти товар по штрихкоду из 1 миллиона записей, да еще по сложному условию ‑это не сделать быстрее, чем на SQL с индексами. Или например посчитать агрегаты — сумму по строкам таблицы. Опять же, быстрее SQL с этим никто не справиться. Можно завести несколько СУБД в рамках приложения. В Python обработчиках возможно использование Pony ORM Также помимо SQL иногда удобнее хранить данные не в реляционном виде, а в виде ключ‑значение. Например, можно записать пользовательские настройки или например, сохранить JSON для последующей обработки.  Работать с NoSQL можно как через стек переменных, так и напрямую через импорт Java‑классов (из Python). Из обработчиков Python можно создавать и работать с файлами из папки приложения без ограничений. Работа с внешними папками, к сожалению, отсутствует по причине безопасности Android т. е. если нужно файл передать например, то это можно сделать к примеру HTTP‑запросом. Также отдельное внимание уделено изображениям и созданы очень простые механизмы для работы с изображениями с минимум кода. По сути, все берет на себя платформа, вы получаете только готовую ссылку на файл.  В платформе возможна работа как с ассетами, определенными в конфигурации (элементы декора) так и с проивольными картинками. Кстати, несмотря на то, что картинку можно вывести в элемент экрана как base64, способ через файлы предпочтительнее, так как быстрее. Особенно это заметно на списках с картинками. Из решения можно связываться с внешним миром через произвольные HTTP‑запросы в обработчиках или же собственно онлайн обработчики, которые тоже являются запросами и через которые можно передать данные в обе стороны (тем более с учетом того, что работа с SQL, NoSQL возможна через стек переменных, а сами обработчики могут работать в асинхроне, то можно не возиться с python и requests, а просто вытягивать данные напрямую из бек‑системы). Но однако данные бывают большие (например, начальное заполнение или картинки), бывают данные требующие особой оперативности или вытраивающиеся в определенный корпоративный ландшафт. Поэтому иногда нужны и произвольные запросы.  Плюс на будущее запланированы другие технологии связи: Работа через WebSocket. P2P cвязь через WIFIDirect устройств напрямую без какой либо сети. XMPP. Работа с очередями (MQTT). Защита и шифрование на уровне приложения. Работа с штрихкодами и QR‑кодами может быть организована несколькими способами: Подпиской на события(Intent broadcast) встроенного сканера (для терминалов сбора данных) — предпочтительный способ для ТСД, на которых это возможно. Распознаванием событий клавиатуры, генерируемых либо встроенным, либо внешним сканером. Это может быть как имитация нажатия клавиш (wedge keys) так и строка с Enter(CR, LF, CR/LF) на конце и некоторые другие варианты перехвата подобных событий.  Работа с внешним сканером через Bluetooth напрямую. Вариант бюджетного решения и в некоторых случаях очень удобного решения «телефон в кармане, сканер в руке». Работа через камеру — это может быть как сканирование из экранов, так и ActiveCV. Также есть возможность перехватывать аппаратную клавиатуру как на экранах, так и на главном меню. Это может пригодиться в случае с ТСД для того, чтобы назначать свои функции на аппаратные кнопки, в том числе кнопки для запуска процессов. В режиме обычных экранов и в Active CV доступен OCR, причем вкупе с нехитрой методикой, которая позволяет работать с текстовыми идентификаторами на предметах также надежно (и почти также быстро), как если бы это были обычные штрихкоды, считываемые камерой.  Также в бизнес‑логику можно встраивать распознавание лиц, чисел, дат, автомобильных номеров. Например, можно распознавать ценники, даты производства партий, сотрудников смены. Из обычных экранов можно запускать ActiveCV и возвращаться с результатом обратно.  В платформе используется TTS Android поэтому командой speak можно озвучивать любые фразы. Также используется Voice Engine для распознавания голоса, поэтому можно использовать голосовой ввод как на экранах (по кнопке) так и в фоне. Логика может быть размещена в Сервисе событий, таким образом чтобы организовать свой голосовой ассистент — связать цикл «Вопрос‑Ответ» с логикой приложения. Например вы сканируете товар, обработчик задает вопрос (speak: «Какое количество?»), и ожидает ответ voice:voice_result, фраза помещается в переменную, из которой ее можно достать обработать и поместить количество в таблицу. Кстати, я лично считаю, что если и можно как то использовать голосовых ассистентов, то только так‑ в привязке к обработчикам, полном доступе к данным и бизнес‑логике. Есть возможность работать с HTML‑макетами через шаблонизатор (Jinja) из python‑обработчиков. Это может пригодиться для того чтобы формировать выходные формы непосредственно на устройстве. Например, печатать ярлыки с штрихкодами и сразу выводить их на мобильный принтер без связи с сервером. Там где связь невозможна. Также HTML‑поле содержит JS и в принципе с его помощи можно организовать свой какой то интерфейс внутри. Например, туториал по конфигурации.  Другая возможность — готовить их на сервере и передавать по запросу в PDF тоже присутствует. Подробнее тут. Можно создавать свои карты с интерактивными векторными объектами. Например, можно создать свою карту склада и показывать в ней ячейки из которых предстоит сделать отбор, подсвечивать разными цветами, обрабатывать нажатия на объекты и многое другое. Подробности тут. Использование векторных карт конкретно для складов дает массу возможностей — более точно планировать перемещения между ячейками с целью минимизации пробегов, выводить аналитику по складу в графическом виде(тепловые карты) — загрузку, оборачиваемость и т. д., использовать элементы интерактивно на экранах (нажимать на ячейку например). Все объекты интерактивны как из кода обработчиков, так и от пользователя. Можно работать с векторным редактором прямо в экранах для того, чтобы делать пометки на фото или просто заметки. Особое внимание уделено простоте и многообразию способов доставки конфигураций и обновлений а также настроек на устройство. Настройки приложения, чтобы не вводить их вручную, могут быть помещены в JSON файл и переданы в файлах, либо этот же JSON закодирован в QR при считывании которого настройки записываются на устройство. Часто удобным способом передачи конфигурации является устроить хостинг на каком то локальном веб‑сервисе либо например, на GitHub. Конфигуратор тоже хостит конфигурацию через Flask так как во время разработки изменения выходят часто и на устройстве достаточно либо перезапустить приложение либо нажать специальную команду в меню. Также можно передать конфигурацию любыми способами на устройство и открыть приложением как файл — она сразу применится. Этот способ — если нет связи. Есть механизм который позволяет хранить, обновлять конфигурации, быстро переключаться между ними, выполнять их фоновые задачи. Каждая конфиурация может иметь Поставщика, у поставщика может быть свой хостинг (Url) на который он выкладывает обновления. Таким образом конфигурация может быть «установлена» в репозиторий, где она всегда доступна в локальном виде без связи с сервером.  У нее может быть исполняемая фоновая часть (например, доставка сообщений к конкретной конфигурации).  При выпуске обновлений они будут проверяться для каждой конфигурации при запуске приложения если поставщик публикует их на своем URL Одна из особенностей Simple — конфигурации очень маленькие, легкие. Это открывает необычные возможности. Одна из таких — возможность выделить любой процесс в виде самостоятельного файла (такой мини‑конфигурации), которая сразу содержит в себе данные по этому процессу, т. е. автономная конфигурация с хранилищем внутри себя. Так, например, можно послать содержимое накладной вместе с процессом в виде suip‑файла стороннему контрагенту любым способом, например по почте. Он откроет это на своем устройстве сразу же так, как если бы у него была ваша корпоративная конфигурация и сможет работать с ней без подключения к вашим ресурсам: необходимые данные — берутся из фала, а результат его деятельности также сразу пишется в файл, который может быть отослан обратно для обработки. О Никаких настроек, никакой связи с вашими ресурсами — толкьо установленное приложение и файл. Например, вы можете отослать электронный упаковочный лист и suip‑фалом проверки приемки у внешнего покупателя, а он откроет это у себя на телефоне или ТСД, просканирует и отошлет обратно.  ТГ-канал с новостями и анонсами: https://t.me/devsimpleui Документация: https://uitxt.readthedocs.io/ru/latest/ Статьи на Инфостарте: https://t.me/devsimpleui  Сайт, на котором можно скачать комплект разработчика: http://simpleui.ru/