[question]: Extremely Slow Callbacks On Version 4.8.9

[bundleberk]

How can we help?

I had to downgrade to OneSignal 4.8.9 because of the bugs that 5.x.x versions had. OSSubscriptionObserver and SetExternalId completion callbacks are extremely slow. SetExternalId callback always triggers after 5 seconds like it is done on purpose. OSSubscriptionObserver is also triggers after 5-10 seconds. Those are very long times since I need to do some other operations like setting tags to the user. Any ideas?

Code of Conduct

• I agree to follow this project's Code of Conduct

[jkasten2]

@bundleberk The calls back are only fired after the network call is completed. Network calls are delayed by 5 seconds so as many operations can be batched together into a single network call as an optimization.

You can call sendTag() before the the device is subscribed. If need to conditionally set tags if the user has accepted notification permissions or not I would recommend OSPermissionObserver instead.

[bundleberk]

Backend sets the tags in our structure unfortunately not the client. In this case I have to wait for approximately 10 seconds to inform the backend that user is subscribed, logged in and ready to be set tags and get notifications. If users kills the app on the first session earlier than 10 seconds they will not be able to get notifications. In this case i will have to use a Worker to send the request even if the app is killed. The callbacks are fired instantly on onesignal 5 though :(

[jkasten2]

@bundleberk Splitting up setting values on the player between your backend and your app, especially on create / first start, does make things more complex. In your scenario it has a lot of serial operations that depend on each other. I think moving the tag setting to the client will simply things a bit, and should make this process faster.

I don't think I have the full picture of what your needs are and what you are currently doing but I'll fill in the gaps by stating some assumptions to get us on the same page. Let me know if this is right or wrong:

1. Your app has a login screen, this calls your backend, the returns some kind of id to your app
2. You use the id you got from your server and call setExternalId
3. When OSSubscriptionObserver fires you make a 2nd call to your backend, where it makes a REST API call to PUT api.onesignal.com/players/{{ONESIGNAL_PLAYER_ID}} to set the tags.

If the above it right I would recommend you instead you pass the tag values you want to set on the OneSignal Player from your login endpoint. So on step 1 above, pass tags in addition to your id to the app from your backend when the end-user logs into your app. Then you call simply call OneSignal.setExternalId(myId) and OneSignal.sendTags(myTags) and the SDK will handle settings these, even if the app is swiped away or there was any connection issues.

[bundleberk]

mostly correct,

1- I call backend to get an id on app's login
2- I start listening to OSSubscriptionObserver.
3- When OSSubscriptionObserver callback fires I get the Player ID
4- I'm calling setExternalId with the id that i got from backend in Step1, and wait for the setExternalId success callback.
5- After setExternalId is successful I make the 2nd call to backend where it makes a REST API call to PUT api.onesignal.com/players/{{ONESIGNAL_PLAYER_ID}} to set the tags.

this whole process takes like 15 seconds to complete which is too long. thanks for the recommendation it could work better but unfortunately I'm unable to change this structure quickly becuase it involves backend development too, I used a Worker to handle all of these. Which led to this issue.

[jkasten2]

Summary, the 5 second delay is by design to optimize network calls. The 15 second delay is due to operations depending on each other, which can be avoided by changing how tags and externalId are used with OneSignal. While there might be a change the SDK could make to make this smoother there isn't plans to make any large changes to the 4.x.x branch, instead this would be better to consider for 5.x.x and future major versions of the SDK.

If this scenario is still a concern for User Model (5.x.x) please open a new issue.