App integration for shared links

[tomneedham]

Discussion topic. I was recently thinking about how nice it can be to be taken to a native app when you access a web link and you have the app installed - although I don't entirely understand the mechanics behind it. However I was wondering if we could do the following:

1. Access shared owncloud link on your mobile device (may have seen it in an email, chat etc)
2. You go to mobile browser
3. Browser / owncloud server pings you to a native app url
4. owncloud app opens up on your mobile device
5. if this points to a file you have in your instance / account on your device, load the files ui and scroll to (internal link)
6. if its not in your owncloud, you can 'add to owncloud' and pick your local account
7. view / open the file using the app if its a public link (open with local applications etc)

This would be a much nicer and native integration than the current experience for shared links on mobile. Maybe you have some other ideas :)

---

Updated by @nasli

AC:

1. Get a private Link and send to someone via email
2. Receiver will click on the link in the email client on his mobile
3. The ownCloud App will open

[michaelstingl]

From my perspective, this don't work with public links yet. Public links don't get resolved to the location of the files in your account. Private links could work.

Link will open mobile Safaris and ownCloud server should display a "Smart App Banners".

ownCloud iOS app could implement the application:openURL:sourceApplication:annotation: method to open the right view inside the app.

Related: https://github.com/owncloud/enterprise/issues/2173 (internal only)

[michaelstingl]

Currently, Smart App Banners are broken (tested in 10.0.3 on iOS 11.2): see @SamuAlfageme 's comment: #972 (comment)

https://demo.owncloud.org/	http://www.math-ninja-app.com/

[tomneedham]

Public links don't get resolved to the location of the files in your account.

Agreed. But I was wondering about an improvement, where you could use the native app to decide what to do (since all the information is public in the link anyway). Like add to owncloud, open the file, share the link elsewhere.

Private links could work.

And same with this, this would be cool. If we could try the fileid + hostname and see if you can access this file, if not your instance then basically show error, if your instance but no access show forbidden (and future: request access), if your instance but has access scroll to it. That would be awesome integration

[michaelstingl]

But I was wondering about an improvement, where you could use the native app to decide what to do

Please handle this on the server side and unite the different link types. I don't like the idea to solve this on the client side and implement in all 3 client platforms…

[tomneedham]

What about 'add to owncloud' button on the web ui opens your native app?

[michaelstingl]

No, you need a special URL scheme. We can't register http://mycloud.com/ and http://yourcloud.com/ and http://everycloud.com/ to open the ownCloud iOS app. As far as I know, this string needs to be fixed at time of app compilation.

[nasli]

You are right @michaelstingl , and this is a save flow

[nasli]

The server needs to add a JSON with special configurations and app IDs that allow iOS to open your app.
We are currently working on it to support open private links and will be available soon

[tomneedham]

No, you need a special URL scheme. We can't register http://mycloud.com/ and http://yourcloud.com/ and http://everycloud.com/ to open the ownCloud iOS app. As far as I know, this string needs to be fixed at time of app compilation.

Ok this makes sense. Is anything actually retrived frmo the url you register, or is it just used to register the app handler? Since the button could point to owncloud.org/ios/publiclink/details.... and ios always registeres to that?

[nasli]

Since the button could point to owncloud.org/ios/publiclink/details.... and ios always registeres to that?

No, @tomneedham If you point to this URL "owncloud.org" needs to have a JSON with the unique app identifier of your apps that you want to open in, add the URL domain inside your app and from that URL been able to retrieve a full path to download the file.

[nasli]

This is how universal links works since iOS9 and it's a save approach. iOS no longer support directly URI schemes.

1. You need to set up in your server the appIDs and paths that you support (with an accesible JSON apple-app-site-association)
2. Enable associated domains in your appIDs
3. Add the correct domains in your app capabilities
4. Handle the links in your app

[SamuAlfageme]

@michaelstingl about:

Currently, Smart App Banners are broken (tested in 10.0.3 on iOS 11.2)

I think you're not seeing the banner because at some point in the past you probably dismissed it (and I'm guessing Safari considers all the apps sharing an app-id the same app and therefore dismissing all banners that share this value)

Quoting from Apple's Promoting Apps with Smart App Banners:

And with a large and prominent close button, a banner is easy for users to dismiss. When the user returns to the webpage, the banner won’t reappear.

Also see https://stackoverflow.com/questions/19412838 on how to take back Safari to a clean state and bring the banner back.

[michaelstingl]

@SamuAlfageme You are right. I clicked away this banner too often…

[jesmrec]

This was already shipped in 3.7.4 for private links.

[michaelstingl]

This was already shipped in 3.7.4 for private links.

no solution for unbranded clients yet. I guess this would require a server component to create magic links for iOS users.

[jesmrec]

In the server side magic is posible i guess.

iOS users mean App Store users?

But the app would need to be re-signed with specific associated domains in both app and extensions. Distribution via App Store does not allow iOS users to perform it (afaik), so a fix por every user does not seems to be very friendly. Tell me if i am wrong.

CC @pablocarmu

[michaelstingl]

proposed server enhancements:
https://github.com/owncloud/core/issues/33337