June 22, 2015 - Ben Lloyd Pearson
An Introduction to Tizen 2.3 Application Architecture
This article will cover how Tizen applications are setup and how the Tizen Native and Web APIs work.
Tizen Application Types
There are three primary types of apps that can be built in Tizen:
- Native Application – Applications that are developed similar to traditional Linux applications using C or C++ (though implementation is fairly different) and can access more advanced device-specific features like the camera, GPS, and accelerometer in addition to more advanced system settings and functionality.
- Hybrid Application – Applications that use both the Native and the Web APIs offered by Tizen.
Tizen is being built to work on a wide variety of platforms with a focus on embedded devices. In order to accommodate the various types of devices, a set of profiles have been defined to make it easier to develop applications for specific purposes. In the 2.3 SDK, there are two profile types you can choose from: Mobile and Wearable. The mobile profile is designed for devices like smart phones and tablets and the wearable profile is designed for devices like smart watches.
While both currently support the Tizen Web API, only the mobile profile supports the Native API. This will change once the version 2.3.1 of the wearable API is released which will include support for Native APIs. For the time being, this means if you want to develop a native or hybrid application, you will need to use the mobile profile when creating your new project.
The Native API provides all of the memory management and performance benefits that come with building applications for Linux in C and C++. If you are looking to add features that are not provided by the web API, the Native API should be able to help you as it includes dozens of API modules that cover a large range of capabilities. This API provides numerous interfaces to much of the hardware that is found in modern mobile and wearable devices, and does so in an environment that is tailored for limited resources.
Apps that use the Native API rely on a series of lifecycle events in order to operate; these events put the app in various states that enable certain controls or operations.
Ready – The app is registered with the framework and initializes callbacks to receive notifications from the application framework.
Created – The resources needed for handling the lifecycle framework are completed (UI initialization, setup of database, etc). In this stage, the app is ready for the main loop to be run.
Running – The main loop (the app) is performing its tasks, and interacting with the user. In this state, it constantly checks timers, events, and other services, but only consumes CPU when there is work to be done.
Paused – The app moves to the background and will perform only essential tasks. In this state, the app releases resources to be used by others. This state is only needed for apps that have a UI.
Terminated – The application is closed.
Applications can be moved between the paused and running state as needed. For example, external events like an incoming phone call can force an app to move to a paused state in order to free resources for the phone call events. These lifecycle events are what give the Native API more efficient resource usage when compared to the Web API.
Hybrid apps are able to leverage the benefits of both the Web and Native APIs to allow developers to code as much as they can using the simpler web frameworks and rely on the Native API only when better efficiency or more complicated functionality is needed. For these apps, the Web API is used to create things like the user interface or a front-end to a web service, and to handle basic user interactions. The Native API is limited to services only, meaning you can’t use it to build the UI, but rather it is used to extend the functionality into more advanced areas like gesture recognition, location information, network connections, and security. Setting one up is as simple as setting up a project reference in a web app that points to the related native app.
Bringing it All Together
This article should make it clear why Tizen can be a great platform to develop applications for, and should provide some insight into how a Tizen app should be structured. If you want to learn any more about the information shared in this article, a good starting point is the Tizen Developer Documentation. I will be posting a follow up to this article soon that dives more deeply into what the Native and Web APIs offer and covers what you need to consider when deciding how to use them.Image Credits: Tizen Developer Guide
About Ben Lloyd Pearson
Ben handles Open Source Operations for the Samsung Open Source Group. He has a background that spans many areas of technology including digital media, audio / video production, web development, IT systems support / administration, and technical writing. In addition to his work for Samsung, he also runs Open Source Today, a news blog that covers developments in the open source industry. He lives in Austin, Texas, a place he and his wife chose to live in order to experience one of the best scenes for food, music, and technology in the world. He is a musician, aspiring amateur chef, DIY mechanic, and avid gamer.
Image Credits: Tizen Developer Guide