![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This topic describes the additions and enhancements which have been made to the Agenda model API in EPOC Release 5. For a more complete description of the Agenda model, see EPOC Agenda.
The main change in EPOC Release 5 is the introduction of a server into the Agenda model architecture. The purpose of the Agenda server is to manage concurrent access to an Agenda file by more than one client. Such clients may include the Agenda application, synchronization functions, as well as any third party applications. Without the Agenda server, for instance, synchronization of an Agenda file could not take place if the file was in use. The application accessing the file would first have to be closed down, then later reopened after synchronization had completed.
The Agenda server is documented in RAgendaServ class.
In the new architecture, applications still need to create an Agenda model, but calls in the UI to access the Agenda file are now routed to the appropriate server functions rather than directly to the file.
The following diagram summarises the new architecture.
A typical function call using the new Agenda server architecture might be:
1. The Agenda UI calls FetchEntryL() in CAgnModel.
2. CAgnModel is running as a client of the Agenda server, so calls FetchEntryFromServerL() instead of directly accessing the Agenda file, as before.
3. FetchEntryFromServerL() calls the necessary functions for a server request.
4. CAgnServerSession picks up the request, and calls FetchEntryL() in the CAgnEntryModel the same function as called by the Agenda UI originally in step 1, but this time, since the model is not running as a client, it retrieves the necessary information and passes it to the server.
5. The server returns the information to the model owned by the UI, and hence to the application.
Applications may or may not use the Agenda server.
Existing applications will still work in EPOC Release 5 without the need for modification. In order to use the new Agenda server architecture, however, they will need to be modified. The required modifications are described later in this topic.
An application which does use the server (i.e. its model is assigned a server pointer and is therefore in client mode) can use:
The creation of the Agenda server has meant that the CAgnEntryModel class has been extended with new functions to support the additional server facilities. For a description of these changes, see CAgnEntryModel class.
In addition to the creation of the Agenda server, other changes have been made to the Agenda model. The abstract base class for all Agenda entry types, CAgnEntry has been extended to include attendee details and a location field. The changes to CAgnEntry are described in CAgnEntry class.
Every Agenda entry is identified both by a TAgnEntryId and by a TAgnUniqueId. The TAgnEntryId is used to identify where in the file the entry occurs and is used as an indexing mechanism. Because this value changes whenever the entry is updated, it cannot be used for synchronization. The TAgnUniqueId is assigned when the entry is created, and is preserved during updates.
A third ID, TAgnGlobalId has been introduced in EPOC Release 5. It is used as a global ID, and is a 32 character descriptor. This value is entirely optional and is not currently used.
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |