Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 3120 [details]
Issue on both 4.4.41 and 4.4.50
The adapter moves reused views after updating from a smaller source list.
It's a listview with a custom adapter built on top of BaseAdapter.
It sets text, changes background (in this case it's always the same) and sets padding (in this case also always the same) Everything is ok then I modify the list, do a NotifyDataSetChanged only one item and everything is okay. Then modify again, 3 items again NotifyDataSetChanged. I tried invalidating the textview, the parent view, the list
also post invalidating nothing works there's one thing that works, but it's not correct the adapter does this
View view = ( convertView ?? inflater.Inflate( _ViewResourceId, parent, false ) );
in the GetView() method to reuse the view if it's already created if I never reuse, this doesn't happen. Also, if the list never shrinks to one element, this also doesn't happen. I even started a new project, passed the same structure, the same behavior
There's a background thread, started on OnResume() that is updating a TextView on top. If I don't start the thread, the adapter updates well. Seems like the textview on top is somehow affecting the layout arrangement, which doesn't make much sense. Also, it doesn't happen if I keep the adapter source always with a few items. Only by setting the list to one
item and then again to more I could make this happen.
I'm using a custom adapter, based on BaseAdapter, where I have an array for the source, implementing Count property and GetView method. I'm also reusing the convertView when possible, which seems to be linked to the problem (or not), because if I don't reuse (always inflate a new one) the problem goes away.
Workarounds: Remove Activity.RunOnUiThread( () => ellapsedStatusView.SetText( text, TextView.BufferType.Normal ) );
and it runs fine
on top, the second line has two textviews. One for a description and the other one for the timer increasing the last one is the one accessed by the thread. They are both in a layout and the description has a weight of 1 timer has a weight of 0 wrong timer has wrap_content for width I changed this, setting description with a weight of .70 and timer with weight of .30 also changed width to 0 obviously it works even with gravity set to right|center_vertical
Even though I can't reproduce this every time, sometimes I still get the messed up layout(after applying the layout weight fix).
I would appreciate a different importance on this.
I'm currently on 4.4.54.
Created attachment 3169 [details]
Test case - no fragments
Created attachment 3171 [details]
java test case
After spending too much time porting the test case to eclipse... looks like the problem is with Android... the same happens with the java version. I'm adding the java test case.
@+id/linearLayout5 layout was also set to use weight. I changed this to wrap_content, combined with the other weight fix I had already applied and it seems to fix both scenarios. Can't seem to mess the layout anymore.
This is still a bug, but seems like an Android bug. I tried with different devices and in all I had the same result (2.3.3, 3.2 and 4.0.3).
I guess this can be marked as won't fix or something. Thank you Allie, Chris and anyone else that wasted time with this.
Closing as an Android issue, as per Comment #4.