I appreciate your pragmatic response, however - 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 - Triple checking everything is not the way to make robust software. Deeply understanding the API is. I don't want to mask my bugs with unneeded checkings, because if I don't catch the bug it will pop up sooner or later - 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
You introduced two interesting questions (which I was already asking myself since a couple of days): 1. Can a click event be fired before onResume() finishes executing? Sure, I could set and clear a flag, but I'd like to see some documentation on this, because it'd completely break the usefulness of Activity lifecycle callbacks 2. Does my code call the very same adapter? A little bit of more information can help answer these questions. In my activity I let Android automatically register/unregistering observers by using android:onClick in the XML layout. The adapter is recreated onResume() and is stored as an instance field of my activity (which also is the OnClickListener). Since the adapter is used to read from the 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? If you want to try to crash my app this is the link to download it<https://play.google.com/store/apps/details?id=com.zybnet.metronomefree>. The Activity we are talking about is started when the user clicks on the LCD screen of the metronome 2012/5/7 Jason Teagle <[email protected]> > adapter = new SimpleCursorAdapter( /* query the SQLite db */); >> >> I can't understand why cursor may be null, since onResume() it's clearly >> initialized by >> the query. >> > > You would expect so, but it couldn't hurt to check (as a debugging test) > if adapter.getCursor() actually returns a valid cursor immediately after > the call to new SimpleCursorAdapter() above. > > It might also be worth checking that the adapter instance you set into the > list view in onResume() and the one you are subsequently seeing in > onClickItem() are one and the same. Again, you'd expect it to be, but at > this point you've got little to lose by checking. > > Just as a sanity check, make sure onResume() *is* being called as you > expect, before onClickItem() fires. Stranger things have happened... > > > > it's clearly initialized by the query >> > ... > > since obviously it must be non-null >> > > If programming (and running into problems) can teach you one thing, > hopefully it will be that making assumptions is a mistake {:v) There is > nothing in the docs for the SimpleCursorAdapter constructor that says it > *guarantees* a valid cursor after the operation, even though that is the > logical expectation. > > > > -- > 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<[email protected]> > To unsubscribe from this group, send email to > android-developers+**[email protected]<android-developers%[email protected]> > 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 [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
