DEV Community: Bram De Coninck

Flutter Europe 2020: My First Developer Conference

Bram De Coninck — Sat, 08 Feb 2020 21:22:01 +0000

This year the first Flutter Europe conference took place in Warsaw (Poland) on January 23 and January 24. It was packed with interesting talks and it was awesome to meet other members of the Flutter community. I've learned a lot about animations, performance, augmented reality, building games, domain-driven-design, convincing companies and clients of Flutter's awesomeness, ... In this article I'll share some insights on what was undoubtedly one of the most amazing experiences of my life.

The talks

There were 26 talks in total but 2 were always given at the same time, so you could only attend 13 talks in total. Sometimes it was very difficult to device which talk would be more interesting or fun. Luckily, all talks will soon be published on the Flutter Europe YouTube channel.

I've learned something useful from every talk I attended and I enjoyed all of them, but if I had to pick my 5 favourite talks it would be these:

Performance: Optimizing your Flutter app
Augmented Reality in Flutter
Animations in Flutter Done Right
Building games using Flame
How to convince business to Flutter? Real-life cases

Unfortunately I missed out on some interesting talks. Apparently 'Implementing complex UI with Flutter' was an amazing talk. From what I've heard, Marcin Szałek really had the audience in the palm of his hand. He was able to explain this topic so well that creating complex UI didn't look so difficult or intimidating anymore. This is definitely the first talk I'm going to watch as soon as they're available online.

The Flutter community

If you're anything like me you read Flutter articles, watch Flutter videos, listen to Flutter podcasts, ... on (almost) a daily basis. A lot of the more famous Flutter community members who create this content attended Flutter Europe. I'm really glad I was able to meet so many of my personal heroes and heroines, like Emily Fortuna, Filip Hráček, Matt Rešetár, Simon Lightfoot, Rémi Rousselet, Felix Angelov, Jorge Coca, Hillel Coren, the Codemagic team, ...

They say you should never meet your heroes, but that's not true if your heroes/heroines are members of the Flutter community.

It was also amazing to meet a lot of other members of the Flutter community. On my plane to Warsaw the two people sitting next were also attending Flutter Europe, and I met a lot of others there in between the talks, during lunch or at the two parties.

I was travelling by myself, but there was never a moment where I was alone. I'm usually an introvert but it was so easy to connect with other Flutter developers. I heard a lot of amazing stories about other people's experiences with Flutter and I'm glad I was also able to share my own.

The loot

As I've already mentioned in the title, this was my first developer conference. I've only attended gaming conferences like Gamescom so far. When I go to one of those I know I'll bring home a backpack full of loot, a.k.a. gadgets, toys and merchandise. I didn't expect this to happen at Flutter Europe. I wanted to attend this conference for the knowledge and the networking opportunity, but secretly I hoped I' go home with one of those Dash plushies you see everywhere on social media...

You should be going to a conference for the knowledge instead of the loot, but I can't be the only Flutter developer who wanted to get his hands on a Dash bird plushie, right?

Ever since I learned of their existence I knew I wanted one. I'm really glad attendees were able to earn one by completing a programming challenge. The challenge itself wasn't very hard, the most difficult part was typing on a German keyboard (the semicolon was very well hidden).

Everyone who attended received a Flutter t-shirt and a goodiebag with a hat, a water bottle and some other things. If you visited the booths of GDG, Codemagic, LeanCode and the others, you were also able to get some other t-shirts, all kinds of stickers, ...

My personal highlights

Because I wanted the complete Flutter Europe experience I decided to go to the first party, the one before the conference started. This party took place in a stupendous building called the 'Warsaw Spire'. When I was standing in line to get my badge, someone who seemed quite familiar came to stand next to me. It was Matt Rešetár, a.k.a. Resocoder. In my opinion, his Flutter videos are the best you can find on YouTube and it was an honour to meet him.

At this party I was also finally able to meet Marie Jaksman in real life. You might know her if you're a member of the Codemagic community. She introduced me to Łukasz Kosman, one of the organisers of Flutter Europe and also the co-founder of LeanCode. He gave the 'How to convince business to Flutter? Real-life cases' talk on the second day. Marie told him I was the person who wrote the article about Flutter vs. other mobile development frameworks. His reaction was amazing, but also very unexpected.

He said that he had a slide in his presentation about an experiment I conducted for my article. I was flabbergasted (or should I say fluttergasted?).

This was the first article I've ever written, but apparently it was quite popular. To my surprise, some of the people I met at Flutter Europe had read it. The fact that it was also a part of a presentation at Flutter Europe was definitely a highlight for me.

There's another person worth mentioning who definitely made the whole Flutter Europe experience even better. His name is Dylan Beattie. The first time we saw him was at the party after the first day of the conference where he gave a performance. He turned Billy Joel's 'Piano Man' into 'Bug in the Javascript', Bon Jovi's 'You give love a bad name' into 'You give REST a bad name', ... If you're a programmer who's into the rock classics, you should definitely visit his YouTube channel.

Dylan also gave the last talk of the conference named 'The Art of Code'. He gave some amazing examples of why programming could/should be considered a form of art and at the end of the presentation he talked about a special project of his. Dylan is the creator of 'Rockstar', a programming language designed for creating computer programs that are also song lyrics. It's difficult to explain how amazing his talk was, but you can watch it here and see for yourself. I can guarantee you that you'll enjoy it!

Conclusion

In my opinion, and I'm convinced a lot of other attendees agree with me, Flutter Europe 2020 was an amazing experience. This was only the first edition, but the organisers already got so many things right. Hopefully Flutter Europe 2021 will be even bigger and better. I'm happy I was able to attend and I can't wait for next year's edition!

Localising Flutter applications and automating the localisation process

Bram De Coninck — Thu, 30 Jan 2020 19:16:40 +0000

Developing a small application or PoC in one language is acceptable, but as soon as you release an app to the public you might want to consider localising it first. I live in Belgium, a country best known for its chocolate, waffles, fries and beer. We have three official languages: Dutch, French and German. We also have English as an unofficial language. If I want to publish an app and I want as many Belgians as possible to be able to use it, it'll definitely need to support these languages.

The more languages and locales your application supports, the bigger your target audience will be.

In this article I will guide you through localising your Flutter application using .arb (Application Resource Bundle) files and the Intl package. I will also show you how you can automatically provide your app with the latest translations using the Loco tool. I've written a shell script that can be run locally or used by a CI/CD tool of choice. I'll be using Codemagic because it's easy to set up and visualise.

Adding the dependencies to the project

Before you can localise your Flutter app, you'll first need to add some dependencies to the pubspec.yaml file of your project.

dependencies:
  flutter:
    sdk: flutter

  flutter_localizations:
    sdk: flutter

dev_dependencies:
  flutter_test:
    sdk: flutter

  intl_translation: ^0.17.7

Localisation in the MaterialApp

Most of the setup for the localisation happens in the MaterialApp, which is the heart of your Flutter app. It doesn't necessarily have to be a MaterialApp though, it can also be a CupertinoApp or a WidgetsApp. This is the place where the supported locales are defined and is decided which locale is going to be used in the app. It's also where we'll add our own localisations delegate, which is where the rest of the magic happens.

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Localisation Demo';
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: HelloWorld(),
      // List of all supported locales (language code followed by country code).
      // For this example, I'll be using Belgian English, Belgian Dutch and Belgian French.
      // The order of the supported locales is very important because a fallback mechanism is used.
      supportedLocales: const [
        Locale('en', 'BE'),
        Locale('nl', 'BE'),
        Locale('fr', 'BE'),
      ],
      // These delegates are responsible for loading the translations of the selected locale.
      localizationsDelegates: [
        // This is where all translations are defined, will be added later.
        const AppLocalizationsDelegate(),
        // Built-in delegate for the localisation of the Material widgets (e.g. tooltips).
        GlobalMaterialLocalizations.delegate,
        // Built-in localisation for text direction (left-to-right or right-to-left).
        GlobalWidgetsLocalizations.delegate
      ],
      // This is where it's decided which locale should be used.
      localeResolutionCallback: (Locale locale, Iterable<Locale> supportedLocales) {
        for (final supportedLocale in supportedLocales) {
          // The language of the device of the user is compared to every supported language.
          // If the language codes match, the supported locale with that language code is chosen.
          // This allows users using American English or British English as locales
          // to be able to use the Belgian English localisation.
          if (locale.languageCode == supportedLocale.languageCode) {
            return supportedLocale;
          }
        }

        // If the language of the user isn't supported, the default locale should be used.
        return supportedLocales.first;
      },
    );
  }
}

Creating the AppLocalizations class and the AppLocalizationsDelegate

The AppLocalizations class contains the logic to load the messages (= translations) of a given locale. It's also where you'll define all Intl messages that will be used in the app. All messages should be in the same language, the language of the 'source locale' of your project. In this case it's Belgian English.

I've created two Intl messages: one for the app title and one for a 'hello world' message that we'll use later in the UI.

class AppLocalizations {
  static Future<AppLocalizations> load(Locale locale) {
    final String name = locale.countryCode == null || locale.countryCode.isEmpty
      ? locale.languageCode
      : locale.toString();
    final String localeName = Intl.canonicalizedLocale(name);

    return initializeMessages(localeName).then((_) {
      Intl.defaultLocale = localeName;
      return AppLocalizations();
    });
  }

  // Localizations are usually accessed using the InheritedWidget "of" syntax.
  static AppLocalizations of(BuildContext context) {
    return Localizations.of<AppLocalizations>(context, AppLocalizations);
  }

  // Messages which contain a string in the default language of your app and a name as identifier.
  // CamelCasing is required for the name of the Intl message.
  String get appTitle => Intl.message('Localisation Demo', name: 'appTitle');
  String get helloWorld => Intl.message('Hello world!', name: 'helloWorld');
}

The AppLocalizationsDelegate is the glue between the AppLocalizations class and the MaterialApp. The load function returns an AppLocalizations object as it contains all localised messages. The isSupported function can be used to check if a certain locale (or in this case language code) is supported.

class AppLocalizationsDelegate extends LocalizationsDelegate<AppLocalizations> {
  // As the instance of this delegate will never change, it can have a const constructor.
  const AppLocalizationsDelegate();

  // Checks whether or not a certain locale (or language code in this cast) is supported.
  // The order of the locales doesn't matter in this case.
  @override
  bool isSupported(Locale locale) => ['en', 'nl', 'fr'].contains(locale.languageCode);

  // Load the translations of a certain locale.
  @override
  Future<AppLocalizations> load(Locale locale) => AppLocalizations.load(locale);

  // Defines whether or not all the app’s widgets should be reloaded when the load method is completed.
  @override
  bool shouldReload(LocalizationsDelegate<AppLocalizations> old) => false;
}

If you copy/paste this code you'll get an error on the initializeMessages method, as it's not defined yet. This method will be generated later by the Intl package. Before you can start providing translations to your Flutter app, you first need to create a Loco project.

Creating the Loco project

Head over to Loco and create an account if you don't already have one. Loco has a generous free plan which allows you to create two projects. Create a new Loco project and make sure to select the same source locale you've used for your Intl messages.

Next, head over to 'Developer Tools' and click on 'API Keys'. This will open up a dialog in which you can create a 'Full access key' for your project. Make sure to save this key somewhere, as it's impossible to retrieve it later. In case you lose this key, you'll have to generate a new one.

How Flutter works together with Loco

Your Flutter app will interact with Loco in two ways. The Intl messages you created in the AppLocalizations class will be imported into Loco. Everytime you add or update these translations your Loco project will get an update as well. New assets will be created in your source locale or existing assets will get a new value. The second way you use Loco is by downloading all translations for all locales in .arb format and then turning these files into .dart files.

It doesn't have to be the job of the developer to provide the translations for the app, it can also be done by a product owner or a client for example.

In your Loco project you can choose additional locales you want to support, in my case Belgian Dutch and Belgian French. Translating messages for a new locale from your source locale can be done by a very user-friendly GUI. You don't need to be a technical person to add or edit translations.

Automating the localisation process

Importing messages into Loco and exporting translations from Loco can be done manually, but it's a tedious process. These are the steps that need to be taken for the entire localisation process:

Generate .arb files from the Intl messages defined in the AppLocalizations class.
Import those .arb files into the Loco project to add/update the translations for the source locale.
Fetch the latest translations for all locales in .arb format from the Loco project.
Generate .dart files from these translations.

It's possible to automate this process with a simple shell script I've provided below. The only thing you need to do is provide a value for all variables: your Loco API key, the path of the AppLocalizations class and the desired output path for the translations.

#!/usr/bin/env sh

set -e # Exit on first failed command

# Variables
LOCO_API_KEY="LOCO_API_KEY"
APP_LOCALIZATIONS_PATH="lib/app_localizations.dart"
OUTPUT_PATH="lib/l10n"

# Get packages
flutter packages get

# Generate .arb files
mkdir l10n-input
flutter pub pub run intl_translation:extract_to_arb --output-dir=l10n-input $APP_LOCALIZATIONS_PATH

# Import translations into Loco
curl -f -s --data-binary "@l10n-input/intl_messages.arb" "https://localise.biz/api/import/arb?async=true&index=id&locale=en&key=$LOCO_API_KEY"

# Export translations from Loco
curl -s -o "translated.zip" "https://localise.biz/api/export/archive/arb.zip?key=$LOCO_API_KEY"
unzip -qq "translated.zip" -d "l10n-translated"

# Create directory for output if it doesn't exist yet
if [ ! -d $OUTPUT_PATH ]
then
    mkdir $OUTPUT_PATH
fi

# Generate Dart files with translations
flutter pub pub run intl_translation:generate_from_arb --output-dir=$OUTPUT_PATH --no-use-deferred-loading $APP_LOCALIZATIONS_PATH l10n-translated/*/l10n/intl_messages_*.arb

# Cleanup
rm translated.zip
rm -rf l10n-translated
rm -rf l10n-input

It's possible to run this script locally but you can also integrate it into your CI/CD tool of choice. I've chosen to use Codemagic because it's easy to set up and use. Codemagic allows you to execute shell scripts before and after every phase of a build. It's important to execute this script before the build phase though. I've decide to run the script before the test phase.

Using a CI/CD tool to fetch translations automatically will make sure users always have the most recent translations.

The reason it's so useful to integrate this script into a CI/CD tool is that with every build of the application the latest translations will be fetched automatically. A developer might forget to fetch the latest translations before releasing a new version of the Flutter app to the stores and it's possible that another person has added or updated translations on Loco.

Using localised messages in the UI

In the example below you can see how to get a localised message from the AppLocalizations class and use it in a Text widget. Try changing the language of your device without closing the app. When you open the app again, the widget will be rerendered automatically and display the message in the language you've selected (as long as it's supported, obviously).

class HelloWorld extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(AppLocalizations.of(context).helloWorld),
      ),
    );
  }
}

Using localised messages without context

Using localised messages without context is possible but it's a bit hacky in my opinion. There's currently no other way to do it though.

It can sometimes be useful to get a localised message without using context, in a BLoC or a ViewModel for example.

class AppLocalizations {
  static AppLocalizations current;

  AppLocalizations._(Locale locale) {
    current = this;
  }

  static Future<AppLocalizations> load(Locale locale) {
    final String name = locale.countryCode == null || locale.countryCode.isEmpty
      ? locale.languageCode
      : locale.toString();
    final String localeName = Intl.canonicalizedLocale(name);

    return initializeMessages(localeName).then((_) {
      Intl.defaultLocale = localeName;
      return AppLocalizations._(locale);
    });
  }

  // Localizations are usually accessed using the InheritedWidget "of" syntax
  static AppLocalizations of(BuildContext context) {
    return Localizations.of<AppLocalizations>(context, AppLocalizations);
  }

I've added a static AppLocalizations object in the AppLocalizations class. It gets its value from the private constructor, which is used in the load method. As you can see in the example below, it's now possible to use localised messages without context.

class HelloWorld extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(AppLocalizations.current.helloWorld),
      ),
    );
  }
}

Localising the app title

It's also possible to localise the name of your application by using the onGenerateTitle callback of the MaterialApp at the root of your project. Make sure you're not using the 'title' property of the MaterialApp.

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: HelloWorld(),
      // Make sure you're not using the title property!
      onGenerateTitle: (BuildContext context) => AppLocalizations.of(context).appTitle,
      ...
    );
  }
}

Conclusion

This approach makes localising your Flutter apps a lot easier. Developers create or adjust Intl messages in the source locale in the AppLocalizations class. Anyone can provide translations for those messages on Loco, it doesn't have to be the developer. Using the provided script and a CI/CD tool of choice will make sure the Flutter app and the Loco project are always synchronised. This allows the users of the Flutter app to always have the most recent translations.

Flutter Versus Other Mobile Development Frameworks: A UI And Performance Experiment

Bram De Coninck — Mon, 13 Jan 2020 22:21:15 +0000

I’ve already read a lot of articles about how Flutter compares to other mobile development frameworks, but most of them were written from a theoretical point of view. It’s already been well established that Flutter is a solid choice for creating mobile applications and that it’s a worthy opponent to frameworks like React Native and Xamarin Forms.

Everyone agrees that Flutter looks good on paper, but how can companies who still doubt Flutter be convinced that they should at least consider using it? Theories and opinions are one thing, but what we really need more of is proof of Flutter’s capabilities and performance.

This year I graduated in Applied Computer Science at University College Ghent in Belgium. During my last year I was given the opportunity to write a thesis around a topic of my choice. I decided to write my thesis around Flutter because I hoped it would be one of the first of its kind. In the first section I discussed how Flutter works, what Dart is and why it’s ideal for Flutter and I also discussed a couple of state management techniques. In the second section I performed two experiments.

During the first experiment I created the same app five times, each time with a different framework. The frameworks I used were native Android, native iOS, Flutter, Xamarin Forms and React Native. During the second experiment I measured the CPU usage of the apps I created in the first experiment. In this article I will share the results of these experiments.

Creating the same application five times

I’m going to be honest with you, this first experiment wasn’t really fair. I don’t have the same amount of experience with every framework I used. If I were to make a ranking of the amount of experience I had with each framework from highest to lowest, it would probably look like this:

Android
Flutter
Xamarin Forms
iOS
React Native

I do however want to point out that I had already created mock-ups of the application so I wouldn’t have to mess around with thinking about the UI during the development of the first app. I also knew enough about every framework to create the application without Googling a lot, so there wasn’t much of a learning curve.

The name of the application I created is Cocktailr. As the name indicates, this app is for cocktail lovers who want to discover new cocktails and also search for cocktails they can make with ingredients they have or want to use.The application exists out of four screens: a cocktail list screen, a cocktail detail screen, an ingredient list screen and a cocktail creation screen. The images underneath are the mock-ups I created before developing the applications. I don’t think I have to show you the screens of the five apps I created because, spoiler alert, they all look nearly identical to the mock-ups (apart from some minor inconsistencies which I’ll discuss later). Instead, I’m going to discuss what it was like to develop the app with each framework and also point out some of the difficulties I encountered. I’m also going to compare the amount of time it took to create the apps per framework.

Creating the native Android application

To create the native Android application I used Android Studio as IDE and Kotlin as programming language. The 3rd party packages I relied on were Glide for fetching network images, Retrofit for consuming HTTP requests and GSON to convert JSON objects into POJOs (Plain Old Java Objects). I also used something called the Navigation Component, which is a part of Android Jetpack, a suite of libraries, tools, and guidance to help developers write high-quality apps easier. It was still in alpha at the time, but I loved it and I felt comfortable using it.

To create layouts on Android you can either use a visual layout builder or you can create it in XML. Usually you’ll work with both to get the best of both worlds.

The main problem I had (and still have) with Android development is that there are too many ways to accomplish a certain task. If you were to Google how to make network requests on Android you would discover all kinds of different packages and documentation. That’s why the Android developers at Google are currently working on Android Jetpack, the set of tools I mentioned earlier. This will make finding the right tools to solve your problems more straightforward. Since both Java and Kotlin are supported for Android development, you’re sometimes going to find code samples or tutorials written in the language you’re not using. Android Studio does have support for turning Java code into Kotlin code but the ‘translation’ isn’t always 100% accurate.

Another difficult problem is that it can be quite hard to add elements to your layout dynamically (Jetpack Compose, which allows you to create layouts declaratively like with Dart, wasn’t around when I created this project). On the cocktail detail screen I wanted to add a table with the names of the ingredients of the cocktail and also a measurement per ingredient. I found it quite difficult to add rows to a table programmatically. There isn’t a lot of information about it in the official Android documentation, so when you have a problem like this you’re probably going to have to look for a solution on websites like StackOverflow. I was eventually able to add the rows programmatically but the solution was, in my opinion, quite cumbersome. The Kotlin code underneath is the function I wrote to create table rows programmatically.

private fun createTableRows() {
    tl_cocktail_detail_ingredients.removeAllViews()

    val params = TableRow.LayoutParams(0, TableRow.LayoutParams.WRAP_CONTENT, 1f)

    val tv1 = TextView(this.context)
    tv1.text = "INGREDIENT"
    tv1.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)
    tv1.setPadding(6, 6, 6, 6)
    tv1.layoutParams = params
    tv1.gravity = Gravity.CENTER
    tv1.setTextColor(ContextCompat.getColor(this.context!!, R.color.black))
    tv1.typeface = Typeface.DEFAULT_BOLD

    val tv2 = TextView(this.context)
    tv2.text = "AMOUNT"
    tv2.setPadding(6, 6, 6, 6)
    tv2.layoutParams = params
    tv2.gravity = Gravity.CENTER
    tv2.setTextColor(ContextCompat.getColor(this.context!!, R.color.black))
    tv2.typeface = Typeface.DEFAULT_BOLD

    val tr = TableRow(this.context)
    tr.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)

    tr.addView(tv1)
    tr.addView(tv2)

    tl_cocktail_detail_ingredients.addView(tr)

    if (!cocktail?.ingredients.isNullOrEmpty() && !cocktail?.measurements.isNullOrEmpty()) {
        cocktail!!.ingredients.forEachIndexed { index, ingredient ->
            val tv1 = TextView(this.context)
            tv1.text = ingredient
            tv1.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)
            tv1.setPadding(32, 6, 6, 6)
            tv1.layoutParams = params

            val tv2 = TextView(this.context)
            if (index >= cocktail!!.measurements.count()) {
                tv2.text = ""
            } else {
                tv2.text = cocktail!!.measurements[index]
            }
            tv2.setPadding(32, 6, 6, 6)
            tv2.layoutParams = params

            val tr = TableRow(this.context)
            tr.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)

            tr.addView(tv1)
            tr.addView(tv2)

            tl_cocktail_detail_ingredients.addView(tr)
        }
    }
}

Something that isn’t really an issue but I also find quite cumbersome is how certain styling has to be done. Let’s say you want to create a text field with a border around it. To accomplish this, you’ll have to add the text field to the layout of your screen but you’ll also have to create a separate XML file to define the border. Then, you need to set that separate file as the background of the text field. It isn’t difficult at all, it just feels like a lot of work for such a simple task. The XML code underneath is set as background of the textfield to create a border around it.

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape= "rectangle">
    <solid android:color="#ffffff"/>
    <corners android:radius="5dp" />
    <stroke android:width="1dp" android:color="#000000"/>
</shape>

Creating the native iOS application

To create the native iOS application I used Xcode as IDE and Swift as programming language. No 3rd party packages were used. I based my way of working on the book “App Development with Swift”, which is an official book by Apple.

Even though I’m an Android developer at heart, I must say it’s a lot easier to find the best way to tackle a certain problem. There are for example less ways to add functionality like consuming HTTP requests, which makes it easier to find the solution that fits best for the needs of your project.

Something that I had to figure out that wasn’t described in the book was how to subscribe to changes happening in the cocktail repository, the class were all cocktail objects are stored. I didn’t want to refetch all cocktails every time the cocktail list screen was opened. To solve this problem I used something called the NotificationCenter.

Thanks to the book I mentioned earlier I hardly had to google anything. In fact, the article I found on NotificationCenter was the only source of information I used apart from the book. I was lucky that the article had an example on how to use it in Swift, but during the development of other applications I encountered the same issue I had on Android. Older articles or StackOverflow answers might have solutions provided in Objective-C, the language used for iOS development before Swift was introduced. Even though I didn’t have this issue during the development of the native iOS application for Cocktailr, I thought it was worth mentioning that it exists.

My main issue with iOS development is that a Storyboard, the visual layout builder for iOS apps, can be more complex than necessary. For example, finding a setting to add a border around a text field can be very difficult. Luckily, it’s a lot easier to do this programmatically than it is in Android. SwiftUI, a way to create layouts declaratively with Swift, wasn’t around when I created this app by the way. It’s also possible to make changes to your layout in the XML file of a Storyboard, but unlike Android, the XML is a mess. The XML code underneath is the cocktail list screen, which actually only contains a list when you think about it.

<scene sceneID="aud-0C-1Pk">
    <objects>
        <tableViewController id="3Sf-E8-Zfo" customClass="CocktailTableViewController" customModule="Cocktailr_iOS" customModuleProvider="target" sceneMemberID="viewController">
            <tableView key="view" clipsSubviews="YES" contentMode="scaleToFill" alwaysBounceVertical="YES" dataMode="prototypes" style="plain" separatorStyle="default" rowHeight="-1" estimatedRowHeight="-1" sectionHeaderHeight="28" sectionFooterHeight="28" id="9Np-nI-tQC">
                <rect key="frame" x="0.0" y="0.0" width="414" height="896"/>
                <autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>
                <color key="backgroundColor" white="1" alpha="1" colorSpace="custom" customColorSpace="genericGamma22GrayColorSpace"/>
                <prototypes>
                    <tableViewCell clipsSubviews="YES" contentMode="scaleToFill" preservesSuperviewLayoutMargins="YES" selectionStyle="default" indentationWidth="10" reuseIdentifier="CocktailCell" id="qUV-tm-57K" customClass="CocktailTableViewCell" customModule="Cocktailr_iOS" customModuleProvider="target">
                        <rect key="frame" x="0.0" y="28" width="414" height="44"/>
                        <autoresizingMask key="autoresizingMask"/>
                        <tableViewCellContentView key="contentView" opaque="NO" clipsSubviews="YES" multipleTouchEnabled="YES" contentMode="center" preservesSuperviewLayoutMargins="YES" insetsLayoutMarginsFromSafeArea="NO" tableViewCell="qUV-tm-57K" id="4Hj-H9-rtF">
                            <rect key="frame" x="0.0" y="0.0" width="414" height="43.5"/>
                            <autoresizingMask key="autoresizingMask"/>
                        </tableViewCellContentView>
                        <connections>
                            <segue destination="IYp-bk-shv" kind="show" identifier="CocktailDetailSegue" id="bjc-Sd-8ni"/>
                        </connections>
                    </tableViewCell>
                </prototypes>
                <connections>
                    <outlet property="dataSource" destination="3Sf-E8-Zfo" id="Arh-Wp-anV"/>
                    <outlet property="delegate" destination="3Sf-E8-Zfo" id="qJE-tE-xa7"/>
                </connections>
            </tableView>
            <navigationItem key="navigationItem" title="Cocktailr" id="0Li-fu-c3B">
                <barButtonItem key="backBarButtonItem" title=" " id="4vq-K8-peJ"/>
                <barButtonItem key="rightBarButtonItem" title="Search" image="Search Icon" id="fCh-D0-Tws">
                    <connections>
                        <action selector="searchBarButtonClick:" destination="3Sf-E8-Zfo" id="0Pk-I0-Hsb"/>
                    </connections>
                </barButtonItem>
            </navigationItem>
            <connections>
                <segue destination="UPM-k4-dYF" kind="show" identifier="SearchTableViewSegue" id="e9G-mk-bUI"/>
            </connections>
        </tableViewController>
        <placeholder placeholderIdentifier="IBFirstResponder" id="dkZ-bW-bEE" userLabel="First Responder" sceneMemberID="firstResponder"/>
    </objects>
    <point key="canvasLocation" x="886" y="-457"/>
</scene>

I encountered a problem during the creation of the cocktail list page. The list, or TableView as it’s called on iOS, exists out of custom cells. Each cell contains the information of one cocktail: an image, its name and its ID. When you scroll through the list of cocktails you’ll see that all of a sudden the cocktail names don’t match with the images anymore. This happens because the cells of the list are reused when you scroll through the list and it takes a bit longer to load an image than it does to load text. Some iOS developers have told me this is an issue all junior iOS developers encounter and that it’s quite easy to fix. I thought it was still worth mentioning, as I didn’t have a similar problem with any of the other frameworks.

I also had to use a TableView to create the table on the cocktail detail page, as there isn’t an iOS component to create tables. The name ‘TableView’ can be quite misleading.

Creating the Flutter application

To create the Flutter application I used Visual Studio Code as IDE and Dart as programming language. The 3rd party packages I relied on were Image_picker for taking photos, Http for consuming HTTP requests and RxDart to use Observables for data streams. I used the BLoC state management technique for this application, but I didn’t use the 3rd party package. I found all of the information I needed to create this application in the official Flutter docs and in articles about BLoC written by Didier Boelens.

Flutter doesn’t have a visual layout builder. You also don’t need an additional language like XML to create your layout. You use Dart to create widgets which together will form your layouts, and you build these layouts declaratively.

The biggest problem I faced during the development of this application was state management. I didn’t have a lot of experience with BLoC at the time and the Provider package wasn’t around when I created this application. BLoC is, in my opinion and as regularly stated by Google, the superior state management technique. It has a huge learning curve to it though. I didn’t have any experience with Redux or Scoped_Model either, and only using setState() wasn’t going to suffice, so I had to resort to BLoC.

Flutter provides its own widgets, and it has a lot of them! One of them is a Table widget, which made it really easy to create the table on the cocktail detail page. I had problems creating this table with both Android and iOS, so this was a nice change of pace. The code underneath is the function to create all the table rows.

List<TableRow> _createTable(Cocktail cocktail) {
  List<TableRow> tableList = [];
  tableList.add(
    TableRow(
      children: [
        Padding(
          child: Text(
            "INGREDIENT",
            textAlign: TextAlign.center,
            style: TextStyle(fontWeight: FontWeight.bold),
          ),
          padding: EdgeInsets.all(4),
        ),
        Padding(
          child: Text(
            "MEASUREMENT",
            textAlign: TextAlign.center,
            style: TextStyle(fontWeight: FontWeight.bold),
          ),
          padding: EdgeInsets.all(4),
        )
      ],
    ),
  );
  for (int i = 0; i < cocktail.ingredients.length; i++) {
    tableList.add(
      TableRow(
        children: [
          Padding(
            child: Text(cocktail.ingredients[i]),
            padding: EdgeInsets.all(4),
          ),
          Padding(
            child: Text(i < cocktail.measurements.length
                ? cocktail.measurements[i]
                : ''),
            padding: EdgeInsets.all(4),
          )
        ],
      ),
    );
  }
  return tableList;
}

The only other ‘issue’ I encountered is that the iOS app doesn’t have a native look-and-feel. I used the Material widgets to create the application. Native Android apps implement Material design, but native iOS apps implement Cupertino design instead. A lot of widgets do look native on both platforms though, like the List widget for example. Other widgets like the AppBar widget don’t. Some widgets like the Switch widget have an adaptive constructor, which allows you to create a switch that look native on both platforms. It’s possible to create separate widgets for Android and iOS for widgets without an adaptive constructor, but unfortunately that costs more time.

Creating the React Native application

To create the React Native application I used Visual Studio Code as IDE and TypeScript as programming language. I relied on a lot of 3rd party packages to create this application:

Expo to make the development of the application easier and because it has picture taking support built-in.
React-native-easy-toasts for showing a toast on the cocktail creation screen.
React-native-elements because it has a lot of beautiful UI components.
React-native-svg-transformer to be able to use SVG icons.
React-navigation for the navigation of the app.
Styled-components to make it easier to style components.

React Native doesn’t have a visual layout builder. You use a language called JSX to create your layouts declaratively.

Managing state was one of the biggest challenges I encountered during the creation of this application. I didn’t know Redux, and learning it would have been a big time investment. This was not the fault of React Native, it was my own fault.

The only styling issue I encountered was during the creation of the cards used in the list of the cocktail list screen. To create shadows on this card for Android I had to use the ‘elevation’ property. To have the same effect on iOS I had to use the ’shadow-color’, ’shadow-radius’, ’shadow-opacity’ and ’shadow-offset’ properties. Having to do styling in two different ways to have the same result on both Android and iOS isn’t really great when your goal is to make a cross-platform app. The code underneath shows the style I created for iOS and the elevation property I used for Android. It also shows the CocktailCard as a whole, written in JSX.

const styles = StyleSheet.create({
    cardWrapper: {
        shadowColor: '#000000',
        shadowOffset: {
            width: 0,
            height: 3,
        },
        shadowRadius: 2,
        shadowOpacity: 0.3,
    },
})

export default class CocktailCard extends React.PureComponent {
    render() {
        const { id, image, name, onPress } = this.props

        return (
            <CocktailCardWrapper elevation={5} style={styles.cardWrapper} onPress={onPress}>
                <CocktailImage source={{ uri: image }} />
                <CocktailText>
                    <CocktailName>{name}</CocktailName>
                    <CocktailId>{`ID: ${id}`}</CocktailId>
                </CocktailText>
            </CocktailCardWrapper>
        )
    }
}

The Android and iOS app created with React Native did have a native look-and-feel. That’s because React Native uses widgets of the platform it’s running on instead of providing its own widgets like Flutter does.

Both Flutter and React Native support Stateful Hot Reload, but I have to say that it’s faster on Flutter than on React Native. On React Native it took longer to reload the app and sometimes it wouldn’t even work at all. The fact that it took longer might have something to do with the use of Expo.

Creating the Xamarin Forms application

To create the Xamarin Forms application I used Visual Studio for Mac as IDE and C# as programming language. The only 3rd party packages I relied on was Xam.Plugin.Media for taking pictures.
Xamarin Forms has a visual layout builder, but it isn’t as good as the ones you use for native Android and native iOS development. You’ll do most of the layout building with the XAML language, which is very similar to XML.

When I created this application, Xamarin Forms didn’t support Hot Reload. At the time of writing this article it’s either in beta or already supported. I don’t know how well it performs in comparison to the Hot Reload of Flutter and React Native though.

Xamarin Forms is a cross-platform framework but when it comes to styling it doesn’t seem to be as straightforward as Flutter or React Native. I wanted to change the colour of the app bar to red. Apparently this isn’t a change you can make in the shared codebase, you need to change the colour of the app bar on Android and iOS separately. This is also the case for the colour of the selected item in the bottom navigation bar. Because you have to do the same styling twice, you might end up with inconsistencies between your Android and iOS applications if you’re not careful.

Now that we’re on the topic of colours, I was unable to change the colour of the search icon in the app bar on the cocktail list screen and the camera icon of the cocktail detail screen. There is probably a way to change these colours, but it’s not straightforward at all. The images underneath illustrate the colour inconsistencies between Android and iOS.

The biggest issue I encountered was, again, the table on the cocktail detail screen. The styling of the table wasn’t the issue though. I have to iterate over the list of ingredients and the list of measurements, but iterating over two lists isn’t possible to create your layout. I had to create a new model which contains the ingredient and its measurement. Then I was able to iterate over a list of those objects. This is the only framework where I had to change the models in such a way and it’s very cumbersome.

Conclusion of the first experiment

The table below shows how much time it took to create every screen per framework. As you can see, I was able to build the Flutter application and the React Native application faster than either one of the native applications. You also have to keep in mind that because these are both cross-platform frameworks I was able to make an Android and iOS application in less time than one native application.

Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks. Their Hot Reload functionality also sped up the development cycle a lot.
Both the Flutter and the React Native applications look nearly identical to the mock-ups. The Xamarin Forms application has some minor yet visible differences.

I was able to create the Flutter app faster than the React Native app, but that’s because I had more experience with Flutter than with React Native. I also didn’t know how to manage state properly in the React Native. That’s why declare both Flutter and React Native the winners of this experiment.

Measuring the performance of the Android applications

This experiment will determine the performance of the Android applications created during the first experiment. To conduct this experiment, I used the Android Profiler, a tool built into Android Studio. This tool allows you to collect data about CPU-usage, network activity and memory/battery consumption. I chose to focus on the CPU-usage as performance indicator for this experiment.

It’s best to use a physical device for this experiment. I used the smartphone the smartphone I owned at the time, a OnePlus 6T with the following specifications:

Operating System: Android 9.0 (Pie); OxygenOS 9.0.13
Chipset: Qualcomm SDM845 Snapdragon 845 (10nm)
CPU: Octa-core (4x2.8 GHz Kryo 385 Gold & 4x1.7 GHz Kryo 385 Silver)
GPU: Adreno 630
Memory: 8 GB RAM
Storage: 128 GB ROM

How the experiment was conducted

When conducting this experiment, a certain route was followed in every application and in the meantime the Android Profiler kept track of the CPU-usage. This tool then generated graphs to visualise the data it gathered. These steps were followed in every application:

Open the app and wait until the cocktails are loaded in
Start measuring the CPU-usage
Scroll down to the bottom of the list of cocktails
Scroll back up to the first cocktail in the list
Click the first cocktail in the list
Return to the list of cocktails
Open the list of ingredients
Scroll down to the bottom of the list of ingredients
Enter ‘Gin’ into the search field
Click on the ‘Gin’ ingredient. (This brings you back to the cocktail list screen.)
Scroll down to the bottom of the list of cocktails again
Scroll back up to the first cocktail in the list again
Click the first cocktail in the list
Return to the list of cocktails
Click on the ‘suggestion’ button in the bottom navigation bar
Write the word ‘description’ as description
Click on the camera button, grant permissions and take a picture
Tap the ‘Make suggestion’ button

Preparations for the experiment

I was able to install the native Android application correctly on my device using Android Studio, which was very easy. Correctly installing the other applications wasn’t as straightforward. To install the Flutter application for example, I had to use the command flutter run — profile. I wasn’t able to use a debug build because the Flutter application would have been compiled JIT (Just In Time, used for debugging) instead of AOT (Ahead Of Time, used for release and profile builds). This would have tempered the performance of the application.

In the Xamarin Forms project I enabled ‘Enable developer instrumentation (debugging and profiling)’ before installing the application. To install the React Native application I first had to start Expo and then enable profiling and install the application.

Results of the experiment

The graphs underneath were generated by the Android Profiler. The green waves represent the CPU-usage of the application. The dark blue waves represent the CPU-usage of other processes. The vertical lines represent the moments in time where started and stopped measuring the CPU-usage.

Take a moment to look back at the steps I followed in every application to notice that certain actions were more CPU-intensive than others. The spike you see near the beginning of every graph is when I started scrolling in the list of cocktails. The spike near the middle of the graph is when I started scrolling in the list of cocktails again, but this time all cocktails with gin as ingredient were shown. That list has more cocktails in it than the original one.

CPU-usage of the native Android application:

CPU-usage of the Flutter application:

CPU-usage of the React Native application:

CPU-usage of the Xamarin Forms application:

Conclusion of the second experiment

The table below contains statistics based on the data off the graphs that were generated by the Android Profiler. The first thing that stood out to me is that every application has a minimum CPU-usage of 0%. This happened when I opened the cocktail creation screen. At that time, the application is in a static state, causing the CPU temporarily unused.

The second thing that stood out to me is that the 4 apps can be split into 2 groups. The CPU-usage of the Flutter application peers with the CPU-usage of the native Android application, while the CPU-usage of the React Native application matches the CPU-usage of the Xamarin Forms application.

Before conducting this experiment, I had anticipated that the native Android application would have been the most performant one and the apps of the cross-platform frameworks would follow. For the most part this is true, but the Flutter application is an exception to this. The Flutter application was even slightly more economical on the CPU.

When I was conducting the experiment it was already noticeable to me that the Xamarin Forms and the React Native application struggled when I scrolled through the list of cocktails. I think this is because of all of the cocktail images that needed to be downloaded. The Xamarin Forms application also struggled a bit when I was scrolling down the list of ingredients, which only had text and no images.

It’s obvious that the CPU-usage of the Flutter application is smaller than that of the React Native and Xamarin Forms applications, and that’s why I declare Flutter the winner of this experiment.

Is Flutter more performant than React Native and Xamarin Forms?

In the second experiment it was concluded that the Flutter application was less taxing on the CPU than the React Native and Xamarin Forms applications. This doesn’t automatically prove that Flutter is more performant than React Native or Xamarin Forms.

There are a lot of features that the Cocktailr app doesn’t have, like caching for example. That would reduce the amount of network requests that need to be made and would make the app more performant, meaning that it could lead to different results. I also only used CPU-usage as a performance indicator. I don’t have any data on the memory or battery consumption for example. These are also an important performance indicators.

I didn’t know beforehand what the results of this experiment were going to be. All I hoped to prove is that Flutter can stands its ground against other cross-platform frameworks, and I think I achieved that goal.