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
More url parsing updates #1060
Merged
vshcherb
merged 13 commits into
osmandapp:master
from
eighthave:more-url-parsing-updates
Feb 2, 2015
Merged
More url parsing updates #1060
vshcherb
merged 13 commits into
osmandapp:master
from
eighthave:more-url-parsing-updates
Feb 2, 2015
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amap.com aka autonavi is a popular mapping service in China.
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
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.
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.
This just makes sure that there is a full lat/lon match before outputing.
* also handle maps.yandex.com URLs * properly handle unparsable short links (i.e. don't crash or return results) * include text= as Label
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().
This includes some valid Google Maps links that cause problems with the new `parseGoogleMapsPath()` method.
eighthave
force-pushed
the
more-url-parsing-updates
branch
from
February 2, 2015 23:30
b31fa18
to
8595952
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds support for parsing more URLs:
It also adds more tests including adding unparsable URLs to make sure the parsing does the right thing. The last commit includes some valid Google Maps links that cause problems with the new
parseGoogleMapsPath()
method. I didn't have time to fixparseGoogleMapsPath()
though, and I couldn't really make senses of it either, so I'm just documenting the issues with that commit.