AudioSession.instance creates new listeners or instance every time called on iOS about audio_session HOT 7 CLOSED

Fixed in 0.0.9

from audio_session.

Oh, you're right!

Both addObserver and removeObserver are tied to the plugin instance. What should happen is that initWithRegistrar and dealloc should both look at sessions.count and only call addObserver if this is the first session being created, and only call removeObserver if this is the last session being deallocated.

from audio_session.

Not to mention that dealloc probably doesn't get called since each instance is retained in the sessions array. Probably the array of sessions needs to be __weak.

from audio_session.

Unfortunately my obj-c knowledge is very limited or almost non-existant so I have little there.... But I'm wondering what benefits there are of having multiple instances over one platform instance?

from audio_session.

Plugins that do it that way generally break when they are loaded into apps that use more than one FlutterEngine instance (like audio_service-based apps, or any apps that do background execution).

Basically what should happen in an app that uses multiple FlutterEngines is that each FlutterEngine will have its own plugin registrar, and the plugins will be instantiated anew in each registrar. So the plugin should have an instance of itself loaded in each FlutterEngine, but it is up to the plugin to manage any parts of its state that are to be shared globally between all instances. You'll notice that the only instance data in DarwinAudioSession is the registrar and the channel, which need to be different per instance, while everything else was intended to be shared.

Technically DarwinAudioSession isn't itself the plugin, AudioSessionPlugin is, but the way I designed it is that DarwinAudioSession is kind of like a sub-plugin that behaves in the same way as a plugin. If I ever end up exposing another iOS API aside from AVAudioSession, the intention was that it would also be encapsulated in its own class, and itself behave in the same way as a plugin. That way, AudioSessionPlugin doesn't need to concern itself with how each individual API works.

from audio_session.

Plugins that do it that way generally break when they are loaded into apps that use more than one FlutterEngine instance (like audio_service-based apps, or any apps that do background execution).

Basically what should happen in an app that uses multiple FlutterEngines is that each FlutterEngine will have its own plugin registrar, and the plugins will be instantiated anew in each registrar. So the plugin should have an instance of itself loaded in each FlutterEngine, but it is up to the plugin to manage any parts of its state that are to be shared globally between all instances. You'll notice that the only instance data in DarwinAudioSession is the registrar and the channel, which need to be different per instance, while everything else was intended to be shared.

Technically DarwinAudioSession isn't itself the plugin, AudioSessionPlugin is, but the way I designed it is that DarwinAudioSession is kind of like a sub-plugin that behaves in the same way as a plugin. If I ever end up exposing another iOS API aside from AVAudioSession, the intention was that it would also be encapsulated in its own class, and itself behave in the same way as a plugin. That way, AudioSessionPlugin doesn't need to concern itself with how each individual API works.

Thank you for taking the time to write this. It all makes sense to me now.

from audio_session.

I have fixed the ARC management in the latest commit along with your issue, although fixing the ARC code has revealed a bug in just_audio and forced me to fix it's ARC code, too. I'll need to do some sort of coordinated release so that the new audio_session and just_audio are available at the same time.

I haven't pushed the just_audio fixes yet, so if you try the new audio_session with just_audio now, you'll experience a crash whenever a FlutterEngine is destroyed (when audio_service is stopped).

I might take a look at #7 before doing a release, and will let you know when it is available for testing.

from audio_session.