-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Fix intent filters #247
Fix intent filters #247
Conversation
Signed-off-by: Arnau Mora Gras <[email protected]>
Signed-off-by: Arnau Mora Gras <[email protected]>
Signed-off-by: Arnau Mora Gras <[email protected]>
Signed-off-by: Arnau Mora Gras <[email protected]>
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.
file://
urls do not work. However, I'm not sure if they should be used, or we should stick tocontent://
Not even on Android 6 (Level 23)? If that is the case we should remove them from the manifest.
Also I don't understand the answer you gave in the issue on HTTPS URLs do they work, or not? With the current state of the PR, I can not add it from the browser. The browser will just start a download. Where did you find that wildcards are prohibited or we need verified domains for it?
If it does not work we should remove http(s) from the intent filter in the manifest too :)
It was introduced in Android 7. See the changelog
No
Yes, that's the thing, only the browser is authorized to open "unknown" domains.
Technically we are using them as App Links, since our app is not a web browser. For that, we need to either "Add intent filters that contain the autoVerify attribute." or "Declare the association between your website and your intent filters by hosting a Digital Asset Links JSON file [...]". In both cases, we need to be the owner of the website we are trying to open to verify our app. It wouldn't be crazy to add automatic verification for Nextcloud, for example, by adding our verification file to the repo, which would be installed on all instances. I don't know if they would want that, of course, and it's still not a solution needing to have it added everywhere. Also we would have to keep a list of the verified domains on the app, which is unsustainable. What we can actually try to add is supporting share intent filters. For example, as shown here. That way users can add the link by sharing it to the app. It's not as convenient as just opening the link, but it's a good solution I think. |
Ok, so then let's leave the
Then we should remove this
from the manifest, no?
Sounds good, in theory browsers and other apps should be able to share "text/calendar" mime type files to ICSx5 then. Even if Chrome or firefox can't do it now, they might in the future. I think should add this then :) |
Actually I'm not sure if Android detects the mime type correctly. If it does, yes, we should remove that. If not, we have to leave it. I'll test that one to be sure.
I'll add it 😄 |
Signed-off-by: Arnau Mora Gras <[email protected]>
Signed-off-by: Arnau Mora Gras <[email protected]>
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.
Mmmh should work fine. I'll check it again |
Signed-off-by: Arnau Mora Gras <[email protected]>
Done. Can you check again? |
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.
Yup, works fine now
Working features:
webcal://
orwebcals://
link with the app.*.ics
file with the app.*.ics
file with the app.Remaining bugs:
showNextButton
, or at least it's not updated on the UI, so the next step cannot be reached. If a character is removed and added back to the url field, the button shows up.file://
urls do not work. However, I'm not sure if they should be used, or we should stick tocontent://