Новая система хранения в Simple UI. Это все меняет.

28.06.21

Разработка - Мобильная разработка

Новая система хранения и синхронизации создания для того, чтобы радикально (в разы) упростить процесс разработки оффлайн-решений и открыть путь к созданию более гибких и мощных самостоятельных конфигураций. Она базируется на принципах NoSQL и JSON и идеально вписывается в архитектуру платформы. Теперь работать с хранимыми данными можно как с обычными переменными. Это, хоть и не слишком заметное, но важное событие, важная веха в развитии продукта. Эта статья является дополнением к основной статье по Simple UI: https://infostart.ru/public/1153616/

Классическое для Android-разработки решение – хранить данные в SQLite обладает немалыми достоинствами и является стандартным подходом и именно поэтому это было реализовано в первую очередь. Однако основная миссия Simple UI (именно на это указывает слово simple) – максимально упростить процесс разработки и поддержки решений. А вот с этим у SQL есть проблемы. На помощь приходит NoSQL и то, как удачно его можно вписать в архитектуру с Переменными. Напомню, что вся работа с данными и командами в Simple UI происходит через стек переменных. Так вот теперь можно работать с хранимым данными просто как с переменными – не задумываясь о структуре и типизации, не зная SQL и без лишнего boilerplate кода и без необходимости парсить данные для синхронизации. Система такая простая что с ней справится даже ребенок. Я думаю это кардинально изменит ситуацию с оффлайн-разработкой на платформе и ускорит разработку offline- или offline-first-решений в разы!

В чем по моему мнению NoSQL подход выигрывает у SQL:


1.Не надо знать SQL    SQL вроде язык простой, но по факту существует множество стандартов и особенностей в разных средах реализации. Например SQLite который используется в Android сильно отличается от T-SQL и в командах и в типизации
 

2.В SQL данные хранятся в таблицах, чтобы загрузить данных из сервера надо распарсить JSON, написать команды вставки/обновления в SQL-СУБД. А потом тоже самое проделать в обратном порядке чтобы послать данные на сервер.    А в новой системе хранения вы просто помещаете JSON в СУБД командой put_ а потом достаете командой get_ Данные преобразовывать не надо.
 

3.Тоже самое относится к различным экранным объектам в JSON. Вам надо сделать JSON из данных таблиц СУБД чтобы отобразить его на форме    Да, в SimpleUI сложные элементы экрана такие как таблица, список карточек и т.д. – хранятся в JSON их можно делать на сервере сразу и использовать как для отображения так и для хранения 
 

4. Не надо думать как поддерживать консистентность при апдейтах, если все данные по объекту инкапсулированы в единый JSON.    Когда речь идет об одной простой таблице обеспечение связанности и объем работ, который нужно сделать не так ощущается, но если это 3NF и данные документа хранятся в нескольких таблицах то вставлять/обновлять их также надо в нескольких таблицах, вот тут разница в простоте весьма ощутима.
 

5. Типизация в SQL сильная вещь, но что происходит когда структура данных меняется?    Происходит много проблем, в то время как при JSON системе хранения каждый объект может быть со своей структурой. Пример – разные объекты ОС имеют разную структуру полей, причем даже не привязанную к видам ОС а просто могут быть индивидуальные поля.
 

6. Связь с внешними NoSQL СУБД (Mongo DB, CouchDB) с NoSQL – праздник, с SQL много много проблем.     А зачем вообще нужны внешние NoSQL? Для того чтобы хранить файлы, картинки, видео а также сложные нетипизированные данные. Да, в SQL такой фокус не пройдет
 

7.Скорость записи    Да, да – скорость записи в NoSQL базах выше

Но SQL обладает и преимуществами. На самом деле я не предлагаю полностью забыть про SQL – их можно использовать вместе, параллельно.
Какие преимущества есть у SQL:
1. Агрегатные функции удобнее в SQL    Тут не поспоришь. Вычисление остатков товара в SQL удобнее, другое дело что например остатки товара на складе все таки правильно вычислять на сервере в 1С например, а не на локальном устройстве, так как нужно согласование с данными других участников процесса
2.WHERE и скорость поиска    А тут можно поспорить. С помощью системы индексов висящих в памяти удалось сделать поиск таким же быстрым – это по сути поиск по заранее подготовленному массиву в ОЗУ «ключ-значение». Но если углубляться в частные случаи то where на текущий момент где то лучше.

 

Как с этим работать?


С этим работать очень просто. Все данные хранятся в СУБД по системе «ключ-значение» это могут быть простые данные(числа, строки и т.д.) или JSON-строки. Данные можно разбить по конфигурациям – под каждую конфигурацию своя СУБД, либо частично объединять либо не разбивать. Это регулируется с помощью поля «Имя базы noSQL» - его можно не заполнять вообще(все данные будут сыпаться в одну кучу).

Базовые команды

Вот все команды «базового уровня» которые есть на текущий момент. Их более чем достаточно для реализации всего того, что до этого реализовалось с sQLite. 

1)Запись, чтение, удаление:

  • (put_ключ, переменная) - записать данные в СУБД в ключ

  • (get_ключ, переменная) - получить данные из СУБД из ключа в переменную. Если в обработчике есть команды get_find_ и finindex_ система извлекает данные из СУБД в Переменные, после чего вызывает событие «_results» (как бы новый такт обработчика)

  • (del_ключ,) - удалить ключ

  • (getallkeys, переменная) - получить

2)Поиск и индексы:

  • (find_имяпеременной, имяполя=значение) - «условно медленный» поиск по объектам в СУБД. в «имяпеременной» возвращается JSON-массив найденных объектов. «имяполя» - имя поля в корне JSON объектов по кторому будет вестись поиск. Вид сравнение можно использовать «=»(точное сравнение) или «~»(вхождение подстроки). Значение - значение поиска.

  • (createindex_имяиндекса, имяполя) и (findindex_имяиндекса, имяполя=значение). Индексы - загруженные в память таблицы значение - ключ, по которым происходит более быстрый поиск. Т.е. если индекс задать заранее, поиск будет произвдиться очень быстро - ведь это поиск по массивы у памяти а не в СУБД. Поэтому где в начале, возможно при запуске конфигурации, следует создать нужные индексы командой createindex_. Далее использовать команду findindex_, где в качестве параметра поиска уже использовать имя ранее созданного индекса.

3)Очередь (аналог авторегистрации плана обмена в 1С)

Очередь используется для автоматической фиксации изменённых или добавленных объектов. Это используется например для синхронизации - всегда можно получить список ключей, измененных на устройстве, чтобы выгрузить в основную систему. Очередь пишется автоматически, но ее можно выключить например при загрузке данных из учетной системы командой («StopQueue»,»»)

  • _sys_queue - переменная-очередь, в которой всегда содержится список ключей объектов, разделенных через «;»

  • (removequeue,ключ) - удалить ключ из очереди (например, при успешной выгрузке)

Работа с переменными - еще более простой способ что то сохранить.

Можно просто записать все переменные или список переменных в СУБД, а потом извлечь. Т.е. собсвенно, вы работаете с просто переменными. 

  • (puthasmap,списокпеременных) - записать дамп переменных в СУБД, списокпеременных - список имен переменных через «;»

  • (gethashmap,) - прочитать дамп переменных из СУБД в Переменные

Синхронизация с 1С

 

Одна из возможных схем синхронизации – передавать все через Переменные. Так как с переменными можно работать на сервере 1С в обработчике 1С то загрузка данных на устройство осуществляется в 1С, далее устройство работает с локальной СУБД  с помощью скриптов Python а когда нужно загрузить в 1С это также происходит на стороне 1С. Для этого используется «Очередь» - аналог «Плана обмена» в 1С

Но! Это не единственный вариант решения. Можно просто слать/принимать JSON через REST API, брокер очередей или другим способом. Просто этот способ показался мне простым и более наглядным именно для реализации с 1С. Поэтому именно его я выбрал в качестве примера в демо базе.


В этом видео я хочу прокомментировать процесс разработки с новой системой хранения. Тут рассмотрено простое решение - Заказы поставщика из 1С выгружаются на устройство, далее происходит работа с Приемкой по заказам оффлайн, а потом факт загружается обратно в 1С. Такой пример есть для SQL реализации, сейчас это сделано на NoSQL.

 

 

Дерево технологий

 



Такая система хранения открывает путь к другим замечательным возможностям - возможности совместной работы с серверными или «облачными» NoSQL СУБД такими как MongoDB Atlas, CouchDB, Couchbase  практически бесшовно так как структура хранения объектов совпадает. Данные в таких СУБД хранятся как правило в JSON и все что надо – отправить уже готовый ваш JSON или принять без необходимости в преобразованиях

Но зачем вообще нужны такие СУБД? Дело в том что в них удобно хранить неструктурированную информацию, а также большие файлы, картинки и прочее. С BLOB в SQL такая штука не проходит. Параллельно планируется доработка системы работы с мультимедиа, для совместной работы с NoSQL внутри устройства и синхронизации с другими СУБД.
 

Вместо заключения

Время покажет, но думаю теперь на оффлайн клиенты будет тратиться времени столько же сколько на онлайн и разрабатывать чисто он-лайн уже не будет иметь смысла. Вместо этого будет "offline first" - пишем базу и сразу отправляем на сервер в фоне либо пакетами по расписанию если есть возможность (если нет - копится в очереди, потом по возможности отправляется). Плюс какие то данные чисто всегда с сервера. Общемировая статистика по стекам разработки говорит о постоянном увеличении доли NoSQL как в серверном так и в мобильном сегменте.

Для меня очень ценно знать мнение сообщества разработчиков на Simple UI, поэтому буду крайне признателен за ваши комментарии по этой новой системе хранения - будете ли вы ее использовать, стоит ли ее развивать, что хотелось бы добавить? Или эта система не нужна, а для оффлайна достаточно SQLite?

мобильная разработка Android SimpleUI Simple

См. также

SALE! 25%

Что нам стоит бота построить? Нарисуем - будет жить! Графический конструктор телеграм-ботов/Telegram

Мобильная разработка Мессенджеры и боты Платформа 1С v8.3 Платные (руб)

Теперь создать telegram-бота - элементарно. Достаточно просто нарисовать блок-схему телеграм-бота, и он сразу заработает. Это возможно при использовании Графического конструктора телеграм-ботов. Это единственный конструктор ботов для telegram, чье качество и функционал подтверждены фирмой 1С, есть сертификат 1С:Совместимо. Расширение в интерактивном режиме, с помощью блок-схем, позволяет с минимальными трудозатратами создать телеграм-ботов в любой конфигурации, работающей на платформе «1С:Предприятие 8.3».

13200 9900 руб.

27.12.2021    35015    89    161    

185

"Штрихкод-информер" 1С (штрих-код-чекер) - мобильный ТСД и прайс-чекер в смартфоне

Мобильная разработка Сканер штрих-кода Терминал сбора данных Управляемые формы Мобильная платформа 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Сбор заказов, инвентаризация, проверка ценников, просмотр полной информации об остатках и ценах со смартфона Онлайн - все это содержит в себе решение 1С "Штрихкод-информер" (штрих-код чекер). Отправка данных со смартфона выполняется либо напрямую в открытую форму документа, отсканировав QR-код, либо в общую корзину учетной системы, не подходя к компьютеру. Кассир или оператор сможет просмотреть список присланных данных и загрузить в любую форму, поддерживающую работу с ТСД. Для работы с мобильным приложением требуется опубликовать HTTP-сервис из поставляемого расширения.

2880 руб.

03.12.2018    56352    174    103    

167

Программа "Мобильный ТСД сканер для 1С" - приложение для телефона для инвентаризации и сбора штрихкодов для iOS и Android

Сканер штрих-кода Терминал сбора данных Мобильная разработка Монитор заказов Оптовая торговля Розничная торговля Ценообразование, анализ цен Программист Пользователь Платформа 1С v8.3 Мобильная платформа 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Простой мобильный ТСД (терминал сбора данных) сканер для 1С для смартфонов на iOS и Android, не требующий сложных настроек и установки дополнительных программ. Обмен между Вашей 1С и мобильным приложением осуществляется через облачный сервис и расширение конфигурации. Работает с конфигурациями УТ 11, ERP, КА2, Розница 2, Розница 3, УНФ 1.6, УНФ 3.0. Полнофункциональный демо-доступ для своей конфигурации можно запросить в настройках мобильного приложения - все необходимое придет на почту автоматически.

2000 руб.

22.04.2019    93445    537    186    

304

Магазин 15 - приемка товара по штрихкодам или инвентаризация в торговом зале

Логистика, склад и ТМЦ Мобильная разработка Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Россия Платные (руб)

Специализированное программное обеспечение для мобильных устройств со встроенным сканером штрихкодов. Позволяет быстро автоматизировать, оптимизировать рабочие места и бизнес процессы по учету товара в магазине. Например, приемку товара по штрихкодам или инвентаризацию прямо в торговом зале.

12950 руб.

30.05.2023    3622    2    0    

4

Работа с графикой в браузере (SimpleWEB). Векторный редактор

Мобильная разработка WEB-интеграция Программист Мобильная платформа Абонемент ($m)

В SimpleWEB добавились средства для работы с графикой и отслеживание событий мыши, в онлайн редактор https://seditor.ru:1555/ добавился «Векторный редактор» на этом API. Теперь можно нарисовать схемы складов на ПК, сделать карты (*.sug-файлы) для мобильной платформы SimpleUI, выводить данные из 1С в графическом виде. Таким образом, API для работы с векторными файлами теперь есть и в веб- и в мобильной платформе, а также средства для создания и редактирования векторных файлов есть тоже в обеих платформах.

1 стартмани

20.03.2024    1853    1    informa1555    1    

44

Зачем нам 1С:Элемент

Мобильная разработка Языки и среды Программист Бесплатно (free)

Flutter может быть использован с 1С:Предприятием для разработки кроссплатформенных мобильных приложений, обеспечивая единый интерфейс и функциональность на устройствах под управлением iOS и Android. Это позволяет создавать приложения с высокой производительностью благодаря использованию собственного движка рендеринга Flutter. Интеграция Flutter с 1С:Предприятием позволяет создавать мобильные приложения любого уровня сложности, интегрировать их в корпоративные информационные системы, а также реализовывать бизнес-логику

19.03.2024    11714    ROk_dev    67    

44

JavaScript в Simple

Мобильная разработка Программист Бесплатно (free)

В SimpleUI и SimpleWEB, наряду с обработчиками на python и онлайн (1С и т.д.) добавляется интерпретатор JavaScript. В андроид платформе он скорее играет на поле python, т.к. является оффлайновым решением для самостоятельной обработки и расширяет аудиторию разработчиков для разработки самостоятельных решений. Дополнение к основной статье https://infostart.ru/1c/tools/1153616/

12.02.2024    1828    informa1555    0    

25
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 304 28.06.21 15:19 Сейчас в теме
Исходники открытые или закрытые ?
user1035175; kote; +2 Ответить
2. narodukr 6 30.06.21 14:16 Сейчас в теме
Однозначно лучше иметь выбор (SQL, NoSQL), чем жить без выбора. Каждый разработчик для каждой конкретной задачи выберет тот инструмент который подходит.
3. davdykin 25 09.07.21 19:22 Сейчас в теме
(2)Вы не забывайте, любая "универсальность" как правило имеет "цену", производительность, сложность инструмента и т.д.
Оставьте свое сообщение