6

I'm wrapping up the development of a mobile app (ionic, but irrelevant), backed by a backend developed in Ruby on Rails 5, irrelevant again since this is more of a theoretical question/issue.

The thing here is, given the fact that users in the mobile application can log in or not (they've got a bunch of functionalities, and maybe half of those can be accessed by not logged in users), how should I handle the storage of the notification itself and the read state? Note: with notification I'm not referring to a push notification, but to the "message" that stays in a side menu inside the app (I've got push delivery covered).

The main issue here is: I want to be able to track the read notifications to prevent them from being marked as unread in case the user reinstalls the app (imagine 50 unread notifications just because you reinstalled).

I began with a model as follows for storing the notifications in the backend:

  • id
  • user_id
  • push_notification_id (reference to the push notification id, irrelevant)
  • read: Boolean
  • content: Text

With this model, I'd insert a row for every user that needs to be notified, and track with a boolean column whether it was read or not. The issue is, only registered users could have notifications.

A second option is the removal of the user_id reference and the "read" attribute server-side, and assume I'm always gonna notify everyone, not some users. But now, I need a way to track which notifications were read. I could do that locally in the mobile app storing some ids in the local storage, but then again those would be deleted in case of reinstall.

A third option I've thought of, is to implement the second option with an "expiry" column server-side, which indicates when a notification should stop being "unread" by default in case of a new app install. This is the best I've got so far, but I'm not really convinced.

I know I'm asking for a lot of things here, but I am just looking for a good implementation model someone has made before, since I've been unable to find anything googling, and I'm sure this is a heavily repeated design pattern.

Thank you!

Martí Gascó
  • 385
  • 2
  • 11
  • 1
    We might need a bit more context to be helpful here. What is the purpose of these notifications? Are they customized to a user? From your description it sounds like they are the same for everyone, going out to every user at the same time. – Michael Nov 16 '16 at 18:06
  • The purpose is to serve as a companion to the push notifications. Every time a push notification is sent to the users, a "notification" object is created server-side, for the client to list in a sidebar, with the same content, or maybe some extended content. As for the customisation for one user, it was initially intended that way, even though it's not a requirement, it'd be nice to have in case it was needed. However, the main point was just a model of monitoring the "read" status (client-side or server-side) given the fact that the client may reinstall at some point without logging in. – Martí Gascó Nov 21 '16 at 11:20

3 Answers3

1

We used similar approach like you with some changes:

  • for the problem with registered/unregistered user, you can change the user_id for some device uid so the user does not need to be logged in to track the read
  • instead of cumulating the info about read in one table, we had a table of unread notifications and in moment of chnage, we moved the read ones to new table -> the table will not get huge and the operations on it (like counting) will remain fast (depends on users count, but think for future!)
  • plus some features likes storing date_insert and running a monthly job to clear entries older than a year
Zavael
  • 2,383
  • 1
  • 32
  • 44
1

Before you send a notification to user, generate a hash, place it into your Notification table and in the notification body. On mobile side, when user opens the push notification - you need to send a request to the server with that hash and notification-type (if you want). Server gets the hash and finds out which user and notes that the notification was read, and you can set your flag (isRead) to true,

Stephen Rauch
  • 47,830
  • 31
  • 106
  • 135
Yelnar
  • 81
  • 1
  • 4
0

You might find this example from the folks at unow.com useful.

https://github.com/universitynow/message_center/tree/ce3ed6e17b4e650eae53e031ea764012ce6cbf4b/lib/concerns/models

The "item" model should give you some ideas for how to hand read status for one more more recipients.

ob1
  • 1,792
  • 15
  • 20