×
Namespaces

Variants
Actions
Revision as of 15:01, 3 April 2009 by Forum Nokia KB (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Asynchronous operations in Symbian and Qt

From Nokia Developer Wiki
Jump to: navigation, search


Template:KBTS

Article Metadata
Compatibility
Platform(s): S60
Symbian
Article
Keywords: CActive, Active Object, Signals and Slots
Created: (03 Apr 2009)
Last edited: Forum Nokia KB (03 Apr 2009)

Overview

This article provides a comparison of asynchronous request handling in S60 and Qt.

Description

The following table compares the Active Objects/Active Scheduler mechanism in S60 and signals/slots in Qt.

Solution

Operations S60 Qt
Asynchronous event handling for applications using asynchronous service providers Active Object Signal/Slot
Class hierarchy User-defined classes that need to use asynchronous services should be derived from CActive. User-defined classes should be derived from QObject or any classes derived from it.
Wait loop once asynchronous request is made CActiveScheduler class emulates the wait loop if an asynchronous event is waiting to be completed. Once the event completes, it calls the respective handler, for example, RunL. No separate wait loop is required. Signal/slot mechanism combined with application main loop takes care of this.
Asynchronous event handling in UI Active scheduler is built-in with UI applications which makes the application wait in an infinite loop until the next event is received. Events are generated when the user interacts with the UI components. QApplication manages the event loop for an application. Signals are built-in for standard UI components and are emitted (generated) when the user interacts with the UI components.
Function invoked when asynchronous event is completed For user-defined classes, the standard function RunL is invoked. For user-defined classes, you can define the signals, emit those signals, and decide which function (slot) should handle those signals.
Functions invoked when events/signals from standard UI components need to be handled Standard functions such as OfferKeyEventL, HandlePointerEventL, and HandleCommandL are invoked. There are standard signals defined but you can decide the slot where it needs to be called when the signal is emitted.
Input parameters for the standard function The function parameters for standard functions (RunL, OfferKeyEventL) are predefined and cannot be changed. Signal parameter(s) and slot parameter(s) can be decided by the developer. The advantage of this is that the class level variables can be reduced as they can be created in a function and passed in signals/slots as parameters when the signals and slots are being connected. Even standard signals with predefined parameters can be altered using QSignalMapper classes.
Number of asynchronous requests in user-defined class There can be only one outstanding request in user-defined classes which will be serviced by RunL. There can be many signals and slots connected in every class. Hence many requests can be serviced/processed.
User-defined events Not possible. User-defined classes can subclass standard classes and define their own signals. User-defined classes can also add their own signals.
Inter-object communication mechanism No separate mechanism. The object whose information is required is usually kept as a member variable and standard C++ getter/setter functions are used. There is no direct mechanism of automatically getting intimated of the state information of an object. Signals and slots can be used to exchange information between objects eliminating the need of an object being made a member variable of the class. The state of the object can also be tracked by making the object emit a signal and connecting the signal to a slot in the class.
Making asynchronous calls work like synchronous calls Depending on whether the asynchronous function is executed in the same thread or different thread, one of the APIs in CActiveSchedulerWait or the API User::WaitForRequest() can be used. QEventLoop can be used to achieve this:

QEventLoop eventLoop; connect(this, SIGNAL(TwmsAsyncFunctioncompleted()), &eventLoop, SLOT(quit())); eventLoop.exec(QEventLoop::ExcludeUserInputEvents); This will also block the UI events in case the user does not want to process them until the asynchronous operation completes.

166 page views in the last 30 days.