На самом деле не обязательно релизной. У заказчика может быть более десятка встреч с инвесторами о которых разработчикам становиться известно в последнюю очередь.
А по поводу оверхеда — я ответил комментарием ниже. В любом случае — никто не запрещает вывести обычный лог в том месте, где возможно требуется упор на призводительность.
Полностью согласен — данный метод работает медленней простого вывода сообщения.
Однако, на мой взгляд, оверхед здесь минимален — логирование открытия той или иной активити таким образом никак не скажется на быстродействии, а логирование циклов с множеством повторов выглядит, как мне кажется, вообще неоправдано — будет работать медленно при любом логировании, да и лог забъется мусором за достаточно короткое время.
Работать по-прежнему не будет. Причина та же — перед отменой задания AsyncTask (а именно FutueTask) проверяет свой статус и если выполнение уже завершилось, то никаких действий предприниматься не будет.
Проблема именно в AsyncTask — получая уведомление о том, что поток завершил работу, AsyncTask «постит» сообщение MESSAGE_POST_RESULT в обработчик событий. Все бы хорошо, но в методе cancel() по каким-то причинам не отменяется посланое событие, а идет прямой вызов метода FutueTask.cancel(), который исправно рапортует о том, что отменять уже нечего.
Спасибо.
В данной статье я не пытался изобразить нечто вроде идеально написанного класса. Если вы внимательней прочитаете статью, то обратите внимание на следующее предложение: «Класс по понятным причинам был упрощен и слегка модифицирован, но свою основную функцию он выполняет». Главное — познакомить читателей с возможностью использования такого подхода и я очень даже верю в то, что существует реализация данного класса куда более «правильная» даже в сравнении с той что используется в нашем реальном проекте.
Если же реализация вам ну совсем не нравиться — присылайте свой вариант — я обязательно добавлю его к статье.
Не могу согласиться с тем что реализация Singleton в корне не правильная. Проблема данной реализации хорошо известна, и для однопоточного кода пример работает, как мне кажется, на ура. В любом случае, спасибо за комментарий.
А по поводу оверхеда — я ответил комментарием ниже. В любом случае — никто не запрещает вывести обычный лог в том месте, где возможно требуется упор на призводительность.
Однако, на мой взгляд, оверхед здесь минимален — логирование открытия той или иной активити таким образом никак не скажется на быстродействии, а логирование циклов с множеством повторов выглядит, как мне кажется, вообще неоправдано — будет работать медленно при любом логировании, да и лог забъется мусором за достаточно короткое время.
Проблема именно в AsyncTask — получая уведомление о том, что поток завершил работу, AsyncTask «постит» сообщение MESSAGE_POST_RESULT в обработчик событий. Все бы хорошо, но в методе cancel() по каким-то причинам не отменяется посланое событие, а идет прямой вызов метода FutueTask.cancel(), который исправно рапортует о том, что отменять уже нечего.
В данной статье я не пытался изобразить нечто вроде идеально написанного класса. Если вы внимательней прочитаете статью, то обратите внимание на следующее предложение: «Класс по понятным причинам был упрощен и слегка модифицирован, но свою основную функцию он выполняет». Главное — познакомить читателей с возможностью использования такого подхода и я очень даже верю в то, что существует реализация данного класса куда более «правильная» даже в сравнении с той что используется в нашем реальном проекте.
Если же реализация вам ну совсем не нравиться — присылайте свой вариант — я обязательно добавлю его к статье.