'DownloadDrawablesAsync' does not implement inherited abstract member 'AsyncTask.DoInBackground(params Object[])'

[fernandovm]

When I try compile a binding to google mediation mopub adapter I get the error 'DownloadDrawablesAsync' does not implement inherited abstract member 'AsyncTask.DoInBackground(params Object[])'

Steps to Reproduce

1. Try compile the attached sample project Google.Ads.Mediation.Mopub.zip

Expected Behavior

A successful build.

Actual Behavior

1>C:\Users\fernando\source\repos\Google.Ads.Mediation.Mopub\Google.Ads.Mediation.Mopub\obj\Debug\generated\src\Com.Mopub.Mobileads.Dfp.Adapters.DownloadDrawablesAsync.cs(10,23,10,45): error CS0534: 'DownloadDrawablesAsync' does not implement inherited abstract member 'AsyncTask.DoInBackground(params Object[])'

Version Information

Microsoft Visual Studio Enterprise 2019
Version 16.5.5
VisualStudio.16.Release/16.5.5+30104.148
Microsoft .NET Framework
Version 4.8.03752

Installed Version: Enterprise

Xamarin 16.5.000.533 (d16-5@9152e1b)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 16.5.0.470 (remotes/origin/d16-5@681de3fd6)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates 16.5.49 (0904f41)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK 10.2.0.100 (d16-5/988c811)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: c0c5c78
Java.Interop: xamarin/java.interop/d16-5@fc18c54
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-5@9f4ed4b

Xamarin.iOS and Xamarin.Mac SDK 13.16.0.13 (b75deaf)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

[moljac]

@fernandovm
If bindings project would be that easy... We are trying to make bindings projects easy, but it will work only in ideal case.

In your case you are inheriting a type and binding generator generates code w/o compiling (or even better semantically analysing the code), so the only way is to tweak class inheritance (metadata) with metadata transforms in metadata.xml:

1. remove base class - NO-NO
2. check if the method is generated and why c# has issues with it

So that method was generated:

		// Metadata.xml XPath method reference: path="/api/package[@name='com.mopub.mobileads.dfp.adapters']/class[@name='DownloadDrawablesAsync']/method[@name='doInBackground' and count(parameter)=1 and parameter[1][@type='java.lang.Object...']]"
		[Register ("doInBackground", "([Ljava/lang/Object;)Ljava/util/HashMap;", "GetDoInBackground_arrayLjava_lang_Object_Handler")]
		protected virtual unsafe global::System.Collections.Generic.IDictionary<string, global::Android.Graphics.Drawables.Drawable> DoInBackground (params global::Java.Lang.Object[] @params)
		{
			const string __id = "doInBackground.([Ljava/lang/Object;)Ljava/util/HashMap;";
			IntPtr native__params = JNIEnv.NewArray (@params);
			try {
				JniArgumentValue* __args = stackalloc JniArgumentValue [1];
				__args [0] = new JniArgumentValue (native__params);
				var __rm = _members.InstanceMethods.InvokeVirtualObjectMethod (__id, this, __args);
				return global::Android.Runtime.JavaDictionary<string, global::Android.Graphics.Drawables.Drawable>.FromJniHandle (__rm.Handle, JniHandleOwnership.TransferLocalRef);
			} finally {
				if (@params != null) {
					JNIEnv.CopyArray (native__params, @params);
					JNIEnv.DeleteLocalRef (native__params);
				}
			}
		}

So why does it not build?

Because Mopub version returns System.Collections.Generic.IDictionary<string, global::Android.Graphics.Drawables.Drawable>, while AsyncTask returns Java.Lang.Object

see: https://docs.microsoft.com/en-us/dotnet/api/android.os.asynctask.doinbackground?view=xamarin-android-sdk-9#Android_OS_AsyncTask_DoInBackground_Java_Lang_Object___

So if add this to your metadata.xml:

    <attr
        path="/api/package[@name='com.mopub.mobileads.dfp.adapters']/class[@name='DownloadDrawablesAsync']/method[@name='doInBackground' and count(parameter)=1 and parameter[1][@type='java.lang.Object...']]"
        name="managedReturn"
        >
        Java.Lang.Object
    </attr>

It should have the same signature as method in the base class, but the error persists.

@jpobst @jonpryor

This will make your code build (at least it did in my code):

    <remove-node
        path="/api/package[@name='com.mopub.mobileads.dfp.adapters']/class[@name='DownloadDrawablesAsync']/method[@name='doInBackground']"
        />
    <add-node
        path="/api/package[@name='com.mopub.mobileads.dfp.adapters']/class[@name='DownloadDrawablesAsync']"
        >
        <!--
        java.util.HashMap&lt;java.lang.String, android.graphics.drawable.Drawable&gt;
        -->
      <method 
            visibility="protected" static="false" abstract="false" return="java.lang.Object" name="doInBackground" 
            deprecated="not deprecated" final="false" bridge="false" native="false"
            synchronized="false" synthetic="false" 
            >
        <parameter type="java.lang.Object..."  name="params" >
        </parameter>
      </method>
        
    </add-node>

I will create repro sample in the repo and post it here.

[moljac]

I managed to bind v.5.4.1 without any metadata.

There is something in v.5.12.0

OK mvnrepository does not have the latest version, but bintray:

https://bintray.com/mopub/mopub-android-sdk/mopub-android-sdk/_latestVersion

5.12.0 builds w/o issues and metadata too

https://github.com/HolisticWare/HolisticWareComponents/tree/master/XPlat/Mopub

Seems that new and old style projects (and tooling) do make the difference:

https://github.com/HolisticWare/HolisticWareComponents/blob/master/XPlat/Mopub/source/Mopub.XamarinAndroid/Mopub.XamarinAndroid.csproj

[jpobst]

I'm not sure why managedReturn isn't good enough. Switching it to return will build:

<attr
    path="/api/package[@name='com.mopub.mobileads.dfp.adapters']/class[@name='DownloadDrawablesAsync']/method[@name='doInBackground' and count(parameter)=1 and parameter[1][@type='java.lang.Object...']]"
    name="return">
    Java.Lang.Object
</attr>

That's generally frowned upon as it messes with the type that gets sent to Java, so you will need to test it before you ship it. (This is effectively what @moljac's <remove-node>/<add-node> is doing.)

[jpobst]

For internal investigation:

There's 2 issues with what gets generated for managedReturn:

[Register ("doInBackground", "([Ljava/lang/Object;)Ljava/util/HashMap;", "GetDoInBackground_arrayLjava_lang_Object_Handler")]
protected virtual unsafe global::Java.Lang.Object DoInBackground (params global::Java.Lang.Object[] @params)
{
    const string __id = "doInBackground.([Ljava/lang/Object;)Ljava/util/HashMap;";
    IntPtr native__params = JNIEnv.NewArray (@params);
    try {
        JniArgumentValue* __args = stackalloc JniArgumentValue [1];
        __args [0] = new JniArgumentValue (native__params);
        var __rm = _members.InstanceMethods.InvokeVirtualObjectMethod (__id, this, __args);
        return global::Android.Runtime.JavaDictionary<string, global::Android.Graphics.Drawables.Drawable>.FromJniHandle (__rm.Handle, JniHandleOwnership.TransferLocalRef);
    } finally {
        if (@params != null) {
            JNIEnv.CopyArray (native__params, @params);
            JNIEnv.DeleteLocalRef (native__params);
        }
    }
}

1. It is virtual rather than override. (managedType parameter overrides don't influence override detection #586)
2. The binding code is returning JavaDictionary<string, Drawable> instead of JLO.

[jonpryor]

@jpobst asked:

I'm not sure why managedReturn isn't good enough.

It's not good enough because managedReturn only changes the declared return type, and nothing in the body. The problem is that JavaDictionary<T>.FromJniHandle() returns an IDictionary<TKey, TValue>, which is not implicitly convertible to Java.Lang.Object, hence the compilation error.

[jonpryor]

The problem with the "just change the return type" approach, suggested by @jpobst and @moljac, is that it will break subclassing and overriding, because the return type is used to tell the Java Callable Wrapper generator what Java return type to use. By altering it to be java.lang.Object, the JCW return type will likewise be java.lang.Object, which is not the original java.util.HashMap or a subclass thereof.

The result will be Java Callable Wrapper generator errors from javac.

[moljac]

@jonpryor @jpobst

If such metadata fails (like my attempt to change managedReturn) would it be possible to emit warning or error in such case?

[jonpryor]

What we need is a (not fully specified or thought-out) generator "solution" which allows the Java & managed return types to "diverge" in more significant ways than what managedReturn currently allows.

For example, if there was an implicit conversion from IDictionary & other collection types to Java.Lang.Object, managedReturn would likely work as-is:

partial class /* Java.Lang */ Object {
    public static implicit operator Java.Lang.Object (IDictionary value) => new JavaDictionary (value);
    // ...
}

While this "works," is this something we want to support? (Though Java.Lang.Object already has a ton of implicit conversion operators, so perhaps this is "fine"…)

Alternatively, could we allow generator to detect that the types aren't implicitly convertible, e.g. that IDictionary isn't implicitly convertible to Java.Lang.Object, and in such instances insert an appropriate .JavaCast<T>?

return JavaDictionary<string, Drawable>.FromJniHandle (__rm.Handle, JniHandleOwnership.TransferLocalRef)
    .JavaCast<Java.Lang.Object> ();

Though as-is, this would also require some additional "glue code" to add a new .JavaCast<T>() extension method that operates on IDictionary/etc.

[jpobst]

@moljac The thing is your metadata doesn't "fail". If it couldn't match anything it would have given you an error like: <attr path=\"{0}\"/> matched no nodes..

All metadata does is modify the api.xml using XPath, it doesn't understand what that actually is, and it is successfully adding the managedReturn attribute.

It just happens to be a successful change that doesn't fix the issue. 😄