Ошибка Android: java.lang.IllegalStateException: попытка запросить уже закрытый курсор
(Linux/Eclipse Dev для Xoom Tablet работает с HoneyComb 3.0.1)
В моем приложении я использую камеру (startIntentForResult()), чтобы сделать снимок. После того, как снимок сделан, я получаю обратный вызов onActivityResult() и могу загрузить Bitmap, используя Uri, прошедший через намерение "сфотографировать". В этот момент моя активность возобновляется, и я получаю сообщение об ошибке, чтобы перезагрузить изображения в галерею:
FATAL EXCEPTION: main
ERROR/AndroidRuntime(4148): java.lang.RuntimeException: Unable to resume activity {...}:
java.lang.IllegalStateException: trying to requery an already closed cursor
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2243)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1019)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:126)
at android.app.ActivityThread.main(ActivityThread.java:3997)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:491)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.IllegalStateException: trying to requery an already closed cursor
at android.app.Activity.performRestart(Activity.java:4337)
at android.app.Activity.performResume(Activity.java:4360)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2205)
... 10 more
Единственная логика курсора, которую я использую, заключается в том, что после взятия изображения я конвертирую Uri в файл, используя следующую логику
String [] projection = {
MediaStore.Images.Media._ID,
MediaStore.Images.ImageColumns.ORIENTATION,
MediaStore.Images.Media.DATA
};
Cursor cursor = activity.managedQuery(
uri,
projection, // Which columns to return
null, // WHERE clause; which rows to return (all rows)
null, // WHERE clause selection arguments (none)
null); // Order-by clause (ascending by name)
int fileColumnIndex = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA);
if (cursor.moveToFirst()) {
return new File(cursor.getString(fileColumnIndex));
}
return null;
Любые идеи, что я делаю неправильно?
Ответы
Ответ 1
Похоже, что вызов managedQuery() устарел в API Honeycomb.
Doc для managedQuery() читает:
This method is deprecated.
Use CursorLoader instead.
Wrapper around query(android.net.Uri, String[], String, String[], String)
that the resulting Cursor to call startManagingCursor(Cursor) so that the
activity will manage its lifecycle for you. **If you are targeting HONEYCOMB
or later, consider instead using LoaderManager instead, available via
getLoaderManager()**.
Также я заметил, что я вызывал cursor.close() после запроса, который, как я думаю, является no-no. Нашел эту действительно полезную ссылку. После некоторого чтения я придумал это изменение, которое, похоже, работает.
// causes problem with the cursor in Honeycomb
Cursor cursor = activity.managedQuery(
uri,
projection, // Which columns to return
null, // WHERE clause; which rows to return (all rows)
null, // WHERE clause selection arguments (none)
null); // Order-by clause (ascending by name)
// -------------------------------------------------------------------
// works in Honeycomb
String selection = null;
String[] selectionArgs = null;
String sortOrder = null;
CursorLoader cursorLoader = new CursorLoader(
activity,
uri,
projection,
selection,
selectionArgs,
sortOrder);
Cursor cursor = cursorLoader.loadInBackground();
Ответ 2
Для записи здесь, как я исправил это в своем коде (который работает на Android 1.6 и выше): Проблема в моем случае состояла в том, что я случайно закрыл управляемые курсоры, вызвав CursorAdapter.changeCursor(). Вызов Activity.stopManagingCursor() на курсоре адаптера перед изменением курсора решил проблему:
// changeCursor() will close current one for us: we must stop managing it first.
Cursor currentCursor = ((SimpleCursorAdapter)getListAdapter()).getCursor(); // *** adding these lines
stopManagingCursor(currentCursor); // *** solved the problem
Cursor c = db.fetchItems(selectedDate);
startManagingCursor(c);
((SimpleCursorAdapter)getListAdapter()).changeCursor(c);
Ответ 3
ИСПРАВЛЕНИЕ: используйте context.getContentResolver().query
вместо activity.managedQuery
.
Cursor cursor = null;
try {
cursor = context.getContentResolver().query(uri, PROJECTION, null, null, null);
} catch(Exception e) {
e.printStackTrace();
}
return cursor;
Ответ 4
Я создал этот вопрос здесь, так как я не мог прокомментировать последний ответ (по какой-то причине отключены комментарии). Я думал, что открытие нового потока на этом только усложнит ситуацию.
Я получаю сбои приложения, когда я перехожу от Activity A к Activity B, а затем возвращается к Activity A. Это происходит не всегда - только иногда, и мне трудно найти ТОЧНО, где это происходит. Все происходит на одном устройстве (Nexus S), но я не думаю, что это проблема с устройством.
У меня есть несколько вопросов относительно ответа @Martin Stine.
- В документации говорится о
changeCursor(c);
: "Измените базовый курсор на новый курсор. Если есть существующий курсор, он будет закрыт". Итак, почему я должен stopManagingCursor(currentCursor);
- не избыточно?
- Когда я использую код, предлагаемый @Martin Stine, я получаю исключение нулевого указателя. Причиной этого является то, что в первом "запуске" приложения
((SimpleCursorAdapter)getListAdapter())
будет оцениваться значение NULL, потому что ни один указатель еще не был создан. Конечно, я мог бы проверить, не получаю ли я null и только потом попытаюсь остановить управление курсором, но, наконец, я решил разместить мой `stopManagingCursor (currentCursor); в методе onPause() этой активности. Я думал, что у меня наверняка будет указатель, чтобы остановить управление, и я должен сделать это, прежде чем я оставлю действие другим. Проблема - я использую несколько курсоров (один для заполнения текста поля EditText, а другой для представления списка) в моей деятельности, я думаю, не все они связаны с курсором ListAdapter -
- Как узнать, какой из них остановить? Если у меня есть 3 разных вида списка?
- Должен ли я закрыть их во время
onPause()
?
- Как мне получить список всех моих открытых курсоров?
Так много вопросов... Надеюсь, кто-нибудь может помочь.
Когда я добираюсь до onPause()
, у меня есть указатель, чтобы остановить управление, но я еще не решил, разрешает ли это проблему, поскольку эта ошибка появляется спорадически.
Большое спасибо!
ПОСЛЕ НЕКОТОРЫХ ИССЛЕДОВАНИЙ:
Я нашел что-то интересное, которое могло бы дать ответ на "таинственную" сторону этой проблемы:
В действии A используются два курсора: один для заполнения поля EditText. Другой - заполнить ListView.
При переходе из Activity A в Activity B и возвращении поле + ListView в Activity A должно быть заполнено снова. Кажется, что в поле EditText никогда не будет проблемы с этим. Я не мог найти способ получить текущий курсор EditText (например, в Cursor currentCursor = ((SimpleCursorAdapter)getListAdapter()).getCursor();
), и причина говорит мне, что поле EditText не сохранит его. С другой стороны, ListView будет "помнить" свой курсор с последнего времени (от Activity A → Activity B). Кроме того, и это странно, у Cursor currentCursor = ((SimpleCursorAdapter)getListAdapter()).getCursor();
будет другой идентификатор после Activity B → Activity A и все это БЕЗ, когда-либо вызывающее
Cursor currentCursor = ((SimpleCursorAdapter)getListAdapter()).getCursor();
stopManagingCursor(currentCursor);
Я думаю, в некоторых случаях, когда системе нужно освобождать ресурсы, курсор будет убит, а когда Activity B → Activity A, система все равно попытается использовать этот старый мертвый курсор, что приведет к исключению. И в других случаях система придумает новый курсор, который все еще жив, и, таким образом, исключение не произойдет. Это может объяснить, почему это проявляется только иногда. Я думаю, что это трудно отлаживать из-за разницы в скорости приложения при запуске или отладке приложения. При отладке требуется больше времени и, следовательно, может дать системному времени новый курсор или наоборот.
В моем понимании это делает использование
Cursor currentCursor = ((SimpleCursorAdapter)currentListAdapter).getCursor();
stopManagingCursor(currentCursor);
Как рекомендовано @Martin Stine a должно в НЕКОТОРЫХ случаях и избыточным в OTHERS: если я вернусь к методу, и система пытается использовать мертвый курсор, нужно создать новый курсор и заменить его в ListAdapter, иначе я получаю сердитые пользователи приложений с разбитым приложением. В другом случае, когда система найдет себе новый курсор - строки выше избыточны, поскольку они делают недействительным хороший курсор и создают новый.
Я предполагаю, что для предотвращения этой избыточности мне понадобится что-то вроде этого:
ListAdapter currentListAdapter = getListAdapter();
Cursor currentCursor = null;
Cursor c = null;
//prevent Exception in case the ListAdapter doesn't exist yet
if(currentListAdapter != null)
{
currentCursor = ((SimpleCursorAdapter)currentListAdapter).getCursor();
//make sure cursor is really dead to prevent redundancy
if(currentCursor != null)
{
stopManagingCursor(currentCursor);
c = db.fetchItems(selectedDate);
((SimpleCursorAdapter)getListAdapter()).changeCursor(c);
}
else
{
c = db.fetchItems(selectedDate);
}
}
else
{
c = db.fetchItems(selectedDate);
}
startManagingCursor(c);
Мне бы очень хотелось услышать, что вы думаете об этом!
Ответ 5
Просто добавьте следующий код в конец блока курсора.
try {
Cursor c = db.displayName(number);
startManagingCursor(c);
if (!c.moveToFirst()) {
if (logname == null)
logname = "Unknown";
System.out.println("Null " + logname);
} else {
logname = c.getString(c
.getColumnIndex(DataBaseHandler.KEY_NAME));
logdp = c.getBlob(c
.getColumnIndex(DataBaseHandler.KEY_IMAGE));
// tvphoneno_oncall.setText(logname);
System.out.println("Move name " + logname);
System.out.println("Move number " + number);
System.out.println("Move dp " + logdp);
}
stopManagingCursor(c);
}
Ответ 6
Эта проблема долго меня мучила, и я наконец придумал простое решение, которое работает как прелесть на всех версиях Android. Во-первых, не используйте startManagingCursor(), поскольку он, очевидно, глючит и не рекомендуется в любом случае. Во-вторых, закройте курсор как можно скорее после того, как вы закончите с ним. Я использую try и, наконец, чтобы гарантировать, что Курсор закрывается при любых обстоятельствах. Если ваш метод должен возвращать курсор, тогда вызывающая процедура отвечает за его закрытие как можно скорее.
Я использовал, чтобы курсоры открывались для жизни Activity, но с тех пор я отказался от этого транзакционного подхода. Теперь мое приложение очень стабильно и не страдает от "ошибки в Android: java.lang.IllegalStateException: попытка запросить уже закрытый курсор" при переключении действий, даже если они обращаются к одной и той же базе данных.
static public Boolean musicReferencedByOtherFlash(NotesDB db, long rowIdImage)
{
Cursor dt = null;
try
{
dt = db.getNotesWithMusic(rowIdImage);
if ( (dt != null)
&& (dt.getCount() > 1))
return true;
}
finally
{
if (dt != null)
dt.close();
}
return false;
}