Bug 10710 - Since upgrading to 4.6 OsmDroidThirdParty fails to build
Summary: Since upgrading to 4.6 OsmDroidThirdParty fails to build
Status: RESOLVED FEATURE
Alias: None
Product: Android
Classification: Xamarin
Component: Bindings ()
Version: 4.6.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Atsushi Eno
URL:
Depends on:
Blocks:
 
Reported: 2013-02-26 21:24 UTC by Jeremy Kolb
Modified: 2013-03-01 07:14 UTC (History)
1 user (show)

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


Attachments
ZIP containing projects (1.75 MB, application/x-zip-compressed)
2013-02-26 21:27 UTC, Jeremy Kolb
Details


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 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.

Related Links:
Status:
RESOLVED FEATURE

Description Jeremy Kolb 2013-02-26 21:24:52 UTC
Attached are two bindings projects.  OsmDroidThirdParty depends on OsmDroid and it won't build anymore complaining about:

2>C:\Projects\OsmDroidJavaBindings\OsmDroidThirdParty\obj\Debug\generated\src\OsmDroid.TileProvider.TileSource.Bing.BingMapTileSource.cs(8,23,8,40): error CS0535: 'OsmDroid.TileProvider.TileSource.Bing.BingMapTileSource' does not implement interface member 'OsmDroid.TileProvider.TileSource.IStyledTileSource.SetStyle(string)'
2>C:\Projects\OsmDroidJavaBindings\OsmDroidThirdParty\obj\Debug\generated\src\OsmDroid.TileProvider.TileSource.Bing.BingMapTileSource.cs(8,23,8,40): error CS0738: 'OsmDroid.TileProvider.TileSource.Bing.BingMapTileSource' does not implement interface member 'OsmDroid.TileProvider.TileSource.IStyledTileSource.Style'. 'OsmDroid.TileProvider.TileSource.Bing.BingMapTileSource.Style' cannot implement 'OsmDroid.TileProvider.TileSource.IStyledTileSource.Style' because it does not have the matching return type of 'Java.Lang.Object'.

This seems to be a regression.
Comment 1 Jeremy Kolb 2013-02-26 21:27:41 UTC
Created attachment 3493 [details]
ZIP containing projects
Comment 2 Jeremy Kolb 2013-02-28 18:10:41 UTC
I'm not sure why IStyledTileSource worked before.
Comment 3 Atsushi Eno 2013-03-01 07:14:06 UTC
We have extended support for generics in our jar binding projects which often brings more API, and sometimes results in interface mismatch caused by Java variants. This is not a regression but a new emerged API mismatch between Java and .NET that needs manual fix.

BingMapTileSource implements IStyledTileSource<String> but generic parameter is not expanded in the interface itself. Thus, while Java implements this generic parameter in IStyledTileSource as string in BingMapTileSource, the interface actually expects Java.Lang.Object, which is what JNI expects.

To resolve this mismatch, add the source code below:

--------
using System;
using System.Collections.Generic;
using Android.Runtime;

namespace OsmDroid.TileProvider.TileSource.Bing {
	
	public partial class BingMapTileSource : global::OsmDroid.TileProvider.TileSource.QuadTreeTileSource, global::OsmDroid.TileProvider.TileSource.IStyledTileSource {
		Java.Lang.Object OsmDroid.TileProvider.TileSource.IStyledTileSource.Style {
			get { return new Java.Lang.String (Style); }
			set { Style = (string) value.JavaCast<Java.Lang.String> (); }
		}

		void OsmDroid.TileProvider.TileSource.IStyledTileSource.SetStyle (string value)
		{
			Style = value;
		}
	}
}


(There is no formalized way that a Java interface use is bound to certain generic parameter, at least so far, so we don't give explicit interface implementation.)