Sytody is a POC of todo app crossplatform (iOS & Android), which has the distinction of using voice recognition to add tasks. 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 innocuous, quite the contrary ... 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 I like since few months : it's Flutter , a crossplatform development SDK developed by Google, based on their Dart 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 functions / API native of iOS / Android .
![sytody-screen]({{"/img/speech_reco_shots.png" | prepend:site.baseurl }})
After practicing, in depth, Air Mobile, Cordova via Meteor and Nativescript, this aspect has become central in the choice (or not) 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).
Like other solutions, Flutter offers a way to access all the functions of the OS on which the application is launched. Unlike other solutions, this means is simple, and most often without any capillotract 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 native , (and / or vice versa): cf. MethodChannel
- Or send streams from Dart to the native (and / or vice versa), to broadcast data flows (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 sérialisation des types "basiques" : String, Map, List and the various numeric types.
For calling "remote" methods :
- on the Flutter/Dart side, we instantiate a MethodChannel, givint it an identifier,
- and we instantiate in ObjC or Swift for iOS,
- and/or in Java or Kotlin for Android.
The next step wil be to invoke methods via the channel, from one side to the other, by transmitting, or note, arguments.
Let's take a very basic example : a simple method to retrive the version of the host.
- we instantiate a channel named "plugin_demo"
- we invoke a method "getPlatformVersion" on this channel, without passing arguments
https://gist.github.com/4b0b1bc97121f6639e55e221ef388496
invokeMethod(String name, dynamic args) returns a Future ( aka promise ), which can be processed with .then(...) or async/await.
- There is also created a
FlutterMethodChannelchannel named "plugin_demo" - A function is defined to handle the calls coming from Flutter.
https://gist.github.com/f48764327dfabd67df6bb94451b862d2
Same principles as for iOS :
https://gist.github.com/113c7a0ce6cabf1d50dbe870ec01fd8e
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 will look at a concrete / complete example with the implementation of speech recognition.