Home » Archived » Eclipse SmartHome » Introducing Notifications(Initial discussion and brainstorming)
| Introducing Notifications [message #1707486] |
Sat, 05 September 2015 09:59  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Hi all,
Cfr the various threads left and right, I have compiled some stuff in a basic UML that is up for discussion.
Here are some quick thoughts of how it could work. I will have certainly missed things.
NotificationPublisher in essence create Notifications (through a NotificationFactory) which they post at the NotificationService (NS). the NS stamps the Notification with a configurable expiration timestamp and a sequential number. the NS then queries all NotificationSubscribers if they have interest in the given Notification (can be based on the Type of the Notification). The Notification and its list of interested Subscribers is then persisted, and the NS calls receiveNotification on all Subscribers.
Subscribers can present the Notification at the user, route it to an external service, whatever. Once a certain action (e.g. user input) is deemed completed, the Subscriber can acknowledge the Notification to the NS. Upon acknowledgment, the NS will then revoke the Notification from the other Subscribers that got the same Notification, and will finally let the NotificationPublisher know that the Notification was acknowledged (onAcknowledgment). At that point, the Notification is canned, but we could also opt to graveyard it in a persistent store for audit trailing purposes (alarm systems!)
Publishers can also, if necessary, revoke Notifications.
The NS constantly monitors the persistent store and prunes any expired notifications (e.g. no acknowledge received before the expiryDateTime of the Notificaiton). If a Notification expires, the Subscribers and the Publishers are signalled. For a subscriber that could mean that for example a UI dialog box is retired, and for example a publisher can take a decision, action to do something else based on the negative acknowledgment.
There is also a EventNotificationBridge that can, probably based on filters, convert Events into Notifications, which then can be routed to external services like PushOver and alike. Subscribers that offer no interactivity with a user or system, e.g. they just take the notification as is, can forego acknowledgment, or will not react on onRevoked, or onExpired. We will have to figure out how the payload of Events can be mapped on to Notifications? maybe Notifications also need a json payload field.
Few thoughts I had:
1. Should the NS track what Subscriber is interested in a given NotificationType, or should it query the Subscribers every time there is a Notification? the former might be more efficient, but the latter allows the Subscriber to change its interest over time, etc
2. Should all this happen in a synchronous way? do we need a sequence number on the Notification to keep things in order?
3. Do we need explicitly NotificationFilters ( and have the NS filter), or do we let that to the Subscriber to decide what it does with a Notification?
Regards
Karel
|
|
| | | |
| Re: Introducing Notifications [message #1707985 is a reply to message #1707757] |
Fri, 11 September 2015 09:00  |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Karel,
I have discussed your proposal with Dennis yesterday. Here is some feedback:
The overall architecture looks quite good, but we would suggest to actually start a bit smaller. As a blueprint, we could use the PersistentInbox, since the discovery inbox seems to be a very similar functionality.
An initial implementation could have only 3 main classes (for which we would align the naming with the Android notification API (http://developer.android.com/guide/topics/ui/notifiers/notifications.html)):
- Notification
- NotificationBuilder (your NotificationFactory)
- NotificationManager (your NotificationService)
Let's describe them one by one:
Notification:
- We do not think that we need an expiry date as it will always be tough to come up with one
- The type could be just string instead of enum with constants being defined within the class (similar to Android)
- There should only be getter methods, no setters
- There is no localization feature within Notifications, they have to be created in the correct locale in the first place by the producer.
- As properties, we would hence suggest: String:id, String:title, String:text, String:icon, String:type, int:priority, URI:context, URI:action, boolean:sticky
NotificationBuilder:
- Similar to ThingBuilder or http://developer.android.com/reference/android/support/v4/app/NotificationCompat.Builder.html
- Is used to construct Notification instances since they do not have any setters.
NotificationManager:
- has add, remove, update methods, which can be directly used by consumers; no need to have them implement a NotificationPublisher interface.
- sends events (of new Notification event types) whenever anything changes, so we do not need the NotificationSubscriber, since we can simply use the existing EventSubscriber infrastructure.
For producing notifications, we should not have a general EventNotificationBridge, since not all events make sense to have as notification (probably only a small fraction). So we should rather have dedicated notification producers, e.g. for thing offline notifications (which are deleted by this service when a thing gets online again). Such producers could be a second implementation phase, though.
What do you and others think about this approach?
Regards,
Kai
|
|
| |
| Re: Introducing Notifications [message #1708190 is a reply to message #1708042] |
Mon, 14 September 2015 12:43 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
- if not getters on Notification, how to read out properties? public members?
I said "no setters", not "no getters" 
- great idea to leverage Events for Notifications, but this presumes a get(someNoficiationUID) method on NotificationManager in order to retrieve the notification after being signalled a new one is available
No, the payload of the event would already contain the full notification; no need to get it from the NotificationManager. There is only a getAll for notifications that you might have missed in the past because you weren't listening to events.
- Notification:id extends/implements UID.java?
I would go for a simple String as I don't think that we need hierarchical IDs. And UID is currently in a thing package, so we would have to refactor that...
- No sequence numbers for the Notifications?
No, simply have an ordered list returned by getAll() - that should be imho enough (at least for a start)
- Could we not apply an EventFilter on the EventNotificationBridge to select what the end-user is interested in to receive?
My point was that you would want some custom code to transform events into notifications: You might want to aggregate, localize or enrich them. So we will probably need different specific "producers", which all could be configured by the user to define whether he is interested, what kind of notification he prefers etc. I would leave this implementation out of scope for the first step.
- no needsAcknowledgement / isAcknowledged property on Notification?
Yes, notifications would simple be removed (and subscribers are informed about that through an event)
- who can remove() Notifications from the NotificationManager?
Anybody.
- some processed expect interaction within a given time, in order to decide some action.
So this process is free at any time to delete the notification again
Regards,
Kai
|
|
|
| Re: Introducing Notifications [message #1708198 is a reply to message #1708190] |
Mon, 14 September 2015 14:57 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
No, the payload of the event would already contain the full notification; no need to get it from the NotificationManager. There is only a getAll for notifications that you might have missed in the past because you weren't listening to events.
-> So, there will be no way to change a Notification once it is generated/posted. Any change would then be done through a remove(), add() sequence, and thus generate a new Notification that might not be in sequence anymore. Just thinking out loud if that would be an issue for some use cases
- Notification:id extends/implements UID.java?
I would go for a simple String as I don't think that we need hierarchical IDs. And UID is currently in a thing package, so we would have to refactor that...
-> Could be something similar, with different parts separated by a : . We could include for example the name of the instance that generated the Notification. Ok for me to have a free-format id, but it will certainly not be unique then? Could that lead to duplicate Notifications, and would that be an issue?
- Could we not apply an EventFilter on the EventNotificationBridge to select what the end-user is interested in to receive?
My point was that you would want some custom code to transform events into notifications: You might want to aggregate, localize or enrich them. So we will probably need different specific "producers", which all could be configured by the user to define whether he is interested, what kind of notification he prefers etc. I would leave this implementation out of scope for the first step.
-> Whatever we decide to do, I will certainly contribute some implementation of this kind as I need it anyways in my setup, unless we are Ok that one can listen for Events instead, and inject these in an external system (cfr my pull request). If the route is to go for Notification as the "exit" strategy, then we would at least some Notification generators somewhere, no?
Regards
K
|
|
|
| Re: Introducing Notifications [message #1708318 is a reply to message #1708198] |
Tue, 15 September 2015 13:18 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
> So, there will be no way to change a Notification once it is generated/posted. Any change would then be done through a remove(), add() sequence
No, just like the Inbox, the add would either add or update Notifications (using the id for comparison). To make it clear, the method might better be called addOrUpdate. If a Notification does not have an id, it is always considered to be a new one and an id can be automatically generated for it.
> Ok for me to have a free-format id, but it will certainly not be unique then?
Right, but we did the same for the new rules as well. I think if we have the convention that people should prefix there notifications with some suitable string, the risk to run into duplicates is neglectable.
> If the route is to go for Notification as the "exit" strategy, then we would at least some Notification generators somewhere, no?
Yes, of course. I only suggested to discuss their details as a second step as I consider them to be the "extensions" to the framework that we are discussion right now.
|
|
| | | |
| Re: Introducing Notifications [message #1708456 is a reply to message #1708417] |
Wed, 16 September 2015 17:09 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Kai Kreuzer wrote on Wed, 16 September 2015 07:53Good point about the timestamp, I actually missed that in my list of properties above, but definitely wanted it as well I assume the timestamp is optional and if not filled by the producer, it is automatically set by the manager?
Yes, it is even not possible to set by the producer, but set at instantiation of the Notification (by the NotificationBuilder)
Quote:
Regarding a "source" property: Yes, this would be somewhat overlapping to the id prefix. What use cases do you see where a producer wants to query its notifications?
I have implemented NotificationFilterCriteria to query the stored Notifications. Imagine that a producer needs to update a lingering notification, then it would have to traverse the all the Notifications (getAll()) if no filtering would be possible. In one of the producers classes, I use ' serviceID + ":" + idCounter ' as UID for the Notifications for now, but since these producers are a kind of "set-and-forget" producers, I do not have a need currently to query the store. But you could also imagine that at startup of a producer, the producer wants to query the store for any notifications it generated previously, and if necessary prune those to start with a clean slate.
Karel
|
|
| | | | | | | | | | |
Goto Forum:
Current Time: Fri Apr 26 07:26:49 GMT 2024
Powered by FUDForum. Page generated in 0.04555 seconds |
] 
Search
Help
Register
Login
Home
