pskink:

That's a farily boilerplate filter implementation, but --

-- it still leaves one (at most) cursor open at the very end.

You can see it by enabling strict mode, and I saw it happenning on 4.0.2.

Patching things up in application code is, of course, trivial, but...
these trivial things really add up.

swebb99:

Managed cursors do other things besides getting closed by the activity --

-- they also get requeried each time the activity is resumed, and it's
done on the UI thread.

This can make resuming your activity slower.

Because of this, I'd try to avoid startManagingCursor, and add code in
your activity's onDestroy to reach into the views, get their adapters,
then the cursors, and close them.

Calling adapter.changeCursor(null) does this nicely.

-- Kostya

13 января 2012 г. 20:29 пользователь skink <[email protected]> написал:
>
>
> On 13 Sty, 13:14, swebb99 <[email protected]> wrote:
>> I have extended an SimpleCursorAdapter and define a
>> FilterQueryProvider like so:
>>
>> setFilterQueryProvider(new FilterQueryProvider() {
>>     public Cursor runQuery(CharSequence constraint) {
>>         return getMatching(constraint);
>>     }
>>
>> });
>>
>> I can't see how the Cursor can be managed because this class is called
>> from the a background thread via the CursorAdaptor class:
>>
>> public Cursor runQueryOnBackgroundThread(CharSequence constraint) {
>>     if (mFilterQueryProvider != null) {
>>         return mFilterQueryProvider.runQuery(constraint);
>>     }
>>     return mCursor;
>>
>> }
>>
>> Now the documentation for this method states that:
>>
>> After this method returns the resulting cursor is passed to {@link
>> #changeCursor(Cursor)} and the previous cursor is closed.
>>
>> As can be seen from the code that does not seem to be the case, infact
>> nothing is done with the cursor and so it is left dangling and not
>> closed.
>>
>> I tried to override the runQueryOnBackgrounfThread on my own extended
>> Adapter and call changeCursor(c) in it however that results in an
>> exception because this triggers off a chain of events which attempt to
>> modify the associated adapters view not from the UI thread.
>>
>> So any idea's how I manage (close) the cursor returned from my filter?
>>
>> Thanks
>
> hi,
>
> first: you don't have to call setFilterQueryProvider with your custom
> FilterQueryProvider class, just override runQueryOnBackgroundThread
> method in your custom SimpleCursorAdapter adapter
>
> second: override changeCursor in your adapter
>
> @Override
> public void changeCursor(Cursor c) {
>        Log.d(TAG, "changeCursor " + c);
>        super.changeCursor(c);
> }
>
> and you will see that changeCursor is indeed called (at least in 2.2
> as i saw)
>
> third: check super changeCursor(c) in CursorAdapter to see if
> super.changeCursor(c) is really closing old cursor, if not close it in
> your implementation
>
> pskink
>
> --
> 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

-- 
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

Reply via email to