feat: pass targeting params and an authId to loadMessage - #362
Open
bschmalb-ksta wants to merge 2 commits into
Open
bschmalb-ksta wants to merge 2 commits into
bschmalb-ksta wants to merge 2 commits into
Conversation
The scenario in the sourcepoint portal picks the message a property serves from the targeting params the SDK sends along, and neither platform could send any, so a property with more than one message always fell through to the same one. SPConfig now takes targeting params per campaign. They reach addCampaign(campaignType, params, groupPmId) on android and SPCampaign(targetingParams:) on ios. loadMessage takes an optional authId, which both native SDKs already accept, so a consent decision a signed in user has taken elsewhere is found again instead of the message being shown a second time. Both are optional and default to nothing, so an existing caller is unaffected. Closes thekorn#265
Both native sides already put the id of the tapped custom button on the pigeon message, but the dart mappers built a ConsentAction without it, so ConsentAction.customActionId was always null and a message with more than one custom button could not be told apart in onAction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The scenario in the sourcepoint portal picks which message a property serves from the targeting params the SDK sends along, and neither platform could send any, so a property with more than one message always fell through to the same one. SPConfig now takes targeting params per campaign and they reach addCampaign(campaignType, params, groupPmId) on android and SPCampaign(targetingParams:) on ios. loadMessage also takes an optional authId, which both native SDKs already accept. Both are optional and default to nothing, so an existing caller is unaffected. One thing that was simply dropped: both native sides already put the id of the tapped custom button on the pigeon message, but the dart mappers rebuilt ConsentAction without it, so customActionId was always null.
Tested with the four packages' unit tests, where the new ones cover the targeting params and the authId reaching the pigeon call and the custom action id reaching the delegate, by building the example app on an android emulator, and by running our own app on an ios simulator and an android emulator against a property whose scenario branches on a targeting param: both now serve the message the params ask for instead of the one the scenario falls through to. The example's ios build fails on main here too, on "Failed to copy Flutter framework" before any plugin code is compiled, which is why ios is covered by our own app instead.
Closes #265