I am so glad that you asked! I recently blogged about creating reusable plugins for Xamarin.Forms, and it might have caught you a bit off guard. Does Xamarin.Forms or Xamarin itself have plugins? The short answer is YES with the power of PCLs and NuGet.
Component vs. PluginFor a long time, Xamarin developers have been able to add rich functionality to their mobile applications by adding Components from the Component Store. While you might consider these “plugins” of sorts, let me define what a plugin means to me.
When refer to Components, we’re generally talking about a library for Xamarin.iOS or Xamarin.Android that has been packaged for the Xamarin Component Store - similar to how a NuGet is a Library that has been packaged for the NuGet Gallery. Sometimes they have the same API, however sometimes they do not. For instance, Twilio has a great component that has very specific and tight integration with iOS and Android, and requires you to write code in the platform specific project.
When I refer to a plugin for Xamarin, I am referring to a special kind of NuGet that adds cross-platform functionality or abstracts platform specific functionality to a common API. These are both completely cross-platform and extremely small (i.e., they do 1 or 2 things really well with minimal to no dependencies). The plugin API can be accessed on each platform; however, most likely you will only use the common API in a Portable Class Library or Shared Code project.
I like to use the name Plugin as it follows the same pattern as MVVMCross. In fact, nearly every single MVVMCross Plugin could be turned into a Plugin for Xamarin & Windows with a small amount of work so any Xamarin developer could take advantage of it.
I created my Vibrate and Settings Plugins specifically to provide simple examples of Plugins for Xamarin & Windows - but another great source for model plugins would be nearly anything that comes from Paul Betts, such as Akavache.
Xamarin.Forms or Xamarin plugin?If you read my earlier blog post about creating plugins specifically for Xamarin.Forms, you might be wondering if you should create them for only Xamarin.Forms or if you should create a more platform independent Xamarin plugin. This is a great question as well and just remember that any “Xamarin plugin” would work in a Xamarin.Forms project. So, it really only depends on what you are trying to accomplish. If you intend to leverage some of the functionality that is built into Xamarin.Forms, or to create custom controls for Xamarin.Forms, then your plugin should be a “Plugin for Xamarin.Forms”.
If you are not using anything that explicitly depends on Xamarin.Forms, then you should really strive to make it completely platform independent, and leverage the Bait & Switch approach to target iOS, Android, and Windows Platforms. I tend to always attempt to target iOS, Android, and Windows Phone at minimum in all of my plugins to ensure compatibility with Xamarin.Forms.
NamingAfter taking a few swings at this, I’ve found that following this naming scheme works pretty well:
- Xamarin.Forms only:
- Feature Plugin for Xamarin.Forms
- Feature Plugin for Xamarin
- Xamarin + Windows Platforms:
- Feature Plugin for Xamarin and Windows
Replacing “Feature” with what your plugin does :)
If you want to learn more about creating plugins, be sure to check out my full repo on GitHub.