On iOS 11, there seems to be something different in the app state when an app is backgrounded using the home button vs when it opens an external webview link and goes to safari.
On returning to my app, I am requiring the user to validate with touch ID. If the app is backgrounded using the home button and returns, the call to LAPolicy.deviceOwnerAuthenticationWithBiometrics shows a prompt and waits for the user interaction. However, the user goes to an external website through a link in the app, and returns to the app using the "Back to app" button that shows in the status bar, a call to LAPolicy.deviceOwnerAuthenticationWithBiometrics results in an error immediately without displaying the touch ID prompt.
I've checked that the application state in both cases when the call is made is that the app is active. It's being done on the main thread, and it's being made on applicationDidBecomeActive.
This is the error I see:
Error Domain=com.apple.LocalAuthentication Code=-1004 "User interaction is required." UserInfo={NSLocalizedDescription=User interaction is required.}`
Any insights into the behavior of LAPolicy.deviceOwnerAuthenticationWithBiometrics? The code used to call it is:
let context = LAContext()
context.localizedFallbackTitle = ""
print("--> internalAuthenticateBiometrics background \(UIApplication.shared.applicationState == UIApplicationState.background)")
context.evaluatePolicy(LAPolicy.deviceOwnerAuthenticationWithBiometrics, localizedReason:NSLocalizedString("Place your finger to sign in.",comment: "")) { [weak self] (success, error) in
print("--> internalAuthenticateBiometrics completion success \(success) error \(error)")
}
We discovered that this specific issue was happening on older versions of iOS 11. We were testing on devices that had iOS 11.0.3 and 11.1.2. I updated my OS to 11.4 and the issue went away.
As of right now, I can only assume that Apple fixed some app foregrounding and biometrics issues. FYI this issue didn't have anything to do with the views being backgrounded or covered, because we made sure everything was visible, appDidEnterForeground was called, viewDidAppear was happening, and we even added delays in triggering biometrics after several seconds.
Related
I'm currently working on an issue with a Microsoft Edge Add-In written in React in which state changes aren't working, and I can't see any of my console logs.
Some context:
I have a web Add-In for Microsoft Outlook desktop that I am trying to run on Windows 10 version 1903. I've added console logs to the event handlers of a few button clicks and several other events throughout the app, but none of these console logs actually show up in the Microsoft Edge DevTools console. I can see calls to console.log('We just clicked a button') in the compiled JavaScript file in the Debugger, so my changes are being picked up and are in fact there, but no actual console logs show up inside of the DevTools console. The only error I see in DevTools is XML5632: Only one root element is allowed on index.html (1, 1).
I should note that the web Add-In works in Microsoft Outlook desktop on later versions of Windows 10, but running it on version 1903 is the only time that it's problematic.
An answer on this forum: https://www.outsystems.com/forums/discussion/20753/xml5632-only-one-root-element-is-allowed-error-on-windows-edge/#Post88600 suggests it's a problem with Edge interpreting an Ajax call as XML, but doesn't elaborate much more beyond that.
My guess is that this a JavaScript issue with pre-Chromium Edge, but I'd like to know if anyone has any suggestions on a workaround or fix so that I can 1.) Resolve the issue with the state change in my React app and 2.) See my console logs.
Not sure if anyone had this problem, since I could not look it up anywhere but I cannot see any logs for react native app because the browser console tells me that "Another debugger is already connected" its a warning that keeps looping.
Metro bundler is telling me that I have to see the javascript logs in the browser. I cannot work on my app without debugging it, can anyone help ?
This happens if you have another tab opened at http://localhost:8081/debugger-ui as you can only have one instance of the debugger running.
You could either go back to the already running tab and see the logs there or close the other tab and refresh this one.
I would like to close the threads or clear cache if the App crashes or Phone switch off or some other abrupt actions. Please advise if this method only gets called when the user kill the App or Signout from the App.
I'm pretty sure stop() gets called when you force kill the app, switch apps, lock the screen, phone auto locks, or anything really where the app is no longer visible.
You can also check edge cases by connecting your Android (in dev mode) to your laptop, downloading platform-tools (logcat), adding a print statement inside the stop() function and using the following command "./adb logcat -s "System.out" inside the platform-tools directory. Not sure how to do it on iOS.
I am trying to achieve same results that can be seen on 29:52 second of Enhancing VoIP Apps with CallKit - WWDC 2016.
In that video it shows that after answering call the buttons are moved and changed by animation, and the screen stays in native in-call UI.
I built the Speakerbox and tried the "Simulate Incoming Call" function, but as soon as the call is answered by answer call button (the same action that is shown on video), the native call screen disappears and the application screen is shown with active calls shown in the list (which is different from what is shown in WWDC video):
Though there is a native call UI screen for very short time during transition from Incoming Call native UI to the app, but I can't find how to force it to stay on that screen.
Debugging the Speakerbox app there is no any delegate method called until all native screens are disappeared and the app is already opened.
I have tested receiving incoming call when the screen is locked, in that case the native UI is shown:
I would like to achieve same result on non locked phone.
Simply you can't keep native UI after accept incoming call, at least in iOS 10, maybe in iOS 11 Apple give a way to keep native UI.
If you lock the phone and then receive an incoming call, you will have similar experience to what you saw on WWDC. There is no a way to change this behavior in iOS 10.
We have a Silverlight application that runs OOB (out of browser) so the user can install it. When it's running OOB we display a button that calls Application.Current.MainWindow.Close() so that the user can exit the application. This works perfectly fine on windows, but causes an error saying the application has quit unexpectedly on OS X. Anyone have any ideas why this might be? Thanks!
Found out the problem. This is apparently a "protected" action and must be done directly in response to a user action. It cannot be scheduled to happen later (we were playing an animation on the button click and then after a timer expired trying to close the window; we have to just close the window).
An exception was actually thrown on the windows version, it just never displayed any sort of message box.