Portable Class Library (PCL) is a set of platform independent APIs that can be referenced in more than one platform. They are a subset of the .NET Base Class Library (BCL).
Note
.NET BCL is a library that contains the standards of the C# language. It provides types to represent the data types of the Common Language Interface, file access, custom attributes, security attributes, string manipulation, formatting, streams, and collections. It defines types in namespaces we might be familiar with (System, System.Collections, System.Collections.Generics, System.Diagnostics, System.Globalization, System.IO, System.Security, System.Security.Permissions, System.Text, and System.Threading)
In a PCL, we need to select a profile that includes a list of targeted platforms. Actually the more platforms we need to support, the smaller is the subset of BCL we can use.
Unlike a Shared project, a PCL generates a compiled library that can be referenced by projects included in the targeted frameworks.
To create a PCL, we can right click on the solution and go to Add | New Project.
In the New Project dialog, we need to select C# in the left side list and Portable Library in the central list.
When a PCL is created in Xamarin Studio it is automatically configured with a profile that works for Xamarin.iOS and Xamarin.Android. We can check the References folder in order to see the subset of .NET portable library that we can use in our project.
In the PCL Settings we can define the profile. Double-click the project, and the Project Options dialog will appear. In this dialog we can go to Build | General and check or change the current profile. Changing any of the Target Framework options automatically updates the Current Profile.
Once a PCL has been created, we can reference it from any compatible application or library by double clicking on References under the tab Projects.
This means that we can create our very own PCL plugin. These PCL plugins will allow us to add rich cross platform functionality to Xamarin, Xamarin.Forms and Windows Projects that use a PCL or Shared Project.
We are now going to explore the code of a simple cross-platform plugin to check the connection status of a mobile device acquiring additional information such as connection type and bandwidth.
We will develop our own shortly but for now it's worth taking a look and fully understanding something that has been done by the team behind Xamarin. The plugin has been written by James Montemagno. It is available on NuGet and the code has been published at https://github.com/jamesmontemagno/Xamarin.Plugins.
Note
NuGet is an open source package manager for the Microsoft development platform. It is fully supported by Xamarin Studio. We'll find several plugins usable from our apps here. To explore them right-click on the name of the project on the Solution pad and then Add | Add Nuget packages…
Also, Xamarin has its own package repository called Xamarin Component Library. We can easily access the Xamarin Component Library from https://components.xamarin.com/. There are tons of components and most of them are platform independent. We can find, download, and use them in our projects to add functionality to our projects in minutes. Examples include cloud integration, barcode scanning, charting, themes, and so on.
The idea is to be able to understand the structure and architecture of an existing plugin in order to invent our own plugin.
The plugin we are going to analyze has been written in order to have a simple interface that works cross platform and allows us to check the connectivity. This feature is going to be really useful in our projects and we will use it later in the book.
We are now starting to explore the development of this plugin. The mentioned link (https://github.com/jamesmontemagno/Xamarin.Plugins) contains different plugins but we are going to focus on the project called Connectivity.
After downloading them, we can open the file Connectivity.sln from the Connectivity folder.
As we can see, it is composed of 11 projects:
Connectivity.PluginConnectivity.Plugin.AbstractionsConnectivity.Plugin.AndroidConnectivity.Plugin.iOSConnectivity.Plugin.iOSUnifiedConnectivity.Plugin.Net45Connectivity.Plugin.UWPConnectivity.Plugin.WindowsPhone8Connectivity.Plugin.WindowsPhone81Connectivity.Plugin.WindowsPhone81SLConnectivity.Plugin.WindowsStore
The core project is generally the first one to develop.
In this case, the core project is Connectivity.Plugin.Abstractions. We can see it has included a References folder in each project. Each project depends on Connectivity.Plugin.Abstractions while it has only one dependency to ".NET Portable Subset", which confirms to us that is a PCL project.
Expanding the Connectivity.Plugin.Abstractions on the Solution pad, we can see the core of the shareable classes. There are three files:
IConnectivity.cs: This is the interface that defines methods, properties and events of the feature that is implemented in the plugin.BaseConnectivity.cs: This is the abstract class that does some common work, like throwing events or disposing the objects. This class can be inherited from an implementation class on the platform specific project. When a class inherits from an abstract class, we need to implement all the methods and properties defined as virtual on the base class and we have the option to override the methods marked as virtual.ConnectionType.cs: This is the enumerator that defines a set of items to describe the type of the connection.
The Connectivity.Plugin project defines a CrossConnectivity class that uses the Connectivity.Plugin.Abstractions library and contains the main point of access to the APIs defined there. It is also a PCL library but the file CrossConnectivity.cs will be linked to the platform specific projects and this means that this class is going to be compiled directly in the platform specific libraries.
We can now explore the platform specific projects. They all reference the Connectivity.Plugin.Abstractions but note that they are not PCL projects any more. They are now using the platform specific core libraries. They all have a customized implementation of the BaseConnectivity class that is called with the same name ConnectivityImplementation in all of them. This is not mandatory but is a reasonable choice that allows us to have the same semantic structure.
Each ConnectivityImplementation class has its own implementation because the ways to check the connectivity differ between Windows, iOS, and Android, but we want to provide a common way to call it from the multiplatform application we want to develop.
Note also how sometimes the implementation of the BaseConnectivity is shared. We can look, for example, at Connectivity.Plugin.iOS and Connectivity.Plugin.iOSUnified. The class ConnectivityImplementation that has been written in the Connectivity.Plugin.iOS project has been linked to the Connectivity.Plugin.iOSUnified project. The difference between Connectivity.Plugin.iOS and Connectivity.Plugin.iOSUnified is in the referenced classes. Connectivity.Plugin.iOS depends on the monotouch core library, which doesn't support 64 bit like the iOSUnified that depends on the Xamarin.iOS core library. In this case, it is not going to make any difference to the code written for the specific platform, so Connectivity.Plugin.iOSUnified contains only classes linked from the Connectivity.Plugin.iOS project.