Activities & Notifications

A core part of the experience for any chat platform is how you can stay up-to-date on things that have happened while you were away. The most common ways of surfacing this kind of information is through sending “push notifications” when you’re not using the app, and displaying “toasts” and “recent activity” when you are using the app.

A toast is similar to a push notification banner in that it will display in an area of the screen and disappear at some point shortly after, however with a toast it can be themed to fit the style of the app and even controlled in a way that makes it less intrusive to the user experience, including disabling toasts all together if a user wants to.

So how does the whole flow work? In a nut-shell, deep linking.

Deep linking allows app builders to register a URL scheme of their choosing and then utilize that scheme to open the app with a URL that uses that scheme. For Tower, this means registering something like twr:// as the scheme. Any URLs that the device attempts to open that has that scheme will instead open the app. From there, we can parse the URL and take action on its parts. For example, say we twr://conversation/<some ID>, we can determine that we want to attempt to open a conversation with a specific ID. If everything is successful and the user has access to that conversation we can then route the user right into the experience.

So we know how to handle the notifications, but where do they come from in the first place?

Activities and notifications are nearly synonymous, though they’re both generated at the same time and for the same reasons, more or less. The current notification system has the following triggers:

• User A is notified and an activity is created when User B requests to chat with them in a conversation

• User B is notified and an activity is created when User A accepts that request

  • There are no notifications or activities if User A declines the request

• Every message sent during a conversation can trigger a notification to be sent to the recipient

  • No activities are created for messages

• User A is notified and an activity is created when User B (or vice versa) ends the conversation

• User A is notified and an activity is created 24 hours after User B (or vice versa) has rated the conversation but User A has not submitted a rating

These notifications and activities are generated in the service layer at the moment that the users perform any of the actions above.

But why have both activities and notifications?

Mostly because push notifications are not guaranteed to ever arrive, and there are times when the user is using the app and might have toasts disabled temporarily. In this case, when they navigate back to the activities experience in the application, they can see that new events have taken place that they need to be aware of and possibly take action on.

This week we defined our deep linking strategy and how to wrap that into our notifications and activities, which was a major piece of the remaining functionality to nail down before we prepare for beta. There are a few more big pieces to finish up, but things are starting to get exciting!

Oh, we’ve also got our Apple developer account finally up and running after a lot of back and forth with Apple.

TTFN.