Bug 8272 - AudioRouteChange events are very difficult to handle
Summary: AudioRouteChange events are very difficult to handle
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 5.3.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-11-07 17:45 UTC by adam.lickel
Modified: 2013-01-23 09:31 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description adam.lickel 2012-11-07 17:45:56 UTC
Specifically, we receive a dictionary as an IntPtr.
None of the keys are publicly bound to C# constants.
Some of the newer keys are extern C strings normally, so their values are not officially documented.

In order to handle pulling out the headphones it's necessary to evaluate the change reason as well as the old output route.

On iOS 4 and below there's a string route.
On iOS 5+ there's two arrays that map directly to AudioSession.OutputRoutes.

Ideally, I'd like either:

* bindings to all of the keys to evaluate the dictionary as well as to generate AudioSessionOutputRouteKind enums
* a discrete object with bindings for these values (potentially with access to the underlying NSDictionary for future-proofing purposes)

If bindings are provided, it would probably be cleaner to have a discrete event than to use the existing PropertyListener handling directly.
Comment 1 Miguel de Icaza [MSFT] 2012-11-12 13:15:35 UTC
Hello Adam,

I do not see an AudioRouteChange event, can you point me to where you are getting this IntPtr?
Comment 2 adam.lickel 2012-11-12 13:55:45 UTC
It's a PropertyListener callback.
The C# key is AudioSessionProperty.AudioRouteChange.

The callback's parameters are the property key, the size of the data, and a `data` pointer.
For this particular property, it returns an NSDictionary.
Comment 3 Miguel de Icaza [MSFT] 2012-11-12 15:07:26 UTC
Hello Adam,

Thanks for sharing.

We will take a look at this;   Right now I am leaning towards a strongly typed listener for each property, it is a shame that the Apple docs are pretty bad when it comes to which properties actually contain data on the callbacks.
Comment 4 Miguel de Icaza [MSFT] 2013-01-20 10:51:34 UTC
The APIs to review include:

AudioSession: AddListener(), RemoveListener

There are two options to expose this functionality:

We add new overloads to AddListener (...), one for each possible AudioSessionProperty enum value, or we add C# events that take EventArgs for each kind of property change.

I am prototyping the C# events version.
Comment 5 Miguel de Icaza [MSFT] 2013-01-23 09:31:24 UTC
Implemented + sample;   Will be available in the next stable release (after 6.0.9)
Comment 6 Miguel de Icaza [MSFT] 2013-01-23 09:31:33 UTC