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 [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
