Remove platform-conditional API definition in favor of "unsupported" error code #30
Comments
Firehed
added a commit
that referenced
this issue
Jul 28, 2024
As noted in #29, the initial design of the autofill interactions used a delegate-based system, rather than async/await like the modal APIs. This was based on an incorrect assumption (carried over from web, where it may also be flawed) on how promises resolve. Upon further experimentation, it seems perfectly fine and non-problematic to have a promise that might take minutes to resolve and not have it block other interactions. This (breaking) change adjusts the autofill API to also use async/await instead of delegates. Client code is a lot more straightforward, and the internals become more reliable since a bunch of conditional paths are eliminated. In the same vein, I've also added a new `.unsupportedOnPlatform` error code so that clients can have fewer availability checks, part of #30. The API as a whole is still `#if`'d to iOS+visionOS, but that will get lifted eventually in a separate PR (see #16).
Merged
Firehed
added a commit
that referenced
this issue
Sep 9, 2024
This adds some centralized hints for platform availability, which should make addressing #30 easier and clearer. For now this is being kept internal, but it's intended to become public in short order.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To make client code simpler, we can internalize the platform checks within the SDK and return an error code on unsupported platforms. Clients can still call it conditionally if it better suits their UI, but this simplifies the common handling.
The text was updated successfully, but these errors were encountered: