best practices for "data layer" in android client apps

daneejela picture daneejela · Nov 13, 2012 · Viewed 11.2k times · Source

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

iTech picture iTech · Nov 13, 2012

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.