Adjusted to avoid exports, etc, from a top-level bld.inf
/** Copyright (c) 2006 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: **/#ifndef M_NCDOPERATION_H#define M_NCDOPERATION_H#include <e32cmn.h>#include "catalogsbase.h"#include "ncdinterfaceids.h"class TNcdProgress;class MNcdQuery;class MNcdNode;/** * Main operation interface. * * Operation objects are used in the Catalogs engine for potentially * time consuming operations e.g. downloading items or loading node data * from server. * * Operation objects function asynchronously. All operations have their own * observer interface that operation users should implement. Callbacks to * observers occur at key points in an operation's execution. These points * include progress events, query receival and operation completion. * * All operations related to a node that they are started from. The node can * be aqcuired via this interface. The intention is that operations mostly * just notify their observers of progress, completion etc. and that the * observers can get what they need via the node. * * Operations can send querys to observers at any time. Querys always need * to be completed before the operation can continue! Querys are mostly sent * in situations where user interaction is needed to continue the operation * (e.g. filling credit card information for a purchase operation). * * @note Parallel operations from different clients for one node metadata are * not supported. Requests for an operation for a node metadata that already * has an active operation for another client, will fail with the error code * KNcdErrorParallelOperationNotAllowed. * * This affects only clients using the same family id, and only operations that * are node-specific. Operation request methods that can cause this have this * potential exception in their comments. * * Clients can handle this situation e.g. by waiting a moment and trying again * to see if the other operation has completed. However, as a general rule * situations where clients run in parallel and excecute operations on the * same content should be avoided to allow smooth operation of said clients. * * @see MNcdNode * @see MNcdQuery * */class MNcdOperation : public virtual MCatalogsBase {public: /** * Unique identifier for the interface, required for all MCatalogsBase interfaces. * * */ enum { KInterfaceUid = ENcdOperationUid }; /** * Operation states. * * */ enum TState { /** Nothing done yet, initial state. */ EStateStopped, /** Operation is running. */ EStateRunning, /** Waiting query completion. */ EStateQuery, /** Operation complete. */ EStateComplete, /** Operation cancelled */ EStateCancelled }; /** * Getter for operation state. It can be useful to find * out the operations state in situations where the operation * is not actively monitored (via observer) or where an operation * is left in an unactive state and later resumed. * * @return State of the operation. */ virtual TState OperationStateL() const = 0; /** * Type of the operation. This can be used to easily get the * correct interface via QueryInterfaceL. * * @return Interface id of the operation interface. */ virtual TNcdInterfaceId OperationType() const = 0; /** * Starts operation, an asynchronous function. * * @exception KErrInUse if operation already started. * @exception KErrCancel if operation has been cancelled */ virtual void StartOperationL() = 0; /** * Cancel operation, a synchronous function. * * OperationComplete() will be called for each observer with KErrCancel * as the error parameter. * * @note Operation can not be started again. */ virtual void CancelOperation() = 0; /** * Returns current progress information immediately. * Can be safely used during an ui update. Users should always use this * method when displaying progress information for operations. * * Both made progress and maximum progress can change during an operation * e.g. when file size information is received for a download operation. * * Progress information should never be used to decide whether an * operation has been completed! Operation completion is always explicitly * notified via an observer callback! * * @return Structure describing operation progress. */ virtual TNcdProgress Progress() const = 0; /** * Notifies the operation that the current query has been completed. This * must be called to continue the operation if a query is pending! * The query is acquired in the operation callback. * * Before completion, the query object needs to be set to a valid state. * This means that all its non-optional items need to be set to valid * values and the query is accepted, OR the query is declined/cancelled. * * @exception KErrNotFound No query object pending for the operation. * KErrNotReady Query object is not in a valid state. */ virtual void CompleteQueryL( MNcdQuery& aQuery ) = 0; /** * Getter for the node that this operation was started from. * This can be used in callbacks to easily access the related node. * * @note AddRef() is called to the node so the user must call Release() * when no longer needed. * @return Pointer to the node object that originated this operation. * Counted, Release() must be called after use. */ virtual MNcdNode* Node() = 0;protected: /** * Destructor. * * @see MCatalogsBase::~MCatalogsBase */ virtual ~MNcdOperation() {} };#endif // M_NCDOPERATION_H