Skip to content
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

Merged
merged 30 commits into from
Jun 20, 2024
Merged

Merge staging into main for Core v3.1.0 #686

merged 30 commits into from
Jun 20, 2024

Conversation

prudrabhat
Copy link
Contributor

Description

Merge staging into main for Core v3.1.0
Key Changes:

How Has This Been Tested?

  • Unit + functional + integration tests
  • Manual smoke tests against Snapshot

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

prudrabhat and others added 25 commits June 10, 2024 16:15
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
Merge `dev` into `staging` for `Core v3.1.0`
prudrabhat and others added 3 commits June 20, 2024 12:01
Switch Event extension functions to properties
Merge `staging` with `dev` for a patch
Copy link

codecov bot commented Jun 20, 2024

Codecov Report

Attention: Patch coverage is 92.85714% with 2 lines in your changes missing coverage. Please review.

Project coverage is 71.36%. Comparing base (79487fa) to head (449a92b).
Report is 2 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (79487fa) and HEAD (449a92b). Click for more details.

HEAD has 1 upload less than BASE | Flag | BASE (79487fa) | HEAD (449a92b) | |------|------|------| |unit-tests|4|3|
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     
Flag Coverage Δ
functional-tests 27.64% <3.57%> (-0.07%) ⬇️
unit-tests 67.44% <89.29%> (-1.46%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
...keting/mobile/services/ui/common/AEPPresentable.kt 94.71% <100.00%> (+0.55%) ⬆️
...g/mobile/services/ui/message/views/MessageFrame.kt 94.29% <100.00%> (+0.08%) ⬆️
...java/com/adobe/marketing/mobile/util/EventUtils.kt 80.00% <80.00%> (ø)
...ne/java/com/adobe/marketing/mobile/MobileCore.java 63.70% <83.33%> (+0.66%) ⬆️

... and 13 files with indirect coverage changes

@prudrabhat prudrabhat merged commit ed8f87a into main Jun 20, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants