// Copyright (c) 1998-2009 Nokia Corporation and/or its subsidiary(-ies).
// All rights reserved.
// This component and the accompanying materials are made available
// under the terms of "Eclipse Public License v1.0"
// which accompanies this distribution, and is available
// at the URL "http://www.eclipse.org/legal/epl-v10.html".
//
// Initial Contributors:
// Nokia Corporation - initial contribution.
//
// Contributors:
//
// Description:
// MTCLBASE.H
//
/**
* @file
* @publishedAll
* @released
*/
#ifndef __MTCLBASE_H__
#define __MTCLBASE_H__
#include <e32base.h>
#include <badesca.h>
#include <msvapi.h>
#include <cmsvattachment.h>
#include <msvstd.hrh>
#include <cmsvrecipientlist.h>
class CMsvAttachmentWaiter;
/** Specifies one or more parts of a message in message-forwarding, message-reply,
and message-validation functions.
Standard message parts are defined by the constants that can be added (or
bitwise-or'ed) together to specify multiple parts. Some message parts may
not be meaningful for some MTMs.
Specifies find attributes which modify the behaviour of the search text utility
provided by the Global Find API. This does not apply to v5.1 nor to v5. */
typedef TUint TMsvPartList;
class CParaFormatLayer;
class CCharFormatLayer;
//
// Prototype of expected factory function
typedef CBaseMtm* MtmFactoryFunctionL(CRegisteredMtmDll&, CMsvSession&);
/** Specifies function IDs for standard MTM functions.
The function IDs are specified such that they do not coincide
with the free area defined for MTM commands.
If MTMs also offer their own equivalents of these functions,
they may implement these function IDs by considering the
two IDs to be the same in their client MTM.
MTMs that support SendAs must support SendMessage.
*/
enum TMtmStandardAsyncCommands
{
KMTMStandardFunctionsSendMessage = KMtmFirstFreeStandardMtmFunctionId
};
/***********************************************
***********************************************/
class CBaseMtm : public CBase, public MMsvEntryObserver
/** Provides a high-level interface for accessing and manipulating a Message Server
entry.
Message client applications use the class to access such functionality polymorphically.
MTM implementers implement a derived class to provide such functionality for
their message protocol.
The following are some significant groups of functions:
Context functions: the SetCurrentEntryL() and SwitchCurrentEntryL() functions
change the context - the entry on which later actions are performed. After
creating a new Client-side MTM object, a message client application should
set an initial context before using other functions. Note that: any changes
made to an existing context are not automatically saved: the message client
application should ensure this itself by calling SaveMessageL(); no message
data for the new context is retrieved from the Message Server, to retrieve
entry data, call LoadMessageL() after setting the context; calling Body()
immediately after setting the context returns an empty CRichText object: this
is because the private cache of context body text that the base class maintains
is re-initialised to an empty value. MTM implementers should note that the
virtual ContextEntrySwitched() is called from these functions to allow derived
classes to also clear any caches of MTM-specific entry data.
Store and restore entry data functions: the changes that a message client
application makes to a message context through Client-side MTM functions,
such as altering the body text obtained through Body(), are, for efficiency,
cached in memory by a Client-side MTM. The message store and restore functions
are concerned with transferring data between that cache and committed storage.
Note that, unlike message contexts, message client applications are not expected
to manipulate directly service contexts. Instead, the corresponding User Interface
MTM will provide dialogs to allow the user to alter service settings, and
call Client-side MTM functions to handle their retrieval and storage. Symbian
OS v5 expects the base class functions to handle storage and retrieval for
both message and service contexts, and their implementations must detect what
the context is, and act accordingly. Post-v5, the API is clarified by restricting
the base class functions to handle message contexts only. To handle service
contexts, a Client-side MTM must define its own functions for the User Interface
MTM to call.
Store and restore body text functions: the base class maintains a private
CRichText object cache to store the body text for the current context. This
can be accessed for reading and writing by message client applications through
Body(). StoreBodyL() and RestoreBodyL() encapsulate for implementers of derived
classes the retrieval and storage of this CRichText object to a CMsvStore.
Address list functions: the format and storage of message addresses is MTM-specific.
AddresseeList(), AddAddresseeL(), and RemoveAddressee() are designed to allow
clients with no MTM-specific knowledge to access address information in a
generic way. The base class has a protected data member iAddresseeList, an
array of descriptors, which these functions manipulate. Implementations should
save the address information to the appropriate place in the message store
when the message is stored.
MTM-specific functionality: MTM components can offer protocol-specific functionality
not provided by base class interface functions. MTM components define IDs
that correspond to each protocol-specific operation offered, and implement
the InvokeSyncFunctionL() and InvokeAsyncFunctionL() functions to allow clients
to access these operations by passing in the appropriate ID. Two functions
are provided to allow the MTM component to offer both synchronous and asynchronous
functionality. Message client applications can dynamically add user-interface
features for these operations using CBaseMtmUiData::MtmSpecificFunctions().
MTM developers should document the IDs if they wish to make the operations
available to clients.
@publishedAll
@released
*/
{
public:
IMPORT_C ~CBaseMtm();
IMPORT_C TUid Type() const;
//
// context related
IMPORT_C void SetCurrentEntryL(CMsvEntry* aEntry);
IMPORT_C void SwitchCurrentEntryL(TMsvId aId);
IMPORT_C CMsvEntry& Entry() const;
IMPORT_C TBool HasContext() const;
//
//
/** 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. */
virtual void SaveMessageL()=0;
/** 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. */
virtual void LoadMessageL()=0;
/** Validates the current message context.
The precise validation performed is specific to the MTM, but, typically, checks
that the specified message parts are well-formed.
Requirements:
Implementation of this function is highly protocol-specific. A minimum step
is to check that the current context is a message.
@param aPartList Indicates the message parts for which validation is requested
@return If valid, KErrNone If invalid, identifies the invalid part(s). The
error value is the bitmask of the TMsvPartList IDs for each invalid part */
virtual TMsvPartList ValidateMessage(TMsvPartList aPartList)=0;
/** 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.
@param aTextToFind The plain-text version of the text to be found.
@param aPartList Indicates the message parts which should be searched.
@return 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. */
virtual TMsvPartList Find(const TDesC& aTextToFind, TMsvPartList aPartList)=0;
//
//
/** 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.
@param aDestination The entry to which to assign the reply
@param aPartlist Defines the parts that are to be copied from the original
message into the reply
@param aCompletionStatus The request status to be completed when the operation
has finished
@leave KErrNotSupported The Client-side MTM does not support reply operations
@leave Other leave codes Dependent on implementation
@return If successful, this is an asynchronously completing reply operation.
If failed, this is a completed operation, with status set to the relevant
error code. */
virtual CMsvOperation* ReplyL(TMsvId aDestination, TMsvPartList aPartlist, TRequestStatus& aCompletionStatus)=0;
/** 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.
@param aDestination The entry to which to assign the forwarded message
@param aPartList Defines the parts that are to be copied from the original
message into the forwarded message
@param aCompletionStatus The request status to be completed when the operation
has finished
@leave KErrNotSupported The Client-side MTM does not support creation of forwarded
messages
@leave Other leave codes Dependent on implementation
@return 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. */
virtual CMsvOperation* ForwardL(TMsvId aDestination, TMsvPartList aPartList, TRequestStatus& aCompletionStatus)=0;
//
// addresssee list (used by objects with no MTM knowledge)
IMPORT_C const CMsvRecipientList& AddresseeList() const;
/** 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.
@param aRealAddress String representing an address to be added to the list
for the current message
@leave KErrNotSupported The message already has the maximum number of addressees
@leave Other leave codes Dependent on implementation */
virtual void AddAddresseeL(const TDesC& aRealAddress)=0;
/** 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.
@param aRealAddress String representing an address to be added to the list
for the current message
@param aAlias Alias information
@leave KErrNotSupported The message already has the maximum number of addressees
@leave Other leave codes Dependent on implementation */
virtual void AddAddresseeL(const TDesC& aRealAddress, const TDesC& aAlias)=0;
IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress);
IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress, const TDesC& aAlias);
/** 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.
@param aIndex Index of address to be removed */
virtual void RemoveAddressee(TInt aIndex)=0;
//
// standard data accessor/mutators
IMPORT_C CRichText& Body();
IMPORT_C const CRichText& Body() const;
IMPORT_C virtual void SetSubjectL(const TDesC& aSubject); // default leaves with KErrNotSupported
IMPORT_C virtual const TPtrC SubjectL() const; // default leaves with KErrNotSupported
//
// RTTI functions
IMPORT_C virtual TInt QueryCapability(TUid aCapability, TInt& aResponse); // default returns KErrNotSupported
/** 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.
@param aFunctionId ID of the requested operation
@param aSelection Selection of message entries. This is used if the operation
requires message entries to work on.
@param aParameter Buffer containing input and output parameters. The format
of this is specific to the operation.
@leave KErrNotSupported aFunctionId is not a recognised operation ID
@leave Other leave codes Dependent on implementation */
virtual void InvokeSyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter)=0;
/** 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.
@param aFunctionId ID of the requested operation
@param aSelection Selection of message entries. This is used if the operation
requires message entries to work on.
@param aParameter Buffer containing input and output parameters. The format
of this is specific to the operation.
@param aCompletionStatus The request status to be completed when the operation
has finished
@leave KErrNotSupported aFunctionId is not a recognised operation ID
@leave Other leave codes Dependent on implementation
@return If successful, this is an asynchronously completing operation. If failed,
this is a completed operation, with status set to the relevant error code. */
virtual CMsvOperation* InvokeAsyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter, TRequestStatus& aCompletionStatus)=0;
//
IMPORT_C CMsvSession& Session();
// Attachment functions to support the SendAs API
virtual inline void Filler1() {};
virtual inline void Filler2() {};
IMPORT_C virtual void AddAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
IMPORT_C virtual void AddAttachmentL(RFile& aFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
IMPORT_C virtual void AddLinkedAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
IMPORT_C virtual void AddEntryAsAttachmentL(TMsvId aAttachmentId, TRequestStatus& aStatus);
IMPORT_C virtual void CreateAttachmentL(const TDesC& aFileName, RFile& aAttachmentFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
IMPORT_C virtual void CancelAttachmentOperation();
IMPORT_C virtual void CreateMessageL(TMsvId aServiceId);
// BIO functions to support the SendAs API
// Entry().Entry().iBioType will be set by SendAs if this function does not leave.
// The default implementation in CBaseMtm is to do nothing.
IMPORT_C virtual void BioTypeChangedL(TUid aBioTypeUid);
IMPORT_C virtual TMsvId DefaultServiceL() const;
IMPORT_C virtual void RemoveDefaultServiceL();
IMPORT_C virtual void ChangeDefaultServiceL(const TMsvId& aService);
//For setting the character encoding value, options are 7-bit, 8-bit and 16-bit Unicode.
IMPORT_C TInt SetMessageCharacterSet(TUint aCharSet);
IMPORT_C void SetExtensionData(TAny* aSortData);
IMPORT_C TAny* GetExtensionData();
protected:
IMPORT_C CBaseMtm(CRegisteredMtmDll& aRegisteredMtmDll, CMsvSession& aSession);
//
IMPORT_C void StoreBodyL(CMsvStore& aStore);
IMPORT_C void RestoreBodyL(CMsvStore& aStore);
//
/** 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. */
virtual void ContextEntrySwitched()=0; // called after the context of this instance has been changed to another entry
//
IMPORT_C void HandleEntryEventL(TMsvEntryEvent aEvent, TAny* aArg1, TAny* aArg2, TAny* aArg3);
// Method used for extension: called by non virtual methods that need
// to have a polymorphic behaviour.
IMPORT_C virtual TAny* GetInterface(TUid aUid);
// From CBase
IMPORT_C virtual TInt Extension_(TUint aExtensionId, TAny*& a0, TAny* a1);
private:
void DeleteEntry();
void AddFilePathAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, CMsvAttachment::TMsvAttachmentType aType, TRequestStatus& aStatus);
protected:
/** The current context. */
CMsvEntry* iMsvEntry;
/** The address list for the current context. */
CMsvRecipientList* iAddresseeList;
/** Paragraph formatting applied to the CRichText object for the body text, as
returned by Body(). This is set to an empty CParaFormatLayer instance whenever
the context is set.
Implementations can modify this if they wish to apply particular formatting
to body text. */
CParaFormatLayer* iParaFormatLayer;
/** Character formatting applied to the CRichText object for the body text, as
returned by Body().
Implementations can modify this if they wish to apply particular formatting
to body text. */
CCharFormatLayer* iCharFormatLayer;
private:
TMsvId iEntryId;
CRichText* iRichTextBody;
CRegisteredMtmDll& iRegisteredMtmDll;
CMsvSession& iSession;
CMsvAttachmentWaiter* iAttachmentWaiter;
// Extra data member to allow for future extensions
TAny* iExtensionData;
};
#endif // __MTCLBASE_H__