Decoupling retrofit annotation processing and request processing

[square]

Decoupling retrofit annotation processing and request processing

[JakeWharton]

Interesting suggestion. My initial reaction is "I love it!" but I'll have to think on it a bit more. We generally like small, purpose-built libraries and this could potentially introduce a bit of scope creep into Retrofit. I have a local branch which aims to tear out the Apache HttpClient-specific things from the core of the library which may actually aid in making this a lot easier. Perhaps it will be best to revisit this once that branch lands (hopefully before the new year).

[stephanenicolas]

I understand. Actually, this is a question for us with RoboSpice as well. We add new libraries as extensions of RoboSpice to build proofs of concepts and try new technologies, but our core remains quite stable now. Indeed, we think of extensions as "samples" but it gave some users the feeling that our library is becoming a five-headed beast.
I would be interested to see how you deal with this kind of complexity if you go in the direction of the feature I suggested.

I am building a new extension of RoboSpice to integrate Retrofit and hope to publish it by the end of the year as well.

[stephanenicolas]

@JakeWharton and other team members. If you are interested, I just added a retrofit module with tests and samples to RoboSpice. This module offers to execute retrofit http requests inside an android service and use file caching transparently for annotated JSON-POJOs.

Caching uses the same Gson mechanism as Retrofit converters.

We would be interested to get notified of the first release of Retrofit on maven central so that people can start using the Retrofit module of RoboSpice.

Sample :
https://github.com/octo-online/robospice/tree/master/samples/robospice-sample-retrofit

Extension module for Retrofit + tests :
https://github.com/octo-online/robospice/tree/master/extensions/robospice-retrofit-parent

We would be glad to get associated to Retrofit for its first release.

Would you also be interested in some contributions, for instance to provider jackson 1 & 2 converters ?

[JakeWharton]

We definitely do not want converters built-in for other serialization types or libraries. If the user of the library is smart enough to know they need something else then they should be able to implement it with reasonable simplicity. We want to provide the minimum viable configuration by default for use so that Retrofit is usable out-of-the-box. Providing a million configuration options and requiring the user to make a ton of decisions up front will turn most people off.

[stephanenicolas]

An approach to medidate on for us... ;)
Do you have any plan for releasing at least a snapshot of retrofit soon ?

[andreaturli]

+1 @stephanenicolas is it going to be released soon on maven central or something?

[codefromthecrypt]

my 2p is that an attractive aspect of retrofit is the lack of modularity wrt http engine or serialization engines. It ends up being far less code, special arbitrary portability words, hooks, etc. leading to a quicker grok. plugin models tend to end up with distance between each supported thing which can lead to reliability cliffs.

All that said, I'm torn :)

I don't like HttpURLConnection, but I don't like forcing an apache dep either. HttpURLConnection sucks in old jres particularly, but those places are fairly well known, etc. I'd help maintain HttpURLConnection if there was interest in adding or switching to that.

[codefromthecrypt]

heh of course you do already have what I want :) https://github.com/square/retrofit/blob/master/retrofit/src/main/java/retrofit/http/client/UrlConnectionClient.java

nm

[JakeWharton]

HttpUrlConnection is supported on Android for 2.3 and newer and on the JVM by default.

[JakeWharton]

@stephanenicolas While I think providing the parsing of annotations would be useful, I think the value in Retrofit is abstraction behind interfaces. The annotations are metadata on top of method declared on an interface. You shouldn't require the annotation metadata in order to provide alternate class implementations of your APIs. In fact, we do this heavily at Square. All of our apps can run in what we call "mock mode" where fake class that implement our API interfaces return example data. We can use 100% of both Square Wallet and Square Register in this mode for testing and development purposes.