Mobile native Wearable native

Data Control

Data control is a standard mechanism for exchanging specific data between applications.

All applications can request data shared by other applications using a data control. However, only service applications can provide their own data.

There are 2 types of data controls:

  • DATA_CONTROL_SQL

    Allows you to use an SQL-type data control to access specific data exported by other service applications. You can also define an SQL-type data control provider to export specific data from your service application.

  • DATA_CONTROL_MAP

    Allows you to use a key-value-type data control to access data exported by other service applications. You can also define a key-value-type data control provider to export specific data from your service application.

Data controls can supply operations to access shared data and get back results.

The data control requires the following provider information:

  • Provider ID

    Unique provider ID to identify the data control for a specific provider.

    Format:

    • Provider ID must consist of alpha-numeric letters separated with the period (".") character, and it must start with letters.
    • Custom provider ID must start with a vendor name to avoid conflicts with other developers.
    • IRI format: http://{provider URI}/datacontrol/provider/{provider name}
  • Data ID

    String ID for identifying specific data, usually a database table name or a registry section name.

    Format:

    • Data ID consists of one or more components, separated by a slash ("/") character.

Figure: Data control mechanism

Data control mechanism

Using Data Controls

You can get a datacontrol_h instance from the datacontrol_map_create() or datacontrol_sql_create() function.

  • Map type data control

    If you specify the datacontrol_h instance using the data_control_map_create(), data_control_map_set_provider_id(), or data_control_map_set_data_id() function, you can get the specific map-type data control uniquely.

    After resolving the data control, call the data control map APIs, such as data_control_map_set(), data_control_map_get(), data_control_map_add(), and data_control_map_remove().

    The result is returned by a response callback, such as data_control_map_get_response_cb(), data_control_map_set_response_cb(), data_control_map_add_response_cb(), or data_control_map_remove_response_cb() of the data_control_map_response_cb struct. The response callback is invoked when a service application finishes its operation.

  • Sql type data control

    If you specify the datacontrol_h instance using the data_control_sql_create(), data_control_sql_set_provider_id(), or data_control_sql_set_data_id() function, you can get the specific SQL-type data control uniquely.

    After resolving the data control, call the data control SQL APIs, such as datacontrol_sql_select(), data_control_sql_insert(), data_control_sql_update(), and data_control_sql_delete().

    The result is returned by a response callback, such as data_control_sql_select_response_cb(), data_control_sql_insert_response_cb(), data_control_sql_update_response_cb(), or data_control_sql_delete_response_cb() of the data_control_sql_response_cb struct. The response callback is invoked when a service application finishes its operation.

    Once you get the result_set_cursor using the data_control_sql_select_response_cb() callback, you can use the following functions to get information:

    • data_control_sql_step_first()
    • data_control_sql_step_last()
    • data_control_sql_step_next()
    • data_control_sql_set_previous()
    • data_control_sql_get_column_count()
    • data_control_sql_get_column_name()
    • data_control_sql_get_column_item_size()
    • data_control_sql_get_column_item_type()
    • data_control_sql_get_blob_data()
    • data_control_sql_get_int_data()
    • data_control_sql_get_int64_data()
    • data_control_sql_get_double_data()
    • data_control_sql_get_text_data()

Developing with Data Controls

You can develop with data controls by adding the <datacontrol> element to the tizen-manifest.xml file.

The following code example describes how to add the <datacontrol> element:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns="http://tizen.org/ns/packages" package="@PACKAGE_NAME@" version="@VERSION@" 
          install-location="internal-only">
   <label>datacontrolprovider</label>
   <author email="PUT YOUR EMAIL" href="www.tizen.org">PUT YOUR NAME</author>
   <description>datacontrolprovider</description>
   <ui-application appid="org.tizen.datacontrolprovider" 
                   exec="datacontrolprovider" 
                   nodisplay="true" multiple="false" type="capp" taskmanage="true" 
                   auto-restart="false" on-boot="false">
      <datacontrol providerid = "Your Provider ID"
                   access="ReadWrite" type="Sql"/>
      <datacontrol providerid = "Your Provider ID"
                   access="ReadWrite" type="Map"/>
   </ui-application>
</manifest>

The service application providing its own database file must register the provider callback using the data_control_provider_sql_register_cb() function. Similarly, the service application providing its own registry file or key-value pairs data set must register the provider callback using the data_control_provider_map_register_cb() function.

The service application sends the SQL- or map-type data control result to the other application by using functions, such as data_control_provider_send_select_result(), data_control_provider_send_insert_result(), data_control_provider_send_update_result(), or data_control_provider_send_delete_result().

You can export the data of your service application to other applications.

Exporting DataControl Functionality

You can export functionalities of your Tizen native application in the application project settings in the IDE. The provider ID, type, and accessibility must be specified for the data control.

Figure: Exporting data control

Exporting data control

Data Model

The data model must be opened to the public to help other applications to use the exported data controls. The data model consists of the following data:

  • Provider ID
    • It is used for identifying a data control provider.
    • It must be unique and use a fully qualified domain name.
    • Platform-defined data control provider is defined in the format: http://tizen.org/datacontrol/provider/<application name>
    • User-defined data control provider is defined in the format: http://<vendor.com>/datacontrol/provider/<application name>
  • Data ID
    • It is used for identifying data exported by the data control provider.
    • It must be unique in the data control provider and it is given as a string with a slash as a delimiter.
  • Type
    • You can use Tizen native applications that provide their own data structure table and implement the SQL-type data control provider using the database file.
    • You can use Tizen native applications that provide their own key-value pairs data structure map and implement the map-type data control provider using registry file or collection map classes.
  • Data schema
    • SQL-type data control exports column names and types of the data structure table.
    • Map-type data control exports key names and types of the data structure map.
  • Data accessibility

    Tizen native applications can control read and write access from other applications by allowing data control accessibility.

Table: Data model example of a data control provider
Data control type Data control provider ID Data control data ID Data schema Data accessibility
SQL http://<vendor.com>/datacontrol/provider/sample data1

column1
(type: Integer)

column2
(type: String)

 Read-Only
Map http://<vendor.com>/datacontrol/provider/sample2 data2

key1
(type: String)

key2
(type: String)

 Read-Write
Go to top