UI Notifications

From Tizen Wiki
Jump to: navigation, search

The purpose of this page is to:

  • Introduce the UI Notifications system used on Tizen ;
  • Document the additional integration work which may done by an integrator ;
  • Document the roadmap.


About UI Notifications

Tizen implements an API named "notification", which provides a secure socket to allow priviliged frameworks to send system-wide notifications (power, network, general hardware...).

These notifications are then collected by a central daemon called "notification-service", which keeps them in a central database and can feed them to clients (which may, then, delete them if needed).

The very same package implements a generic consumer named "notification-display-service". This daemon will start shortly after "notification-service", reed new notifications, and display them on screen if one the 2 following display backends are supported : X11, Wayland.

Here is a sample of an interactive Bluetooth pairing notification displayed using this service

There may sometimes be a need for interactions between the user and displayed notifications (such as a user confirmation for pairing with a Bluetooth device). These needs are documented below (see "plugins").

Profiles

notification-display-service is currently actively supported under Tizen Common.

Other profiles may customize its appearance and supported frameworks, directly or using plugins.

Testing the service

The notification-service-test package contains a client able to send generic notifications, named 'send-notification'.

Here is how to use it :

$ su
(enter "tizen" password)
$ zypper in notification-service-test
$ exit
$ send-notification --title="MyNotification" --content="MyMessage" --icon="/usr/share/weston/terminal.png"

The resulting popup window should appear on your Wayland/X11 display system.

Plugins

UI design and integration

notification-display-service currently uses a very generic and dependency-free library to display notifications. The code responsible of it, which is in the core of the service, will be moved to an optional path, which will be in the "plugins/display/" subdirectory of the package.

So integrators will be able to customize the look-and-feel by adding a plugin, without modifying the existing code.

Client frameworks

View-only notifications

For a client to display a notification, it should pull the "notification" library (platform/core/api/notification), and use it this way :

#include <notification.h>

notification_h noti = notification_create (NOTIFICATION_TYPE_NOTI);

notification_set_text (noti, NOTIFICATION_TEXT_TYPE_TITLE, "My Title", NULL, NOTIFICATION_VARIABLE_TYPE_NONE);
notification_set_text (noti, NOTIFICATION_TEXT_TYPE_CONTENT, "My Message", NULL, NOTIFICATION_VARIABLE_TYPE_NONE);
notification_insert (noti, NULL);

The notification will be displayed with the "My Title/My Message" text, and a generic "OK" button.

Interactive notifications

There are some cases, where the displayed popups should be customized by the originating framework. Plus, there are other cases, where user input is wanted and should be send back to the originating framework.

For these cases, there is a response wait/send in libnotification directly. The client framework (which sends the notification) should the following when creating the notification :

#include <bundle.h>

bundle *b = bundle_create ();
bundle_add (b, "buttons", "Send PIN,Cancel");          /* defines the bottom buttons */
bundle_add (b, "textfield", "Please enter the PIN");   /* sets the input field text */

notification_set_execute_option (noti, NOTIFICATION_EXECUTE_TYPE_RESPONDING,
                                       NULL, NULL, b);

and somewhere after the "notification_insert ()" call, wait for user input this way :

int respi; char *respc;
notification_wait_response (noti, 60, &respi, &respc);  /* tiemout set to 60 seconds */

"respi" will be 1 if the user clicked the 1st button ("Send PIN"), 2 the 2nd button ("Cancel"). "respc" will be whatever text the user entered in the input field (can be empty, but not NULL, unless the "textfield" entry has not been specified in the bundle)

(PS : an error may be returned ; in this case "respi" will be 0 and "respc" will be NULL)


Summary

The final directory layout will be :

|- /usr/bin/notification-service
|- /usr/bin/notification-display-service
|- /usr/lib$ARCH/notification-service/plugins/display/wlmessage.so
|- /usr/lib$ARCH/notification-service/plugins/display/<integrator-UI>.so
|- /usr/lib$ARCH/notification-service/plugins/bluetooth.so
|- /usr/lib$ARCH/notification-service/plugins/privacy-manager.so
|- /usr/lib$ARCH/notification-service/plugins/<integrator-framework.so
...

Roadmap

  • Switch to a multi-user system (the database is currently central and stored in "/usr/dbspace". The users could have personal databases, and if the Seats are supported, just see notification popups appear on their specific screen).
  • Do not run as root

Links