3

The case is this:

  1. A user logs in to the app on their iPhone A
  2. The user login in to the same app on their iPhone B

Now, in the database, there are 2 tokens for one user, that is correct.

+---------+-------------------+
| user_id |   device_token    |
+---------+-------------------+
|       1 | 1st_device_token1 |
|       1 | 2nd_device_token1 |
+---------+-------------------+

Say, that user deleted the app, installed it again (on both devices) and that means, tokens in APNs changed, therefore in our database, there are 4 unique tokens.

+---------+-----------------------+
| user_id |     device_token      |
+---------+-----------------------+
|       1 | 1st_device_token1     |
|       1 | 2nd_device_token1     |
|       1 | 1st_device_token1_new |
|       1 | 2nd_device_token1_new |
+---------+-----------------------+

Now, a push notification for that user is going to be sent to 4 devices (4 tokens). If they keep deleting and installing the app (may happen :) ), I would have in the database a large amount of tokens for one user and think, that they have such a vast number of devices, while in reality, there are a lot of invalid tokens.

How to prevent that?

Ivan Hanák
  • 2,214
  • 1
  • 16
  • 25
  • The feedback information from the push servers has historically never very good, however I think its been improved quite a lot now. Have you checked the latest documentation on what information the server returns when you send a push to see if it will include information on if the push token is invalid or if the push can't be delivered? But anyway, this is rather an edge case isn't it. While its possible, who is actually going to delete and re-install the app so many times it leads to a "vast number" of entries in your database? – Gruntcakes Dec 30 '16 at 17:55

1 Answers1

0

Pushwoosh periodically clears its database from invalidated tokens (once per day or so), so having a "vast number" of entries should not be a problem. As for sending pushes to multiple devices of one user, there is a specific Push by UserID feature for this case.

The idea is to set a particular UserID on a login event and reset it to a default value on a logout with the following method:

[[PushNotificationManager pushManager] setUserId:@“external_user_1”]

Once UserID is set, you can send your /createMessage API requests with "users" parameter:

{
  "request": {
    "application": "APPLICATION_CODE",
    "auth": "API_ACCESS_TOKEN",
    "notifications": [{
      "send_date": "now",
      "content": "Hello world!",
      "users":["external_user_1"]
    }]
  }
}

This feature is accessible for all payment plans, so it should be accessible for you.

John Moutafis
  • 22,254
  • 11
  • 68
  • 112
WFHM
  • 81
  • 5