              
OrganizerThe Organizer API enables a client to request calendar, schedule and personal data from local or remote backends. This is part of the Qt Mobility Project. NamespaceThe QtMobility APIs are placed into the QtMobility namespace. This is done to facilitate the future migration of Mobility APIs into Qt. See the Quickstart guide for an example on how the namespace impacts on application development. IntroductionThe Organizer API provides clients with the ability to access calendar, schedule and personal data in a platform-independent and datastore-agnostic manner. This is achieved by defining generic personal information data abstractions which can sufficiently describe calendar and scheduling data stored a platform's native calendaring system. Through the plugin architecture, it can be used as a front-end API for any calenaring system (eg. an online calendar). Basic UsageThe Qt Organizer API provides both a synchronous and an asynchronous API. Note that for clarity, the short examples on this page demonstrate the synchronous API. While these code snippets might be useful for non-GUI applications, it is highly recommended that the asynchronous API is used for GUI applications. The Organizer ManagerOrganizer information is stored in datastores whose functionality is exposed via the QOrganizerManager class. Most users of the API will want to use the default manager for the platform, which provides access to the system address book. Instantiating a manager by using the default constructor will result in the default manager for that platform being instantiated: QOrganizerManager defaultManager; Creating a New ItemYou can create a new item simply by instantiating one and saving it a manager. // a default constructed journal will have it's date/time set to the current date/time.
QOrganizerJournal journal;
journal.setDescription("The conference went well. We all agree that marshmallows are awesome, "\
"but we were unable to reach any agreement as to how we could possibly "\
"increase our intake of marshmallows. Several action points were assigned "\
"to various members of the group; I have been tasked with finding a good "\
"recipe that combines both marshmallows and chocolate, by next Wednesday.");
defaultManager.saveItem(&journal);
Retrieving ItemsYou can request all items from the manager that occur in a given time range. QList<QOrganizerItem> entries =
defaultManager.items(QDateTime(QDate(2010, 1, 1), QTime(0, 0, 0)),
QDateTime(QDate(2010, 1, 31), QTime(23, 59, 59)));
It is also possible filter the items on the value of a detail. entries = defaultManager.items(QOrganizerItemLocation::match("Meeting Room 8"));
The above code will retrieve both items that have been saved to the manager and items which are generated based on recurrence rules. Given a recurring item, it is possible to retrieve a list of items that it generates; that is, to get a list of the upcoming occurrences of a single recurring item. This can be done using QOrganizerManager::itemOccurrences(): You can also retrieve a particular existing item from a manager, by directly requesting the item with a particular (previously known) id. The synchronous API provides the QOrganizerManager::item() function to retrieve a single item by its id. With the asynchronous API, this can be done using a QOrganizerItemFetchRequest and a QOrganizerItemIdFilter. Updating an Existing ItemYou can update a previously saved item retrieving the item, modifying it, and saving it back to the manager. The manager uses the id of the item to match up the provided item with the one in the database. journal.addComment("Serves: 8. Ingredients: 500g Milk Chocolate, 500g Marshmallows."\
" Step 1: Put the marshmallows into 8 separate bowls."\
" Step 2: Melt the chocolate."\
" Step 3: Pour the chocolate over the marshmallows in the bowls."\
" Step 4: Put the bowls into the refrigerator for 20 minutes; serve chilled.");
if (!defaultManager.saveItem(&journal))
qDebug() << "Unable to save updated journal! Error:" << defaultManager.error();
Removing an item from a managerYou can remove an item from the manager by using its id. defaultManager.removeItem(journal.id()); The Organizer Item ModelItemsA QOrganizerItem represents an event, todo, journal or note. Each item stored in a manager is identified by a QOrganizerItemId. The id is the means by which the manager can:
The QOrganizerItem class provides a generic interface for accessing events, todos, journals and notes. To actually access specific fields of an item, convenience subclasses of QOrganizerItem are offered. These are QOrganizerEvent, QOrganizerTodo, QOrganizerJournal and QOrganizerNote. Additionally, QOrganizerEventOccurrence and QOrganizerTodoOccurrence can be used for manipulating occurrences of event or todos (see the Recurring Items section). Here is an example of how to retrieve details specific to an item: QList<QOrganizerItem> items = defaultManager.items();
foreach (QOrganizerItem item, entries) {
if (item.type() == QOrganizerItemType::TypeEvent) {
QOrganizerEvent event(item);
qDebug() << "Event:" << event.startDateTime() << ", " << event.displayLabel();
} else if (item.type() == QOrganizerItemType::TypeEventOccurrence) {
QOrganizerEventOccurrence event(item);
qDebug() << "Event:" << event.startDateTime() << ", " << event.displayLabel();
} else if (item.type() == QOrganizerItemType::TypeTodo) {
// process todos
} else if (item.type() == QOrganizerItemType::TypeTodoOccurrence) {
// process recurring todos
} else if (item.type() == QOrganizerItemType::TypeJournal) {
// process journals
} else if (item.type() == QOrganizerItemType::TypeNote) {
// process notes
}
}
Recurring ItemsA recurring item is an item that occurs more than once; for example, a meeting that occurs every week for the next 10 weeks. A recurring item is created by creating a QOrganizerEvent or QOrganizerTodo and setting a QOrganizerRecurrenceRule on it to specify the rules for when it should recur. When QOrganizerManager::items() is called, recurring items are not returned. Rather, they expanded into multiple QOrganizerEventOccurrence and QOrganizerTodoOccurrence items. Each generated occurrence item has a null id. You can make an exception for an occurrence by taking a generated item occurrence from the manager, making the necessary modifications, and resaving it. When the manager is then queried with QOrganizerManager::items(), it will return the list of occurrences as before, but with the modifications in place. The modified item will be given a non-null id, and replaces the generated one in the list. Here is an example of changing a single occurrence of an item: QOrganizerEventOccurrence nextMarshmallowMeeting = defaultManager.itemOccurrences(marshmallowMeeting).value(0);
nextMarshmallowMeeting.setStartDateTime(QDateTime::fromString("13.05.2010 18:00:00", "dd.MM.yy hh:mm:ss"));
nextMarshmallowMeeting.setEndDateTime(QDateTime::fromString("13.05.2010 20:00:00", "dd.MM.yy hh:mm:ss"));
nextMarshmallowMeeting.addComment("The next meeting will go for an hour longer (starting one "\
"hour earlier than usual), since we have scheduled one hour"\
"to taste the results of the recipe that I will be presenting "\
"at the meeting.");
defaultManager.saveItem(&nextMarshmallowMeeting);
You can also query the manager for a list of unexpanded items by calling QOrganizerManager::itemsForExport(). The list of returned items will contain all items that have been saved to the manager with a call to QOrganizerManager::saveItem() That is, recurring events will be returned as is, and event occurrences will not appear unless they are exceptions (ie. have a non-null id). Fetching the list in this way can be useful for transfering items to other managers or for exporting to iCalendar with QtVersit. CollectionsEvery item stored in a manager belongs to exactly one collection. A collection can have properties such as a name, a "color", a specified icon, a description, and so on. Collections may be added or removed if the manager supports those operations, or modified. There will always be at least one collection in a manager, and the manager will always have a default collection into which items are saved if no other collection is specified. Some managers will allow users to create collections (for example, a "football fixtures" collection) while others may have built-in collections (for example, "work" and "home" collections). A list of all collections can be retrieved from a manager with one function call: QList<QOrganizerCollection> collections = defaultManager.collections(); To save an item to a collection, set the collection ID on the item object. If the collection id is the null id, the item will be saved in the collection in which it is currently saved (if the item already exists) or into the manager's default collection (if it is a new item). marshmallowMeeting.setCollectionId(collection.id());
defaultManager.saveItem(&marshmallowMeeting);
To retrieve all items in a collection, a QOrganizerItemCollectionFilter should be used. QOrganizerItemCollectionFilter collectionFilter;
collectionFilter.setCollectionId(collection.id());
items = defaultManager.items(collectionFilter);
All-day EventsEvents and Todos can be specified as all-day or multi-day by setting the AllDay field to true (using QOrganizerEvent::setAllDay()). When this field is set to true, it means that the time portion of the StartDateTime and EndDateTime should be ignored. An event or todo marked as all-day should be considered to start and end roughly on its given start and end dates (inclusive), but without specifying exact times. For example, a birthday could be specified as an all-day QOrganizerEvent where the StartDateTime and EndDateTime have the same value. API UsageAsynchronous APIThe asynchronous API provides a way to access or modify the organizer item information managed by a particular backend via non-blocking, asynchronous requests. It is recommended for most applications that the asynchronous API be used where possible. The asynchronous API is offered through various classes derived from the QOrganizerAbstractRequest class, including QOrganizerItemIdFetchRequest, QOrganizerItemFetchRequest, QOrganizerItemFetchForExportRequest, QOrganizerItemSaveRequest, QOrganizerItemRemoveRequest, QOrganizerItemOccurrenceFetchRequest, QOrganizerCollectionFetchRequest, QOrganizerCollectionRemoveRequest, QOrganizerCollectionSaveRequest, QOrganizerItemDetailDefinitionFetchRequest, QOrganizerItemDetailDefinitionSaveRequest, and QOrganizerItemDetailDefinitionRemoveRequest. The asynchronous API allows manipulation of items, collections and schema definitions, but does not provide manager capability or meta data information reporting. For more detailed documentation on the asynchronous API, see the Organizer Asynchronous API. Synchronous APIThe synchronous API provides the simplest way to access or modify the organizer item information managed by a particular backend. It has the disadvantage that calls block the current thread of execution until completion and is therefore most suitable only for applications which interact with local, high-speed datastores, or for applications which do not require a responsive user interface. The synchronous API is offered through the QOrganizerManager class, and includes manipulation of items, collections and schema definitions. As previously described, the meta data reporting and manipulation functions are also provided via synchronous API only. For more detailed documentation on the synchronous API, see the Organizer Synchronous API. More informationWhile the information on this page should be sufficient for the common use-cases, please see the discussion on Advanced Organizer API Usage for more details on the intricacies of the API. It is possible for third party developers to implement a manager engine plugin from which clients may request data. For more information on this topic (for example, if you intend to implement a manager backend) please see Qt Organizer Manager Engines. Reference documentationMain Classes
QOrganizerItemDetail Leaf ClassesSeveral subclasses of QOrganizerItemDetail are provided as part of the Qt Mobility Organizer API. They are general in design but are intended to fulfill specific use-cases. Please note that certain backends may choose not to support one or more of these subclasses as they appear here; they may offer their own which provide similar functionality.
Each of these subclasses provide access to information stored in fields which may have certain constraints, as listed in the schema. Asynchronous RequestsYou may use either the synchronous or asynchronous API to access functionality provided by a manager backend. The asynchronous API is offered through subclasses of the QOrganizerAbstractRequest class:
Organizer Item Selection And SortingYou may select an organizer item by specifying a unique item id, or by supplying a QOrganizerItemFilter which matches the item or items they wish to select. The various derivatives of QOrganizerItemFilter allow for fine-grained and flexible selection of organizer data according to various criteria:
A client can also request that the results of such a selection be sorted, by passing a QOrganizerItemSortOrder (or list of sort orders) to the manager. Implementing BackendsA backend implementor must implement the following interfaces:
For more information on this topic, see please see the documentation on implementing manager engines. Synchronization and SerializationThe organizer API is used by another Qt Mobility module: the Versit* module. It allows serialization of a QOrganizerItem into an iCalendar document, and vice versa. [*] Versit ® is a trademark of the Internet Mail Consortium. ExamplesThe following sample applications show examples of API usage: QML ElementsFor details on the QML support provided for the Organizer API see the documentation for the Organizer QML Plugin. Note: At the time of the Qt Mobility 1.1 release the QML support for the Organizer API is incomplete and likely to be refined and improved in the next patch release. X
|
