Wait for activity to be set rather than immediately return in waitUntilSystemConditionsAvailable

[brismithers]

Description

One Line Summary

Wait for activity to be set rather than immediately return in waitUntilSystemConditionsAvailable

Details

IApplicationService.waitUntilSystemConditionsAvailable is used by the InAppMessagesManager when attempting to display an IAM, to ensure the IAM can be displayed based on system conditions. If triggering of an IAM occurs during the foreground process, it's possible for evaluation to happen prior to the activity being started. And when this happens, the IAM will not be displayed.

An example of code that can drive this behavior pretty frequently is below, the key is to add a trigger (which drives IAM evaluation/display) early in the foregrounding process:

OneSignal.getNotifications().addClickListener(event ->
{
       OneSignal.getInAppMessages().addTrigger("key1", "value1");
});

This updates waitUntilSystemConditionsAvailable to wait up to 5 seconds for an activity to be set before determining the system conditions will never be available. This gives any other threads (such as the main thread) to appropriately start the activity. Note that if waitUntilSystemConditionsAvailable is called on the main thread, we do not wait the 5 seconds for the activity to become set, as it cannot happen given onActivityStarted is called on the main thread.

Motivation

Reliability to show IAMs in all scenarios

Scope

This functionality is limited to whether to an IAM can be displayed to the user, based on the current application state.

Testing

Unit testing

2 additional tests were added against waitUntilSystemConditionsAvailable to validate setting the activity within the 5 second limit, and outside of the 5 second limit.

Manual testing

Ran the example app on an Android emulator with the example code above. It does not hit the condition every time, but using additional logging I was able to confirm waitUntilSystemConditionsAvailable will successfully wait (and time out) if the activity isn't set, or wait and pick up the newly set activity.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is