[question]: How to wait cleanly for completion of user related modifications?

[Danielku15]

How can we help?

How do I wait for the actual result of certain operations to happen. I noticed (also by reading the SDK source) that various operations are asynchronously happening. e.g. when I disable the push, it first only stores the state locally, and the scheduler will upload those changes to the API delayed.

There seem to be some callbacks on the user synchronization, but also they are only fired once, and also just in certain cases (like language modification).

The SDK is very senstive in this regards that if you make certain modifications while those updates are running, it can mess up the state. Hence I want to cleanly wait for certain operations to fully complete before making further updates and calls against the SDK.

I also thought of maybe making certain API calls myself instead of relying on the SDK. e.g. to disable push rather set the userSubscribePref myself but with having the OneSignalRestClient not available on the SDK surface I will be reinventing the wheel.

For now I would be fine with having a clean event for the internalSyncUserState completion to be sure the user information was updated.

The usecase behind this is a user who does a logout and login in the app itself which needs to change certain details about the user in onesignal.

Code of Conduct

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

[brismithers]

Hi @Danielku15, to confirm it looks like disablePush is the only asynchronous call that doesn't have a callback mechanism, and is the one you are having issues with? In general the SDK should be making you have to wait for things to settle on the backend, I'm curious if you would be able to provide more detail on what the inconsistencies are?

Thanks!

[Danielku15]

As you correctly identified the disabling of the push is the call we would need to a callback for. When a user performs an explicit logout in the app we would disable for his user the notifications. During a login the user gets activated for push. If we want to logout and login fast, and potentially change along details like the external user id (because a different account is used) the user state synchronization could happen wrongly.

The inconsistencies come currently mainly into play with #1704 and the appId changes mentioned there. This is where we can see the inconsistencies best because we cannot cleanly unregister from one app during logout and reactivate the user correctly for push in a "different" app.

[jennantilla]

Apologies that we missed responding back to you, @Danielku15.

We appreciate your feedback regarding a callback for disablePush. While most of our efforts in the last few quarters have been for our latest major release (this method does not exist on the new SDK), we may still consider updates to 4.x.x in the future so will keep this in mind.

Thanks!