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.
