You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2023. It is now read-only.
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.
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.
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:
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 adata
field which contains the JSON data needed by thatcode
.For instance,
server_password_acquired
notification contains thepassword
field ondata
, whilefile_downloaded
notifications contains thefile_name
field ondata
.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
andip
. The underlyingserver_id
is NOT sent to the client. Notice that even when the server is a gateway (i.e. the Client knows itsserver_id
) the notification will only containnetwork_id
andip
.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. Thenotification_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 thenotification_id
that was marked as read, or a specialall
field, meaning that all notifications of thatclass
were read. The event payload contains theclass
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
server_password_acquired
notification.The text was updated successfully, but these errors were encountered: