[MOB-6055] callback on setEmail/setUserId

[devcsomnicg]

🔹 Jira Ticket(s)

• MOB-6055

✏️ Description

Add callbacks for setEmail/setUserId, and it returns success/failure based on device token is registered successfully or not. It will always return success if autoPushRegistration is false.

[devcsomnicg]

@roninopf Could you please start review for this ?

[roninopf]

@devcsomnicg Will do! Would you like to look over the tests as well?

[devcsomnicg]

@roninopf updated code and tests, could you please run the tests again

[Ayyanchira]

Will have to resolve the conflict. But looks like its replacing the existing method with one with additional parameter. As like for other SDKs, we should have additional methods for the ones with completionHandlers. This is to avoid breakages for developers who would just update to newer versions of SDK

[devcsomnicg]

@Ayyanchira done, added additional methods.

[devcsomnicg]

@Ayyanchira Updated this with suggestions on PR. please review

[devcsomnicg]

@Ayyanchira Updated this with suggestions on PR. please review

[Ayyanchira]

Added some comments. Merging to omni cg branch for internal testing. Looks good so far.

[Ayyanchira]

Had initial thought that we might need additional functions with and without handlers as we do in Android. But looks like having optional parameters makes it modern and lets us have only one signature instead of bloating up the IterableApi class. 👍🏼

[devcsomnicg]

@Ayyanchira ok so for this we are good right ?

[Ayyanchira]

If this is going to be global but only used for setting the user credentials, we might have to rename it that way. Because, we will be adding success failure callbacks to other api calls / function calls as well and they will have to pass in success and failure callbacks too. using this global variable to store that and replace whats been stored in that can cause inconsistent behaviors

[Ayyanchira]

Like for example, updateEmail also uses success and failure callback handler to notify the state. But by not having it stored globally, it allows for good separation.

[devcsomnicg]

@Ayyanchira yes we can rename it so that is identified differently, but it would be class variable because it is used from the whole different method and that is why we need to hold a reference to it

[Ayyanchira]

Checked and its working well. So lets go ahead with current changes as it is for now until other methods also start needing success and failure callback handlers.

[Ayyanchira]

Test methods are failing @devcsomnicg . It looks like setEmail leads to AppExtensionHelper.application?.registerForRemoteNotifications(), but that doesn't lead to registerDevice Flow.

[devcsomnicg]

Test methods are failing @devcsomnicg . It looks like setEmail leads to AppExtensionHelper.application?.registerForRemoteNotifications(), but that doesn't lead to registerDevice Flow.

I am not sure about where this code is AppExtensionHelper.application.registerForRemoteNotifications() but, to give you a example when you do registerForRemoteNotifications it calls this function didRegisterForRemoteNotificationsWithDeviceToken here https://github.com/Iterable/swift-sdk/blob/5c033ded01e200acee52c9bd1fca377dbdcbbbce/sample-apps/swift-sample-app/swift-sample-app/AppDelegate.swift#L105.

[Ayyanchira]

Added a call to registerDevice() with no success failure callback after setEmail -> here in this PR. This commit.
Verified that it eventually triggers the callbacks.
This means the test assumes that registerDevice will eventually get called. And it checks if the handlers set while setting the credentials still remain active or not.