|
|
              
Advanced Organizer API UsageIntroductionThis section provides some detailed information on more advanced topics regarding the Qt Organizer API. The Detail ModelWhile QOrganizerItem and its subclasses provide methods for data access and manipulation which should be sufficient for most purposes, it is actually a generic container that can hold arbitrary data in the form of details. In fact, functions for manipulating items, such as QOrganizerItem::displayLabel() or QOrganizerEvent::setRecurrenceRule() are merely convenience functions that perform operations on the underlying details of an item. A QOrganizerItem consists of nothing more than the details it contains, as well as an id and the id of its collection. A QOrganizerItemDetail is a single, cohesive unit of information that is stored in an item. A detail may have specific meta-data associated with it, as well as access constraints which may apply to the detail (e.g., read-only, irremovable, etc). A list of all standard details defined by this API are listed here. Some details are read-only (such as the modification timestamp of an item) or irremovable (like the type of an item), but most are freely modifiable by clients. The QOrganizerItem::details(), QOrganizerItem::detail(), QOrganizerItem::saveDetail() and QOrganizerItem::removeDetail() functions can be used to manipulate these details. It is important to note that details are implicitly shared objects with particular semantics surrounding saving, removal and modification. Optimization in item retrievalClients can inform the manager that they do not require certain details from an item, which can allow a manager to optimize item retrieval. In this way, the client can inform the manager that they are not interested in any binary blob data (e.g., images) in retrieved items. These restrictions can be specified by providing a QOrganizerItemFetchHint as an argument to the retrieval operation. Note that if the item already exists in the database, it will be completely replaced. This means that clients should not save any item which was retrieved with a non-empty fetchHint defined, or data loss may occur. The Organizer Manager and Manager EnginesThe Organizer ManagerAccess to organizer items is provided by implementations of the Qt Organizer manager API. Each manager may support different capabilities (for example, the ability to store certain datatypes, the ability to natively filter on different details or details of different definitions, the provision of locking mechanisms, the provision of changelog information, etc) which are reported by the manager on request. The manager therefore provides access to detail definitions and collections of organizer items stored in different datastores, in a platform and datastore independent manner. The QOrganizerManager is in fact a client-facing interface through to a platform-specific manager engine (which is implemented as a Qt plugin). While clients never interact directly with the manager engine, they may need to be aware of limitations of individual engines, or differences between engines. The API offered through QOrganizerManager allows clients to retrieve this information for the engine which provides the functionality exposed through a particular QOrganizerManager. Storage considerationsA QOrganizerManagerEngine may provide an aggregated view of multiple physical datastores, some of which may be remote datastores. Clients of the API are aware only that the data is managed by a QOrganizerManagerEngine with a particular URI. It is possible that multiple different engines will have overlap in the datastores which they aggregate, and in that case the way in which those engines were implemented will determine whether operations are thread-safe or not. Since the data may physically be stored in a remote datastore, any operations may be dominated by the return-trip-time of communications with the remote datastore. As such, it is recommended that clients use the asynchronous client API to access organizer information from any QOrganizerManager. Provided EnginesThe Organizer module of the QtMobility project includes several backends already, some of which are designed to interface with the default calendar on their particular platform. In-Memory Example EngineThe in-memory engine identifies itself as the "memory" engine. It is available on all platforms which are supported by the QtMobility project. The in-memory engine supports the default schema, and provides almost all functionality available through the QtMobility Organizer API; however, all data is stored in-memory and is not persisted in any way. Symbian EngineThe Symbian engine identifies itself as the "symbian" engine, and is only available on the Symbian S60 3.1, S60 3.2, S60 5.0 and Symbian^3 platforms. The Symbian engine supports a modified version of the default schema. The schema supported by the Symbian engine depends on which version of the platform is being used. The Symbian engine allows clients to use both the asynchronous and synchronous interfaces, and persists all saved data to the system calendar. Maemo 5 (Fremantle) EngineThe Maemo 5 (Fremantle) engine identifies itself as the "maemo5" engine, but is only available on the Maemo 5 (Fremantle) platform which has the correct libraries installed (including calendar-backend). The Maemo 5 (Fremantle) engine supports a modified version of the default schema, and persists all saved information to the system calendar. Manager Settings And ConfigurationUsers of the items API can define which backend they wish to access if a manager for that backend is available. The list of available managers can be queried programmatically at run-time, and the capabilities of different managers can be ascertained by inspecting a QOrganizerManager instance. Furthermore, some managers can be constructed with parameters which affect the operation of the backend. Querying a manager for capabilitiesDifferent managers will support different capabilities and details. Clients can use the meta data reporting functions of QOrganizerManager to determine what the capabilities of the manager they have instantiated might be. Loading the manager for a specific backendThe client can choose to load a manager for a specific backend. While the engine could be found and retrieved using a more advanced plugin framework (such as the Qt Service Framework), this code assumes that the client has prior knowledge of the backend in question: QOrganizerManager specificManager("symbian"); Clients may wish to use this feature of the API if they wish to store or retrieve item information to a particular manager (for example, one that interfaces with a particular online service). Loading a manager with specific parametersThe client can load a manager with specific parameters defined. The parameters which are available are backend specific, and so the client has to know which parameters are valid for a particular backend, and what argument it takes. Meta Data APIThe QOrganizerManager class provides a static function QOrganizerManager::availableManagers() which allows clients of the API to determine (at run time) which plugins (managers) are available for use. Clients of the API also need to be able to determine (at run time) what the capabilities of a given plugin (organizer item manager) are. The QOrganizerManager class provides API to query the capabilities of a given manager with the following synchronous functions: A given manager is identified by its URI. The URI consists of the manager's name, any relevant parameters which were used during instantiation of the manager, and the version of the manager. While the name of the manager identifies the plugin which provides the functionality, you cannot guarantee that the data available through one manager will be available through another with the same name (for example, if one parameter tells the plugin to store and retrieve organizer information from a particular online service or local file). The synchronous API offered to allow run-time querying of a manager's metadata includes: The functionality that the above functions provide is only available through synchronous API. |
