Home · All Classes · Grouped Classes · Annotated · Functions

Services

Introduction

Application Services are standardized APIs to access functionality supplied by other applications. They allow applications to invoke the services of other applications, while allowing the specific application providing the service to be selected by the system integrator or end-user. Messages between applications are delivered via Qtopia IPC.

Pre-defined Services

The following provides a list of the pre-defined services:

Available Services

Alarm Contacts ModemEmulator Settings Time
AlarmServer ContactsPhone PackageManager SettingsManager TimeMonitor
Alert Date PhotoEdit SMS VoiceRecording
Calendar Dialer PrintServer Suspend WebAccess
Camera Email Profiles TaskManager
CleanupWizard Help Qtopia Tasks
Clock InputMethod QtopiaPowerManager Telephony

Requesting Services

To request a service, the calling application executes:

    QtopiaServiceRequest srv(servicename, action);
    srv << parameters;
    srv.send();

For example:

    QtopiaServiceRequest srv("WebAccess", "openURL(QString)");
    srv << QString("www.trolltech.com");
    srv.send();

QtopiaServiceRequest::send() returns a boolean value indicating whether the service is available. The next image demonstrates the service interaction if it is assumed that the mail application where to request the WebAccess service:

"Qtopia Service execution"

Responding to Service Requests

To respond to a service request, an application should use the QtopiaAbstractService class. The following example responds to the openURL(QString) request on the WebAccess service. It would typically be implemented by a Web browser application:

    class WebAccessService : public QtopiaAbstractService
    {
        Q_OBJECT
    public:
        WebAccessService( QObject *parent )
            : QtopiaAbstractService( "WebAccess", parent )
            { publishAll(); }

    public slots:
        void openURL( const QString& url );
    };

When an openURL(QString) request arrives, it will be automatically delivered to the WebAccessService::openURL() slot in the application.

Applications register as providing a service by supplying a standard Qtopia configuration file, $QPEDIR/services/<servicename>/<appname> where:

The file should be installed by the build sytem. See Register a service provider for more information.

The standard keys in this file are:

The file may contain any additional sections, keys and values as defined by the documentation of the service.

Adding a New Service

Each new service must be carefully specified as it provides a system- wide API that can be invoked by other applications and the user. A service should only be added if it:

To add a new service, provide a standard Qtopia configuration file, $QPEDIR/services/<servicename>.service. Again this file should be installed by the build sytem. +See Create a new service for more information. The keys in this file are:

For example:

    [Translation]
    File=QtopiaServices
    Context=Calendar
    [Service]
    Actions = raiseToday();newEvent()
    Icon = datebook_icon
    Name[]=Calendar
    [newEvent()]
    Icon = datebook_icon
    Name[]=New event
    [raiseToday()]
    Icon=today
    Name[]=Today's calendar

Usually, only one application responds to a given service. The user selects the application to handle the service using the Application Services settings. If the service can be provided by multiple applications, the service file will contain:

    Multiple = 1

in the [Service] section.

Advanced Service Functionality

Some services may be parameterised on the type of data to be processed. Different applications may handle different data types. The Qtopia Data Sharing (QDS) system should be used for these types of services.


Copyright © 2007 Trolltech Trademarks
Qtopia 4.2.5