There were parts of this code that were sticking in a URL-encoded query
string into GeoParsedPoint, and other parts that were putting in a regular
non-URL-encoded String. This meant that URLs with an & in the query string
encoded as %26 were not being properly parsed, since & is used to split up
the query string. That also makes it impossible to output a properly
encoded URI from getGeoUriString().
Not all location URLs have useful information in the query string, so only
parse it if it is used in the section for a given hostname.
Also, rename queryMap to params for consistency.
By not modifying "path" from what Uri.getPath() returns, it keeps the
pattern matching consistent since the contents of "path" will always be the
same as Uri.getPath(), and what is visible in the URI itself.
This parses out all of the parameters in the query string for both http:
and geo: URIs. This will only work on URIs with valid syntax, so it will
not work on URIs that do odd things like have a query string in the
fragment, like this one:
http://www.amap.com/#!poi!!q=38.174596,114.995033|2|%E5%AE%BE%E9%A6%86&radius=1000
This is a nice format of shortlink since it uses a public, offline algorithm
to generate them. So Osmand can get what it needs from the shortlink
without going online.
https://wiki.openstreetmap.org/wiki/Shortlink
This method is used to parse the custom OpenStreetMap shortlink algorithm
that encodes lat, lon, and zoom. The previous version,
MapUtils.decodeShortLocString(), only parsed lat, lon from the shortlink.
It seems this code is quite out of date, because none of the URL formats
listed in the tests seem to work. This commit updates the URL formats in
the tests, then makes all of them parse properly. It also changes the
parsing technique, leveraging java.net.URL's built-in parsing abilities to
assist. Also, I plan on adding a lot more URL formats, so the current code
structure made it very difficult to add to. So each service will be split
out into its own section, starting here.
In order to maintain privacy when sharing location, this changes the shared
location link to use HTTPS, thereby hiding the location info from anyone
who might be snooping on the WiFi, ISP, internet, etc.
Unfortunately, http://osm.org does not yet work with HTTPS, but the
standard OSM URLs are short enough to fit into a text message. They are
planning on supporting https://osm.org in the future:
https://github.com/openstreetmap/operations/issues/2
Some networks require a proxy to get internet beyond the firewall, and
proxies are also useful for channeling all traffic through circumvention
and privacy proxies like Tor, I2P, Psiphon, etc. In places where the
connection to download tiles might be blocked, using a proxy can give the
user access.
To increase user privacy, especially with traffic that includes sensitive
information like location and tracking markers, HTTPS should be used
whenever possible. It seems that HTTPS is broken for a lot of sites on
versions older than android-10/Gingerbread, so HTTPS is not used on those
old platforms.
