Bug 11279 - AdapterView subclasses should compile
Summary: AdapterView subclasses should compile
Alias: None
Product: Android
Classification: Xamarin
Component: Bindings ()
Version: 4.6.x
Hardware: PC Mac OS
: Low normal
Target Milestone: master
Assignee: Atsushi Eno
Depends on:
Reported: 2013-03-19 22:26 UTC by Jonathan Pryor
Modified: 2018-02-12 14:24 UTC (History)
5 users (show)

Tags: XATriaged
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 for Bug 11279 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Jonathan Pryor 2013-03-19 22:26:37 UTC
(Where making things generics breaks the generator...)


Consider AdapterView: http://developer.android.com/reference/android/widget/AdapterView.html

Unlike most other generic Java types, we provided a generic derived type:


Doing this brought about a bit of a problem: for user-written code, the AdapterView<T> type should be preferred, and to make things consistent with most existing Java tutorials, the AdapterView<T>.Adapter property should be of type T:

    class MyExample : AdapterView<Whatever> {
        public override Whatever Adapter {
            get {/*...*/}
            set {/*...*/}

This presents a bit of a problem, though, as AdapterView<T> inherits AdapterView, and AdapterView.Adapter is abstract; this C# code doesn't compile

    abstract class AdapterView : ViewGroup {
        public abstract Java.Lang.Object Adapter {get;set;}
    abstract class AdapterView<T> : AdapterView {
        public T Adapter {get; set;}

The above results in uninheritable code; it is not possible within C# to inherit AdapterView<T>, as AdapterView<T>.Adapter hides AdapterView.Adapter, thus preventing its implementation.

The solution was to this was to rename AdapterView.Adapter to AdapterView.RawAdapter:


The problem:

This is all fine and dandy, but it means that when binding a .jar that subclasses AdapterView, this implementation detail leaks, e.g.


The workaround:

Whenever binding a .jar that has a type which inherits AdapterView, a _new_ file needs to be added to the project which defines the RawAdapter property, e.g. for the above HZLVBinding project:

  using Android.Runtime;
  namespace Com.Devsmart.Android.UI {
    partial class HorizontalListView {
      protected override Java.Lang.Object RawAdapter {
        get {return Adapter.JavaCast<Java.Lang.Object>();}
        set {Adapter = value.JavaCast<global::Android.Widget.IListAdapter>();}

The namespace and class name need to _exactly_ match the AdapterView subclass that is being bound and is causing compilation errors.

The fix: generator should automate the above and generate the above RawAdapter property override when appropriate.
Comment 1 Atsushi Eno 2013-06-13 07:57:46 UTC
There is workaround. Plus, this kind of "special casing" is not desirable. There would be a lot of similar use of generics and they should be considered at a time.

We should consider "from scratch" for "perfect binding implementation" which means long term solution.
Comment 2 mwesolowski 2017-09-20 09:15:38 UTC
We have the same issue. Any progress with "from scratch" for "perfect binding implementation"?