Basic notification pattern

It is a common use case to have a notification system for the app. A good pattern is to have a centralized “Notification” object that refers to the object that triggered the notification via an “Object” attribute (which stores the object via the object name and row_id). The notification object can include mechanisms to optionally send emails based on user preferences, rules etc. The code to manage the notifications is app-specific and not covered in this tutorial.

Configuration would go as follows:

- Object : MyNotification
- Attributes : 
  - ntfDatetime
  - ntfUsrId
  - ntfObject
  - ntfIsRead
  - etc.

We would then proceed to add a domain for our app, with no homepage and containing a single object : the notification object. This results on the platform adding a menu item which gives direct access to the list.

The last bit is to display a counter of unread notifications in the menu, which can be done by modifying the general JS script (available through Interface > Dispositions : responsive > Resources : SCRIPT ) like so:

(function($) {
	$(document).on("ui.ready", function() {
		setNotifications(); // at startup
		$ui.options.defaultContentLoad = setNotifications; // on each page change
	});
	
	function setNotifications(){
		var ntf = $ui.getApp().getBusinessObject("MyNotification");
		ntf.getCount(function(){
			$('ul.main-menu').find('a[data-domain=\'MyNotifDomain\'] > .text').html('Notifications ('+ntf.count+')');
		}, {ntfIsRead: '0'})
	}
})(jQuery);
3 Likes

It might generate too many calls, or never refresh if the user doesn’t do anything for several minutes.
I would have used a regular interval instead to reload the counter every minute:

setInterval(setNotifications, 60000)