feat(ios): add getRequestStatusForAuthorization - #499
Open
touyou wants to merge 2 commits into
Open
Conversation
`hasPermissions` always returns null for read types on iOS because HealthKit
does not expose read-authorization status. This makes it impossible to tell a
first-time request from an already-answered one.
Add `getRequestStatusForAuthorization`, a thin wrapper over HealthKit's
`HKHealthStore.getRequestStatusForAuthorization(toShare:read:)`, which reports
whether the authorization sheet would still be shown (`shouldRequest`) or not
(`unnecessary`). It does not reveal whether read access was granted — HealthKit
never exposes that — but it lets apps branch their permission UX.
- Dart: `Health.getRequestStatusForAuthorization(types, {permissions})` returning
a new `HealthAuthorizationRequestStatus` enum. Returns null on Android.
- iOS: new method-channel handler mirroring `requestAuthorization`'s read/write
set building.
- Tests for argument validation, the non-iOS null path, channel forwarding and
enum mapping.
|
Any udpate? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
On iOS,
hasPermissionsalways returnsnullfor read types becauseHealthKit deliberately does not expose read-authorization status to apps
(see #939 and many related reports). As a result, apps cannot tell a
first-time authorization request from one the user has already answered,
which makes it impossible to branch permission UX correctly (e.g. show a
request flow vs. guide the user to the Health app to change an existing
decision).
HealthKit exposes exactly this signal via
HKHealthStore.getRequestStatusForAuthorization(toShare:read:),but the plugin doesn't surface it. This PR adds a thin wrapper.
What's new
Health.getRequestStatusForAuthorization(List<HealthDataType> types, {List<HealthDataAccess>? permissions})returning a new
HealthAuthorizationRequestStatusenum(
shouldRequest/unnecessary/unknown). Returnsnullon Android.getRequestStatusForAuthorizationmethod-channel handler inHealthDataOperations, mirroringrequestAuthorization's read/write setbuilding, then calling
getRequestStatusForAuthorization(toShare:read:)andmapping
HKAuthorizationRequestStatus.nullpath, channel forwardingand enum mapping.
Important caveat (documented in the API)
This reports whether the authorization sheet would still be shown, not
whether read access was granted — HealthKit never exposes read-grant
status. The dartdoc states this explicitly so callers don't misuse it as a
"is read allowed?" check.
Backward compatibility
Purely additive. No existing API changes. Android behaviour is a no-op
(
null), guarded on the Dart side so no platform channel call is made there.