Closed kbalani12 closed 1 year ago
Hi @kbalani12,
The method requestImmediateDataFlush
actually just flushes the local data to the server for the current user. Since you are looking to get the latest content cards, can you try using requestContentCardsRefresh
instead?
This is exactly what we do, the problem is that it doesn't work for the very first launch. The sequence that we need to enforce is that current user is set first and then content card is refreshed. we can't enforce this because we don't know when local data is flushed to server. If we call refreshContentCards
prior to it then all we get is empty result.
Hi @kbalani12,
Sorry about the delay! After calling changeUser
, the local data is automatically flushed to the server (regardless of the ProcessingPolicy since this behavior is needed for proper functionality), so no need to call requestImmediateDataFlush
after changing user.
Depending on when you attempt to display the content cards after changing user, you may be displaying it prior to the content card payload coming back. Also, depending on how your campaign is set up and which experiments you are running, you may want to update your campaign settings to set when to re-evaluate eligibility for the content card to get the appropriate cards at display time. To have our team look at your integration + your campaign settings further, please contact support@braze.com with the relevant campaigns and our Support team can follow up with the issues you are facing.
Thanks!
This isn't specific to campaign, most of iOS API that are async (via network or computing delay) needs to be accompanied with a success/failure notification callbacks or delegate.
This is done via WebSDK of Braze. Their method signature:
requestImmediateDataFlush(callback?: (success: boolean) => void): void
If we refresh content cards using this sequences:
Appboy.sharedInstance().changeUser("user id")
Appboy.sharedInstance().requestContentCardsRefresh()
Content cards returns stale response. However, the below one returns the correct response
Appboy.sharedInstance().changeUser("user id")
DispatchQueue.main.asyncAfter(deadline: .now() + 2.0) {
Appboy.sharedInstance().requestContentCardsRefresh()
}
Ideally what we would like to do instead.
Appboy.sharedInstance().changeUser("user id", completion: { error in
if (!error) {
Appboy.sharedInstance().requestContentCardsRefresh()
}
})
The request for this is to at minimum provide a callback for requestImmediateDataFlush
.
Hi @kbalani12,
The proposed solution above actually would not address your use case because the endpoints for user data and Content Cards are separated out, meaning that changeUser
/ requestImmediateDataFlush
is communicating with a separate endpoint than what refreshContentCards
is. This means that even if we accepted a completion
to the first couple APIs, we would not be able to guarantee it is executed in the manner you describe.
However, the current default implementation of Content Cards should be adequate to handle your use case, as it will automatically refresh Content Cards in a few places. First, whenever a Content Card feed is about to be displayed, it will request for the latest cards if it is outside of a timeout. Also, if you monitor the requests that come to your device using a tool such as Proxyman, you will notice that immediately after changing a user, there will be another request from the /content_cards
endpoint which contains the new data for that user.
Let me know if that answers your questions!
I'm closing this issue due to inactivity. Feel free to contact our Support team at support@braze.com if you continue to run into issues or have more details related to this thread.
Thanks!
What problem are you facing?
We are retrieving content cards for a valid user and content feed is blank. This is primarily because user isn't set at app launch. If an experiment needs to be performed just after launch then there is no deterministic way to do it.
We request
requestImmediateDataFlush
after setting current user but it doesn't provide with completion callback to fetch subsequent request to content cardsWorkarounds
Add a manual delay.
Ideal Solution
Provide with completion callback when dispatch to server request is completed.
Other Information
No response