[tonytonycoder11]

On iOS and macOS the plugin made itself the app's notification delegate as soon as the app launched, in every build, even when the app never started Flutwire. An app that keeps Flutwire in its production build with init switched off, which is the only option when just some flavors should record, had its notification handling routed through the plugin without asking for it.

Now the plugin does nothing until Flutwire has run in that build. initialize, which Dart calls only when Flutwire is recording, adopts the delegate and writes the version and build number of the app. At the next launch of the same build the plugin adopts the delegate at registration, so that a tap on the notification after the app was killed still finds it in place. A notification can only exist if Flutwire ran before, so nothing is lost. A build that never starts Flutwire never writes the mark and never touches the delegate.

It also forwards userNotificationCenter(_:openSettingsFor:) to the delegate it replaced. The plugin passed on the other two delegate calls and dropped this one.

I checked it on the iOS simulator with the example app and a probe that logged UNUserNotificationCenter.current().delegate:

• Fresh install with Flutwire off: the delegate stays nil, nothing is written to disk.
• Same install with Flutwire on: the delegate becomes the plugin and the mark is written.
• Same build launched with Flutwire off afterwards: the plugin adopts the delegate early, because the mark is there. That is the one case left, a device where that very build ran Flutwire before.

The example also builds for macOS. Android was already idle until Dart asks: it creates a channel and waits.

The package README gets a short section on recording in test builds only.

Targets 0.2.0.

[trueup-by-nacode-studios]

This pull request adds no capability the code did not already have.

_{4 files read · 2642 ms · against 36d8943 · engine 1.4.1}