Asynchronous operations in Symbian and Qt
Jump to navigation
Jump to search
Overview[edit | edit source]
Description[edit | edit source]
The following table compares the Active Objects/Active Scheduler mechanism in Symbian and signals/slots in Qt.
Solution[edit | edit source]
Operations | Symbian | 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. |