1) Yes, that's exactly what I'm talking about
2) Serve data to the UI via a CP, to leverage Android's notificaitons.
Nothing changes here, no need for broadcast receivers. Perform other
operations bypassing the CP, dealing directly with the DB.
3) Not sure what you mean - if threading, SQLiteDatabase is thread safe.
4) Is there a one to one mapping between your REST and data URIs to
worry about this? I thought not, your prior messages explicitly mention
multiple database operations per one logical entity.
Another thought is this: a CP URI doesn't have to be mapped one to one
to a particular table. A CP implementation can work with multiple tables
inside a single ContentResolver.<insert/update/query/delete>() call made
by a client, and can wrap them in a DB transaction.
So that's another path to take, if you really want to always access all
your data through a CP: put the logic of mapping between logical entires
and tables inside the CP, treating CP operations as dealing with logical
entities rather than tables.
-- Kostya
05.11.2011 17:36, Flávio Faria пишет:
I prefer using ContentProviders for the following reasons:
1) I'll have my activities handling my cursors on their lifecycles
themselves;
2) It's easier to implement an MVP pattern with the help of
ContentObservers notifying the UI;
3) ContentProviders synchronize database accesses for me;
4) ContentProviders address resources by URI, as well as REST
implementations do, so i can easily map them.
If I take your suggestion:
1) will be OK if I have a simple CP exposing my entities by query();
2) I'll have to use BroadcastReceivers to simulate ContentObservers
(solves the problem, but looks messy);
3) I'll have to synchronize database accesses myself;
4) I'll have to implement all the local URI addressing logic for my
solution.
I thought that implementing this kind of architecture was a simple
problem that many people had already gone through. On the other hand,
I'm still looking for implementation examples or in-depth explanations
complementing that IO talk.
On Nov 4, 4:27 pm, Kostya Vasilyev<[email protected]> wrote:
Not sure what CP's have to do with REST...
My recommendation still stands - implement your own data access classes
that directly deal with a SQliteDatabase. Make them as simple or as
complex as you wish - from calling SQLiteDatabase directly to an
abstract object/database mapper.
Then layer a CP on top of this database - if you need one.
If you're not going to expose your data to other apps with a CP, then
the only reason to use a CP, as far I'm concerned, is to leverage
Android's built-in URI-based data change notification mechanism to more
easily sync the UI, and first of all, list views, with data updates.
It's still a good reason -- but it's much easier to implement a small CP
with query() just for the URIs you need in the UI, than to bottleneck
all your internal entity-changing logic through CP/CR interfaces.
-- Kostya
04.11.2011 23:38, Flávio Faria пишет:
Thanks Kostya,
Actually, I don't need to expose my data. I'm using a ContentProvider
because I'm trying to implement the REST architecture suggested by
Virgil Dobjanschi on Google I/O:
http://www.google.com/events/io/2010/sessions/developing-RESTful-andr...
Though, I have complex entities in a normalized database, so I need
transactions in order to insert parts of a single entity on their
respective tables and do some data validation (say queries) between
these insert operations. Is there a better solution for that?
--
Kostya Vasilyev
--
Kostya Vasilyev
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
