best practices for "data layer" in android client apps

Question

Here is one design/ best practices question..

I'm new to android development, and basically new to web/mobile solutions.

So, my question is - what are best practices when organizing structure of android application that get data from the remote server?

Should request to server go into one class that does communication with server (get and post requests), or should I look at my requests as data source, meaning that every data class manages it for itself?

or should I have more levels of abstraction - one level for acquiring data, other for model that uses some interfaces without knowing from what source data come from?

I'm curious how experienced android developers approach to these design issues...

Answer 1

Virgil Dobjanschi presentation is a good resource as pointed earlier, which basically tells you to run your requests from a background service so the activity does not get destroyed and to store your data in the database as early as possible.

For more technical details, the way I am doing it is to divide the app into three components:

1- Library to encapsulate the handling of the HTTP request and response (with ApacheHTTP), which can handle simple request/response and advanced features that might involve cookies (can be necessary for login) and modifying the HTTP header.

2- Marshal/Unmarsha layer, where I parse the server data (e.g. XML or JSON) and convert it to objects (i.e. models) that the rest of my app will deal with.

3- Persistence layer.

As per Dobjanschi's presentation, I usually make data requests run in a service not in a thread worker inside the activity.

Answer 2

Use one of the 3 models presented at this Google I/O talk. It provides you suggestions that will help you out on the whole process of definition of your app architecture. It'll also prevent you from making common mistakes beginners use to make:

http://www.youtube.com/watch?v=xHXn3Kg2IQE

This post will also help you out:

Need sample Android REST Client project which implements Virgil Dobjanschi REST implementation pattern