-
Notifications
You must be signed in to change notification settings - Fork 24
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
Merge staging
into main
for Core v3.1.0
#686
Conversation
The InAppMessage WebView is hosted inside a Card container. By default the Card background color is grey. This is causing unintended results(grey bg being seen) for in-app messages where dimensions are set to fill the entire screen but the content only occupies a portion of it. As a soution, set the container Card's background color to Transperent as with the WebView.
Set in-app web view container background to be transparent
Currently, the ComposeView attached to the Activity when presentables are shown is not removed until the activity is destroyed. This is OK for most use-cases that follow the sigle window mode where the newly resumed activity obscures the previous one, and the presentable redraws on the new activity. However, this approach of waiting until the activity is destroyed may result in the presentables being shown on each activity in a multi-window side-by-side mode. While we do not support multi-window mode, we should ensure that the experience does not deteriorate in such a case. As a solution, change the current detachment logic to to the following: - Track the current activity that the presentable is attached to - When presentable is visble on Activity A and another activity B resumes, use the Android activity co-ordination guarantees to detach presentable from Activity-A and re-attach to Activity B - Reset the reference held to the activity that the presentable is attached to when the activity is destroyed.
The SDKs often needs to change its standard business logic to enable debugging/testing workflows. We need an event structure that external systems can follow to generate an event that communicates to the listening SDK extension that it should operate in a debug mode - a mode outside of expected production behavior if one exists. This commit adds an eventSource "com.adobe.eventSource.debug" to identify such events. Further, it adds utility methods to identify the eventType and eventSource provided within the `data.debug` content of such events.
Moved event data extraction logic to a common place.
Detach presentables before re-attaching to top Activity
Do not initialize SDK in direct boot mode
Add support for debug events
Update versions [Core-3.1.0]
Merge `dev` into `staging` for `Core v3.1.0`
Switch Event extension functions to properties
Merge `staging` with `dev` for a patch
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #686 +/- ##
=============================================
- Coverage 81.55% 71.36% -10.19%
+ Complexity 2134 1873 -261
=============================================
Files 191 192 +1
Lines 8906 8933 +27
Branches 1110 1116 +6
=============================================
- Hits 7263 6375 -888
- Misses 1089 2093 +1004
+ Partials 554 465 -89
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Description
Merge
staging
intomain
for Core v3.1.0Key Changes:
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: