[RFC] Flutter support

[mattmapadmi]

Flutter support

Type: Enhancement

Start Date: 2023-09-19

Author: Matt Malone

Related components: -

Summary

Create a version of Mockzilla that can be consumed by a Flutter app

Motivation

We currently have an internal Flutter-only version of Mockzilla based off the old non-KMM library. As such, its API does not

Detailed design

This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the network to understand, and for somebody familiar with the code practices to implement. This should get into specifics and corner-cases, and include examples of how the feature is used.

Drawbacks

I Why should we not do this?

Alternatives

What other designs have been considered? What is the impact of not doing this?

Unresolved questions

What parts of the design are still to be done?

[TomRHandcock]

Just throwing in some thoughts here about how to go about porting this package to Flutter.

Structure

Ideally we would use a federated plugin. The main benefit is that consumers of the plugin only need to include the code required for the platform being built (through a platform specific plugin), however there is a secondary benefit of maintainability in that each platform plugin is only concerned with its respective implementation.

Federated plugins also offer the ability for other parties to extend the implementation to other platforms in future, these other plugins can optionally be endorsed to be automatically included by consumers.

Generating bindings

There are a few ways to generate bindings between Flutter/Dart and native code:

• Pigeon - Generates an interface on the native side from a specification which can be implemented and called via a generated Dart class to provide type-safe communication, also works the other way around.
• ffigen & (experimental) jnigen - Allows bindings to be generated for arbitrary native classes in Dart, while ffigen is stable and frequently used for iOS, the Android equivalent (jnigen) is not yet ready for production.
• Klutter - Specifically for use with KMP projects, like Pigeon this does the heavy lifting of handling the method channel config however the downside is consumers of Klutter plugins also have Klutter as a dependency.

[TomRHandcock]

@SamC-Apadmi (or anyone else with permissions) In the above PR, I had identified a few outstanding tasks between the current version of the Flutter plugin and what I would call version 1.0;, if these could be added as individual issues to the project, it would help with transparency.

I intend to move on to CI integration next with some time spent to look into logic to only run the unit tests required across the Dart, Kotlin (and eventually Swift) test suite.

[JordanllHarper]

Is this an old task?

[TomRHandcock]

@JordanllHarper Kind of, this issue was made before any scoping for Flutter support had been done. What I see this issue as now is a parent for all Flutter related work that will be closed once we have achieved a 1.0 release. Imo, this is a good place for any discussions related to Flutter support as a whole.