How to keep unread notifications relevant

You’ve probably puzzled over this at some point in your career. Don’t worry — the answer is here. First of all, what do I mean by keeping unread notifications relevant? What’s the problem? Like a lot of things, it’s easier to explain with an example. Let’s say we have a system that helps you find people for upcoming job shifts. It sends a notification to someone asking if they want a shift on Saturday from 12 pm to 3 pm at a given address. A few people respond “yes,” you pick someone, and that person gets notified that they’ve got the gig. If the time of the shift changes or it gets cancelled altogether, the system sends them another notification. Now let’s zoom in. The job is offered. That notification says something like: New job on 18th of April, 12pm — 3pm, 48 Pirrama Rd, Pyrmont NSW 2009 They get a ping that there’s a new notification. They’re out and about and haven’t read it yet. In the meantime, you realise the shift is longer and update the job in the system. It issues another notification: The job has changed to 18th of April, 12pm — 5pm, 48 Pirrama Rd, Pyrmont NSW 2009 When they finally check their notifications, ideally we’d like them to see a single notification: New job on 18th of April, 12pm — 5pm at 48 Pirrama Rd, Pyrmont NSW 2009 Now let’s say they’ve got the job, and a few days later the details change again: The job has changed to 18th of April, 12pm — 5pm, 14 Vine St, Redfern NSW 2016 Just like before, they’re out and haven’t checked their phone. Then you realise the job is cancelled. The system sends one more notification: The job is cancelled. Again, when they check their notifications, we’d like them to see only the cancellation — the previous job updates are no longer relevant once the job is cancelled. There could be many more notifications, with various ways they affect one another. Here’s how to structure your code in a way that’s robust and easy to expand. Structure We have two main parts: a set of existing notifications and a new notification that gets added to the set. It’ll either update some of the existing notifications or be added as a new one. Going back to our example, let’s say our set of existing notifications contains a single job notification: New job on 18th of April, 12pm — 3pm, 48 Pirrama Rd, Pyrmont NSW 2009 The new job change notification gets added to the set: The job has changed to 18th of April, 12pm — 5pm, 48 Pirrama Rd, Pyrmont NSW 2009 As a result, we expect the set to contain just one notification: New job on 18th of April, 12pm — 5pm at 48 Pirrama Rd, Pyrmont NSW 2009 We loop through existing notifications and “update” them one by one with the new notification. In that process, we check whether both the new and old notifications are still relevant and act accordingly: Example What’s a technical article without a class diagram? Here NotificationSet represents the set of existing notifications that we want to update with the new notification. This new notification is passed to the add method as a parameter of type NotificationData. Each existing notification has its own update logic that is represented by ExistingNotificationUpdate. It interacts with NewNotificationAddition — the logic of adding the new notification to the set. After all these interactions it determines if this new notification isRelevant(). Similarly the ExistingNotificationUpdate determines if it should be deleted via isDeleted() method. Java implementation Here’s Java implementation of the above pseudo-code: public void add(NotificationData newNotificationData) { checkNotNull(newNotificationData); NewNotificationAddition newNotificationAddition = newNotificationData.createNewNotificationAddition(); for (Notification n : newHashSet(notifications)) { ExistingNotificationUpdate existingNotificationUpdate = notificationUpdateFactory.createNotificationUpdate(n); newNotificationAddition.call(existingNotificationUpdate); if (existingNotificationUpdate.isDeleted()) { notifications.remove(n); } } if (newNotificationAddition.isRelevant()) { notifications.add(notificationFactory.newNotification(newNotificationData)); } } I’ve written a working example that demonstrates this pattern: https://github.com/denissudak/unread-notifications-update Even if you don’t work with Java, I’d still recommend checking it out as it communicates the idea through working code. I hope you find it useful. Enjoy!

Jun 2, 2025 - 22:40

How to keep unread notifications relevant

You’ve probably puzzled over this at some point in your career. Don’t worry — the answer is here.

First of all, what do I mean by keeping unread notifications relevant? What’s the problem? Like a lot of things, it’s easier to explain with an example.

Let’s say we have a system that helps you find people for upcoming job shifts. It sends a notification to someone asking if they want a shift on Saturday from 12 pm to 3 pm at a given address. A few people respond “yes,” you pick someone, and that person gets notified that they’ve got the gig. If the time of the shift changes or it gets cancelled altogether, the system sends them another notification.

Now let’s zoom in. The job is offered. That notification says something like:

New job on 18th of April, 12pm — 3pm, 48 Pirrama Rd, Pyrmont NSW 2009

They get a ping that there’s a new notification. They’re out and about and haven’t read it yet. In the meantime, you realise the shift is longer and update the job in the system. It issues another notification:

The job has changed to 18th of April, 12pm — 5pm, 48 Pirrama Rd, Pyrmont NSW 2009

When they finally check their notifications, ideally we’d like them to see a single notification:

New job on 18th of April, 12pm — 5pm at 48 Pirrama Rd, Pyrmont NSW 2009

Now let’s say they’ve got the job, and a few days later the details change again:

The job has changed to 18th of April, 12pm — 5pm, 14 Vine St, Redfern NSW 2016

Just like before, they’re out and haven’t checked their phone. Then you realise the job is cancelled. The system sends one more notification:

The job is cancelled.

Again, when they check their notifications, we’d like them to see only the cancellation — the previous job updates are no longer relevant once the job is cancelled.

There could be many more notifications, with various ways they affect one another. Here’s how to structure your code in a way that’s robust and easy to expand.

Structure

We have two main parts: a set of existing notifications and a new notification that gets added to the set. It’ll either update some of the existing notifications or be added as a new one.

Going back to our example, let’s say our set of existing notifications contains a single job notification:

New job on 18th of April, 12pm — 3pm, 48 Pirrama Rd, Pyrmont NSW 2009

The new job change notification gets added to the set:

The job has changed to 18th of April, 12pm — 5pm, 48 Pirrama Rd, Pyrmont NSW 2009

As a result, we expect the set to contain just one notification:

New job on 18th of April, 12pm — 5pm at 48 Pirrama Rd, Pyrmont NSW 2009

We loop through existing notifications and “update” them one by one with the new notification. In that process, we check whether both the new and old notifications are still relevant and act accordingly:

Example

What’s a technical article without a class diagram?

Here NotificationSet represents the set of existing notifications that we want to update with the new notification. This new notification is passed to the add method as a parameter of type NotificationData.

Each existing notification has its own update logic that is represented by ExistingNotificationUpdate. It interacts with NewNotificationAddition — the logic of adding the new notification to the set. After all these interactions it determines if this new notification isRelevant(). Similarly the ExistingNotificationUpdate determines if it should be deleted via isDeleted() method.

Java implementation

Here’s Java implementation of the above pseudo-code:

public void add(NotificationData newNotificationData) {
    checkNotNull(newNotificationData);

    NewNotificationAddition newNotificationAddition = newNotificationData.createNewNotificationAddition();
    for (Notification n : newHashSet(notifications)) {
        ExistingNotificationUpdate existingNotificationUpdate = notificationUpdateFactory.createNotificationUpdate(n);
        newNotificationAddition.call(existingNotificationUpdate);
        if (existingNotificationUpdate.isDeleted()) {
            notifications.remove(n);
        }
    }
    if (newNotificationAddition.isRelevant()) {
        notifications.add(notificationFactory.newNotification(newNotificationData));
    }
}

I’ve written a working example that demonstrates this pattern: https://github.com/denissudak/unread-notifications-update

Even if you don’t work with Java, I’d still recommend checking it out as it communicates the idea through working code.

I hope you find it useful. Enjoy!