Ok. AFAIK, refreshing a list view with notifyDataSetChanged /
Invalidated is asynchronous: it requests a layout change, which is then
processed by a handler message.
Perhaps clicks go through within that window - between the time when you
change your data structure and call notifyDataSetXXX and then time when
the list view actually gets repopulated. You blocking the UI thread
makes it more likely to happen, as that causes unprocessed messages to
accumulate and then go through all at once.
One way to fix this would be to add a call to adapter.getItem() or
getCount() in your button's click handler: those functions know when the
adapter is in a "pending refresh" state and return null / 0:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/widget/CursorAdapter.java;h=baa6833fb1a8ca36559bbffb6b5cb9aa54453236;hb=refs/heads/froyo#l130
Note the use of "mDataValid".
-- Kostya
09.02.2011 2:22, ivan пишет:
I guess the cursor position tag would/could present a problem if the
data size were changing, but it's not (in this particular instance)
and the query/requery results are sorted in a specific order per the
_id.
Weird.
On Feb 8, 4:03 pm, Kostya Vasilyev<kmans...@gmail.com> wrote:
Then perhaps the cursor gets requeried and the position changes.
You can track down requeries with a cursor factory and some logging, but
perhaps it's easier to set a tag to the item's _id value, as that should not
change (and you need the _id to delete, anyway).
--
Kostya Vasilyev --http://kmansoft.wordpress.com
09.02.2011 1:54 пользователь "ivan"<istas...@gmail.com> написал:
"You were saying something about buttons - how are you creating them,
and
mapping to the right data item? "
I set a tag to the cursor position in the bindView() function.
On Feb 8, 3:20 pm, Kostya Vasilyev<kmans...@gmail.com> wrote:
No, waiting on synchronized block or thread.wait blocks the waiting
thread
and only lets other threads run.
But, that synchronization doesn't sound good for a different reason,
since
you are blocking the UI thread, and that should not happen.
One way around it is to make that cached data item available in the query
used to populate the list, and fire off update requests to the worker
thread
as needed. Once the worker thread updates the cached item, the list
should
update automatically (since you mentioned that your data is in a content
provider).
You were saying something about buttons - how are you creating them, and
mapping to the right data item?
--
Kostya Vasilyev --http://kmansoft.wordpress.com
09.02.2011 1:04 пользователь "ivan"<istas...@gmail.com> написал:
The only manipulation to the view object is via the non-overridden
ResourseCursorAdapter bindView() function. On occasion this function
will block for a couple seconds maximum if a drm data cache is
occurring in another thread, but that thread never touches the view
object. Maybe waiting on a synchronized block of code (in the UI
thread) to get values from the multi-threaded cache causes the UI
thread to wait, releasing cycles to the UI thread, which in turn
allows the misplaced event to occur?
On Feb 8, 12:32 pm, Kostya Vasilyev<kmans...@gmail.com> wrote:
Are you sure that you only touch the ListView and its adapter from the
UI thread?
-- Kostya
08.02.2011 22:11, ivan пишет:
Thanks for the reply.
The button events are -- nine times out of ten -- tied to the
correct
data, but if you rapidly push a button you can throw an event that
will be tied to the wrong data. I thought that this didn't make
sense
since everything should be occurring on the UI thread (right?). But
it appears that the event can sneak in before the screen is actually
refreshed.
On Feb 8, 11:24 am, Kostya Vasilyev<kmans...@gmail.com> wrote:
If the button is linked to the wrong item, then you have a bug in
your
adapter's getView, where you're not properly associating the button
with
the item for the case where convertView != null.
As for performance, I find it useful, when refreshing a ListView
item
in
response to some event, to go through the visible list items, find
the
ones that are affected, and push new values into them right then
and
there, rather than calling notifyDataSetChanged / Invalidated.
-- Kostya
08.02.2011 19:47, ivan пишет:
Anyone?
On Feb 7, 4:33 pm, ivan<istas...@gmail.com> wrote:
I'm using a ResourceCursorAdapter to display a list of downloads
from
a ContentProvider that track's my application's downloads --
modeled
after Android's DownloadProvider.
The problem is that when a download is actively running it
frequently
calls bind view--every few seconds--to update a download progress
bar,
with a view object that is NOT currently associated with a given
cursor position. Thus, bind view is constantly recycling and
binding
view objects to new item/cursor positions.
This is especially a problem if the user attempts to push a
button
on
one of the items while it's being bound to a different view
object
and
cursor position, which results in an event being fired for the
wrong
data.
Does anyone have advice on how to minimize unnecessary view
recycling?
It appears to only occur for the bottom and top list items (of
the
three on the screen), while the middle item remains tied to a
single
cursor and view object.
Thanks,
-Ivan
--
Kostya Vasilyev -- WiFi Manager + pretty widget --
http://kmansoft.wordpress.com
--
Kostya Vasilyev -- WiFi Manager + pretty widget --
http://kmansoft.wordpress.com
--
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
--
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
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
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
