I'm trying to implement the second REST client model presented by Virgil Dobjanschi on this video:
http://developer.android.com/videos/index.html#v=xHXn3Kg2IQE
This is the high level diagram for the model I'm talking about:
I implemented everything as suggested, but I have a complex SQLite database model with lots of tables and I need to use transactions to update my local data with brand new data retrieved from server (step 7 in the picture).
Are there any suggestions you could make to help me out implement a transactional ContentProvider for this case?
Some of you may suggest me to use raw SQLite instead, but this way I won't take the advantages of ContentObservers, managedQueries and database accesses synchronization provided by the ContentProvider.
Any help would be appreciated.
Since you don't have access to the the Level 11 API, you could do this instead. Lets say you want to do this transaction stuff in your update method:
final Cursor update(Uri uri, ContentValues values, String where, String[] selectionArgs)
{
if(uri == uri1){
//do stuff you normally do
}
//other uri stuff
...
else if(uri == special_uri){
//do your transaction stuff here
}
}
In this case, special_uri is a uri you use to indicate that you're going to need to do your special transaction stuff. In other words, we're using the URI here to indicate that a transaction must be done.
You can implement custom function in your ContentProvider that execute your necessary transactions. Then you can call those funcitons using the call() function in your Processor.
Related
I'm a beginner in android. I want to perform basic CRUD operations of SQLiteDatabase using AsyncTask class. I have one int and 4 String parameters for table.How do i pass arguments to insert data in table from DataBaseHelper Class to AsyncTask Class.
This tutorial explains the usage of ContentProvider and Loader. Although Content Providers are overkill for small applications, it is the best way to implement a SQLiteDatabase within your application. Basically it allows you to have a app database accessible from every other application you wish and eases the usage of CRUD operations inside any of those.
With it, you don't need any reference to your SQLiteOpenHelper in order to make any operation in your database. Content Providers work by calling getContentResolver().<insert/delete/update>() directly in your Activity, keeping your code clean. Also, every operation you do using this API is sent to the background thread, leaving you no work at all besides configuring it for the first time.
A class that extends ContentProviderwill have 4 methods: insert(), delete(), update() and query(). These same methods must receive an URI that points to the table you will be using in that operation. Cool, huh? 4 methods for every operation in any table. You could also use a Constants class to map your URIs and boom: you got state of the art code.
I'm using GreenDao to store a lot of data, coming from a REST service.
A lot of my entities are connected with relations.
Everything works great, but tomorrow I have to implement a rocksolid workflow.
When I load my data I have to check if an error occurs.
If so, I have to make sure nothing is stored in the SQLite DB.
Normally I would work with transactions and rollback in case of an exception,
otherwise commit to the db.
For now I just use insertordelete to save an entity, everytime I created an object.
What would be the way to implement this?
On inserts and updates Greendao checks if there is a ongoing transaction. If that is the case greendao will not start a new transaction.
So the only thing to do is to start a transaction on your database and commit/rollback after your work is done or you notice an error. All inserts and updates will be in the same transaction which has benefits concerning data consistency and also on performance, since greendao will start new transactions with commit/rollback for every insert and update operation.
Summarized you can use code like this:
SQLiteDatabase db = dao.getDatabase();
db.beginTransaction();
try {
// do all your inserts and so on here.
db.setTransactionSuccessful();
} catch (Exception ex) {
} finally {
db.endTransaction();
}
I also tweaked my greendao a bit so that it doesn't cache inserted objects to get further performance and memoryusage benefits (since I insert a lot of data once and I only use very few data during runtime depending on user input). See this post.
As I understand from the docs, one SyncAdapter defined in a SyncService is limited to receive only one ContentProvider authority to work on.
But, at the same time, it has access to ContentResolver which it allows to run queries on other ContentProviders as well. I don't understand this particular design concept if a developer is needed to provide a single content authority to SyncAdapter and nonetheless she is able to do whatever she wants on whatever ContentProvider she has access to. My question is: What are the consequences of ignoring onPerformSync's parameters: String authority and ContentProviderClient provider and going with pure ContentResolver?
My application's (actually its SyncService) idea is simple: query a calendar server (OwnCloud in my case) to get not only events (synced with com.android.calendar) but also VTODOS, which are then distributed between various task management apps I can get source code and/or ContentProviderContract. I also thought of my own "Hub" ContentProvider, which has basic VTODO/Task structure, and is the only one compared to the server. It should be able to sync 2-way with different content providers of task management apps and then it syncs with the server.
I have read using ContentProviderClient vs ContentResolver to access content provider and I think I understand the difference. I'm now puzzled why there is so strong suggestion from android SDK to use a single ContentProvider in a single SyncAdapter and yet you are allowed to use ContentResolver to bypass that limitation.
I spent all day figuring this out and searched hundreds of SO/Google resources on the matter (some of them multiple times). I have also seen questions regarding using one SyncAdapter to sync multiple ContentProviders, but none of the answers were any close to suggesting using ContentResolver instead.
There is no special limitation on ContentResolver's API when used from the context of SyncAdapter. IMHO, the only reason why the framework passes ContentProviderClient and authority to onPerformSync() is convenience and kind of a hint to developers as to how SyncAdapter intended work.
This fact is easily seen in the source code for AbstractThreadedSyncAdapter.SyncThread - the ContentProviderClient passed to onPerformSync() is obtained in a standard fashion:
#Override
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
// Trace this sync instance. Note, conceptually this should be in
// SyncStorageEngine.insertStartSyncEvent(), but the trace functions require unique
// threads in order to track overlapping operations, so we'll do it here for now.
Trace.traceBegin(Trace.TRACE_TAG_SYNC_MANAGER, mAuthority);
SyncResult syncResult = new SyncResult();
ContentProviderClient provider = null;
try {
if (isCanceled()) {
return;
}
provider = mContext.getContentResolver().acquireContentProviderClient(mAuthority);
if (provider != null) {
AbstractThreadedSyncAdapter.this.onPerformSync(mAccount, mExtras,
mAuthority, provider, syncResult);
} else {
syncResult.databaseError = true;
}
} finally {
Trace.traceEnd(Trace.TRACE_TAG_SYNC_MANAGER);
if (provider != null) {
provider.release();
}
if (!isCanceled()) {
mSyncContext.onFinished(syncResult);
}
// synchronize so that the assignment will be seen by other threads
// that also synchronize accesses to mSyncThreads
synchronized (mSyncThreadLock) {
mSyncThreads.remove(mThreadsKey);
}
}
}
Therefore, the bootom line: you can use ContentResolver in your SyncAdapter as you wish - just call getContext().getContentResolver() and access any exported ContentProvider.
This is actually two questions:
If i expose my SQLite as a ContentProvider in my application it will work in an asynchronous fashion ?
Imagine i have the following tables in my database:
TableChats
TableChatMessages
and i also have a class
Message
To work with ListViews and have those list views use data from the ContentProvider must that data returned be a Cursor ? or is it possible to query for all messages in a chat and return an array of Message.
Sorry i know this may be a dumb question but i'm new to android development and the concept of ContentProvider and ListViews and how to connect them isn't quite yet clear to me.
To my knowledge
A content provider manages access to a central repository of data which shared between multiple applications. Normally all methods access the data work on the UI thread. If you want asynchronous, they suggest to use CursorLoader.
You can query all messages, get data from Cursor and put to your Message object.
Sample:
Cursor sampleCursor = getContentResolver().query("Your query");
ArrayList<Message> list;
if(sampleCursor!=null){
while(sampleCursor.moveNext()){
Message item = new Message();
item.sender = sampleCursor.getString(senderColumnIndex);
item.messageBody= sampleCursor.getString(messageBodyColumnIndex);
list.add(item);
}}
//Pass your list to your adapter.
Or directly pass your cursor using CursorAdapter
Dear Fellow Android Developers!
EDIT:
Thank you all for your answers. I see from many of them that it seems to be common (and accepted) practice to write your own close() method in your database adapter. Fair enough.
But how does that work with a ContentProvider? Usually when querying my database through my ContentProvider I simply issue something like:
Cursor managedCursor = managedQuery(...);
I don't see how I, with this methodology, can access the custom close() method in my custom ContentProvider implementation. Should I instead, from my Activity, do something like:
MyCustomProvider myProvider = (MyCustomProvider) getContentResolver();
and then:
myProvider.query(...);
myProvider.close();
And above all; is this at all necessary (as of point 2 below)?
END EDIT
To a certain degree I must say that I get the concept of the SQLiteOpenHelper, what it is, how it's used and so. I even use it on a regular basis when I write my own ContentProvider's.
The thing is that I'm not sure what to do with the SQLiteDatabase object, returned by the myOpenHelper.getWritableDatabase() (or the myOpenHelper.getReadableDatabase() function for what matters) when I'm done with it.
According to Android ContentProvider.onCreate() documentation:
You should defer nontrivial initialization (such as opening, upgrading, and scanning databases) until the content provider is used (via query(Uri, String[], String, String[], String), insert(Uri, ContentValues), etc).
[...]
If you do use SQLiteOpenHelper, make sure to avoid calling getReadableDatabase() or getWritableDatabase() from this method. (Instead, override onOpen(SQLiteDatabase) to initialize the database when it is first opened.)
The above gives me a hint where to initialize the database (the query(...), insert(...), etc functions), but it doesn't tell me anything on how to treat the created SQLiteDatbase object when I've finished using it.
Should I save it as a member variable of my ContentProvider implementation (and treat it much like a "private singleton" for future use)?
Should I just leave it when exiting the query(...), insert(...), etc. functions and trust that the SQLiteOpenHelper will manage it for me in future calls?
[Insert your alternative point-of-view here]
Being the confiding (or lazy) developer I've implemented my code according to the second alternative above. But I can't get rid of the creepy feeling that I'm neglecting something important.
It depends on what you're doing with your database. If you just do an insert, delete or select where you get an business object back, then you can close the database right after using it. As far as I know it is designed that you simply close it and request a new one when ever you need it.
But be careful when you're working with a cursor then you have to keep the database open as long as the cursor is in use. Otherwise the application will crash when the cursor has to reload data.
I guess you should close it, for example in onDestroy() of an activity that is using it.
So in my DBAdapter class I have:
/**
* Close the database
*/
public void close() {
mDb.close(); //mDb was obtained using mDbHelper.getWritableDatabase();
}
And in my activity:
public void onCreate(Bundle bundle){
...
mDBAdapter = new DBAdapter(this);
// Open or create the database
mDBAdapter.open();
}
#Override
public void onDestroy() {
// Close the database
mDBAdapter.close();
super.onDestroy();
}
Not sure if this is suitable for your provider concept.
If you check the example of use for that object in the API of Android, you can see the object is just used, but no close is necesary.
They implement the method close() though, but I havent seen they use it.