Xamarin.Forms - Are PCL projects supported?

[CristianMadularu]

Hi, 

I recently started testing the Esri-ArcGIS set of libraries in some Xamarin Forms mini test projects. My tests looked promising which is why I started porting some of the code to one of our main Xamarin Forms solutions.

This solution is PCL based (vs shared).

I was not able to find a nuget package that would allow me to target the PCL project (where my pages using the MapView control would be).

Any suggestions?

Thank you,

 Cristian 

[dotMorten_esri · Accepted solution]

PCLs are not supported. You need to use the shared Xamarin.Forms project template.

[CristianMadularu]

Hi Morten, 

Thank you for the quick reply.

I believe that to be a severe limitation. Most large applications would not use shared projects. They would be PCL based. There are reasons for that, but, probably one of the most important one would be the better unit testing support the PCL projects offer. Also, it is also likely that potential map consumers may want to add the Esri map into their already exiting PCL based projects.

If I may suggest, supporting PCL should not be complicated. Behind the scenes you would still have platform specific implementations but you would need to abstract the implementation and then have some initialization code in the platform specific project. (Similar to the way the Map is abstracted in Xamarin Forms). 

In my case, after some digging, I was able to use the ArcGIS map in a project based on a PCL template using some IOT (Unity in my case) magic

Thank you,

 Cristian

[dotMorten_esri]

I understand the need for also supporting PCL, but we just can't support it the way PCLs are limited today.

We are considering supporting .NET Standard 2.0 in the future, as this looks to be resolving some of the limitations that PCLs are adding.

> If I may suggest, supporting PCL should not be complicated

True PCL isn't necessarily complicated, but in this case we're hitting "impossible", or we'll be creating an API that would be detrimental to developer ease of use. We chose to favor an easy to use API over a bunch of abstraction levels.

> Most large applications would not use shared projects

I'm curious why you are so much against shared over PCL, or what this statement is based on? You're still able to share code in a single project. Yes it creates a binary per platform, and you reference a project over a binary, but for the most part users use project references, and at the same time you'll never hit the "PCL Wall" and can always add #if-def in a few platform abstraction methods. I understand you don't get a common library binary .dll you can reference, but you would still be able to create a single nuget .nupkg you can reference in all your projects.

[CristianMadularu]

The reason I am avoiding using shared is the unit testing support. I want to be able to be able to unit test as much a possible.

Now, with the imminent release of .net standard 2.0, I converted my PCLs to standard, but still, I want to avoid shared for the reason mentioned above.

Thanks,

 Cristian

PS: Sorry for the late reply.

[dotMorten_esri]

You can still unit test your libraries. In fact your unit test projects in Xamarin and UWP are actual non-pcl platform apps that you run (there's no such thing as a PCL app - only libraries can be PCL - once a library makes it into an app it's no longer PCL).

So... all you need to do is reference the shared library in each of your (otherwise empty) unit test project heads.

[CristianMadularu]

Would you agree with this post? https://xamarinhelp.com/portable-class-library-pcl-vs-shared-projects/  

[dotMorten_esri]

Whether I agree or not is a moot point. Just to recap what I said:

1. We cannot deliver the ArcGIS Runtime as a PCL due to technical limitations of PCL.

2. You can still accomplish all the same things with a shared library that PCL can (and then some), without duplicating any code. The only difference is whether you are referencing a compiled binary or a shared project from your app (or unit tests).

Now our hope is to be able to support .NET Standard 2.0 (or newer) in the future, as this resolves most of our issues. However requiring 2.0 Standard means two things that currently preventing us from going there.

1. Libraries needs to be split in two halves - (the UI can't be .net standard compliant and needs to be in a non-standard lib), and some types needs to be changed or abstracted.

2. Minimum system requirements go from .NET 4.5.2 to 4.6.1 in WPF.

Both of these would cause major breaking changes, and we are not currently in a position to do that. But we are working towards setting ourselves up for hopefully going there in the future and have active work in that area.

[CristianMadularu]

Thank you.

In my case I was able to work around it using dependency injection. I registered the type in the platform specific and resolved it at run time in the PCL.

Thank you for your time and quick reply,

Cristian

[dotMorten_esri]

...btw here's a different opinion by Mr Xamarin himself. http://tirania.org/blog/archive/2016/Jan-22.html

FYI I'm try to saying that there's a right and wrong way. There's different priorities, and sometimes there are even "impossibilities". (I'm putting it in quotes, because sure the ArcGIS Runtime can to some extent be a PCL, but it would be at a big cost of other things)