Indeed I agree. I am preparing a dialog to give users an opportunity to submit more information than a typical crash report.
However I hope that someone from the Android team is on the list and can put some light on the overall Activity lifecycle and the management of views, threads and instance variables, because there is a total lack of documentation on these things. Sure, we have the sources, but it'd be very sad if they were the most accurate technical specification 2012/5/7 Jason Teagle <teagle.ja...@gmail.com> > while debugging on my devices (and emulators) I never got this NPE, so >> basically >> I am blind and must try to figure out what could happen on other devices. >> But, without being able to reproduce this behavior, the local debug is >> useless. I'd >> need to get in touch with the users >> > > I don't envy you in that difficult situation. If you can enlist the help > of several helpful users to help you track it down by adding temporary > debug info into the code and letting them use the temporary version of the > app, it will be of benefit. It's in their interest as much as yours to get > the situation resolved. > > Are you aware of any devices in particular that cause this problem? > > > > Triple checking everything is not the way to make robust software. >> > ... > >> with unneeded checkings, >> > > Be careful about this philosophy. In your code sample, for example, you > have > > > Cursor cursor = adapter.getCursor(); > int position = cursor.getPosition(); > > You are using 'cursor' here without checking it for null - you have *zero* > checks in there. Whilst I appreciate that 'triple checking' was a slightly > exaggerated comment, having *no* checks can be just as bad. > > > > because if I don't catch the bug it will pop up sooner or later >> > > Agreed. But having your users have to put up with constant failures > because you prefer leaving things to fail so that you catch them rather > than coding defensively (and *log* the issue in a catch handler, for > example, so that you still get information on the problem somehow) isn't > always an ideal situation. Some users will prefer to have it fail rather > than do something odd, as per your philosophy, but others will prefer to > have it try its best to move on rather than die, die, die. I'm willing to > bet that the majority fall into the latter category. > > > > Android seems to me too much an unreliable platform. i don't know if it's >> for >> missing documentation, bad design or whatever, just every piece of the API >> fails at some point >> > > Although I do feel that the documentation has lots of room for extra > information, I would suggest that more of the problem you state is to do > with trying to get one platform (Android) to cope with all the nuances of > each manufacturer's (and even each model's) hardware and firmware. It's not > as if manufacturers code with the OS in mind (except, you'd hope, Google's > own devices!). > > > > Can a click event be fired before onResume() finishes executing? >> > ... > > because it'd completely break the usefulness of Activity lifecycle >> callbacks >> > > Totally agreed. I would be alarmed if it were possible, to be honest. > > > > cursor and populate the listview, and since the listview is not empty >> (otherwise one >> could not click an item and thus firing the event listeners), how can we >> have two >> different adapters? >> > > I agree that it seems ludicrous, but bear in mind that you are (in the > click handler) referring to a variable you are maintaining manually > (adapter), rather than getting the adapter directly from the list view. > There is also the possibility of a threading issue, but since everything > happens in the same activity I assume this should not be an issue - it > should all be happening on the main UI thread. > > I can only suggest using > > (SimpleCursorAdapter)listView.**getAdapter().getCursor() > > rather than using the [adapter] member variable and see what happens. > > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to > android-developers@**googlegroups.com<android-developers@googlegroups.com> > To unsubscribe from this group, send email to > android-developers+**unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
