Validation/Default fallback Intent

[kxfang]

Currently individual deep link handler methods/Activities need to do the following manually:

1. Validate the deep link URI. The framework takes care of most of this, but query parameters and parameter values still need to be validated manually.
2. Ensure certain pre-conditions are true (e.g. user must be logged in)
3. Be explicitly aware of the fallback Intent to use if the URI is invalid or a global pre-condition is false

It'd be nice if the framework could help reduce that boilerplate. Note a solution doesn't necessarily need to address all of the issues above. Let me know if this is something we want, and if so we can bounce on some ideas for what the API for this might look like.

[felipecsl]

Let's see if I understood it correctly:

You mean like a "before deep link" action filter? I imagine you'd be able to declare a class or method to run before any/some of your deep links are triggered, like a "hook" where you can interrupt the deep linking if some global state condition is not met, or the deep link itself is invalid. You should be able to modify the original deep link URI and change it to a fallback URI if the validation failed.

If you're familiar with Ruby on Rails, this sounds a lot like the before_action filters. I think it makes a lot of sense. This is starting to look more and more like a general routing framework, so we should be able to reuse ideas from web frameworks 😄

I think this is a good idea. Do you have any specifics in mind on exactly how this would work?

[kxfang]

Was thinking we can have the following interface:

interface Interceptor {
   @Nullable Intent handleDeepLink(Context context, String uri, Map<String, String> parameters);
}

The Interceptor returns an Intent if it wants to intercept the deep link handling and null otherwise. It can also mutate the parameters map as it likes. If the Interceptor returns an Intent, we short-circuit the deep link dispatch process.

When declaring deep links, we can do something like this:

@DeepLink(value = "http://example.com", interceptors = { LogInInterceptor.class, RequiredParamsInterceptor.class })

And for custom deep links, we can declare default interceptors that always run first before additional interceptors declared in each individual handler. So for example:

@DeepLinkSpec(prefix = "http://example.com", interceptors =  LogInInterceptor.class)
public @interface LoggedInOnlyDeepLink {
    String[] value();
    Class<? extends Interceptor> interceptors();
}

And that can be used as follows:

@LoggedInOnlyDeepLink(value = "/user/{id}", interceptors = RequiredParamsInterceptor.class)

In this case the LogInInterceptor would run before the RequiredParamsInterceptor.

[kxfang]

@felipecsl any thoughts on my proposed approach?

[felipecsl]

hey @kxfang sorry for the delay in getting back. I like the overall idea. Not sure about the naming, Interceptor may sound confusing since it's already used by other prominent Android libraries 😃 I think Hook or Filter may be clearer. I'd just change the "return null" behavior to return the original intent instead, if you don't want to intercept it. Otherwise all good. This sounds like a great addition!

[anshu7vyas]

This is exactly what I need for my project. Any updates on this feature?