Обновления и savedInstanceState

После обновления приложения в маркете получил сообщение, ClassNotFoundException - не смогло найти класс, который был перенесе. Начал разбираться. Судя по всему Activity сохранило состояние, потом произошло обновление и при десеарелизации возникла исключительная ситуация. Решение было следующим:
1. Просто в этом блоке перехватить все исключительные ситуации:
try{
.
.
.
}catch(Throwable th){
}

Но мне это кажеться не очень красивым так как могут возникать другие ситуации, которые в дальнейшем могут вызвать более серьезный креш.

хз..хз..

Все таки создал класс в том месте, где он был и отнаследовал его от перенесенного. Проверил - работает. Недаром в своей книге "Effective Java" Блох пишет что с классами, которые реализуют интерфейс Serializable нужно быть очень аккуратными и в первую очередь думать о совместимости. Давайту думать о тех программистах, которые будут работать с нашим кодом ПОТОМ!.

AppWidget & LockScreen - за что???

Обнаружена такая вот фигня - есть AppWidget, который можно разместить на LockScreen устройства. С виджета можно открыть новость в приложении. Все было как обычно - кидаеться broadcast , его ловит reciever и открывает новость. Но!!! С лок скрина - этого не происходило. По наблюдениям в дебагере процесс запуска приложения просто замирал. Причем все необходимые флаги были установлены:
  getWindow().addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
  getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD);

Пришлось делать вот такой костыль, как описано здесь: http://stackoverflow.com/questions/16188402/how-to-start-new-activity-from-lockscreen

Вставлять в приложение ProxyActivity, цель у которого - завести основной мотор всего приложения с некоторой задержкой. Кто нибудь, объясните мне : WHY???? Что это за нах??? И нет ли какого-либо способа сделать это красиво? Просто запустить Reciever который просто запустит Activity?
   

Что лучше, простыня из catch{} или один раз Throwable?

Захотелось поразмыслить по-поводу как лучше. В институтах нам говорят - делайте так:

try{

}catch(NullPointerException){

}catch(JSONParserException){

}catch

.

.

.}finally{

}

один хороший программист мне подсказал, что лучше использовать такую вот метафору:

try{

. 

. 

.

}catch(Throwable th){

     if(th instanceof NullPointerException){

     }

      if(th instanceof ClassCastException){

     }

}

Хорошенько подумав, пришел к выводу, что в принципе в данном подходе, с точки зрения отказоустойчивости все отдлично - по сути можно обработать необходимые ошибки и если возникнет необработанная - приложение продолжит работу. Но, как мне кажеться - тут и кроеться основная проблема данного подхода - можно просто пропустить какое-либо уведомление об ошибке, даже выводя всегда в лог сообщение - лог загружен и ошибка может остаться незамеченной, причинив в итоге уйму проблем, например с вычислениями или нулевыми значениями. 

С другой стороны - данный подход удобен с точки зрения тестирования. При возникновении ошибки на процессе тестирования - мы можем выводить сообщение, содержащее краткое сообщение об ошибке, и благодаря ему уже сможем смотреть в лог. Удобен такой подход с точки зрения пользователя и уменьшения негативных отзывов в маркете, как по мне. Было бы интересно узнать еще чьё-то мнение

     

SingleInstance Activity

Оказалось что если активити создано как singleInstance то у него впринципе не отрабатывает callback onActivityResult.  И можно потратить кучу времени отлавливая баг, связанный с этим досадным недоразумением.