class CImap4ClientMtm : public CBaseMtm |
IMAP4 client MTM interface, providing access to the email services using the IMAP4 protocol.
The class provides support for:
connecting to remote IMAP4 mail servers
synchronising message headers with mailboxes on these servers
getting message bodies and attachments
copying and moving messages
creating messages that forward or reply to IMAP4 messages
server notification of new messages using IMAP IDLE
queueing operations requested when there is no connection to a mail server, to be performed when a connection is made (offline operations).
Note that CImap4ClientMtm does not support many of the generic functions defined by the CBaseMtm base class. In particular:
Message address information, body, subjects, and attachments are not manipulated through CImap4ClientMtm. Consequently, SaveMessageL() has an empty implementation, and is not used. Message access and manipulation is instead done through CImEmailMessage, which understands the email specific message formats, including MHTML (RFC 2557). The RFC 822 email header, which includes subject and address information, is encapsulated in a CImHeader object, which can be obtained from a CImEmailMessage object. IMAP also has its own specific flags, such as draft, answered, and deleted: this can be accessed through TMsvEmailEntry, which extends the message server's generic TMsvEntry to add email-specific information.
The idea of a default service used by base class functions DefaultServiceL(), ChangeDefaultServiceL(), and RemoveDefaultServiceL() is not supported.
IMAP specific commands are issued through the InvokeAsyncFunctionL() function, with the commands defined in the TImap4Cmds enumeration. Details of particular commands are given in the documentation for that enumeration, but the following describes some of the key concepts required to use those commands. Note that usually these commands do not correspond directly to the IMAP protocol commands described in RFC 3501. Instead, they are at a higher level, to simplify the logic required for an email client program.
--------------------------------------
Connection and services
Settings for connection to and use of an IMAP4 mail server and its mailboxes are encapsulated in an CImImap4Settings object, created and accessed through CEmailAccounts. Preferences for the network connection (e.g. the ISP to use) to be made to access an IMAP server are also accessed through CEmailAccounts.
The settings are associated with a service-type entry in the Message Server's message store. Message and folder type entries under the service entry store a local copy of the mailboxes and messages that are present on an IMAP server. For this reason, the service is sometimes referred to as the local mirror of an IMAP server.
By default, it is assumed that the user has a primary mailbox on the server called INBOX, though this can be changed if necessary using CImImap4Settings::SetFolderPathL(). (To avoid confusion, the term "Inbox" used in the IMAP MTM documentation refers to this mailbox, rather than the Message Server's standard local Inbox folder.)
The settings store the user's log-in details required to access the IMAP server, and other settings not related to connection, but which affect the behaviour of commands, such as synchronisation, made to the service.
--------------------------------------
Synchronisation
The IMAP4 MTM provides the means to synchronise message headers on a remote IMAP mailboxes with the messages headers on the phone. Note that synchronisation only refers to message headers. Once headers are synchronised, populate operations (i.e. getting the message bodies) can be done.
The basic steps involved in a full synchronisation are:
The headers of messages in the Inbox are synchronised.
The local list of folders is synchronised with those existing on the remote IMAP service. Depending on the service settings, the local or remote settings of subscribed mailboxes may be updated (see below for more information).
The headers of messages in subscribed folders are synchronised.
Queued offline operations (see below) pending on the Inbox or subscribed folders are performed prior to the relevant folder being synchronised.
Synchronisations can be performed in the background or the foreground. A foreground synchronisation means no other requests, such as message fetching, can be made to the MTM, until the synchronisation is complete. A background synchronisation allows some types of command to be given while it is in progress. Commands that write to the remote server are not allowed however while a background synchronisation is in progress. A client is informed of the state of a background synchronisation through the MMsvImapConnectionObserver callback interface.
Synchronisations commands are made through CImap4ClientMtm::InvokeAsyncFunctionL(). There a variety of commands available that give different options for compounding synchronisation with other commands, such as connection, and synchronising only particular folders. See TImap4Cmds for details. Progress information for synchronisation commands can be obtained from the CMsvOperation object returned by the InvokeAsyncFunctionL(). Synchronisation progress information is encapsulated in a TImap4SyncProgress object.
Settings that affect how a synchronisation is performed include:
Subscriptions: when an IMAP service had been synchronised, the Messaging server will contain entries for all folders on the remote server. These entries will be marked invisible within the TMsvEntry for the folder, implying that they should be invisible to the user. Messages in these folders are not synchronised unless the folder has been subscribed to. Note a folder subscription can be set either locally (i.e. just on the phone), using the KIMAP4MTMLocalSubscribe command, or remotely (on the server), possibly through email clients on other devices. A service can be set to synchronise folders using either or both of these types of subscription (CImImap4Settings::SetSynchronise()). Local and remote subscriptions can themselves be synchronised in various ways (CImImap4Settings::SetSuscribe()).
Filters: a filter prevents certain e-mail messages from being synchronised onto the device when a client requests a synchronisation. Filters can include anything permitted by the IMAP Search command, including date, size, content, and message flags.
Limits: service settings can limit the number of emails synchronised to the inbox (CImImap4Settings::SetInboxSynchronisationLimit()), and to other folders (CImImap4Settings::SetMailboxSynchronisationLimit()).
Sync rate: one of the synchronisation commands (KIMAP4MTMConnectAndSyncCompleteAfterDisconnect) periodically resynchronises the Inbox until the service is disconnected. CImImap4Settings::SyncRate() sets the refresh period.
--------------------------------------
Getting and copying messages
After messages headers have been synchronised, message bodies and attachments can be fetched from the remote email server. Getting message parts and saving them in the mirror service is calling populating them.
Commands for these actions can be made through CImap4ClientMtm::InvokeAsyncFunctionL(). There are a large number of commands, for different combinations of these options:
action type: whether to just populate messages, or to also copy or move them to a local folder
message selection: whether to get all, new, or selected messages
connection: whether to make a new connection or assume an existing connection
disconnect: whether to disconnect or stay online after operation is complete
For the populate type commands, further options can be set that control the message getting behaviour. Basic options control, encapsulated in TImImap4GetMailInfo, specify whether body text and/or attachments are fetched, and a maximum message size. There are also options, encapsulated in TImImap4GetPartialMailInfo, that allow size limits to be separately specified for body text and/or attachments. If the the body is larger than the limit, then the body is partially downloaded up to the limit. Only attachments smaller than the specified size are downloaded. A partially downloaded message can later be fully downloaded.
For the copy or move type commands, a TImImap4GetMailInfo parameter is supplied, in order to specify the destination folder for the messages, and a maximum message size.
Progress information for getting commands can be obtained from the CMsvOperation object returned by the InvokeAsyncFunctionL(). Progress information is encapsulated in a TImap4GenericProgress object.
Fetching and then copying or moving specified messages can also be performed by using the standard Messaging Framework CMsvEntry::CopyL() and CMsvEntry::MoveL() functions on entries under the remote service. If these functions are used, then the entire message is fetched without size limits.
CMsvEntry functions can also be used to:
create a folder on a remote server
delete messages
copy or move messages from a local folder into a remote folder
copy or move messages between remote folders
Note that changing an existing entry through CMsvEntry is not supported. An MTM- specific command KIMAP4MTMRenameFolder is instead provided to rename a remote folder.
The page "CMsvEntry functions for IMAP4 message entries", linked to in the "See also" section below, provides more details on using CMsvEntry.
--------------------------------------
Offline operations
Some operations can only be performed while online, while other commands may be stored while offline for processing when next connected. An attempt to perform a command while offline that requires the MTM to be connected results in immediate completion with the error code KErrDisconnected.
Permitted offline operations include:
copy
move
delete
Queued offline operations are usually performed when a connection is made, prior to the relevant folder being synchronised. Delete operations can alternatively be set to be done on disconnection using the service setting CImImap4Settings::SetDeleteEmailsWhenDisconnecting().
Offline operations are only permitted if the service setting SetDisconnectedUserMode() is true.
It is possible to undo pending offline operations using the commands KIMAP4MTMCancelOffLineOperations and KIMAP4MTMUndeleteAll.
--------------------------------------
IMAP IDLE support
IMAP IDLE (RFC 2177) is an optional expansion of the IMAP email accessing protocol that allows the server to send updates to the client that messages have been created or deleted in real time. The IDLE command is sent from the client to the server when the client is ready to accept unsolicited mailbox update messages. Whether the client requests the server to provide IDLE support is set in the CImImap4Settings::SetImapIdle() service setting. When the IMAP MTM receives such a notification, it synchronises the changed folder. Email clients can be notified of such changes by setting a MMsvEntryObserver observer on a folder.
Protected Member Functions | |
---|---|
CImap4ClientMtm(CRegisteredMtmDll &, CMsvSession &) | |
void | ConstructL() |
void | ContextEntrySwitched() |
Private Member Functions | |
---|---|
void | ConvertToPartialPopulate(TDes8 &) |
CMsvOperation * | CopyMoveOrPopulateL(TInt, TDes8 &, TRequestStatus &) |
TMsvPartList | DoFindL(const TDesC &, TMsvPartList) |
void | FilterAllOrNewMailsL(TInt, const CMsvEntrySelection &, TDes8 &) |
void | FilterMailSelectionL(const CMsvEntrySelection &, TDes8 &) |
TBool | IsPartialPopulate(TDes8 &) |
void | SendOnNextConnectionL() |
TBool | ValidateAddress(const TPtrC &) |
Inherited Attributes | |
---|---|
CBaseMtm::iAddresseeList | |
CBaseMtm::iCharFormatLayer | |
CBaseMtm::iMsvEntry | |
CBaseMtm::iParaFormatLayer |
CImap4ClientMtm | ( | CRegisteredMtmDll & | aRegisteredMtmDll, |
CMsvSession & | aSession | ||
) | [protected] |
CRegisteredMtmDll & aRegisteredMtmDll | |
CMsvSession & aSession |
void | AddAddresseeL | ( | const TDesC & | aRealAddress | ) | [virtual] |
Adds an addressee for the current context.
Addresses are not validated by checking their format by this function. Usually that is performed by calling ValidateMessage().
Requirements:
Implementations should append the address to the object's address cache in the protected iAddresseeList data member. Some implementations may also wish to store addresses in an internal data structure appropriate for the protocol, for example, a class holding message header information.
leave
KErrNotSupported The message already has the maximum number of addressees
leave
Other leave codes Dependent on implementation
const TDesC & aRealAddress | String representing an address to be added to the list for the current message |
void | AddAddresseeL | ( | const TDesC & | aRealAddress, |
const TDesC & | aAlias | |||
) | [virtual] |
Adds an addressee for the current context, and enables the client to specify an alias, which may be useful for some protocols. For example, for fax, if the address is the fax number, the alias could supply the recipient's name.
Addresses are not validated by checking their format by this function. Usually that is performed by calling ValidateMessage().
Requirements:
Implementations should append the address to the object's address cache in the protected iAddresseeList data member. Some implementations may also wish to store addresses in an internal data structure appropriate for the protocol, for example, a class holding message header information.
leave
KErrNotSupported The message already has the maximum number of addressees
leave
Other leave codes Dependent on implementation
IMPORT_C void | AddAttachmentL | ( | const TDesC & | aFilePath, |
const TDesC8 & | aMimeType, | |||
TUint | aCharset, | |||
TRequestStatus & | aStatus | |||
) | [virtual] |
const TDesC & aFilePath | |
const TDesC8 & aMimeType | |
TUint aCharset | |
TRequestStatus & aStatus |
IMPORT_C void | AddAttachmentL | ( | RFile & | aFile, |
const TDesC8 & | aMimeType, | |||
TUint | aCharset, | |||
TRequestStatus & | aStatus | |||
) | [virtual] |
RFile & aFile | |
const TDesC8 & aMimeType | |
TUint aCharset | |
TRequestStatus & aStatus |
IMPORT_C void | AddEntryAsAttachmentL | ( | TMsvId | aAttachmentId, |
TRequestStatus & | aStatus | |||
) | [virtual] |
TMsvId aAttachmentId | |
TRequestStatus & aStatus |
IMPORT_C void | AddLinkedAttachmentL | ( | const TDesC & | aFilePath, |
const TDesC8 & | aMimeType, | |||
TUint | aCharset, | |||
TRequestStatus & | aStatus | |||
) | [virtual] |
const TDesC & aFilePath | |
const TDesC8 & aMimeType | |
TUint aCharset | |
TRequestStatus & aStatus |
IMPORT_C void | ChangeDefaultServiceL | ( | const TMsvId & | aService | ) | [virtual] |
const TMsvId & aService |
void | ContextEntrySwitched | ( | ) | [protected, virtual] |
Called by the base class functions SwitchCurrentEntryL() and SetCurrentEntryL() when the context is changed to another entry.
Client applications do not use this function. It is relevant only to implementers of derived classes.
Requirements:
An implementation should clear:
1. address data stored in iAddresseeList
2. any caches of MTM-specific entry data relating to a previous context. For example, if the implementation has a private buffer storing a message subject, for access through Subject(), this buffer should be cleared.
void | ConvertToPartialPopulate | ( | TDes8 & | aParameter | ) | [private] |
TDes8 & aParameter |
CMsvOperation * | CopyMoveOrPopulateL | ( | TInt | aFunctionId, |
TDes8 & | aParameter, | |||
TRequestStatus & | aCompletionStatus | |||
) | [private] |
TInt aFunctionId | |
TDes8 & aParameter | |
TRequestStatus & aCompletionStatus |
IMPORT_C void | CreateAttachmentL | ( | const TDesC & | aFileName, |
RFile & | aAttachmentFile, | |||
const TDesC8 & | aMimeType, | |||
TUint | aCharset, | |||
TRequestStatus & | aStatus | |||
) | [virtual] |
const TDesC & aFileName | |
RFile & aAttachmentFile | |
const TDesC8 & aMimeType | |
TUint aCharset | |
TRequestStatus & aStatus |
IMPORT_C void | CreateMessageL | ( | TMsvId | aServiceId | ) | [virtual] |
TMsvId aServiceId |
TMsvPartList | DoFindL | ( | const TDesC & | aTextToFind, |
TMsvPartList | aPartList | |||
) | [private] |
const TDesC & aTextToFind | |
TMsvPartList aPartList |
void | FilterAllOrNewMailsL | ( | TInt | aFunctionId, |
const CMsvEntrySelection & | aSelection, | |||
TDes8 & | aParameter | |||
) | [private] |
TInt aFunctionId | |
const CMsvEntrySelection & aSelection | |
TDes8 & aParameter |
void | FilterMailSelectionL | ( | const CMsvEntrySelection & | aSelection, |
TDes8 & | aParameter | |||
) | [private] |
const CMsvEntrySelection & aSelection | |
TDes8 & aParameter |
TMsvPartList | Find | ( | const TDesC & | aTextToFind, |
TMsvPartList | aPartList | |||
) | [virtual] |
Searches the specified message part(s) for the plain-text version of the text to be found.
If the specified part list indicates a part that is not supported, or is not present in the current message, the function behaves as if the specified part exists but does not contain the required text.
Requirements:
The parts of the entry for which searching is allowed is implementation specific. If no searching is supported, always return 0.
If the text was not found, or searching is unsupported, 0. If the text was found, a bitmask of the TMsvPartList IDs for each part in which the text was present.
const TDesC & aTextToFind | The plain-text version of the text to be found. |
TMsvPartList aPartList | Indicates the message parts which should be searched. |
CMsvOperation * | ForwardL | ( | TMsvId | aDestination, |
TMsvPartList | aPartList, | |||
TRequestStatus & | aCompletionStatus | |||
) | [virtual] |
Creates a forwarded message from the current message context.
Some MTMs may support inclusion of elements, specified by aPartlist, from the original message in the forwarded message. The parent for the new entry is specified in aDestination. The returned CMsvOperation object completes when editing the forwarded message is complete. On completion, the context is set to the forwarded message.
Requirements:
A typical implementation for this function would include the following steps:
1. create a new message in the specified destination by calling CMsvEntry::CreateL()
2. set the entry index values as appropriate
3. set message content as required. The normal minimum is to include the text of the original message. An implementation may also follow the options specified in aPartlist to include other properties of the original message.
4. set the context to the reply
5. return a CMsvOperation-derived object to provide asynchronous control and monitoring of the operation
If forwarded messages are not supported, implementations should leave with KErrNotSupported.
The implementation of this function may be similar to that of ReplyL(), allowing opportunities for code sharing.
leave
KErrNotSupported The Client-side MTM does not support creation of forwarded messages
leave
Other leave codes Dependent on implementation
If successful, this is an asynchronously completing forward message operation. If failed, this is a completed operation, with status set to the relevant error code.
TMsvId aDestination | The entry to which to assign the forwarded message |
TMsvPartList aPartList | Defines the parts that are to be copied from the original message into the forwarded message |
TRequestStatus & aCompletionStatus | The request status to be completed when the operation has finished |
void | HandleEntryEvent | ( | TMsvEntryEvent | aEvent, |
TAny * | aArg1, | |||
TAny * | aArg2, | |||
TAny * | aArg3 | |||
) |
CMsvOperation * | InvokeAsyncFunctionL | ( | TInt | aFunctionId, |
const CMsvEntrySelection & | aSelection, | |||
TDes8 & | aParameter, | |||
TRequestStatus & | aCompletionStatus | |||
) | [virtual] |
Invokes asynchronous protocol-specific operations. For synchronous operations, a similar function, InvokeSyncFunctionL(), is available.
aSelection and aParameter allow data to be passed to the operation. The TRequestStatus and CMsvOperation objects are used as normal to control and monitor the operation.
Requirements:
For functionality that requires message transport access, such as making a connection, the implementation should pass the request onto the corresponding Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). Implementations may also provide protocol-specific functions themselves if this is useful.
InvokeAsyncFunctionL() should return a CMsvOperation-derived object to provide asynchronous control and monitoring of the operation. If CMsvSession::TransferCommandL() is called, this should be the CMsvOperation object returned by that function.
leave
KErrNotSupported aFunctionId is not a recognised operation ID
leave
Other leave codes Dependent on implementation
If successful, this is an asynchronously completing operation. If failed, this is a completed operation, with status set to the relevant error code.
TInt aFunctionId | ID of the requested operation |
const CMsvEntrySelection & aSelection | Selection of message entries. This is used if the operation requires message entries to work on. |
TDes8 & aParameter | Buffer containing input and output parameters. The format of this is specific to the operation. |
TRequestStatus & aCompletionStatus | The request status to be completed when the operation has finished |
void | InvokeSyncFunctionL | ( | TInt | aFunctionId, |
const CMsvEntrySelection & | aSelection, | |||
TDes8 & | aParameter | |||
) | [virtual] |
Invokes synchronous protocol-specific operations. For asynchronous operations, a similar function, InvokeAsyncFunctionL(), is available.
aSelection and aParameter allow data to be passed to the operation.
Requirements:
For functionality that requires message transport access, such as making a connection, the implementation should pass the request onto the corresponding Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). Implementations may also provide protocol-specific functions themselves if this is useful.
leave
KErrNotSupported aFunctionId is not a recognised operation ID
leave
Other leave codes Dependent on implementation
TInt aFunctionId | ID of the requested operation |
const CMsvEntrySelection & aSelection | Selection of message entries. This is used if the operation requires message entries to work on. |
TDes8 & aParameter | Buffer containing input and output parameters. The format of this is specific to the operation. |
TBool | IsPartialPopulate | ( | TDes8 & | aParameter | ) | [private] |
TDes8 & aParameter |
void | LoadMessageL | ( | ) | [virtual] |
Loads the cache with the message data for the current context.
It can only be called on message contexts.
It is typically used after the context has been set with SetCurrentEntryL() or SwitchCurrentEntryL(). CBaseMtm functions to manipulate the entry can only be called after this function has been called.
Requirements:
An implementation must restore the store and index entry relating to the message context. Typically, the message store should be opened for reading with CMsvEntry::ReadStoreL(). It should be then be read to set the following:
1. body text: call RestoreBodyL() to update the cached body text
2. address list: read the appropriate MTM-specific area of the store to update iAddresseeList
3. subject: if supported, read the appropriate MTM-specific area of the store and update the cache with SetSubjectL()
The function should panic for non-message contexts.
IMPORT_C CImap4ClientMtm * | NewL | ( | CRegisteredMtmDll & | aRegisteredMtmDll, |
CMsvSession & | aSession | |||
) | [static] |
CRegisteredMtmDll & aRegisteredMtmDll | |
CMsvSession & aSession |
IMPORT_C CImOperationQueueList * | QueueListL | ( | CMsvEntry & | aServiceEntry | ) |
CMsvEntry & aServiceEntry |
void | RemoveAddressee | ( | TInt | aIndex | ) | [virtual] |
Removes an address from the current address list. The address is specified by a zero-based index into the address list. If the index is not known, applications can use AddresseeList() to retrieve the entire list to find the item.
Requirements:
Implementations should call iAddresseeList->Delete(aIndex) to remove the address from in the address list protected data member.
TInt aIndex | Index of address to be removed |
CMsvOperation * | ReplyL | ( | TMsvId | aDestination, |
TMsvPartList | aPartlist, | |||
TRequestStatus & | aCompletionStatus | |||
) | [virtual] |
Creates a reply message to the current message context.
Some MTMs may support inclusion of elements, specified by aPartlist, from the original message in the reply. The parent for the new entry is specified in aDestination.
The returned CMsvOperation object completes when creating the reply is complete. On completion, the context is set to the reply message.
Requirements:
A typical implementation for this function would include the following steps:
1. create a new message in the specified destination by calling CMsvEntry::CreateL()
2. set the entry index values as appropriate
3. set the properties of the message as required. The normal minimum is to set the address to the sender of the original message. An implementation may also follow the options specified in aPartlist to set other properties, for example, to include the original message text.
4. set the context to the reply
5. return a CMsvOperation-derived object to provide asynchronous control and monitoring of the operation
If message replies are not supported, implementations should leave with KErrNotSupported.
The implementation of this function may be similar to that of ForwardL(), allowing opportunities for code sharing.
leave
KErrNotSupported The Client-side MTM does not support reply operations
leave
Other leave codes Dependent on implementation
If successful, this is an asynchronously completing reply operation. If failed, this is a completed operation, with status set to the relevant error code.
TMsvId aDestination | The entry to which to assign the reply |
TMsvPartList aPartlist | Defines the parts that are to be copied from the original message into the reply |
TRequestStatus & aCompletionStatus | The request status to be completed when the operation has finished |
void | SaveMessageL | ( | ) | [virtual] |
Commits cached changes to the storage controlled by the Message Server.
It can only be called on message contexts. It should be called in the following circumstances:
1. to preserve changes when the context is changed, or when the Client-side MTM object is deleted
2. to enable other parts of the Messaging to access the updated entry, as required, for example, before sending a message
Requirements:
An implementation must update the store and index entry relating to the message context. Typically, the message store should be opened for editing with CMsvEntry::EditStoreL(). It should be updated as follows:
1. body text: call StoreBodyL() to update the store's body text stream
2. address list: update the appropriate MTM-specific area of the store from the data in iAddresseeList
3. subject: if supported, update the appropriate MTM-specific area of the store from the private cache set by SetSubjectL()
Changes can then be committed to the store with CMsvStore::CommitL().
The index entry should also be updated to reflect changes. Possible fields that may need updating include: Description (for subject changes); Details and Multiple Recipients (for recipient changes); and Size. Index entry changes are committed using CMsvEntry::ChangeL().
The function should panic for non-message contexts.
IMPORT_C void | SetImap4SettingsL | ( | const CImImap4Settings & | aSettings | ) |
const CImImap4Settings & aSettings |
void | UndoOffLineChangesL | ( | const CImOffLineOperation & | aDeleted, |
TMsvId | aFolderId | |||
) | [virtual] |
const CImOffLineOperation & aDeleted | |
TMsvId aFolderId |
TBool | ValidateAddress | ( | const TPtrC & | anAddress | ) | [private] |
const TPtrC & anAddress |
CImap4ClientSessionObserver * | iImap4ClientSessionObserver | [private] |
TPckgBuf< TImImap4GetPartialMailInfo > | iImap4GetPartialMailInfo | [private] |