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.
I have checked this issue and able to reproduce it successfully. To reproduce this issue I have followed below steps.
1. Open attached test case in XS.
2. Deploy on Android Emulator.
3. Click on 'Dashboard' button.
I observe that when click on the 'Dashboard' button it is called each position multiple times same as in screen cast: http://www.screencast.com/t/hcnQ8Lgujj
Application Output: https://gist.github.com/Mohit-Kheterpal/cf596a20b0c80997e119
Ide log: https://gist.github.com/Mohit-Kheterpal/1fbf9320f00717ef6b58
XAP log: https://gist.github.com/Mohit-Kheterpal/af9681938e76c33631e1
=== Xamarin Studio ===
Version 5.7.2 (build 1)
Installation UUID: 3dbf10c4-ed30-4e55-8a8b-1704777c7b5f
Mono 3.12.0 ((detached/de2f33f)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000076
=== Apple Developer Tools ===
Xcode 5.1.1 (5085)
=== Xamarin.iOS ===
Version: 220.127.116.11 (Business Edition)
Build date: 2015-02-15 22:17:46-0500
=== Xamarin.Android ===
Version: 18.104.22.168 (Business Edition)
Android SDK: /Users/apprpject/Desktop/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
=== Xamarin.Mac ===
Version: 22.214.171.124 (Business Edition)
=== Build Information ===
Release ID: 507020001
Git revision: 103486e2547553077836a5ba20a973487b983830
Build date: 2015-02-13 11:56:36-05
Xamarin addins: 8dd5b934e86ef0595c022dd3930fd40e3376ab4c
=== Operating System ===
Mac OS X 10.8.5
Darwin localhost 12.5.0 Darwin Kernel Version 12.5.0
Sun Sep 29 13:33:47 PDT 2013
Why do you believe that this is a problem?
Do you have a Java sample that indicates that behavior differs from what you're seeing in C#?
Having Adapter.getView() called multiple times is not unexpected:
> there is absolutely no guarantee on the order in which getView()
> will be called nor how many times.
You're even hitting the exact scenario he points out:
> In your particular case you are doing the worst thing possible
> with a ListView by giving it a height=wrap_content. This forces
> ListView to measure a few children out of the adapter at layout
> time, to know how big it should be.
as AndroidControls/Resources/layout/DropDownListItemTemplate.axml contains:
I see what you are saying, but even after removing android:layout_height="wrap_content" the GetView is getting called multiple times.
There are couple of posts that does mention that if you change the android:layout_height from "wrap_content" to a static height or fill_parent, the getview will get called only once.
We have other adapters that we use to show "Card Stacks" & all where this behavior is not exhibited. I am wondering why this behavior is only enhibited in the Spinner.
If this is the expected behavior anyways, are there any recommendations as to how we can improve the performance. Our pages are becoming slow terribly as part of this problem.
> If this is the expected behavior
"Expected behavior" is "whatever Java does." (Within "reason" .) The end.
As such, if you can create a Java app that does the same thing that results in different behavior, *then* I'd be more than happy to investigate further.
At present -- in the interests of not spending too much further time on this issue -- this resembles fairly well known Java behaviors, and thus doesn't appear to be an actual Xamarin.Android bug. It's a "feature"/"behavioral-ism" of the underlying Android platform, and is thus -- short of a "ported Java counterexample" -- Not My Problem™. ("Me" being "the binding guy." It could still fall under the purview of documentation and other teams, but they tend not be on bugzilla.)
> are there any recommendations as to how we can improve the performance.
The general performance-related advice I give is "reduce GREFs as much as possible."
Any Java guides on the performance aspects of .xml layout files should also be applicable.
: I'll make exceptions for things that would otherwise require translating IL to Java byte code to obtain "expected behavior" or would otherwise bloat things, e.g. mirroring *all* members on Android Callable Wrappers without requiring [Export]/etc.