[Xamarin Android Chart]: Duplicate managed type found!

#1

Hi,

When referencing ‘Com.ChinnobiControls.Charts’ from a Xamarin Android project (with API levevel 15, i.e. Android 4.0 and above) I get an ugly error message:

Duplicate managed type found! Mappings between managed types and Java types must be unique.
First Type: ‘Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, Mono.Android.Support.v13, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065’;
Second Type: ‘Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, Mono.Android.Support.v4, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065’

I do have a dependency to Android.Support.v13 API to get access to the ViewPager stuff.

Does ShinobiChart expose, reference or link to Support.v4 library and thus causing this error?

I guess this is the case, and it would be nice if Shinobi could be clean without requiring user having to use the same references to get it to work. I you need to provide the ChartFragment to be v4 compatible it should go into a separate assemly (maybe built against different support package) that I could opt-in if I would like to use it.

Best Regards 
Lars Krog-Jensen

#2

Hi Lars,

Yes, the Xamarin bindings for ShinobiCharts do need to reference Support.v4 in order to bind our SupportChartFragment class.

The root of the problem is that Xamarin have 2 assemblies containing the same Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor class, in the same namespace, unlike the Java case where they have different package names… This problem is not confined to Shinobi, see http://forums.xamarin.com/discussion/4504/build-errors-when-using-mono-android-support-v13 from back in May, before we released.

Your suggestion of splitting the Shinobi dll is interesting, though it only diminishes the problem rather than solving it - it remains for anyone who wants to use SupportChartFragment, or whose app uses any othe libraries (as in the link above) that also reference Support.v4

Robin

#3

Hi Robin,

By splitting it wisely the problem goes away, the Shinobi chart in is own assembly without any fragment references at all, then one SupportV4 and one SupportV13 where the specific fragment versions go. Thus ShinobiChart.dll, ShinobiChart.SupportV4.dll and ShinobiChart.SupportV13.dll, this way I can choose depending on my needs. (You can even use the same class name, ChartFragment, in the v4 version aswell, as there will only be either v4 or v13 around). For my particular needs, I have to use the ChartView directly instead of the supplied fragments as my chart fragment needs to extend a custom framework fragment base anyway.

More and more android projects are like us targeting android >=4 only, see a good writup on why: http://dannyroa.com/2013/10/17/why-its-time-to-support-only-android-4-0-and-above/.

As of today our app is using android standard ActionBar, NavigationDrawer and Fragments heavily, and reverting to myriad of compat libs is not an option. 

Finally, an interesting note is that in release mode (with link all assemblies turned on) the linker seems to do a good job stripping out enough for the build to succeed, though haven’t tried it on a real device. But this is not an option in debug development as this linking is slooow.

Regards
Lars

#4

Hi Lars,

I’ve been in touch with Xamarin and this is a bug in their framework, see https://bugzilla.xamarin.com/show_bug.cgi?id=15205, particularly the response by Jonathon Pryor.

We will not, therefore, be putting any change into the Shinobi bindings until we see what their fix is, and what their recommendations are.

However, this doesn’t help you much, so if you would like to email us at info@shinobicontrols.com, I can let you have a special one-off build of the V1.2 bindings dll with the Mono.Android.Support.v4 reference removed. 

Best regards,

Robin Sillem

#5

Hi Robin,

Thanks alot for this kind suggestion, I will get in touch on the info@ adress.

Regards
Lars

#6

Any updates? Xamarin marked the referenced error as WONTFIX. I downloaded the trial version of the charts library and in an existing project referencing V13 support library (used for ViewPager/FragmentPagerAdapter with non-support FragmentManager, which rules out using the V4 support library) I can only get it to compile by removing the SupportChartFragment* classes via ILDASM and the corresponding entries in __TypeRegistrations, which I am probably not legally allowed to do. Do you plan of fixing this (ie. separate builds of the bindings, as suggested), if not, what price plan, if any, is required to get a legal private build of the bindings without the Support classes?

#7

Hi there,

As it looks like this issue won’t be addressed by Xamarin we are going to investigate ways in which we can help our users in the same situation as yourself. I do like the idea of splitting out the library over support library specific DLLs but whether that’s the way we end up going remains to be seen.

For the time being, feel free to get in touch via info@shinobicontrols.com and we’ll see if we can help you out in the interim. However, one alternative you could try straight away is making your own ChartFragment using a ChartView. The most important life cycle events that you need to forward on from the Fragment to the ChartView are onPause and onResume (see the CustomDataAdapterChartView sample project in the download bundle). The ChartFragment is also retained across Activity re-creation by default so depending on your app’s needs you may want to switch that on as well.

Kind regards,

Patrick

#8

Thanks for the reply. I am using ChartView with the “hacked” version of the library already - note that the problem is not the inability to use the ChartFragment, Support or otherwise, but the inability to compile the project at all if it uses the Support library other than V4. I’ll contact you about the “hacked” part after we buy the library, which is soon.