2 Design and Concepts
This chapter addresses the things that you as a programmer should know about libiac when developing it and use it implement your own address book applications. It helps to understand its architecture and implementation. Armed with this knowledge, you will be better equipped to make this library run with higher performance, avoids potential pitfalls such as deadlocks or unexpected errors and even import any new features on your needs. You will see how libiac works in relation to your code and you can be more confident that you are attacking the problem from the right direction.
2.1 Architecture
Before we get started discussing the principle data structures, let's have a basic view on the architecture of libiac.
Figure 2.1a Framework of Internal Application Communication
Figure 2.1b Process of IAC framework
As we can see Figure 2.1a, enablers provides a non-graphic method to share the services between different kinds of applications. But application running in the system would still like to query a graphic service or other services that enablers cannot cover. In this case, we need another approach to share services.
In IAC, one application need to launcher another application and query that application to show a proper user interface for the further interaction with users. Application launcher acts as an important role in this situation. In figure 2.1b, when contacts applications want a service of message application, it firstly queries application launcher to launching message application. After application launcher finishes launching work, it will return a result to contacts application to tell whether destination application is launched or not. Finally, the real service invocation happens.
2.2 Services query
At the moment, all service supplied by application in the system is listed in table 2.1:
Table 2.1: List of IAC services
|
Application |
Name |
Service Object |
Action Entry |
|
SoundServer |
SS |
app.ss.service |
location |
|
|
SS |
app.ss.service |
mute |
|
|
SS |
app.ss.service |
stop |
|
|
SS |
app.ss.service |
volume |
|
|
SS |
app.ss.service |
remute |
|
|
SS |
app.ss.service |
pause |
|
|
SS |
app.ss.service |
continue |
|
AddressBook |
ABook |
app.addressbook.service |
voice_find |
|
|
ABook |
app.addressbook.service |
mul_select |
|
|
ABook |
app.addressbook.service |
add_contact |
|
SMS |
SMS |
app.sms.service |
send_sms |
|
Dialer |
Voc |
lips.voice.service |
invoke_calling |
|
|
Voc |
lips.voice.service |
num_return |
|
|
Voc |
lips.voice.service |
dial |
To query an IAC service, an application needs to follow steps shown in figure 2.2:
Figure 2.2 Steps to query service
Application should firstly get a unique IAC context which can be retrieved anywhere. Then application uses iac_start_service() call by passing IAC handler as the first parameter to query launcher to start destination application. It should be noticed that iac_start_service() will block the application for a second, so the application should consider the user interface display for this short period. After application gets a confirmation from launcher without any error, it should use iac_execute_service() or iac_execute_service_async() to invoke service in a synchronous or an asynchronous way.
2.3 Services supply
If an application wants to publish any new service through interface provided by IAC, it should also get a unique IAC context firstly same as when it wants to query a service. Then use iac_register_service() to register a service followed by calling iac_register_listener() to register call-back for specific action entry.
Currently, the name used to query launcher to launch application is described in Name field in a .desktop.