S60 3 2 Connection Settings API Specification C: Using Connection Settings API

cmmanager.lib has to be linked to the application before the Connection Settings API is used. The following line has to be added to the MMP file of the application.

LIBRARY         cmmanager.lib

When using types in Connection Settings API for getting information about Destinations and Connection Methods, the first step is to open a CM Manager session.

Below is an example of the initialization process of Connection Settings API. The cmmanager.h header file has to be included for using the RCmManager type.

RCmManager cmManager;

cmManager.OpenLC();

The session has to be closed when it is not used any more:

CleanupStack::PopAndDestroy(); // cmManager

Reading the list of existing Destinations

After the CM Manager has been initialized, the list of IDs of existing Destinations can be queried by invoking the RCmManager::AllDestinationsL method.

Below is an example of how to get the Destination ID list.

RArray<TUint32> destinations;
CleanupClosePushL(destinations);

cmManager.AllDestinationsL(destinations);

Now the Destination IDs can be used to get the actual Destination objects.

The example below goes through all the Destinations and writes the names of the Destinations to the console. The cmdestination.h header file has to be included for using the RCmDestination type.

RCmDestination destination;
HBufC *name = NULL;
            
for(int i = 0; i < destinations.Count(); i++)
    {
    destination = cmManager.DestinationL(destinations[i]);
    CleanupClosePushL(destination); 
    
    name = destination.NameLC();
	
    console->Printf(_L("%S\n"), name);
	
    CleanupStack::PopAndDestroy(name); // destination.NameLC()
    name = NULL;
    CleanupStack::PopAndDestroy(); // destination
    }

Below is an example output of the code above.

Figure 3: Example output of listing Destination names

Reading the existing Connection Methods in a Destination

The number of Connection Methods in a Destination can be queried by calling the RCmDestination::ConnectionMethodCount method. The actual Connection Method object can be queried by invoking the RCmDestination::ConnectionMethodL function.

The example below is an extension of the previous example. It lists the names of the Connection Methods in all Destinations. The cmconnectionmethod.h header file has to be included for using the RCmConnectionMethod type and the cmconnectionmethoddef.h header file has to be included for using the ECmName Connection Method attribute enumeration. The new code is in bold.

Below is an example output of the code above.

Figure 5: Example output of listing Connection Methods

Reading the attributes of a Connection Method

Connection Methods has a set of common attributes and a set of bearer specific attributes. The common attributes can be found in the cmconnectionmethoddef.h file, e.g. ECmBearerType – the bearer type of a Connection Method, ECmName – the name of the Connection Method (this attribute was already used in the example above).

The bearer specific attributes can be found in the def.h files of bearer headers, e.g. cmpluginhscsddef.h – contains the bearer specific attributes of HSCSD bearer type e.g. EHscsdChannelCoding.

Each attribute has a type e.g. the type of EHscsdChannelCoding is TUint32.

Get methods of RCmConnectionMethod can be used for reading the attributes of a Connection Method:

In the code below the previous example is extended to read a couple of common attributes of the Connection Methods. The relevant code about reading attributes is in bold.

Below is an example output of the code above.

Figure 7: Example output of reading attributes of Connection Methods

Reading the attributes of a bearer type

Some attributes do not belong to a concrete Connection Method but they are the attributes of a bearer type, e.g. ECmBearerHasUi which indicates if the bearer has a UI Settings dialog or not. These attributes can be queried by the RCmManager::GetBearerInfoBoolL, GetBearerInfoIntL, GetBearerInfoStringL, GetBearerInfoString8L methods.

The next example reads some attributes of the Packet Data bearer type. The KUidPacketDataBearerType comes from the Packet Data def header cmpluginpacketdatadef.h.

Below is an example output of the code above.

Figure 9: Example output of reading bearer specific attributes

Be aware that some attributes including bearer specific and Connection Method specific attributes require initialized UI context in the client application, e.g. ECmBearerIcon which gives back the bearer specific icon requires it.

Handling of Embedded Destination

Special handling is needed for Embedded Destinations. A destination can contain a link to another destination, thus making it possible to utilize the Connection Methods of another destination when creating the connection. This is called an Embedded Destination.

Embedded Destination is rarely used. Embedded Destination cannot be created by the phone user.

In Connection Settings API an Embedded Destination is represented as a Connection Method with Embedded Destination bearer type. So to be prepared for Embedded Destination first the bearer type of the actual Connection Method has to be checked. If the bearer type is Embedded Destination then the linked destination can be queried by calling the RCmConnectionMethod::DestinationL method.

The next example is code fragment from a program which iterates through the existing Destinations and Connection Methods. It logs the name and the number of Connection Methods in the Embedded Destinations. The relevant codes about handling Embedded Destinations are in bold. The cmpluginembdestinationdef.h header has to be included for the UID of the Embedded Destination bearer type (KUidEmbeddedDestination).

Below is an example output of the code above. In the example ‘MyDestination2’ Destination has an Embedded Destination which points to ‘MyDestination1’.

Figure 11: Example output of handling Embedded Destination

Error handling

Connection Settings API uses standard Symbian OS error reporting mechanism. Leaves and system wide error codes as function return values are used if the error is recoverable. A client application can handle these errors similarly as a normal Symbian platform application.

Memory overhead

Opening a CMManager session takes about 8 kb using in a system which supports five kinds of bearer types.

Using an example setup with six Destinations each containing three Connection Methods, getting the list of existing Destinations takes about 1 kb.

Getting an RCmDestination object uses about 1 kb. Getting an RCmConnectionMethod object uses about 2 kb.

Limitations of the API

Destinations and Connection Methods cannot be created, deleted and edited through Connection Settings API.

In some cases the client application needs an initialized UI context to successfully invoke the methods of the API. E.g. reading some UI related attributes such as bearer specific icon.


Copyright © Nokia Corporation 2001-2008
Back to top