Applications.md
Арго Фреймворк Википедия
Содержание
- Введение
- Установка Фреймворка
- Приложения Фреймворка *
- Системные и Пользовательские Приложения
- Оконные и Фоновые Приложения
- Режимы Запуска Приложений
- Привилегии Приложений
- Создание Приложений
- Примеры Приложений
- Структура Приложений
- Структура Управляющих Элементов
- Утилиты Фреймворка
Приложения Фреймворка
Сам по себе фреймворк не содержит ни единого встроенного приложения и, по сути, без них бесполезен. Всю полезную работу для создания качественного графического интерфейса выполняют приложения, используя API (Application Program Interface) фреймворка.
Приложения фреймворка могут классифицироваться по разным признакам - это системные или пользовательские приложения, оконные или фоновые, по режиму запуска: статические, динамические или запущенные в отдельном процессе (remote). Ниже будут рассмотрены все эти варианты.
Фреймворк имеет раздельные механизмы описания для пользовательского интерфейса и логической части приложения. Пользовательский интерфейс (окна приложения) прописываются в конфигурационных XML файлах приложения, в то время как логическая часть пишется на C/C++/Python языках.
Системные и Пользовательские Приложения
Важнейшей и самой влиятельной характеристикой приложения является его статус как системного или пользовательского приложения. Системное приложение обладает следующими свойствами:
- Такие приложения всегда предустанавливаются и не могут быть удалены из системы. Предустановка выполняется в конфигурационном описании системы и размещением файлов приложения по некоторым заданным правилам.
- Системные приложения обладают расширенным набором привилегий, которые позволяют им взаимодействовать с системным API фреймворка и получать системную информацию для ряда операций: запускать или закрывать другие приложения, получать информацию о файловой системе, работать с системными нотификациями и многое другое. Системные приложения могут автоматически запускаться системой, в то время как пользовательские такой привилегией не обладают. Пользовательские приложения тоже имеют некие привилегии, например, могут запускаться только в единственном экземпляре (singleton). Подробнее о привилегиях будет рассказано позже.
- Система может иметь несколько дисплеев и также несколько виртуальных суб-дисплеев. Системное приложение может создавать несколько окон в различных парах дисплей/суб-дисплей. Пользовательское приложение может создавать свои окна только в дисплее/суб-дисплее по умолчанию.
Пользовательские приложения могут быть установлены в процессе работы фреймворка и также удалены в любой момент. Разумеется, установленные приложения сохраняются при перезагрузке системы.
Оконные и Фоновые Приложения
Как понятно из названия, оконные приложения имеют как минимум одно окно, которое может увидеть пользователь. Окна приложений описываются в конфигурационных XML файлах приложения (все XML файлы фреймворка имеют расширение FML - Framework Markup Language, есть некоторые отличия от XML). Фоновые приложения таких описаний не имеют, и соответственно, никогда на дисплее не отображаются. Только системные приложения могут использовать такой режим. Пользовательские приложения должны иметь хотя бы одно окно.
Режимы Запуска Приложений
Фреймворк поддерживает три основных режима запуска приложений:
- Статический
- Динамический
- Удаленный
Статический режим подразумевает, что логическая часть приложения статически слинкована с исполняемым модулем фреймворка. Это возможно только при сборке исполняемого модуля и, поэтому не приемлемо для пользовательских приложений (ну можно, конечно, обойти. Но зачем? Для отладки приложений в SDK, например).
Приложение в динамическом режиме представляет собой динамическую загружаемую библиотеку (DLL - Dynamic Load Library). При старте приложения библиотека подгружается, и далее все работает как и в случае статической библиотеки. Пользовательские приложения могут быть динамическими, но это только пока и только для SDK.
Удаленный режим подразумевает запуск приложения в другом процессе. При этом пользовательский интерфейс по прежнему обрабатывается фреймворком, в то время как логическая часть находится в другом процессе. Приложение при этом строится как исполняемый бинарный файл. Обмен информацией между приложением и фреймворком производится по некоторым IPC (Inter Process Communication) протоколам, в частности, SDK может использовать TCP/UDP IP соединения для управляющей информации и разделяемую память для передачи больших объемов данных. В удаленном режиме может работать любое приложение, если время обмена данными с фреймворком не имеет существенного значения.
Приложения на языке Python могут работать только в удаленном режиме, статический и динамический варианты работать не будут. Связано это с механизмами Python C-API и необходимостью дополнительных операций линковки в таких вариантах. Теоретически, может быть, это и возможно, но практически реализовывать это я не стану. Однако ничего не мешает сделать приложения на Python системными, как и любое другое.
Использование статического или динамического режима запуска приложения полезно для максимального быстродействия приложений. Но при этом приложение работает в адресном пространстве фреймворка и в случае креша приложения… фреймворк не покрешится, как вы ожидали, но тут есть определенные нерешенные проблемы.
Предполагаются также некоторые дополнительные варианты запуска приложений, но они лишь разновидности уже перечисленных.
Привилегии Приложений
Привилегии приложений предназначены в первую очередь для разграничения возможностей системных и пользовательских приложений при управлении системой. Пользовательские приложения не имеют возможности вмешиваться в системные процессы, поэтому соответствующие привилегии им не доступны (системное приложение должно быть предустановлено, иначе привилегий не получить). Однако, некоторые привилегии пользовательским приложениям все же доступны. Привилегии представляют собой битовые флаги, разделенные на три диапазона: привилегии пользовательских приложений (биты 0 - 7); привилегии системных приложений (биты 8 - 23, также доступен и диапазон 0 - 7); диапазон отладочных приложений (биты 24 - 31, все остальные тоже доступны). В SDK диапазон отладочных приложений не доступен, но позднее может быть добавлен специальный маркер в коде приложения, чтобы этот диапазон включать. Код таких приложений будет закрыт, так же как закрыт код отладочного терминала (dbgshell) сейчас. Отладочный терминал не предоставляет всех возможностей в SDK сейчас, поскольку соответствующий диапазон заблокирован.
Привилегии устанавливаются либо в конфигурационном файле системы при объявлении системного приложения, либо в установочном файле пользовательского приложения. Задавать можно любое значение, но диапазоны все равно будут соблюдены. В дальнейшем разбивка битов по диапазонам, возможно, изменится, поскольку пока много резервных битов, но потом диапазоны будут уточнены.