Hello, dear Google! I have been developing apps (good and not really) for 2 years now. I would appreciate if you could alleviate my qualms about current state of REST client architecture. I stick with an architecture proposed by V. Dobjanshi and one discussed in the Udacity course. Basically, it suggests using Service — ContentProvider for requesting and caching data. Biggest advantages, as I understand, are:

• Overcoming some Activity/Fragment lifecycle(recreation) issues. Though, there’re developers using setRetainedInstance(true), which seems to solve the issue in some cases.
• App is less likely to be shutdown due to Service importance.
• Even if it’s shutdown, cached data can be obtained from ContentProvider.
• ContentProvider, Cursor work with some framework classes out of the box (I don’t use them).

While this is all good, it demands quite a bit of code writing, though there’re libraries to partially alleviate the burden. On the other hand, there are plenty projects avoiding this scheme and it makes me wonder if this architecture is the only way.

Could you please clarify it somewhere?

In my opinion community lacks examples with explanations of all those nasty scenarios you tend to talk in your tutorials.

Developers site is very informative on technical details but it lacks guidance for overall architecture. For instance, writing a REST client is something I have learned from Youtube and Udacity, not Android Developers site. The section on Volley does not mention Service and the section on Background Services does not mention Volley, Network, ContentProvider or anything regarding REST.

The lack of a clear standard makes it hard to argue for/against certain practices.

I have recently asked a question on stack. Thanks for your patience and long live Android!