hellofresh / android-deeplink Goto Github PK

If 2 routes A and B are registered to the parser, and they both match a given deep link

Current Behavior

• We do not have any guarantee for which one is going to be selected

Expected Behavior

• The one that was registered first should ALWAYS be selected

Action is currently defined to return a ParserResult<T>

This poses an inconvenience in several ways:

• This class only has a single property which implies an extra unnecessary dereferencing
• More sophisticated T implementations will still have to be "re-wrapped" into ParserResult increasing the level of indirection
• It doesn't add any particular value as the case may be

We should remove this class altogether, and give the users full autonomy regarding how/what they want to represent the result of the actions

Hello! With the shutdown of JCenter coming, would you please publish this great tool to MavenCentral to let us migrate away from JCenter? Thanks!
https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

Add Apache 2

See the documentation here:
https://www.jfrog.com/confluence/display/RTF/Deploying+Snapshots+to+oss.jfrog.org#DeployingSnapshotstooss.jfrog.org-GettingStartedwithOJO

As this library is now deprecated, you may consider redirecting it to my fork, which will continue to be maintained indefinitely

I had originally tried reaching out to transfer the ownership directly, but couldn't get a hold of anyone. So I went ahead to fork it

Kindly let me know if this is possible, and whatever else I need to do to make it happen

Thank you.

Given the following route definition:

object TestRoute : BaseRoute<Unit>("recipe/:id") {

    override fun run(uri: DeepLinkUri, params: Map<String, String>, env: Environment) = Unit
}

The following behaviors are observed:

• URL: http://www.hellofresh.com/recipe/1234
  • Route is matched as expected
• URL: http://www.hellofresh.com/recipe/
  • Route is also matched: UNEXPECTED
  • Expectation: Matching should fail here since URL trailing slash is analogous to one without

This issue is also related to #45

The idea here is that, with custom scheme URIs, a user might want to treat the host as part of the path segments.
For example:

https://www.hellofresh.com/recipes/all
hellofresh://recipes/all

The first case above, we want to match just recipes/all as the path segment. This is straight forward and properly supported today.
However, without any explicit notification, the second case will treat recipes as the host, leaving all as the path segment, and we will have not been able to match it.

Unfortunately, what the user really wanted for both cases was to match them using a single recipes/all pattern

Currently we have extensions that provide convenience bundled as part of the core library artifact. In order to discourage bloat for the artifact, provide these extensions as optional artifacts so library users can opt-in for their use.

They should reside in a module named deeplink-extension. It version should match the main module's version.

Ideally, we should have keys from predefined path params, and implicit query params in the params map to ease usability
However, on event of a clash, the processor must always prefer the predefined keys to implicit query params.
If a user absolutely needs a particular query key, they can always request this directly from the supplied uri parameter

We should avoid adding query key/values into the parameter map for the following reasons:

1. It’s not exactly part of the defined parameter names in the route pattern, so it can lead to confusion.
2. Query values conflicting with already defined parameters are silently ignored anyway
3. A query key could have multiple values in a given Uri. Since the parameter map is only designed to support 1:1 mapping, it seems like a half-complete solution trying to include queries in the same map

To avoid confusion, we should only add the explicitly defined path params into the map. Everything else can and should be accessed directly from the DeepLinkUri, which already provides a robust set of APIs to retrieve such information

Implement Environment in such a way that it gives the library users a bit of flexibility

Some goals of the environment are:

• Provide a reusable context reference, so that routes can take advantage of this. It should also be possible to override it for tests inside the library, since we do not want to instrument such tests
• Expose a way to communicate the authentication status of a user (end user in this case) to the routes, in case they need to make decisions depending on such information
• Give library users the possibility to extend the environment in such situations where it might be essential to their use case

Good to have:
Consider other potential properties that a user might need in the environment and deliberate on whether it might be a good idea to already include such properties in the Environment. We can open a separate issue in case such issue arises.

Possibly investigate:
https://github.com/marketplace/google-cloud-build or fallback to good ol Jenkins

Apache 2

https://github.com/BreadMoirai/github-release-gradle-plugin

Currently, we only support named path parameters in the path matching algorithm.

It would also be nice to support nameless parameters, where we simply skip that path segment altogether using * symbol

For example:
We will now be able to replace routes such as:

recipes/me/:id
recipes/<some-key>/:id
recipes/something/:id
recipe/whatever/:id

with a single

recipes/*/id

--
In future, it might also be nice to support ** pattern, which matches all path segments, but that is out of scope of this issue. A new issue should be opened for this case, and necessary discussions moved therein

Given this route definition:

object TestRoute : BaseRoute<Unit>("recipes") {

    override fun run(uri: DeepLinkUri, params: Map<String, String>, env: Environment) = Unit
}

The following behaviors are observed with the matcher:

• URL: "http://www.hellofresh.com/recipes"
  • Route is matched as expected
• URL: "http://www.hellofresh.com/recipes/"
  • Route is not matched
  • Expectation: Route should match as well