-
Notifications
You must be signed in to change notification settings - Fork 5
AB#261534 in app ccrm #131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ading Inappresenter simplifications
…ech/Optimove-SDK-iOS into feature/261534-in-app
|
👋 Hey @k-antipochkin, ❗️ Work Item link check failed: There is no Work Item linked to this PR. 🧩 Please add the Work Item ID to the PR title or description using the "Edit" option in the format below: 🟢 Once added, the validation will automatically run again! |
1 similar comment
|
👋 Hey @k-antipochkin, ❗️ Work Item link check failed: There is no Work Item linked to this PR. 🧩 Please add the Work Item ID to the PR title or description using the "Edit" option in the format below: 🟢 Once added, the validation will automatically run again! |
User description
Description of Changes
Add In-App Message Interceptor API OptimoveInApp.setInAppMessageInterceptor(_:) to allow apps to control when in-app messages are shown or suppressed based on custom logic. If no decision is made within the timeout (default 5s), the message is automatically suppressed.
Breaking Changes
Release Checklist
Prepare:
pod lib lintpassesBump versions in:
OptimoveCore.podspecOptimoveNotificationServiceExtension.podspecOptimoveSDK.podspecOptimoveCore/Sources/Classes/Constants/SDKVersion.swiftREADME.mdCHANGELOG.mdUpdate major version numbers in wiki (basic integration + push guides)
Integration tests
T&T Only
Mobile Only
Deferred Deep Links
Combined
Release:
pod trunk pushto publish to CocoaPodsPost Release:
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Introduce a new In-App Message Interceptor API,
OptimoveInApp.setInAppMessageInterceptor(_:), allowing applications to control the display or suppression of in-app messages based on custom logic. Refactor theInAppPresenterto integrate this interception mechanism, ensuring robust and thread-safe handling of message presentation and queuing.OptimoveInApp.setInAppMessageInterceptor(_:)API, enabling custom logic to decide whether to show or suppress in-app messages, with a default 5-second timeout for decision. This includes addingInAppMessageInterceptorandInAppMessageInterceptorDecisionprotocols, and integrating the interception flow withinInAppPresenterby introducing anInterceptionDecisionclass and methods likeapplyMessageInterception,handleShowDecision, andhandleSuppressDecision. Additionally, refactor internal message handling inInAppPresenterto useensureMainandassertOnMainThreadfor improved thread safety and clarity, removing themessageQueueLocksemaphore.Modified files (2)
Latest Contributors(2)
6.2.6to6.3.0across all relevant podspec files and theSDKVersion.swiftconstant, and document the new In-App Message Interceptor API in theCHANGELOG.md.Modified files (5)
Latest Contributors(2)