Bridge-1684 call becomeFirstResponder with dispatch to main queue aft… #65
Conversation
…er delay to prevent invisible keyboard when user hits ‘cancel’ in touch ID context
| @@ -369,7 +369,17 @@ - (void)promptTouchId { | |||
| }]]; | |||
| [strongSelf presentViewController:alert animated:YES completion:nil]; | |||
| } else if (error.code == LAErrorUserCancel) { | |||
| [strongSelf makePasscodeViewBecomeFirstResponder]; | |||
|
|
|||
| // call becomeFirstResponder here to show the keyboard. dispatch to main queue with | |||
There was a problem hiding this comment.
Is the delay really necessary? From the documentation on evaluatePolicy:localizedReason:reply:, the reply block (i.e. this code) "[...] is evaluated on a private queue internal to the framework in an unspecified threading context", so I would expect odd behavior if you tried to set the first responder from here (UIKit not being thread-safe and all). Does dispatching async to the main queue without a delay not suffice?
ETA: Just noticed it dispatches sync to main at the top of the block--so the question becomes, does dispatching async there fix it? I can't see any reason this needs to happen synchronously from the private queue since we have no idea when that will happen anyway.
There was a problem hiding this comment.
@joshbruhin What do you think? Thanks!
There was a problem hiding this comment.
Yes, I did dispatch without delay and it worked. I added a delay only because I thought it might be safer and and it seemed to make for a smoother transition. Based on what you read, it seems it makes no difference from a reliability perspective.
…er delay to prevent invisible keyboard when user hits ‘cancel’ in touch ID context
ResearchKit#915