-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return AuthenticationCallback results on the UI thread (if the AT/ATS call was invoked there) #1094
Conversation
@@ -320,12 +328,14 @@ private void callAcquireTokenSilent(final String resource, final String userUniq | |||
|
|||
@Override | |||
public void onSuccess(AuthenticationResult authenticationResult) { | |||
verifyThread(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
furthermore, in the method body of "showMessage", could we use something similar to:
runOnUiThread(new Runnable() {
@OverRide
public void run() {
Toast.makeText(MainActivity.this, msg, Toast.LENGTH_LONG).show();
}
});
thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the repro and the detailed test cases. These are super helpful. Currently, it seems to be a 100% repro bug on Callback and we definitely need to deliver a fix before more customers encountering this issue.
Just an open suggestion, as we are not going to merge this PR into the release branch. I think it could be better to add the fix of this issue, like using "runOnUiThread" besides logging.
I will leave the priority to @nazukj and @addev-ashish .
immmediate use. Detect if call is on the UI thread: if they are, create a Handler for that thread. If they are not: create an arbitrary Handler and let the caller sort out the threading.
@heidijinxujia @piqiums See commit ae859af This commit conditionally creates the |
Alternatively, if the memory issue is a concern, we could consider running the following implementation through the tests and seeing how it fares private static Handler mUiThreadHandler;
private static Handler mBackgroundHandler;
private static Handler mUiThreadHandler;
private static Handler mBackgroundHandler;
private synchronized Handler getHandler() {
final Handler handler;
if (onUiThread()) {
if (null == mUiThreadHandler) {
// Callback should be invoked on the UI thread.
mUiThreadHandler = new Handler(Looper.getMainLooper());
}
Logger.v(TAG, "Using UI thread Handler.");
handler = mUiThreadHandler;
} else {
if (null == mBackgroundHandler) {
// We're on a background thread, so the handler can be anything...
HandlerThread acquireTokenHandlerThread = new HandlerThread("AcquireTokenRequestHandlerThread");
acquireTokenHandlerThread.start();
mBackgroundHandler = new Handler(acquireTokenHandlerThread.getLooper());
}
Logger.v(TAG, "Using arbitrary thread Handler.");
handler = mBackgroundHandler;
}
return handler;
} |
Not a priority right now - no cycles to run stress test. Closing. |
See issue raised by #1076
This PR does not fix the issue, but adds logging to accompany newly created test cases for this problem.Edit - PR has been updated to resolve #1076 (see commit ae859af)