Major refactoring of how notification scheduling and cleanup is performed:
A dedicated thread is created to offload work from main thread and not create ad-hoc threads for housekeeping
Notification scheduling now submits a task to queue and is done on other thread, because it's not so cheap process
We had clashes between threads if scheduling or canceling happened at the same time as we performed housekeeping (cleanup of old stuff) on other thread; now all these tasks are performed on a separate dedicated thread, so minimize thread clashes
rather than loading saving a set of notification ids each time when scheduling or canceling, a set of ids is maintained in a worker thread and is saved on changes; this should speedup batch scheduling, since we now avoid excessive saves of ids
Couple of unrelated changes:
Noticed that if ShowInForegroud is false on pre-M (<6.0) devices would report notification status as scheduled after it's delivery, fixed
Removed the Samsung specific thing with 500 alarms; now simply handle an exception, so everything works the same, except that now it expands to other devices and if Samsung removed or increased this limitation, we adapt out of the box
Note to QA:
Android only
Changes only affect scheduling or canceling, no need to check different types of notification content
Aside from mentioned pre-M change this PR is not specific to Android version
Since the changes are multi-threading related, advise is to try some high-end and some crappy slow device
Tested by me:
attempt to schedule over 500 notifications on Samsung still works the same - schedules 500, the rest fail, only now you see exceptions is logcat with OS message (used Galaxy S7 7.0)
automated tests pass in Yamato and locally no Nokia 7 Plus
Scheduling 150 notifications is ~3 times faster on Nokia 7 Plus; the performance measured before landing the PR with perf optimisations (JNI stuff), so compared to public package version should be even more
Testing drills required:
schedule notification for the future and see if it arrives whatever you do in between (app in background or closed, open again etc.); just note, that on some devices we already had issues with killing, so in case of problems compare against pre-PR version
schedule batches, cancel some
try reschedule after device reboot
basically, try to break it (get notification not scheduled or not canceled)
I only have a project for perf testing, but it's a simple for loop with Stopwatch :)
Major refactoring of how notification scheduling and cleanup is performed:
Couple of unrelated changes:
Note to QA: