Limitations of Portable projects vs. Shared projects

VagifAbilovVagifAbilov Vagif AbilovNO ✭✭

I suppose using Shared template gives more flexibility because the code in the shared project can contain platform-specific parts switched by compile-time directives. But for the same reason (platform-specific #if directives) I find PCL approach cleaner. When it works. I'd like to know from those who tried both, what do you prefer? When do you use each of them?

Vagif

Posts

  • MarkSmith.8123MarkSmith.8123 Mark Smith USXamarin Team, University, XamUProfessors Xamurai

    Great question - and one I suspect will have many opinions :-)

    My personal preference is to use PCLs. It forces me to think about what I can share and what I cannot, and it allows me to unit test the PCL logic - I can't do that with a Shared Project (without hosting it somewhere else).

    But, it really kind of depends on what you plan to do with the code. If it's just for a single app, and you have a small team (or even just one developer), then Shared Projects are more versatile and will allow you to add platform-specific features much easier.

    However, because of that versatility, it also makes it really easy to produce hard-to-maintain code that has subtle bugs due to conditional compilation - particularly once you try to use it cross-application. You can use partial classes/methods to avoid this, but it's not enforced and you won't know it's broken until you try to compile/test it for each app.

  • VagifAbilovVagifAbilov Vagif Abilov NO ✭✭

    Thanks for the quick response and great answer. I share your view on advantages of PCLs when it comes to better code partitioning. But have you experienced situations when you had to switch from PCL to Shared projects because you couldn't achieve certain goals using PCLs?

  • TheRealJasonSmithTheRealJasonSmith Jason Smith USXamarin Team Xamurai

    Xamarin.Forms is (obviously) written without any shared projects. I believe most any issue with PCL can be resolved with good dependency injection and proper architectural design. Though if you need to interop with a LOT of third party libraries, you might end up writing a lot of wrappers to do that. I think this is where Shared Projects can really shine!

  • VagifAbilovVagifAbilov Vagif Abilov NO ✭✭

    Thanks Jason! That sounds promising.

  • KevinFordKevinFord Kevin Ford USUniversity, Certified XTC Partners ✭✭✭

    Personally I prefer shared projects which are really just an easier way to do code linking. Yes with PCLs you can get around platform specific limitations with DI but that adds more complexity to your application and you have to pay attention to what PCLs you can reference from your PCL. Granted an overuse of #ifs in your shared projects leads to hard to read/maintain code so you have to be careful there too.

    If you do PCLs you will have trouble referencing other assemblies, particularly non-PCLs. With shared projects you will have a lot easier time referring other projects that may only have native versions of the platforms you need but no PCL but in so doing PCLs won't easily be able to use your native assemblies (without using DI or similar).

    As others have indicated I don't think there is a clear one size fits all choice here and which to use would seem to depend on the situation and team.

  • Kon_Kon_ Konstantin Mayarovich USMember
    edited March 2016

    I've read some pretty good answers here, but didn't see anything (maybe I missed it) regarding app performance and file size. Does shared vs PCL impact performance or file size one way or another? Thanks in advance.

  • AdamPAdamP Adam Pedley AUUniversity ✭✭✭✭✭

    @Kon_ - In most applications or with proper design a shared project vs PCL won't see any significant difference in performance or file size.

    Using a lot of PCL libraries might add a slight increase in size over a shared project but again nothing significant since you would have to write native code for each function anyway.

    And if you are calling your DI Framework hundreds of thousands of times then that would cause a perf decrease but if you are in that situation I think the architecture of the app would be incorrect.

    Also this forum post went through PCL vs Shared a bit more: http://forums.xamarin.com/discussion/59381/why-shared-projects/

  • ThomasBurkhartThomasBurkhart Thomas Burkhart DEMember ✭✭✭✭

    Just to add, that at the Moment XF with Xaml does not work for UWP with shared projects. I started with a shared project but changed it to a PCL without any problems.

    @AdamP correct me, but if I store the Interface Reference I get from DI in my PCL there shouldn't be any performance drawbacks.

  • AdamPAdamP Adam Pedley AUUniversity ✭✭✭✭✭

    @ThomasBurkhart - thats right, you wouldn't get any performance penalty if you stored the reference there.

  • jeffchen2002jeffchen2002 qinfu chen USMember

    which category, PCL or shared project does xamarin form belong to ? thanks

  • ThomasBurkhartThomasBurkhart Thomas Burkhart DEMember ✭✭✭✭

    @jeffchen2002 You can built Xamarin Form projects as PCL or as Shared projects. But PCL is recommended

  • jeffchen.5589jeffchen.5589 jeff chen USMember

    after creating the pcl, my InitializeComponent(); is not recoginized. but it is compiled.

    public partial class Page1 : ContentPage
    {
    public Page1()
    {
    InitializeComponent();
    }
    }

Sign In or Register to comment.