But it starts making sense, maybe. The process (VM) is killed, because it runs out of memory, or something else, maybe it's killed to fast to send an exception to the tracker, and then, there some mechanism in Android to restart a new process/VM in order to continue excecuting the app, where it stopped. Because it's a different process, my debugger, which is still debugging the killed process, doesn't stop on the breakpoints, but I see the null pointer exception, which is from the new process. And serialization makes sense exactly for this kind of cases, then it's always possible to continue excecuting although the process was killed... hm... sounds good right :) I hope I'm right and serialization fixed the issues. If I'm saying something wrong or someone wants to add something, please do it.
On Thursday, July 12, 2012 9:01:25 PM UTC+2, user123 wrote: > > So the system is trying to recover the activity after the VM shutted down, > and if I serialize/persist the data it will be restarted correctly and the > app will not crash? > > I thought VM crash would be the end of everything and the app would crash > inevitably after it. I thought that these errors where just some kind of > post traumatic disorder, and if i fix them the app will crash anways... > that's why I was looking how to fix the VM crash instead of the null > pointer. > > But you say, although the VM crashes, if the data can be recovered > everything will run normally, is that right? Then I'll start immediatly to > serialize all the parameters. > > > On Thursday, July 12, 2012 8:24:46 PM UTC+2, Nobu Games wrote: >> >> Seriously, instead of waiting for a reply that explains to you all >> different scenarios when and how the VM crashes, you should start coding a >> solution the clean way and either pass over that data via Intent, store it >> in some SharedPreferences object or in a database or something. >> >> You don't necessarily need to implement Parcelable (which is indeed a >> pain in the backside). If your data classes carry just some serializable >> members then add the Serializable interface to them. Serializable objects >> can also be bundled as Intent extras via >> putSerializable()<http://developer.android.com/reference/android/os/Bundle.html#putSerializable%28java.lang.String,%20java.io.Serializable%29>. >> >> It's pretty much effortless to use. >> >> If your data classes contain contexts or other non-serializable members, >> declare these members as transient: >> >> private transient Context mContext; >>> >> >> And on de-serialization in your next Activity you can assign these >> members again. >> >> Java Collections (like your String List in above example) are >> serializable by the way. >> > -- 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
