Lets begin by defining our plugin design: a federated plugin.

But why a federated plugin?

TL;DR: because it scales well, a nice example is the Flutter community "plus" plugins https://github.com/fluttercommunity/plus_plugins.

In the past I started this other plugin: https://github.com/alexrintt/shared-storage but it does not scaled so well, at first I was calling only a single native function, and over the time I needed to add more and more functions. My idea at first was to make a mirror of the Android API in this plugin, so if I wanna implement something in Flutter using the Android API, I can just rely on my Dart API (since it is a mirror), right? No. Kotlin and Java are different languages and Android has it's own design, it neither suits the Flutter composition design or Dart language design, after some versions you will find yourself in a rabbit hole where you will start thinking on ways to work around problems between the languages and the platforms instead of thinking in the plugin itself, so just no.

Okay, lets begin.

Federated plugin design

A federated plugin by definition is:

Federated plugins are a way of splitting support for different platforms into separate packages. So, a federated plugin can use one package for iOS, another for Android, another for web, and yet another for a car (as an example of an IoT device). Among other benefits, this approach allows a domain expert to extend an existing plugin to work for the platform they know best.

There is also another great advantage besides the cross-platform quoted in the docs:

It make us think about functionalities rather of APIs. APIs often have different classes, signatures, functions and types across different platforms, so it's nearly impossible to create an interface that fits all platforms without creating coupling between the classes, but here is the catch: a high-level use-case doesn't need that. So to write a nice Flutter plugin, first we need to set a high-level use-case, in our case: list device packages and stream uninstallation and installation events, note that we were very broad here, although we defined a technical requirement.