The google docs point out not to use the CursorAdapters
first constructor,
CursorAdapter(Context context, Cursor c)
There are only two other options,
CursorAdapter(Context context, Cursor c, boolean autoRequery)
which says
Constructor that allows control over auto-requery. It is recommended you not use this, but instead CursorAdapter(Context, Cursor, int). When using this constructor, FLAG_REGISTER_CONTENT_OBSERVER will always be set.`
and
CursorAdapter(Context context, Cursor c, int flags)`
which says it is the recommended constructor.
Problem is there are only two flags to use with the last constructor here, FLAG_AUTO_REQUERY
(int 1) and FLAG_REGISTER_CONTENT_OBSERVER
(int 2).
Using FLAG_AUTO_REQUERY
doesn't make sense because I am now using a CursorLoader in which to manage it in the background as well as update it. With FLAG_REGISTER_CONTENT_OBSERVER
, it says its not needed when using CursorLoader
.
Now I ask, what integer do I pass CursorAdapter(Context context, Cursor c, int flags)
in order to make it work fine with my CursorAdapter
? Whats worrying me is how to correctly manage the old cursor. I am not really sure the correct way to do this.
If I use FLAG_REGISTER_CONTENT_OBSERVER
, then I must do something with onContentChanged()
, but when using swapCursor()
in my LoaderManager
, since the cursor is not closed, I could just do adapter.swapCursor(cursor).close()
. But would that conflict with onContentChanged()
in CursorAdapter
? Goal is to not cause any memory leaks and be efficient.
1) CursorAdapterIn BaseAdapter, view is created in getView method; in CursorAdapter, however, view is created in newView() method and elements are populated in bindView(). In the newView() method, you simply inflate the view your custom xml and return it. In the bindView() method, you set the elements of your view.
An easy adapter to map columns from a cursor to TextViews or ImageViews defined in an XML file. You can specify which columns you want, which views you want to display the columns, and the XML file that defines the appearance of these views. Binding occurs in two phases.
SimpleCursorAdapter . Used to write apps that run on platforms prior to Android 3.0. When running on Android 3.0 or above, this implementation is still used; it does not try to switch to the framework's implementation.
I blogged about this topic a couple weeks ago... maybe reading through it will help. You might also consider reading through the sample code on the developers site.
Which constructor should I use?
Use CursorAdapter(Context context, Cursor c, int flags)
(the documentation recommends using this constructor over the former).
What integer do I pass
CursorAdapter(Context context, Cursor c, int flags)
.
Just pass it the integer 0
. You don't want to pass it FLAG_REGISTER_CONTENT_OBSERVER
, since you are using a CursorLoader
with your CursorAdapter
(since the CursorLoader
registers the ContentObserver for you), and you definitely don't want to pass it
FLAG_AUTO_REQUERY` since that flag is deprecated.
What's worrying me is how to correctly manage the old cursor. I am not really sure the correct way to do this.
The whole point of the LoaderManager
is that it does all of the annoying cursor management stuff for you, behind the scenes. The convenience of having your data loaded automatically without having to worry about managing the queried cursor is precisely why the old startManagingCursor
and stopManagingCursor
methods were deprecated.
... I could just do
adapter.swapCursor(cursor).close()
Don't do that. The LoaderManager
will close the cursor on its own. In fact, if I remember correctly, you will get an error if you attempt to call close()
on the cursor. It sounds like you shouldn't have to override onContentChanged()
either.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With