SignInActivity in connect-id-example stacks multiple instances

[rasmusohrstig]

In the example package connect-id-example the Activity holding the ConnectLoginButton is called SignInActivity.

When you sign in and sign out multiple times the Task that SignInActivity belongs to gets stacked up with multiple instances of SignInActivity. This means that you have to use the back button multiple times in order to exit the app.

You can fix this by changing the launch mode of SignInActivity to (the somewhat confusingly named) "singleTask". This means that there will never be more than one instance of SignInActivity in the task used by SignInActivity.

So in AndroidManifest.xml replace this: <activity android:name=".SignInActivity" > With this: <activity android:name=".SignInActivity" android:launchMode="singleTask" >

[rasmusohrstig]

If you want to use this solution with Chrome custom tabs it will no longer work if you let the Chrome custom tab open SignInActivity. You have to move the intent filter to some other Activity, for example SignedInActivity like this:

<activity android:name=".SignedInActivity" >
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
     </intent-filter>
     <intent-filter>
         <data android:scheme="@string/connect_redirect_uri_scheme" />
         <action android:name="android.intent.action.VIEW" />
         <category android:name="android.intent.category.DEFAULT" />
         <category android:name="android.intent.category.BROWSABLE" />
     </intent-filter>
</activity>

[rasmusohrstig]

I just realized that this does not work. The ConnectLoginButton does a check that its Context's IntentFilter matches the redirect Uri. If we try to redirect to SignedInActivity the ConnectLoginButton decides to use ConnectActivity instead of Chrome custom tabs.

This means that we can only use Chrome custom tabs along with a ConnectLoginButton if we redirect back to the same Activity that the ConnectLoginButton is part of.

Is there a reason for the requirement that we must redirect back to the same Activity that the button is part of?

How can we avoid having the SignInActivity stack up over multiple sign in - sign out cycles?

[jorunfa]

Hey again, thanks for reporting this problem. The reasoning behind this checking is to make sure the user will be redirected properly back to the app once he has been authenticated, with Chrome Custom Tabs. As the older versions did not require you have any intent-filter the idea was to fallback to native WebView from ConnectActivity if it was missing. Will try to find you a solution.

[rasmusohrstig]

Hi,

Thanks for the explanation. It makes sense to fall back on the ConnectActivity if there is something wrong with the setup. As a developer and user of the SDK I would personally prefer to have to catch an exception and initiate the fallback mechanism myself. But that is just my preference. The automatic fallback also works ok.

I think the requirement that decides if the callback Uri is acceptable can be made less strict. If we want to make sure that the web view redirects back to the app the requirement could be that the Uri must resolve to a package with the same package name as the calling Context package name.

Instead of this: return context.getClass().getName().equals(componentName.getClassName());

We could do this: return context.getPackageName().equals(componentName.getPackageName());