How to resolve a platform specific interface implementation from a PCL

So far I've seen a very elegant solution for Xamarin.Forms here and a simple solution for PCL here

What is the official way to:

  1. Create a singleton instance in a** platform specific library** (e.g: UWP)
  2. Use that instance in the PCL

Is there such thing as DependencyService for PCL libs?

Answers

  • XavierRigauXavierRigau ✭✭ USMember ✭✭

    You just pointed to my link. I am doing a PCL lib not a Xamarin.Forms app.

  • ClintStLaurentClintStLaurent ✭✭✭✭✭ USUniversity ✭✭✭✭✭

    Sorry... Saw this

    Is there such thing as DependencyService for PCL libs?

    And supplied the link for it.

    So now I'm lost as to what the problem is. You have a Xamarin.Forms solution. Its PCL. You need to get the platform-specific implementation of a class.

    So far this all sounds like flat, standard DependencyService stuff. I'm missing the complication. Can you rephrase it?

  • XavierRigauXavierRigau ✭✭ USMember ✭✭

    I don't have a Xamarin.Forms solution. My solution has UWP/iOs/Android/MacOSX projects, UWP/iOs/Android/MacOSX libraries one PCL library. The platform specific libraries provide the implementation of IWhatever and I want to use the single instance of IWhatever inside my PCL library. My PCL project cannot use Xamarins.Forms.DependencyService because is not a Xamarin.Forms project.

  • ClintStLaurentClintStLaurent ✭✭✭✭✭ USUniversity ✭✭✭✭✭

    Ahhhhhhhhhhhh.... Ohhhh......... ewwww............ Now I see the dilemma.

    Hmmm... Some form of dependency injection maybe?
    Android|MainActivity makes a new instance of the solid IWhatever implementation, then passes it as a parameter to the creation of the App class?

                var pf = new CoolApp(concreteWhatever);
                LoadApplication(pf);
    
  • XavierRigauXavierRigau ✭✭ USMember ✭✭

    I am trying to avoid MEF and any other over complicated DI solutions.

  • ClintStLaurentClintStLaurent ✭✭✭✭✭ USUniversity ✭✭✭✭✭

    I didn't consider that 'complicated' - and it doesn't need MEF.

    The platform project has to make a new instance of the App class regardless. Just pass it the instance of the concrete IWhatever implementation as a parameter.

    The downside is you hang on to that instance for the lifespan of the app. The upside is you don't have long delays while you make new instances and walk through any constructor operations. 6 of one, tomato of another.

  • XavierRigauXavierRigau ✭✭ USMember ✭✭

    This is in the scope of a library and the class has to be a singleton and capable or be initialized during static class construction. So far I am using:

    in the PCL:

    public static class WhateverGlobal
    {
        public static IWhatever Instance;
    }
    

    in every platform Library:

    public class Whatever : IWhatever
    {
        static Whatever()
        {
            WhateverGlobal.Instance = new Whatever();
        }
    

    ....
    }

  • ShimmyWeitzhandlerShimmyWeitzhandler ✭✭✭ USMember ✭✭✭

    I'm using Prism.DryIoc, but my question applies to any DI container.

    How do I resolve the IEventAggregator in the platform specific projects? How do I resolve the IContainer itself?

  • colinedwardscolinedwards ✭✭ USMember ✭✭

    you don't resolve services... you inject them, that's why it's called DI... resolving services is an anti pattern referred to as the 'service locator pattern'.

  • colinedwardscolinedwards ✭✭ USMember ✭✭

    I think the issue here is.. what's the answer for 'net standard 2' and 'bait and switch'? the facility to make available rich platform specific classes / services through a single common package. today this probably centres around UI drawing elements as that seems to me to be the last bastion of 'evil'.

Sign In or Register to comment.