The Android Calendar API implementation could automatically request Marshmallow permissions as needed, the way iOS does (likely using @jamesmontemagno's Permissions Plugin). However, the way permission requests are handled would mean that you could no longer wait on methods synchronously from the UI thread (via .Wait() or .Result).
Not that I want to encourage such patterns, but I think .NET programmers would at least expect those methods to work correctly without deadlocking, and I am reluctant to remove this ability. Especially when app developers have the ability to simply use James' plugin themselves before invoking Calendar methods...
[Some details: The reason Wait/Result deadlock is that the Android permission request model requires receiving a callback on the UI thread. James' plugin abstracts the handling of this callback so that you can just await one function, but that's still what's happening behind the scenes, so if the UI thread is blocked the permission request can never complete.]
[Further trivia: the original Android implementation of the Calendars plugin used a more "modern" callback-based API, but was rewritten to call the older synchronous API on background threads due to this same issue.]
The Android Calendar API implementation could automatically request Marshmallow permissions as needed, the way iOS does (likely using @jamesmontemagno's Permissions Plugin). However, the way permission requests are handled would mean that you could no longer wait on methods synchronously from the UI thread (via .Wait() or .Result).
Not that I want to encourage such patterns, but I think .NET programmers would at least expect those methods to work correctly without deadlocking, and I am reluctant to remove this ability. Especially when app developers have the ability to simply use James' plugin themselves before invoking Calendar methods...
[Some details: The reason Wait/Result deadlock is that the Android permission request model requires receiving a callback on the UI thread. James' plugin abstracts the handling of this callback so that you can just await one function, but that's still what's happening behind the scenes, so if the UI thread is blocked the permission request can never complete.]
[Further trivia: the original Android implementation of the Calendars plugin used a more "modern" callback-based API, but was rewritten to call the older synchronous API on background threads due to this same issue.]