SimpleUI дневник разработки

Пришло время обозначить векторы развития ядра платформы – основополагающей архитектуры. Дело в том что условно платформу можно сравнить с трактором к которому прилагается разное навесное оборудование. Именно на «навесное оборудование» был сделан упор в последнее время, а теперь пришла очередь самого тракторишки. Что то из этого уже было в 1С-ном конструкторе, но было неудобно. Будет удобно.
Так как симпл не мультиплатформенный фреймворк, а под конкретный SDK то возможно максимально задействовать это свойство и выжать именно те фишки Андроида которые дают преимущества.
Я условно назвал стратегию развития «Архитектура 2.0» и она включат в себя следующие блоки:
Обработчики и данные:
• Для каждого события будет произвольный набор любых обработчиков, в том числе повторяющихся тактов (сейчас на каждое событие толкьо питон, потом онлайн, можно будет например онлайн-питон-онлайн-sql)
• Соответственно различные такты можно будет запускать, исполнять командами в тексте, например немедленно выполнить такт и получить результаты
• Асинхронные обработчики смогут заканчиваться другими обработчиками, а не просто заканчиваться в фоне
• Число поддерживаемых интерпретаторов языков скорее всего увеличится ,как минимум будет еще чистый SQL, возможно JS
• Онлайн обработчики также могут быть асинхронными – Long polling или сокеты или просто HTTP в фоне
• Переменные(hashMap) перестанет быть чисто строковым и будет просто JSON, соотвественно будет поддерживать числа, массивы и т.д.
• Появятся новые события
• Планирование заданий, которые работают через системные планировщики даже при выключенном телефоне
• Еще более неубиваемый сервис и фоновые процессы, которые работают даже если приложение не запущено

Связь
• Наконец то полноценная замена push, вместо поллинга по расписанию – снижение нагрузки и повышение оперативности – бек пушит приложение когда надо. Это не имеется ввиду встроенный в приложение веб сервис, который работает только внутри одной подсети. Этот подход – замена FCM т.е. будет работать в любых сетях
• Поддержка сокетов на разных уровнях – на уровне экрана (чтобы например организовать чат), на уровне сервиса или приложения
• Поддержка XMPP
• Работа с MQTT причем маршрутизация пакетов сразу между обработчиками (например заказы на сборку идут к обработчику заказов на сборку и тд.)
• Загрузка больших данных с прогрессом в фоне – внутренняя очередь заданий, автоматизация работы с большими данными в условиях плохой связи
• Работа с запросами-одноразовыми заданиями которые отрабатывают при появлении возможности даже если телефон был выключен и запросами по расписанию, не зависящему от приложения (на уровне системы)
• Конструирование связки «связь-хранение» в урощенном режиме, как кубики. Меньше подготовки\парсинга данных для http-запросов и для SQL запросов
• P2P распределенные сети на базе локального WiFI и bluetooth, где нет связи, но есть группа устройств – не только автономная работа с последующей синхронизацией но автономная работа групп, например раздача заданий работникам от руководителя группы
Хранение
• Работа с хранением через команды-переменные+JSON, так, чтобы можно было управляться в т.ч. из онлайн например
• Работа через singletone , что позволит обращаться к SQLite одним подключением и не будет коллизий на уровне пересечения фоновых заданий и UI-потока, кроме того это проще и производительнее
• События синглтона при изменении даных чтобы перехватывать изменения для синхронизации
• Обработчики-SQL, адаптеры-облачных SQL и NoSQL с единым форматом JSON запросов/ответов. Кубики с единым интерфейсом для разных СУБД, типа ORM только для широкого спектра языков
Визуалка
• Управление обычным меню (не плитками)
• Чаты или чат-образные готовые блоки, которые можно переопределять, встраивать в контейнеры, использовать объект, suip-файлы, стартовать процессы, делиться процессами и данными
• Авторизация, в т.ч. биометрия на уровне конфы
• Развитие веторной графики
• Крупноузловые блоки и другие элементы интерфейса

👍16

880 views05:56