Add bridgeable UIApplication.shouldShowPermissionRationale(_:) - #498
Open
vincentborko wants to merge 1 commit into
Open
Add bridgeable UIApplication.shouldShowPermissionRationale(_:)#498vincentborko wants to merge 1 commit into
vincentborko wants to merge 1 commit into
Conversation
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
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.
Add a bridged
UIApplication.shouldShowPermissionRationale(_:)Motivation
UIApplication.requestPermission(_:showRationale:)already consultsActivityCompat.shouldShowRequestPermissionRationale, but that overload cannot bebridged — as noted in the source today:
So a natively-compiled SkipFuse app has no way to ask whether the next permission
request will actually put a dialog on screen. Android offers no readable
"undetermined" state —
checkSelfPermissionreturnsDENIEDboth for "never asked"and for "declined" — so reconstructing that distinction requires the rationale bit,
and today the only route is hand-rolled JNI reflection into the Activity.
Change
A closure-free, bridgeable accessor next to the existing request methods:
It returns
falseboth for "never requested" and for "permanently denied"; the doccomment says so, since callers that need to separate those must combine it with their
own record of having asked. That mirrors the semantics Android itself exposes rather
than inventing a richer state.
Bridging decision
A plain
String -> Boolmethod, so it crosses the bridge unchanged. Deliberately notan overload of the existing
requestPermissionfamily: the useful call happensbefore a request, and the existing
showRationalecallback fires during one andonly when a rationale is warranted, which cannot express the pre-request question.
Testing
swift testgreen — 92 tests, 0 failures, native XCTest plus the transpiled Kotlinsuite under JUnit in the same run.
Verified the new API reaches the generated Kotlin as
open fun shouldShowPermissionRationale(permission: String): Boolean.Verified the
@bridgeannotation produces the expected entry in the generatedUIApplication_Bridge.swiftof a consuming natively-compiled SkipFuse app:That app's Gradle
assembleDebugis green against it.Note that the bridged call goes through JNI like the rest of the bridge, so callers
still need to be on the main actor; this removes the need for hand-rolled reflection,
not the isolation requirement.