0

I am working on an app, which requires Android push notifications to be implemented.

I have decided to use Firebase Cloud Messaging directly; without using any other abstraction such as AWS SNS or Pusher.

I would like to avoid storing and managing device tokens in the backend, by using the following approach.

In the android app.

  1. When the user logs into the android application, obtain device token but not send it to the server.
  2. Subscribe to a topic that is based on a agreed convention, such that the topic is unique to that user.
  3. On logout unsubscribe from the topic.

In the Server.

  1. Whenever a situation arises to send a notification to particular user, send push notification to the topic, that is based on the convention.

I would like to know if this is a viable strategy to avoid managing device tokens ?

Case against using topics.

From the official docs.

Based on the publish/subscribe model, FCM topic messaging allows you to send a message to multiple devices that have opted in to a particular topic. You compose topic messages as needed, and FCM handles routing and delivering the message reliably to the right devices.

For example, users of a local weather forecasting app could opt in to a "severe weather alerts" topic and receive notifications of storms threatening specified areas. Users of a sports app could subscribe to automatic updates in live game scores for their favorite teams.

I see that topics are recommended, when multiple devices are to be notified. But I have decided to create a topic per user, this would mean most topics would end up getting subscribed by only one device; Is this approach ok ?

Community
  • 1
  • 1
addy
  • 387
  • 1
  • 18
  • So essentially you want to avoid using [device groups](https://firebase.google.com/docs/cloud-messaging/android/device-group)? I don't see offhand why your method wouldn't work, but you would be using topics for something they weren't designed to do, so you're bound to run into some issues. So my question would be *why* do you want to avoid using tokens when your use-case is exactly what they are meant for? – Bryan Sep 05 '17 at 14:03
  • @Bryan For the long term, not having to store data in the backend is a better approach. Storing tokens would mean I need to delete those tokens when the user logs out of the application or when the user's session expires. Using topics would help me not to manage data. I find topics are simpler. – addy Sep 05 '17 at 14:15

2 Answers2

0

I see that topics are recommended, when multiple devices are to be notified

Yes, multiple devices that have something common to listen to, which is the topic. Topics are used for messages that could be received by the general clients since it is public -- i.e. anyone could subscribe and receive messages sent to it.

What is advised to use for multiple devices, but for the same user is to use Device Groups (see my answer here for tips on Managing Device Groups). However, if you don't mind the "topics being public" part, then your approach should be fine.

AL.
  • 36,815
  • 10
  • 142
  • 281
  • What does topics being public mean? Does that mean anybody who knows the topic name can subscribe to it? – addy Sep 05 '17 at 18:21
  • Does using device group help in, not storing and managing tokens? – addy Sep 05 '17 at 18:23
  • Yup. That's the idea. But generally, you could only subscribe to topics from within the app, by callibg `subscribeToTopic` or by using the InstanceID API, which should need the Server Key for authentication, so I think it's safe enough to say that it's not totally public. – AL. Sep 06 '17 at 01:54
  • Using device groups requires you to manage the token, completely. – AL. Sep 06 '17 at 01:54
  • I don't think it's public. I believe one cannot subscribe to topics outside of the app. Please consider rewriting the answer, if you can confirm it. – addy Sep 06 '17 at 03:52
  • I don't think this approach would satisfy my requirements, as I am trying to avoid storing tokens. – addy Sep 06 '17 at 03:53
  • 1
    [Topics are public](https://stackoverflow.com/a/44616143/4625829). If you're confident enough to the security of the app to be just the one to subscribe to your topics, then like I said, your approach should be fine. – AL. Sep 06 '17 at 04:52
0

Yes, Here required device tokens if we want to send push notification whoever installed your app. My research we can save device tokens in back end at first time installation of your app that is better according to my understanding so that we can easy to send push notification across all devices.