Особенность работы класса AsyncTask

[NevRA]

Надо будет учесть это в своих текущих и будущих проектах, спасибо!

[ivanrt]

Мне кажется в этом случае нужно просто написать свой собственный AsyncTask. Будет предсказуемое поведение и полное понимание того, что происходит. В этой же реализации isCanceled() рабоает правильно, только в doInBackground().

[NevRA]

Автор и не говорит, что что-то работает неправильно. Просто есть вероятность получить поведение отличное от ожидаемого.

Писать свой AsyncTask не хочется, т.к. изобретение велосипеда. Идея же доработать в имеющемся AsyncTask то, что не устраивает (в данном случае поведение cancel()) звучит логично.

[pyJIoH]

Как насчет того, чтобы взводить флаг в методе onCancelled() и проверять его в onPostExecute()?

[Eleph]

Работать по-прежнему не будет. Причина та же — перед отменой задания AsyncTask (а именно FutueTask) проверяет свой статус и если выполнение уже завершилось, то никаких действий предприниматься не будет.
Проблема именно в AsyncTask — получая уведомление о том, что поток завершил работу, AsyncTask «постит» сообщение MESSAGE_POST_RESULT в обработчик событий. Все бы хорошо, но в методе cancel() по каким-то причинам не отменяется посланое событие, а идет прямой вызов метода FutueTask.cancel(), который исправно рапортует о том, что отменять уже нечего.

[Kalobok]

Я, конечно, поздновато. Но вот что нашел: в onPostExecute проверять isCancelled бесполезно в любом случае. Если задача была отменена, то вместо него вызывается onCancelled. Конечно, небольшая проблема остается — если cancel был вызван после завершения doInBackground, сработает onPostExecute, а не onCancelled. С другой стороны, раз задача завершилась, нужно ли знать, что ее пытались отменить, но неудачно? На мой взгляд, все логично — isCancelled говорит не о том, был ли вызван cancel, а о том, был ли этим вызовом прерван doInBackground.