/pps/services/hmi-notification/control

Control object for the generic event-source plugin for the HMI Notification Manager

Publishers: Any app
Subscribers: HMI Notification Manager

Note: This type of object is known as a server object, a special PPS object designed for point-to-point communication between a server and one or more clients. For details, see "Server objects" in the Persistent Publish/Subscribe Developer's Guide.

Overview

The generic event-source plugin for the HMI Notification Manager provides a PPS interface that allows applications to use the HMI policy-management facilities without implementing a custom plugin. Applications can use this PPS interface to generate events. The generic plugin can also be used for automated testing. Using the PPS interface, a test application can generate customized events and inspect the outcome for expected results.

PPS messages sent to the plugin's interface from clients take the form of JSON objects that describe an event. The format is similar to that used by the pps/services/hmi-notification/Status and pps/services/hmi-notification/Messaging objects, but additional attributes are included in this control object.

The event message

This object accepts only one command:

msg::	dat:json:
event	`{"parameter":"value", "parameter":"value", ...}` (see below)

Parameters and values are as follows:

Parameter	Value	Description
`name`	`event_name`	Name of the event to be passed to the HMI Notification Manager.
`view`	`view_application`	Name of the application responsible for handling the event.
`type`	`event_type`	Type of event being passed. One of: `display-start` `display-end`
`priority`	`priority_number`	An integer for the priority level (range is `0` to `7`).
`window-type`	`window_type`	Type of window associated with the event. One of: `Fullscreen` `Growl` `Hidden` `Notification` `Overlay`
`fallback_types`	`fallbacks`	List of window types to be used as fallbacks for the event. These events must be given in order of preference and are used as fallback types if the requested window type can't be accepted. These fallbacks will be tried in order until one that can be accepted is found or the event request is rejected.

Examples

A client sends a display-start event with a priority of 1, with no fallback window types:

# echo 'event::{"name":"test_event", "view":"TestApp",
"type":"display-start", "priority":1, "window-type":"Overlay", 
"fallback_types":[]}' >> /pps/services/hmi-notification/control

The Status object should then look like this:

# cat /pps/services/hmi-notification/Status
[n]@Status
display:json:[{"name":"test_event","type":"Overlay","view":"TestApp"}]

The client sends the associated display-end event:

# echo 'event::{"name":"test_event", "view":"TestApp", 
"type":"display-end", "priority":1, "window-type":"Overlay", 
"fallback_types":[]}' >> /pps/services/hmi-notification/control

The Status object should now be restored, showing the previously displayed event in its display list:

# cat /pps/services/hmi-notification/Status
[n]@Status
display:json:[{"name":"Home","type":"Fullscreen","view":"Home"}]

The following example illustrates a situation where the HMI Notification Manager uses a fallback window type.

The client must be attached to the Messaging object (because it's a server object):
```
# exec 3<> /pps/services/hmi-notification/Messaging
```

Next, the client sends a test-event1 event to the generic plugin to ensure that an event with priority 1 or greater is active:

# echo 
'event::{"name":"test-event1","view":"TestApp1","type":"display-start",
"priority":1,"window-type":"Overlay","fallback_types":[]}' 
>> /pps/services/hmi-notification/control

The client then sends test-event2 with priority 1 and fallback window type Growl:

# echo 'event::{"name":"test-event2","view":"TestApp2","type":"display-start",
"priority":1,"window-type":"Overlay","fallback_types":["Growl"]}'
>> /pps/services/hmi-notification/control

Now we can see that the Status object has been updated:

cat /pps/services/hmi-notification/Status ; cat <&3
[n]@Status
display:json:[{"name":"test_event1","type":"Overlay","view":"TestApp1"}]

And the Messaging object will show that a Growl notification event has been sent:

@Messaging
display:json:[{"name":"test_event2","type":"Growl"}]