Flutter, native APIs and plugins [1/3]
Sytody is a POC for a vocal, crossplatform todo app (iOS & Android). It’s a small experiment made in few hours with Flutter, during a rainy weekend 🌦 of May.
That this story begins in May is in no way trivial, quite the contrary … Because it is well known, in french we say :
“En mai, fais ce qu’il te plait !”.
(In may, do what you like)
And for my part, for a few months, if there is something that I like : it’s Flutter, a crossplatform mobile development SDK created by Google, based on Dart their (too unknown) language. This tool has sunny my early professional 2017, by dramatically accelerating my productivity for mobile development, opening up many prospects.
I think I’ll have the opportunity to go into more detail about the reasons for this ⚡️, and the peculiarities of this tool, whose version just tagged alpha has already collected more than 5000⭐️ on Github.
Today, I take the pretext of Sytody, to take an interest in a particular aspect of Flutter : its management of exchanges with the “host” platforms, the possibilities it offers to use the iOS & Android APIs.
After practicing, more or less deeply, Air Mobile, Cordova via Meteor and Nativescript, this aspect has become central in my choice (or non-choice) of a crossplatform SDK.
I would not go back on the complexity or difficulties, often WTF, encountered in my previous cross-platform explorations.
Rather, I will focus on the joy and bliss Flutter brought me on this issue (among others).
1. Flutter-to-iOS & Flutter-to-Android
Like other solutions, Flutter offers a way to access the “host” OS on which the application is launched. Unlike some other solutions, it’s simple, and most often without any weird configuration.
The team having (for the moment?) abandoned the export of MacOS application, 3 platforms are officially managed: iOS, Android and Fuchsia. And having not yet ventured into the (open) secrets of this last, my experience feedback concerns the two main mobile platforms to date: iOS and Android .
The principle of access to native functionality is based on the opening and use of “channels”. These channels allow :
- to call methods from Dart to host , (and / or vice versa): cf. MethodChannel
- Or send streams from Dart to the host (and / or vice versa), to broadcast data (coming from a sensor for example): cf. BasicMessageChannel
It’s very simple, and very effective. For those who have known the Action Message Format — AMF , we find the same principle of calling remote methods, except that in this case, it is not a communication client-> server but DartVM <-> OS host. The channels automatically manage the basic data type serialisation : String, Map, List and the various numeric types.
For calling “remote” methods :
- on the Flutter/Dart side, we instantiate a MethodChannel, giving it an identifier,
- and we instantiate the equivalent in ObjC or Swift for iOS,
- and/or in Java or Kotlin for Android.
- Then, for each channel, a messageHandler is defined , defining its API, the list of methods to which the channel gives access
The next step wil be to invoke methods via the channel, from one side to the other, by transmitting, or note, arguments.
Example
Let’s take a very basic example : a simple method to retrive the version of the host.
Côté Flutter/Dart
- we instantiate a channel named “plugin_demo”
- we invoke a method “getPlatformVersion” on this channel, without passing arguments
invokeMethod(String name, dynamic args) returns a Future ( aka promise ), which can be processed with .then(…) or async/await.
iOS — Swift
- We create a
FlutterMethodChannelnamed "plugin_demo" - A function is defined to handle the calls coming from Flutter.
Android — Java
Same principles as for iOS :
Host to Flutter
Same principle again, but this time invokeMethod is called by the host, to be executed by Dart on the Flutter side.
Now that we have the principle, in the next episode we’ll look at a concrete example with the implementation of a speech recognition channel.
Part 2 : Implementing the speech recognition
