I’m developing an Android application that stores its data inside the usual SQLite DB. I have to expose these data to the components of my application (activities and services) and to other applications.
Unfortunately, I have to operate on these data in various, maybe complex ways before storing them into the DB and before getting them out of the DB. I have to edit fields, aggregate data from several rows or from several columns and so on. That is: I have to perform the typical “data massage” that you can see performed by many business intelligence program and by many statistics one.
That means that a SQLite DB alone is too little. I have to do much more that a simple CRUD.
A content provider does not seem to be a solution, either. A typical Android CP implements an interface very, very similar to the standard CRUD and, more important, always returns a cursor (a temporary table of data organized in rows and columns). It looks too much like a very thin wrap around a SQL database for my needs. I still have to understand if I can put my business logic inside the CP itself, if I can extend the external CP interface (“content:…”) and weather this could be considered a Good Practice.
Maybe an Android service could give me a way to expose my functionalities and I could embed the SQLite DB (or the CP that contains the SQLIte DB) into the service. I still have to understand if this can be a solution and how.
What I really need, most likely, would be something like a RESTful web service:
- A SQL DB that stores then data, at the core of my “thing”
- An interface that accepts verbs (GET, PUT, POST, etc.) and singular/plural names (“People”, “John Doe”, etc.) and returns “objects” (not necessarily “Java Objects”. They could just be JSON or XML files/streams). This interface would be the only layer visible from the outside.
- In the middle, my “business logic” used to operate on data.
Of course, a standard CP is very similar to a RESTful WS and could well be a solution to my problem. I just cannot understand if a CP is flexible enough for this. For example, it looks like a CP can accept only GET/PUT-like requests and that it cannot return anything else than a cursor.
So, what would you use to expose non-just-CRUD functionalities and not-just-elementary-data to the various part (activities) of your application and to other applications?
Just an Android Content Provider (maybe writing you business logic inside the CP itself)?
An Android service that wraps around a SQL DB (or even that wraps around a CP)?
What else?
Which architecture would be most elegant (“maintanable”, “extendable”, “flexible”, “open”)? Do exists any “Best Practice” for this?
Your considerations/suggestions?
I am not sure that I have good understanding of your problem, but it seems that you a little confused with interchanging SQLite,CP,Service. Usually they work side by side.
Maybe it can help you: Google I/O 2010 – Android REST client applications .
My suggestion/assumption:
->Activities,POJOs -> Service (HadlerThread (Separate Thread + MessageQueue)) -> CP