retrofit
retrofit copied to clipboard
square
Expose RequestAction for pluggable parameters handlers.
There's a lot of types people want to use for a lot of things. Having a mechanism to support custom parameter type handling would provide an extension point (albeit an advanced one) to prevent the further need to one-off these in the future. Bonus points if we can somehow figure out how to build the first-party behavior using this mechanism. #613.
This mechanism exists (RequestAction) but its exposure is being punted to 2.1. That said, type handlers (aka converters) for non-body parameters which want a string (like @Path, @Header, etc.) will be supported to allow the use of alternate types (like Date, et. al.).
Now that 2.1 is out is there a way to do this or has it been pushed to 2.2?
Not yet
On Sat, Jul 9, 2016, 3:47 AM Mateusz Czeladka [email protected] wrote:
Now that 2.1 is out is there a way to do this?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/square/retrofit/issues/626#issuecomment-231521591, or mute the thread https://github.com/notifications/unsubscribe/AAEEEUsdASWy_hp6S1A-NjznCn8h921Dks5qT1IRgaJpZM4Crm16 .
Have a look at my draft implementation of this feature (https://github.com/iwo/retrofit/commit/e843d9f94b114ea809d43bf7c6eaf38e4764275c) and let me know what you think.
To simplify review this commit only rearranges existing code without major flow changes or optimization. I'll extract and reuse common ParameterHandler code in further commits.
Design implications
To allow users to create custom ParameterHandler classes RequestBuilder API needs to be public. All the published methods should be reviewed and documented. The linked issues should be reviewed to ensure that the published RequestBuilder API provides enough low level access to allow for implementation of all the peculiar use cases mentioned.
Code style consideration
I moved built in ParameterHandler implementation to a separate package. They could be nested under ParameterHandler abstract class but it would make this file really long (probably around 1k LOC). The trade-off is that package local methods can no longer be used and Utlis is made public. On the other hand, there is a chance that users implementing custom handlers will benefit from access to Utils methods so maybe it's a good thing.
Please let me know what you think about this approach.
More changes in pluggable-parameters-handlers branch.
The code duplication got significantly reduced so it may make sense to merge some of this changes even if you decide not to make the pluggable parameter handlers API public at this point.
Could somebody look if @iwo branch could be incorporated? This is the only thing blocking us to move to Retrofit 2.x
Hey. Are there anymore updates on this? Being able to do something like:
@Authenticated(TOKEN_TYPE)
@GET("/example/path")
Call<ResponseObject> getStuff();
And read the Annotation in an interceptor would be very useful...
You can already do that. Call Request.tag(Invocation.class) which provides the Method and then call getAnnotation(Authenticated.class).
Alright, I'll give it a try. Thanks. I hadn't found any references or hints to this on the Retrofit site (probably makes sense, as it's a too complex scenario for there putting it there).
Hi @JakeWharton, is this feature being actively being planned on for an upcoming release? I'd like to be able to pass a Date object as a query parameter without having to manually transform it to a String first
That is already supported. Register a StringConverterFactory on your Retrofit.Builder which handles Date and converts it to a string in whichever manner you see fit.
Unfortunately there's no sample for this, but I'd accept a PR for one if you want to write one.
@cosminstefanxp Here's a sample for Invocation use: https://github.com/square/retrofit/blob/bcf07d0dffefb4ca1a33d431f5d38cab888b7d11/samples/src/main/java/com/example/retrofit/InvocationMetrics.java
@JakeWharton pardon my ignorance, I thought Converters were only for request/response bodies? (at least based on some of the docs, which say "converting HTTP response body"). Just to clarify, you're saying this will convert query params too?
And if so, could this potentially be used to to convert a List<String> query param into a comma separated list? (iirc, I believe the current behavior is to simply include each item in the list as multiple, separate, repeated query params)
Ah, well, looking at this (https://github.com/square/retrofit/blob/master/samples/src/main/java/com/example/retrofit/JsonQueryParameters.java), I think both questions I had can be answered in the positive. Sorry for the confusion!
So, then, I must be misunderstanding this issue. How is it different than what is possible already?
It would let you perform arbitrary mutation of the request based on a parameter. So, for example, in the List<String> case (assuming there was no built-in support) you could choose to comma-separate the values into a single query parameter or you could emit one query parameter for each item in the list. You could even affect multiple things, like add a header based and a query parameter at the same time.