Support intent: and android-app: url schemes in templates by marcardar · Pull Request #4229 · ankidroid/Anki-Android

marcardar · 2016-04-23T15:47:37Z

marcardar · 2016-04-24T05:08:22Z

Tested against pre-22 (as well as 22+). It is safe to use Intent.parseUri(url, Intent.URI_ANDROID_APP_SCHEME) pre-22.

timrae · 2016-04-24T05:18:28Z

Is there any documentation on that android-app scheme? It'd be nice if there was a cleaner way which was better documented. The docs seem to just recommend using a custom scheme.

marcardar · 2016-04-24T05:26:59Z

The only documentation is here unfortunately.

Definitely the Android team pushes devs away from custom schemes. It looks like Chrome supports custom schemes (less and less) rather than encourages them. That link you included shows the dev how to use an intent: scheme instead of a custom one.

This PR is working really well for me and tested on various API levels. Once AnkiDroid supports intent: and android-app: schemes, I can remove those intent filters from my manifest.

timrae · 2016-04-24T07:51:57Z

That link you included shows the dev how to use an intent: scheme instead of a custom one.

Ooops, sorry I was skim reading. Have you tried using the fallback URL mechanism mentioned in the docs I linked you to?

Also, you may choose to specify fallback URL by adding the following string extra:

S.browser_fallback_url=[encoded_full_url]

If you give it the URL to your google play listing, it should automatically get redirected to the play app on almost all versions of Android I think.

marcardar · 2016-04-24T08:05:53Z

If you give it the URL to your google play listing, it should automatically get redirected to the play app on almost all versions of Android I think.

That works if I click on the link within Google Chrome, but not if the link is in the template. No idea why that should be the case.

When AnkiDroid finds that the resolved intent is not available, it should probably call the fallback URL (if one is set), otherwise use the market:// How does that sound?

marcardar · 2016-04-24T08:08:25Z

Looks like it's already discussed here.

marcardar · 2016-04-24T08:15:55Z

I've just added support for browser_fallback_url. Please check.

timrae · 2016-04-24T08:16:39Z

Did you see the comment about adding BROWSABLE? As I'm sure you know, since Kitkat the Webview is using Chromium so it's supposed to behave the same as Chrome.

timrae · 2016-04-24T08:17:43Z

I've just added support for browser_fallback_url. Please check.

My angle was more to let the Android system deal with the intent in a standard way rather than adding lots of rules to AnkiDroid.

marcardar · 2016-04-24T08:21:14Z

My angle was more to let the Android system deal with the intent in a standard way rather than adding lots of rules to AnkiDroid.

Yeah I agree AnkiDroid shouldn't be doing this unless it has to (as a workaround). Nice spot regarding the BROWSABLE category. I'll try it out now. Although IMO, it seems a little silly to insist that the intent uri MUST include that category (why else would a template include the intent uri?).

Also worth noting that my intent-filter always had both the DEFAULT and BROWSABLE categories included.

marcardar · 2016-04-24T08:31:50Z

BTW, I also tried disabling the custom WebViewClient (by not setting it), to see if the webview would handle the intent uri differently. However, that also does not work. EDIT: this is true only regarding the fallback url.

marcardar · 2016-04-24T08:52:01Z

Oh, actually if you don't set the WebViewClient then the intent: uri is automatically resolved and used. However, it looks like the fallback url is not resolved (Web page note available). I tried this using the zxing examples given in that Chrome link. Note that those intent uris do not include the BROWSABLE category.

So regardless, it looks like we need to resolve these links manually.

marcardar · 2016-04-24T08:59:54Z

I tried adding the BROWSABLE category to the intent uri and that doesn't seem to make any difference compared to not adding it. This is true for when setting the WebViewClient and also when not setting it.

Also worth noting that my intent-filter always had both the DEFAULT and BROWSABLE categories included.

marcardar · 2016-04-24T09:49:56Z

Made small change - remove fallback url from resolved intent (as mentioned here: https://developer.chrome.com/multidevice/android/intents)

marcardar · 2016-04-25T13:14:14Z

AnkiDroid/src/main/java/com/ichi2/anki/AbstractFlashcardViewer.java

+                            }
+                        } else {
+                            // https://developer.chrome.com/multidevice/android/intents says that we should remove this
+                            intent.removeExtra(EXTRA_BROWSER_FALLBACK_URL);


Should we add the Intent.CATEGORY_BROWSABLE here?

timrae · 2016-04-25T13:24:37Z

Can you please remove all the fallback URL stuff? I only suggested adding it as a way to remove the explicit market redirect; if that doesn't work then I prefer to ignore that attribute entirely.

timrae · 2016-04-25T13:25:16Z

AnkiDroid/src/main/java/com/ichi2/anki/AbstractFlashcardViewer.java

+                    if (url.startsWith("intent:")) {
+                        intent = Intent.parseUri(url, Intent.URI_INTENT_SCHEME);
+                    } else if (url.startsWith("android-app:")) {
+                        intent = Intent.parseUri(url, Intent.URI_ANDROID_APP_SCHEME); // note - also works pre-22


Why would this work pre-22? Even if it somehow did work in your tests, the doc says added in 22 so I don't want to use it in production code.

Presumably the constant is inlined at compile time and then parseUri is able to deal with the flag, at least to some extent. Shall I just add a Build.VERSION.SDK_INT if statement?

Weird... Yeah maybe just squeeze it in with url.startsWith("android-app:")

I think we should still parse it, otherwise templates will behave differently on different devices. You can see from the format there is very little difference between intent: and android-app: uris...

Tbh I don't see much point in including support for android-app:

I.e. I think we should just pass those URIs through.

For consistency, it makes sense to treat intent: and android-app: the same. Just like Chrome does.

marcardar · 2016-04-25T14:37:27Z

I've removed the fallback url stuff and improved the android-app: support (including testing on API16).

marcardar · 2016-04-25T14:37:43Z

AnkiDroid/src/main/java/com/ichi2/anki/AbstractFlashcardViewer.java

+                            }
+                        } else {
+                            // https://developer.chrome.com/multidevice/android/intents says that we should remove this
+                            intent.addCategory(Intent.CATEGORY_BROWSABLE);


Any thoughts about this?

marcardar · 2016-04-26T05:52:39Z

Thanks!

marcardar force-pushed the support-intent-url-schemes branch 3 times, most recently from 1b3ea15 to 66c1fa0 Compare April 24, 2016 05:07

marcardar force-pushed the support-intent-url-schemes branch from 66c1fa0 to 4da8016 Compare April 24, 2016 08:15

marcardar force-pushed the support-intent-url-schemes branch 4 times, most recently from fa9b606 to 375a6ae Compare April 24, 2016 09:49

marcardar force-pushed the support-intent-url-schemes branch from 375a6ae to 427b542 Compare April 25, 2016 09:28

support intent: and android-app: url schemes in templates

e3de2d1

marcardar force-pushed the support-intent-url-schemes branch from 427b542 to e3de2d1 Compare April 25, 2016 09:32

marcardar reviewed Apr 25, 2016
View reviewed changes

timrae reviewed Apr 25, 2016
View reviewed changes

removed browser_fallback_url support and improved android-app: support

547d53d

marcardar reviewed Apr 25, 2016
View reviewed changes

timrae merged commit 18a51db into ankidroid:develop Apr 25, 2016

marcardar deleted the support-intent-url-schemes branch April 26, 2016 07:21

Uh oh!

Conversation

marcardar commented Apr 23, 2016

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

timrae commented Apr 24, 2016

Uh oh!

marcardar commented Apr 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

timrae commented Apr 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

timrae commented Apr 24, 2016

Uh oh!

timrae commented Apr 24, 2016

Uh oh!

marcardar commented Apr 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcardar commented Apr 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

marcardar commented Apr 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcardar commented Apr 24, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timrae commented Apr 25, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcardar Apr 25, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcardar commented Apr 25, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcardar commented Apr 26, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

marcardar commented Apr 24, 2016 •

edited

Loading

timrae commented Apr 24, 2016 •

edited

Loading

marcardar commented Apr 24, 2016 •

edited

Loading

marcardar commented Apr 24, 2016 •

edited

Loading

marcardar commented Apr 24, 2016 •

edited

Loading

marcardar Apr 25, 2016 •

edited

Loading