Support android intent uri for JOSM style remote control #1478

simonpoole · 2017-03-07T17:43:30Z

This is WIP.

On Android the normal Urls will actually work, but not as source of an iframe, that's why we need custom code (using a custom scheme in the uri is frowned upon, but I'm a repeat offender).

One aspect that needs work is handling errors, unluckily it is rather unclear if it can be done in any reasonable fashion. The other thing is that I haven't done anything with the "Edit" button because while showing it would work without problems for Vespucci that doesn't go for anything else.

Documentation on how to set up the Android side follows.

simonpoole · 2017-03-07T20:03:38Z

Documentation:

https://paul.kinlan.me/launch-app-from-web-with-fallback/ (there are a number of articles on the topic on the site)
https://developer.chrome.com/multidevice/android/intents

I suppose we could use the fallback url to produce some kind of error message if necessary. I haven't run exhaustive tests against the stock browsers yet (but on the other hand have yet to find one with which it doesn't work). FF is as of yet untested.

tomhughes · 2017-03-07T22:41:12Z

app/assets/javascripts/index.js

+    }
+  };
+
+  function url() {


This is far too vague as a name for this function at this scope - it should either be more explanatory or the function should be pushed down inside remoteEditHandler so that the meaning is implicit.

That said I'm not really sure we it needs to be a function and can't just be done inline in remoteEditHandler without having to repeat the android test...

Typically you wouldn't want to use a function for this or below just for one variant, I just wanted to leave the door open for potential support of at least GoMap!!. But @bryceco needs to weigh in on that.

Fine, but call it remoteEditUrl or something and pass it the query string so the whole of the url logic can be in one place...

Alternatively, we could use L.Browser.android, see https://leafletjs.com/reference-1.6.0.html#browser

No using leaflet internals for non-leaflet things is a terrible idea.

tomhughes · 2017-03-07T22:42:05Z

app/assets/javascripts/index.js

@@ -255,17 +281,17 @@ $(document).ready(function () {
    var iframe = $('<iframe>')
        .hide()
        .appendTo('body')
-        .attr("src", url + querystring.stringify(query))
+        .attr("src", url() + querystring.stringify(query) + (android ? '#Intent;scheme=josm;end;':''))


If url is going to stay as a function then I would just pass query in to it and let it figure out the whole URL in one go rather than splitting the logic for the intent URL across two different locations.

bryceco · 2017-03-07T23:12:37Z

Go Map!! supports geo: and gomaposm: URL schemes. I'm a bit out of the loop as to how that gets hooked up here.

TheFive · 2017-03-08T06:49:11Z

@bryceco It was me, bringing you in the loop on my last vacation, as i tried used GoMap on an iPad.

I do not want to misuse Geourls for editing. If i have a geo url, i would like, to open a MAP and not an Editor.

Thats why i brought up:
MarcusWolschon/osmeditor4android#457
and
bryceco/GoMap#98 (comment)

simonpoole · 2017-03-08T07:35:48Z

To summarize the situation with osm.org and mobile editing:

on iPads/tablets we have an edit button that currently shows 3 options, and it is not unreasonable to assume that the JOSM/mercator entry starts an on device editor (yes it should likely be renamed), if we can reasonably determine that there is no flash support it would likely make sense to drop the P2 entry to avoid confusion,
this PR currently allows the edit button on tablets to work with Android apps that support partial implementations of the JOSM RC protocol, currently that is only Vespucci, but it is simple enough that other apps could too (see https://github.com/MarcusWolschon/osmeditor4android/blob/master/src/main/AndroidManifest.xml line 113 for the intent filter entries, http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl for the load_and_zoom Url that osm.org uses).
it would be sensible if we could start GoMap!! the same way, naturally any old Url based scheme will work, doesn't have to the same as JOSM, @bryceco can you point to relevant documentation?
on phones/small screen devices we currently don't show the edit button, but there is IMHO enough room to shrink the "history" button and add it the right of it, previously there just wasn't any use for it. Given that only the dedicated on device apps make sense, we probably don't need the drop down menu in this scenario.
as said in the original comment: I need to do some investigation on if we can improve the error messaging if no app is installed or something else goes wrong.

simonpoole · 2017-03-08T14:50:38Z

Seems as setting the iframe src will definitely not work in iOS 9. For other long winded approaches see http://stackoverflow.com/questions/32689483/ios9-try-to-open-app-via-scheme-if-possible-or-redirect-to-app-store-otherwise and others.

tomhughes · 2017-03-08T15:02:12Z

Seems the Apple Approved™ way for iOS is "Universal Links" which seems to involve registering a domain against your app on developer.apple.com and then hosting a JSON on file on that domain (with SSL mandatory) that says what paths map to what apps...

when on an android device.

wtimme · 2018-10-29T20:27:21Z

Hey guys,

I hope I'm not too late to the game. Recently, I opened an issue for "Go Map!!" to fix the Associated Domains for Universal Deeplinks (GoMap/#164). The way that Universal Links work is that websites host a JSON file (apple-app-site-association) in which they specify which apps should be able to handle certain paths.

Universal Deeplinks

As per Apple's documentation:

When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.

Universal links work even when your app is not installed. When your app isn’t installed, tapping a link to your website opens the content in Safari, as users expect.

Great. So basically what we need to do is to host a file called apple-app-site-association file (see my comment here).

But:

When a user is browsing your website in Safari and they tap a universal link to a URL in the same domain as the current webpage, iOS respects the user’s most likely intent and opens the link in Safari.
If the user taps a universal link to a URL in a different domain, iOS opens the link in your app.

This means that in order for the "Edit" button on openstreetmap.org to launch "Go Map!!" (if installed), the URL of the button's link needs to have a different domain that openstreetmap.org.

We could use something like launch.openstreetmap.org. Is creating/having an additional (sub) domain a viable option?

Fallback

In case the user does not have "Go Map!!" (or another app that is listed in the apple-app-site-association file) installed, a simple HTTP redirect could send the browser to openstreetmap.org/edit as a fallback. I don't have experience setting this up server-side, but believe that's the way to gracefully handle the case.

Android

I'm not familiar with Android development, to be honest, but if I understood the documentation correctly, developers are able to specify support for particular domains as well. Could someone validate this information?

I'm looking forward to your input, guys!

simonpoole · 2018-10-29T21:57:14Z

@wtimme Android is not an issue as that actually works modulo a bit of bitrot. I just didn't see a lot of point in moving forward with this just for one app.

For GoMap!! the question is if we can supply a bounding box or similar as a parameter in the URL or not, without that it doesn't make a lot of sense.

wtimme · 2018-10-29T22:33:51Z

that actually works modulo a bit of bitrot

Sorry, I don't know this expression. Do you mean that it bloats the software? 🤔

For GoMap!! the question is if we can supply a bounding box or similar as a parameter in the URL or not, without that it doesn't make a lot of sense.

Yes, Universal Deeplinks are passed to the iOS app in a whole, including the anchor (#) tag. As far as I remember, however, the corresponding parsing isn't in place yet. That's something that needs to be done on the iOS side.

As far as "one Universal Link for all platforms", I don't know if anchor tags reach the server-level where a HTTP redirect would typically be implemented.
So maybe we need to provide the lat and lon via query parameters, e. g. https://launch.openstreetmap.org/edit?lat=53.55210&lon=9.99340&zoom=19

Expected behaviour

Just to make it clear, here's what I understood:

When visiting the URL on an iOS device with "Go Map!!" installed, "Go Map!!" should launch and zoom in on the bounding box.
When visiting the URL on an iOS device and does not have "Go Map!!" installed, the browser (e. g. Safari) should open the URL. launch.openstreetmap.org should redirect the user to https://www.openstreetmap.org/edit#map=19/53.55210/9.99340.

bryceco · 2018-10-29T22:34:09Z

GoMap!! doesn’t support a bounding box, but it does support a centerpoint and a zoom level.

tomhughes · 2018-10-29T22:39:40Z

@wtimme as I understand it what you're requesting here is nothing to do with android intents, so it doesn't seem to be anything to do with this ticket?

It also sounds like it is mostly an operational/chef request given that it's a request for a separate web site rather than anything to do with the www.osm.org code - the only change to the web site would be to allow the edit link to point to this new domain I think?

That said it all sounds awfully involved - does iOS really not have a way to trigger an app from a web page without having to create separate web sites to act as an intermediary?!?!

HolgerJeromin · 2018-10-30T05:40:46Z

that actually works modulo a bit of bitrot

Sorry, I don't know this expression. Do you mean that it bloats the software? 🤔

The PR is old so it worked one year ago
but it needs love again to get in a shape to get merged

1ec5 · 2019-12-09T04:49:13Z

That said it all sounds awfully involved - does iOS really not have a way to trigger an app from a web page without having to create separate web sites to act as an intermediary?!?!

The mechanism described in #1478 (comment) – essentially, registering as a replacement for the browser for a given domain – is Apple’s preferred mechanism for unspoofability reasons. But as mentioned in bryceco/GoMap#235 (comment), it’s also possible for osm.org to link to something like osm://load_and_zoom?, and Go Map!! would know how to handle the osm: URL scheme. But I guess that would be quite unlike how the remote control feature works – at that point, would it make more sense to add Go Map!! as an editor alongside Potlatch 2?

dieterdreist · 2019-12-10T14:36:27Z

at that point, would it make more sense to add Go Map!! as an editor alongside Potlatch 2?

Currently, you do not get the editor links on iPhones (you get them on iPad though). This is deliberately of course, so I guess it would be easy to show it if the link to edit with GoMap!! became working. Potlatch1+2 on the other hand, have no purpose on mobile, because they require Flash which is not available for mobile devices since 2011.

1ec5 · 2019-12-11T09:15:52Z

Certainly, I was only alluding to how the menu can list editors other than iD and JOSM, not recommending that Potlatch be offered to mobile devices. 🙂

bryceco · 2020-08-15T18:12:21Z

Things are now fixed in the latest Go Map!! release in the App Store. You can launch the app using a URL like
https://gomaposm.com/edit?center=47.679056,-122.212559&zoom=21

mmd-osm · 2024-07-30T20:22:40Z

Note to self: according to a comment in #3760 (comment), this issue might be superseded by #3760 (pending positive test outcome).

simonpoole force-pushed the vespucci branch from 46cbf82 to 7821ec9 Compare March 7, 2017 18:25

This was referenced Mar 7, 2017

Vespucci Connector MarcusWolschon/osmeditor4android#473

Closed

opening vespucci on mobile devices from osm.org MarcusWolschon/osmeditor4android#457

Closed

tomhughes requested changes Mar 7, 2017

View reviewed changes

TheFive mentioned this pull request Mar 9, 2017

Deeper Integration with osm.org (edit in GoMap!!) bryceco/GoMap#98

Closed

Support android intent uri for JOSM style remote control

3d7dc72

when on an android device.

simonpoole force-pushed the vespucci branch from 7821ec9 to 3d7dc72 Compare February 15, 2018 16:41

tomhughes force-pushed the master branch from 0e51259 to 6142980 Compare October 31, 2018 19:15

dieterdreist mentioned this pull request Dec 10, 2019

enable remote control bryceco/GoMap#235

Closed

simonpoole mentioned this pull request Apr 14, 2022

Enable 'on-the-go' editing with geo://-URI giggls/opencampsitemap#22

Open

simonpoole marked this pull request as draft November 29, 2022 08:20

simonpoole mentioned this pull request Dec 11, 2022

Website from mobile should have option to edit by opening vespucci #3836

Open

tordans mentioned this pull request May 19, 2024

Add to osm.org edit menu bryceco/GoMap#758

Open

simonpoole mentioned this pull request Jul 28, 2024

Use $.ajax instead of iframe to make remote control requests #3760

Closed

simonpoole mentioned this pull request Nov 15, 2024

"Edit" menu shown on (small format) mobile devices largely non-functional #5326

Open

AntonKhorev mentioned this pull request Nov 22, 2024

Add josm scheme link to edit menu #5351

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support android intent uri for JOSM style remote control #1478

Support android intent uri for JOSM style remote control #1478

simonpoole commented Mar 7, 2017 •

edited

Loading

simonpoole commented Mar 7, 2017 •

edited

Loading

tomhughes Mar 7, 2017

simonpoole Mar 7, 2017 •

edited

Loading

tomhughes Mar 7, 2017

simon04 Mar 31, 2020

tomhughes Mar 31, 2020

tomhughes Mar 7, 2017

bryceco commented Mar 7, 2017

TheFive commented Mar 8, 2017

simonpoole commented Mar 8, 2017 •

edited

Loading

simonpoole commented Mar 8, 2017

tomhughes commented Mar 8, 2017

wtimme commented Oct 29, 2018 •

edited

Loading

simonpoole commented Oct 29, 2018

wtimme commented Oct 29, 2018

bryceco commented Oct 29, 2018

tomhughes commented Oct 29, 2018

HolgerJeromin commented Oct 30, 2018

1ec5 commented Dec 9, 2019

dieterdreist commented Dec 10, 2019

1ec5 commented Dec 11, 2019

bryceco commented Aug 15, 2020

mmd-osm commented Jul 30, 2024 •

edited

Loading

Support android intent uri for JOSM style remote control #1478

Are you sure you want to change the base?

Support android intent uri for JOSM style remote control #1478

Conversation

simonpoole commented Mar 7, 2017 • edited Loading

simonpoole commented Mar 7, 2017 • edited Loading

tomhughes Mar 7, 2017

Choose a reason for hiding this comment

simonpoole Mar 7, 2017 • edited Loading

Choose a reason for hiding this comment

tomhughes Mar 7, 2017

Choose a reason for hiding this comment

simon04 Mar 31, 2020

Choose a reason for hiding this comment

tomhughes Mar 31, 2020

Choose a reason for hiding this comment

tomhughes Mar 7, 2017

Choose a reason for hiding this comment

bryceco commented Mar 7, 2017

TheFive commented Mar 8, 2017

simonpoole commented Mar 8, 2017 • edited Loading

simonpoole commented Mar 8, 2017

tomhughes commented Mar 8, 2017

wtimme commented Oct 29, 2018 • edited Loading

Universal Deeplinks

Fallback

Android

simonpoole commented Oct 29, 2018

wtimme commented Oct 29, 2018

Expected behaviour

bryceco commented Oct 29, 2018

tomhughes commented Oct 29, 2018

HolgerJeromin commented Oct 30, 2018

1ec5 commented Dec 9, 2019

dieterdreist commented Dec 10, 2019

1ec5 commented Dec 11, 2019

bryceco commented Aug 15, 2020

mmd-osm commented Jul 30, 2024 • edited Loading

simonpoole commented Mar 7, 2017 •

edited

Loading

simonpoole commented Mar 7, 2017 •

edited

Loading

simonpoole Mar 7, 2017 •

edited

Loading

simonpoole commented Mar 8, 2017 •

edited

Loading

wtimme commented Oct 29, 2018 •

edited

Loading

mmd-osm commented Jul 30, 2024 •

edited

Loading