Updated Demo to NS 5.4 (still functions same as before)
Changed the references.d.ts to use the android-23 since the fingerprint API is only Android23+
Removed the const class = ... declarations on Android as these can cause snapshot to fail. Better to use the full namespace.file.class when accessing the classes in Android plugins. At least that was the case a few months ago and I believe it's still the same. You can take a different approach and call them via a function but I think that's a big uglier than just declaring the full namespace.
Closed #50 by implementing the isKeyguardSecure check inside the available method. If the keyguardSecure method returns true and the device supports fingerprint API (since this plugin is fingerprint-auth at minimum) the available method will resolve({ any: true, touch: false})
From that resolve on the available method, the developer can choose to call verifyFingerprint or not. If they only use the result.any to check for some security setting then the fingerprint method will end up presenting the user with the device credential activity and continue functioning with all normal behavior except the device doesn't have fingerprints enrolled so the user cannot authenticate with the fingerprint, only their device security setting.
This might be the behavior of using the verifyFingerprintWithCustomFallback on iOS. I'm not 100% on its purpose or implementation at the moment. However, now Android seems to have the option to let the developer have some sort of fallback if the fingerprint is not an option 👍.
Sorry for the formatting changes, I didn't realize that until I made the PR. I run prettier locally so it's just their defaults on breaks, spacing, etc.
I did add some types in the android source code to help with intellisense. iOS source didn't actually undergo any source code changes at this time. However, I have run into a case where the user can lock the Biometrics out and I've checked that locally in my app to let the user know, so maybe I'll think of a PR for that in future.
references.d.ts
to use theandroid-23
since the fingerprint API is only Android23+const class = ...
declarations on Android as these can cause snapshot to fail. Better to use the full namespace.file.class when accessing the classes in Android plugins. At least that was the case a few months ago and I believe it's still the same. You can take a different approach and call them via a function but I think that's a big uglier than just declaring the full namespace.isKeyguardSecure
check inside theavailable
method. If thekeyguardSecure
method returns true and the device supportsfingerprint
API (since this plugin is fingerprint-auth at minimum) theavailable
method willresolve({ any: true, touch: false})
From that resolve on theavailable
method, the developer can choose to callverifyFingerprint
or not. If they only use theresult.any
to check for some security setting then the fingerprint method will end up presenting the user with the device credential activity and continue functioning with all normal behavior except the device doesn't have fingerprints enrolled so the user cannot authenticate with the fingerprint, only their device security setting.This might be the behavior of using the
verifyFingerprintWithCustomFallback
on iOS. I'm not 100% on its purpose or implementation at the moment. However, now Android seems to have the option to let the developer have some sort of fallback if the fingerprint is not an option 👍.Sorry for the formatting changes, I didn't realize that until I made the PR. I run prettier locally so it's just their defaults on breaks, spacing, etc. I did add some types in the android source code to help with intellisense. iOS source didn't actually undergo any source code changes at this time. However, I have run into a case where the user can lock the Biometrics out and I've checked that locally in my app to let the user know, so maybe I'll think of a PR for that in future.