The open-source community has developed several hundreds of plugins since the stable Flutter version release at the end of 2018.
Nevertheless, not all of the developers’ needs could be fulfilled by using already existing libraries.
Problem overview: Insufficient functionality in existing open-source Flutter share plugins
We faced such a situation on one of our mobile projects at Akvelon — AdviseMe: fashion advisor for iOS and Android platforms, we needed a way to share multiple images with other applications using the native platform share feature.
As a result, we decided to build our own solution — well designed, reliable, and feature-packed reusable Share plugin.
Our idea in this article is to share our Flutter plugin development experience that will help you to develop plugins faster, reliably, and effectively.
How to start: general principles of Flutter plugin development
Of course, all of the conventional rules of software design are fully applicable to the plugin development. However, there are a few points that we would like to highlight specifically:
- Functionality first
The natural way of designing an API is to wrap an existing functionality, exposing it to the consumer and making it possible to use it. However, while developing a cross-platform plugin you should note that different platforms may support different features, platform-native APIs may not be inconsistent between versions, etc. So, developing a plugin API you should consider your Dart API as a facade, for instance:
And then look for a platform-specific API that you will use for your goals.
- Supported platforms
If you’re creating a plugin that provides access to some general functionality, it will be a good way to consider supporting as many platforms as possible. But sometimes you’re creating a plugin that provides access to the specific platform API. In that case, you should specify that to avoid a misunderstanding with users.
All of the general rules of writing testable code are applied to plugin development. It means that the smallest components should be independently verifiable. In order to do this, each component must have its dependencies injected into it. Consider placing all of your business logic on the Dart side and keep your native code layer as thin as possible, simply providing results. That will result in creating less code since you won’t have to repeat your logic for different platforms. In case of more complicated processing on the native side (for instance, biometric authentication), you should consider separation of logic to make it more unit-testable.
Considering all of the aforementioned rules, here is our to guide on how to properly create a Flutter plugin:
Choose the platforms that you want to support. Currently, Flutter web is in beta and Flutter desktop is in alpha, so you already can expand your plugin functionality to these platforms. However, our task has already been solved on that, thus we decided to support Android and iOS.
Make a decision on which parameters you will need to channel into the native side. Sometimes this choice might seem explicit for one of the platforms, for instance, iOS requires you to send an URL as a separate argument, when Android, on the other hand, is able to parse it from the text. Create a common interface and incapsulate such differences, giving developers an ability not to think about that.
While designing a native part, separate platform-specific files from business logic if there is any. In that case, it would be possible to test them separately.
As a result, we developed the Flutter Share Plugin which is available on GitHub and pub.dev platforms. It supports plain text and URLs, single and multiple media files share. Basically, you can share any file as long as native APIs are able to determine the attachment type.
How to market Flutter plugin
Pub.dev is the package manager for the Dart programming language, containing libraries & packages for Flutter, AngularDart, and others. It’s created and supported by the Flutter team.
In October of 2019, they’ve announced a new feature — verified publishers. When you publish packages as a verified publisher, you get the bonus of easier package administration and publisher detail page. On that page, you can see a few more details, including a contact email for the publisher, a link to the publisher’s homepage, and a short description. The description is provided by the publisher, offering a small branding opportunity for your company.
During the publisher creation process, you’ll need to verify the ownership of the domain through DNS verification. The process is fully automated, so usually, accounts are created without any delay. You’ll just need to verify that you have admin access to the associated domain, based on existing logic in the Google Search Console. After the creation, you can transfer all of your existing packages to the verified publisher to get all the benefits.
This article was written by Nail Shakirov, the Director of Engineering at Akvelon’s Kazan office, and was originally published in Medium.
Written in collaboration with Rustem Muzafarov
Nail Shakirov is the Director of Engineering at Akvelon’s Kazan office. He has a solid software development background and experience in all software development stages: technical design, implementation, testing, and operation.