fix: address hot reloading issues

[fadi-george]

One Line Summary

Closes #763

• fixes minor formatting issues and improves the logic for handling hot restarts on Android and iOS

Details

• use singelton pattenrs for most of the class instances (User, Notifications)
• then in lifecycle inits we remove the old observers

Hot Restart Bug for iOS:

flutter-main-ios-bug.mov

Hot Restart Bug for Android:

flutter-main-android-bug.mov

Hot Restart Fix for iOS:

flutter-hotrestart-fix-ios.mov

Hot Restart Fix for Android:

flutter-hotrestart-fix-android.mov

Motivation

• addresses [Bug]: OneSignal#onWillDisplayNotification getting called as many times as app gets hot restarted while debugging. #763 when the app is hot reloaded for ios or android

Manual testing

• install flutter extension
• you can use vscode / cursor (call action Flutter: Launch Emulator)
• select ios or android device
• go the example/lib/main.dart file then start debugging (you may need flutter extension)

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 

[nan-li]

Hmm I'm concerned about adding complexity for a dev-only scenario. Idk if there are any production side effects? Do you know if some lifecycle callbacks like onDetachedFromEngine could work instead?

[fadi-george]

Hmm I'm concerned about adding complexity for a dev-only scenario. Idk if there are any production side effects? Do you know if some lifecycle callbacks like onDetachedFromEngine could work instead?

These just creates singletons and its a similar approach to what we did for react-native. hot-restarts (which is what the issue is about) doesnt trigger onDetachedFromEngine.

[nan-li]

The changes won't just apply to hot reload, but lifecycleInit() is called whenever clients call OneSignal.initialize("their_app_id"). Have we tested more flows not just for reload?

Did you test clicking from cold start?

nit: Add a comment explaining why this pattern is needed (for future maintainers who might question it)

[nan-li]

not exactly related to this PR, but should the click listener also go in lifecycle init? may be related to the click cold start issues

[fadi-george]

I guess the click listener is opt in so probably best not to mess with this behavior.

[nan-li]

All listeners are opt in