Add support for Notification system

[renatomassaro]

Notifications

Notification is an in-game feature meant to notify the player of actions that may be of her interest. Most of the time it notifies about actions that were made by the player herself, but sometimes the notification may arise due to an external action made by someone else (ex: "new message received", "friendship request").

There are four classes of notifications:

• Account notification - These notifications are bounded to the player account. They extend beyond a single server. Ex: "friendship request". Note that Database actions happen at the account level, so for instance "server password acquired" is another example of account notification.

• Server notification - These notifications are bound to a server. For instance, "file deleted" notification should be shown on the server that file got deleted. A player has access to notifications from her gateway and any remote server she is connected to. Keep in mind that a player will only receive notifications meant for her. If someone else deleted a file, the player will not receive this notification.

• Chat notifications - Notifications exclusive to the chat message. Very similar to Facebook's chat notifications. They have a custom behaviour, so beware when implementing it.

• Clan notifications - Notifications bound to a clan. "New member has joined the clan", or "clan war started" are some examples of clan notifications.

UI

Notifications are grouped into an icon, one icon per class. The icons are displayed at the Header, top-right corner of the screen. Order: [clan], chat, server, account.

The Clan icon is only shown for members who are part of a clan.

Chat Notifications

The Chat dropdown, containing the chat notifications, must show:

• The profile picture of the other person
• The last message sent on the conversation (may be my own message).
• The status of the last message (read, unread)
• The time of the last message (X minutes/hours/days ago)

Notice that:

If the player received a message and haven't read it yet, the background is different (background=unread) than if the player had already read it (background=read). However, it may be that the player just sent a message to the other one, and the other one haven't read the message yet. However, from the player's perspective the message is read, so the background shows it as read (background=read).

Skip the implementation of chat for now, but keep in mind these UI details.

Account notifications

Account notifications are probably the simplest. Its dropdown shows the notifications, sorted by time (newest first). Most account notifications are clickable, meaning that whenever they are clicked, the relevant app will be displayed, with the relevant data highlighted to the player.

When new notifications arise (and they are unread), a red badge should display the number of unread notifications right above the account icon.

We'll assign an abstract icon to each account notification.

Server notifications

Server notifications add a new challenge: displaying the notifications of multiple servers.

At any point in time, the player is "connected" to at most two servers: the gateway and some endpoint. The server notification dropdown should display, on its header, a toggle option between gateway or endpoint notifications. Whichever option is selected should have a different background than the option not selected.

The option that should be selected by default is the one of the player's active context. If the player is currently using the gateway as the active context, the gateway option should be active. Alas, if the endpoint is the current active context, it's the endpoint that should be active by default.

If the player is not connected to any server, the "endpoint" option should appear as disabled (using a gray/faded background color).

If there are unread notifications on any of the two servers, a red badge should be displayed right above the Server icon, displaying the number of unread notifications.

If the inactive option has unread messages, its option toggle, at the dropdown header, should have a red dot indicating there are unread messages.

(See image above again).

We'll assign an abstract icon to each server notification.

How about notifications to servers that are not currently in use?

If the notification is in another gateway, a badge with the number of unread notifications should be shown on the gateway selection dropdown.

The same applies to the endpoint dropdown, but instead of displaying the number of unread messages there, we just display a red dot.

Reading notifications

When notifications arrive, they are marked as unread by default. When the player clicks at the Icon and the notification dropdown is displayed, all notifications are marked as read (note: send the "read.all" request only if there are unread notifications).

Some or all notifications are shown on the bottom-right or bottom-left corner of the screen right after they arrived, staying there for a few seconds. If the user clicks on this notification, that single notification should be marked as read. When that happens, the Client should send a "read" request with the corresponding notification_id.

Implementation details (HEBorn <-> Helix communication)

Events

NotificationAddedEvent

The notification_added event is published to HEBorn right after a notification is added. It must contain all information needed by the Client to properly display it.

Notifications are structured, meaning they have a code that acts as an identifier of the notification, and a data field which contains the JSON data needed by that code.

For instance, server_password_acquired notification contains the password field on data, while file_downloaded notifications contains the file_name field on data.

The event also contains the class field, which tells the Client whether the notification belongs to Server, Account, Chat or Clan.

When the notification belongs to a Server, the corresponding server nip will be sent, on the fields network_id and ip. The underlying server_id is NOT sent to the client. Notice that even when the server is a gateway (i.e. the Client knows its server_id) the notification will only contain network_id and ip.

NotificationReadEvent

Whenever the Client tells Helix that some (or all) notifications should be marked as read, we'll send back the notification_read event. The Client can (and should) mark notifications as read optimistically. The notification_read event is meant to any external Client that may be in use by the player at the same time.

The notification_read event will contain the notification_id that was marked as read, or a special all field, meaning that all notifications of that class were read. The event payload contains the class field.

Note: not implemented yet; specs may change.

Requests

account:notification.read

Mark a single notification as read.

Params:

• notification_id

Note: not implemented yet.

account:notification.read.all

Mark as read all notifications belonging to that class.

Params:

• class

Note: not implemented yet.

Other stuff

• All notifications (chat/server/clan/account) are sent to the Account channel.
• Implementation available at Add Notification system Helix#406. Fully working example: server_password_acquired notification.