Background services in Tizen 2.1

Gabor Paller's picture

In the previous post I presented the argument that Tizen 2.1 native application model is really just an upgrade of bada 2.0. The similarities were really striking but what about the differences? In order to appreciate the step from bada 2.0 to Tizen 2.1, we should take a look at the platform under the mobile application framework.

 

Bada 2.0 ran on a real-time operating system. This made the system suitable to scale downward, to deploy on lower-middle category smartphones. While this was a clever positioning, in reality bada smartphones were more of the high-end. At the same time, the real-time operating system created constraints for the application model, for example bada could never really solve the problem of more than one active application. Meanwhile, Android phones using Linux as base platform became very cheap and the business case for a real-time operating system as a foundation evaporated. The switch to real multitasking operating system could not be avoided anymore and the result is Tizen 2.1.

 

The first very visible outcome of that change is that Tizen 2.1 supports background services which were not present in bada. There can be only one application with user interface running (called UIApp in Tizen parlance) but there can be unlimited number of background services executing. More exactly: the life-cycle of the background services is managed by the platform and as long as the limit is not reached, they can run in parallel.

 

The example projects are attached to this post. You have to be logged in to Sfonge website to access them.

 

There are two projects in the archive, wordsserviceservice and wordsserviceui. Wordsserviceservice is meant to be a background service which provides the next interesting word when invoked. Wordsserviceui is an example of an UIApp connecting to the service. This UIApp actually looks like our previous words1 application but the story here is that now those interesting words are not tied to a particular application. Due to the background service, they can be accessed by any UIApp and can be integrated into any UI. Compile and deploy wordsserviceservice first and observe that this app does not appear among the installed app. Then do the same with wordsserviceui and you should get the same UI as words1 had.

This simple pair of applications is a good exercise to examine, how Tizen 2.1 compares to the wildly popular Android platform. According to the Tizen documentation, one UIApp and any number of service applications can be bundled into the same application package. Now after having struggled for days, I am pretty much convinced that Tizen 2.1 as it is now cannot provide this feature. The tool chain prevents you having more than one app (either UI or service) in the application manifest (if you edit the manifest manually, it won't deploy on the emulator). Worse, the API is completely unclear how to do it. A Tizen application is essentially a DLL that has only one entry point, the OspMain function. In order to support more than one application per application package, OspMain should fork into these applications but currently it is undocumented, how to do it. That's why this very simple example program deploys as two applications which is certainly impossible for a commercial application (like a media player and its control UI).

 

Supposing that this problem is resolved, Android is definitely more elegant when launching the service application. Observe this code fragment:

 

    AppManager* pAppManager = AppManager::GetInstance();
    for (int i=0; i < 5; ++i) {
        if (pAppManager->IsRunning(serviceId)) {
                AppLog("words1 : Service is ready !!!");
                break;
        } else {
                AppLog("words1 : Service is not ready !!! try to launch !!!" );
                r = pAppManager->LaunchApplication( serviceId, null);
                TryReturn(!IsFailed(r), r, "words1 : [%s]", GetErrorMessage(r))
                Thread::Sleep(CHECK_INTERVAL);
        }
    }

 

This fragment checks whether the service application (identified by serviceId) is running. If it isn't, it launches the service application, waits 1 sec and repeats the test. There is no callback to the UIApp that launched the service that the service is ready to use.

 

Tizen 2.1 on the other hand has a simple inter-process communication that in my humble opinion is easier to use than Android's AIDL. Tizen simply thinks in terms of local and remote message ports. Local ports receive messages and messages can be sent to remote ports. Messages are simple hash maps. The invocation pattern is unidirectional so if you need a transaction, it can be made up of two invocations.

 

Tizen is a big step forward for the bada application model (that is now called Tizen native). Tizen 2.1 and its tool chain as it is cannot fully exploit it yet but the direction is definitely a good one. 

Attached file: 
Taxonomy upgrade extras: