In this article, we will learn how to use abstractions to implement platform specific functionality in our xamarin forms shared code. Therefore, xamarin forms has some useful API s but it does not expose everything from the platform. In fact, it's very likely there'll be some feature that you need to use which is not available to your shared code for these cases we have to put a little architecture thought into our application. We want to use the API is available in the platform specific project but somehow invoke them from our shared code.
As an example consider dialling the phone all three platforms have support for this feature but each one accomplishes it differently to fully control it we would want to write that code uniquely per platform. Let’s explore what xamarin forms has to offer here platform features not expose those xamarin forms can be used but will require some architectural design.
First, you want to create some form of abstractions that might be an interface or base class that is something to represent the feature that you want to use in your shared code. The best practice is to build an abstraction implemented by the target platform which defines the platform specific functionality .Here we define an IDialer interface which describes how our code will dial the phone on each platform then in each of the platform specific projects we'll implement that interface using the platform specific API which is available to us in those projects. Our shared code will always use the interface which means it's not tied directly to the implementation or platform-specific code projects implement the shared Dialer interface using the platform specific api to locate the implementation. We can use a variety of techniques often it's either a variation of the service locator design pattern or the dependency injection design pattern. It really does not matter how you bind to the implementation the key thing is the separation being used here when creating your own abstractions. You can of course roll your own locator object or provide a singleton property that your platform-specific code assigns.
Alternatively, xamarin forms has two built-in mechanisms.
The first is a generalized messaging service called Messaging Center that as a publish/subscribe event system. You can send messages from anywhere in your shared code and have some handler likely in each of the platform libraries receive the message and then process it in the platform specific way. This is exactly what page does when creating alerts and action sheets.
The second way is to use a dependency service API. This is specifically designed to locate and bind interfaces or abstract classes to implementations.
When using the dependency service the first step is to define our abstraction. The IDialer interface in this case must be in our shared code since all parties need to know about this class or interface.
Next, we will implement the abstraction in each of our platform specific projects. Here we define it for iOS but we would also want to do an implementation in the Android and uwp projects. Notice that it does not need to be public, external users won't know about the class directly. They will only reference it by the abstraction.
Next in each of the platform, specific projects we let the dependency service know about our implementation using the dependency attribute. This is declared the assembly level as you can see here and identifies the implementation, which is then registered with the dependency service xamarin forms. You can also use a new register method to add specific instances or types to the dependency service and code vs. declaratively with an attribute. This allows you to make runtime decisions about the implementation of the service .Or to instantiate a service implementation with the parameterised constructor.
Finally, anywhere in your app you can request the abstraction from the dependency service. It will return the first registered class that implements the specific interface or derives from the specified base class .If no classes found null is returned this means that you can implement a service for one platform but leave it off for another if it's not possible to implement or it's optional.