Scheduling tracking refactoring and unique ids

aurimasc commented 2 years ago

Changes:

Notification ID generation moved to Java and changed to ensure ids are unique (https://jira.unity3d.com/browse/MNB-5); previously we relied on random ids, but there was a risk of duplicate ids
Scheduling using Notification.Builder API had no way of getting the id; new API method added that returns the generated id in an out parameter
Instead of having a separate scheduled notification Map in manager with synchronization and id set in thread now have a concurrent Map that is shared between both; also map now holds Notification.Builder instead of built Notification
Ensure alarms are cancelled on notification delivery
Added a couple of automated tests for notification status after it was dismissed

Notes to QA:

Android only
No changes related to various notification types
Basic sending/scheudling/status reporting works
Tried scheduling hundreds of notification and could no longer reproduce id duplication (previously it wasn't all that hard)
Devices used for testing:
- Nokia 7 Plus (10.0)
- Samsung Galaxy S7 (7.0)
To test:
- the same drills as in https://github.com/Unity-Technologies/com.unity.mobile.notifications/pull/195
- worth to check that all APIs that are supposed to generate ID do generate it (there are three in total, all called SendNotification, one AndroidNotification and returns generated ID, one takes AndroidJavaObject (builder) and gives id in an out parameter, third one just the builder, does not give the id out, I guess this one can be skipped)

vaidasma commented 2 years ago

One PR specific issue found: Samsung S8 is unable to send notifications due to android.content.res.Resources$NotFoundException

aurimasc commented 2 years ago

Unity-Technologies / com.unity.mobile.notifications