A lot of things happen in the lifecycle of an app. Bugs get fixed and features are added. Besides the changes in functionality of the app itself, it is also important to maintain and upgrade the dependencies of the app. Once in a while you have to upgrade the Flutter version that you are using. Upgrading the Flutter version is what this document is all about.

Upgrading Flutter

I think that everybody who uses Flutter has seen this message once in a while:

┌─────────────────────────────────────────────────────────────────────────────┐
│ A new version of Flutter is available!                                      │
│                                                                             │
│ To upgrade to the latest version, run "flutter upgrade".                    │
└─────────────────────────────────────────────────────────────────────────────┘

This command only updates the Flutter tooling, it does nothing for your source code. Although it looks that this is harmless, there is a caveat. Your project now contains files and folders that were generated with an older version of Flutter while it is compiled with a newer Flutter version.

Some examples:

• .gitignore might have changed and you might track or ignore wrong files and folders.

• The platform folders might have changes. Think about a new gradle version being used by the latest version of Flutter (build.gradle => build.gradle.kts).

• There might be new or changed entries in the pubspec.yaml.

Upgrading Flutter and your project step-by-step

The solution I describe in this document is to create all files and folders with the latest version of Flutter and to merge back the necessary changes. On top of that git is used to document the upgrade step-by step. For installing an pinning specific Flutter versions to a project, I use fvm.

You can use this git repository alongside with this document.

https://github.com/jsroest/upgrade_demo/commits/main/

Step 01 - Step 06: Create sample app

With “Step 01” through “Step 06” I created a demo app with Flutter 3.29.3 for demonstrating the upgrade process. As these steps are not relevant for the upgrade process itself, I do not describe the details here.

Step 07: Start flutter upgrade from 3.29.3 to 3.32.4.

This is an empty commit that documents the start of the update process.

Step 08: Delete all except .git, lib and test.

Delete everything except the source in the lib and test folder. Be sure to also delete all hidden files, except the “.git” folder. Add a commit to document the deletion.

Step 09: Create a new project with Flutter 3.32.4.

To minimize the manual work, it is necessary to use the same values with the “Flutter create” command as that was used in the original project.

• Match the description of the project.

• Match the organization.

• Match the project name.

• Match all platforms used and their languages (Java/Kotlin Objective-C/Swift).

• etc

Make 3.32.4 global and check the version fvm is using afterwards.

• fvm global 3.32.4

• fvm flutter --version

Recreate all files except any files in the lib and test folder. Flutter will skip those folders if they are already present.

• fvm flutter create --description "Demo upgrade from flutter 3.29.3 to flutter 3.32.4" --org com.rubigo --project-name upgrade_demo --platforms android .

• git add .

Add a commit to document the newly created files.

Step 10: Pin to Flutter 3.32.4 with fvm.

Pin the version of Flutter to use with fvm.

• fvm use 3.32.4

• git add .

Add a commit to document the new Flutter version to use for this project.

Step 11: Start manual merge.

This is the most complicated part of the upgrade. Here you have to judge the changes you have made to the original files and you have to merge them with the newly created files and or structure.

I like to mark this with an empty commit, to just have a point you can rollback to if the merge fails.

After the empty commit you have to do the following:

• Delete all except .git (don’t forget the hidden files and folders).

• Get all files and folders from Step 07. For this you have to know the git commit hash that belongs to Step 07.
  git checkout e019a0d144027d849bfb87f664ee5f0946bccde8 -- .
  This command will copy all files and folders that are present at the moment of Step 07.

• After the checkout you have to judge and merge every single file manually.

  I find Android Studio a good tool for that, because it’s easy to

  • Rollback a file if you want to keep the newly generated one.

  • Revert changes per line or block.

  • Commit the changes per file.

If you make a mistake with merging a specific file, you will have to restore the original from Step 07 with:
git checkout e019a0d144027d849bfb87f664ee5f0946bccde8 -- path/to/file

• I like to commit the changes per file.
  Be aware that it can be very confusing.

  Old version: Is the newly generated file.

  New version: Is the original file from Step 07.

Step 12: Merge completed. Flutter upgrade to 3.32.4 done.

I prefer an empty commit to mark the merge and upgrade as completed.

When you are done, you can check the upgrade by selecting the commit of Step 12 and Step 07. For that you can use e.g. Sourcetree or Fork

Final words

There is more work to be done after this. The code you have now may not compile at this point.

You might have to do one or more from these steps:

• Update/check all dependencies

• Migrate abandoned/unmaintained packages

• Apply new code guidelines and or lints

• Reformat all your code

Let me know what you think, feedback is appreciated.

We all understand that an internal combustion engine needs maintenance. The oil needs to be changed regularly, likewise the spark plugs and the timing belt. A failure to do so will most likely result in a higher consumption, lower engine performance, and in the end complete engine failure. Maintenance is necessary, because the engine has internal moving parts that wear out during its lifetime. It just comes down to physics.

If we take that analogy to software, one could argue that software does not need maintenance. It does not have any moving internal parts. So why is software maintenance even a thing?

The moving parts of software

With software, the “moving parts” are not on the inside of the program but on the outside.

Device OS

The device OS where the software is running on gets feature and security updates. It is not certain that the software will run flawlessly on a newer OS. It can be the features in the OS that change, but it can also be that the software is actively refused by the OS. Android nowadays prevents really old software to be run. Software compiled with older SDK’s are actively refused. That minimum SDK boundary rises automatically, with every new OS release.

Programming language

The app’s programming language evolves. The language gets new features and functions, but also some functions get deprecated and are eventually removed.

Libraries used

The libraries that the app uses are in motion. Some libraries are updated to follow the programming languages best practises and deprecation guidelines. Some libraries get new functionalities, and others are abandoned or superseded by competing libraries.

Programming tools

The programming tools evolve. The programming tools, like Android Studio, will support a lower boundary and an upper boundary of the programming language. To load an old project, an old version of Android Studio needs to be used.

Developers OS

The operating system of the developers laptop, changes. There comes a point in time when the developer is not able to start an old version of the development tools, like Android Studio.

CPU architecture developers OS

Eventually the developer gets a new laptop with a new processor architecture. Like in the past years where Apple made the transition from x86/x64 to arm64. I must admit that the backwards compatibility provided is pretty good, but it is for a fact that old x86/x64 virtual machine images are not usable on arm64. That means, that old windows software has to be able to run on the arm version of Windows, otherwise you are out of luck.

Security

If software maintenance is neglected, so is the security of the solution. The amount of vulnerabilities in software increases with time because of newly discovered vulnerabilities. Using unmaintained software is like driving a car without ever checking the tires.

Technical debt

The above shows that with software maintenance, everything is connected. The software itself does not change, of course, but it’s surroundings do. When software is not maintained it’s technical debt increases with time. If software maintenance is neglected long enough it might even become irreparable. Then the software is total loss, just like a car engine that snapped it’s timing belt.

Be sure that your software is maintained and kept up to date.

Technology Release Timeline (2013 - 2024+)

In the history of building workforce apps, there was in interesting twist.

In the beginning, computers were a thing for large companies, research facilities and universities. Consumers rarely came in touch with them. They were difficult to operate and very, very expensive.

At a later point in time, consumers got interested in computers, because they got less expensive and smaller. The Personal Computer was born. Remember the IBM-XT? I remember it well because I had one; I’m that…. experienced 😁.

Computers got smaller, and smaller until they could run on batteries.

The Telxon PTC960-SL was the first handheld I used to program for. It had similar specs as the original IBM-XT.

It was a Microsoft DOS compatible machine, with a 21×16 line text LCD and a kind of wifi. We used this to support warehouse personnel with their daily job and to give them realtime information at their current location.

At a later point in time, when DOS was replaced by Windows on the desktops, the OS on these devices was replaced with WindowsCE and Windows Mobile.

At this exact point, the twist happened. The computer companies were shifting their focus from enterprises to consumers. There was much more to earn there, the consumer market was much bigger. Not a few big chunks of money to earn, but many, many more small chunks.

So in the early days, the focus was on enterprises and consumers were a side market. Now it is the other way around. The focus is now on consumers and the enterprise is a side market.

There is not much to complain, in the end a lot of things improved, but there are some pain points that I will explain here below.

Hardware for the workforce

As devices for consumers are build in large quantities, they are in general cheaper and with better hardware specifications than the Enterprise counterparts. I remember, roughly ten or fifteen years ago, that enterprises tried to use consumer devices as a cheap alternative. The thought was simple: Buy a new one at the local shop if it fails or dropped and shattered. But in the end that didn’t work out well.

1. The lifecycle of a consumer device is short and unpredictable.
   “No sir, that particular model is replaced by this new fancy bigger one.”

2. There is no way to get an SLA (service level agreement) on these devices.
   “How can you expect an SLA on a 300 dollar device?”

3. Erratic OS updates.
   “We promise some updates for the first year, and it depends.”

4. OS updates can not be scheduled.
   “Production is halted in hall 1 and 2 because Android <X> came out last night.”

5. Contents of OS updates is not clear.
   “All 300 devices are offline, because of a patch in the WiFi driver.”

6. No internal hardware barcode scanner.
   “A camera can scan a barcode too. I do this all the time with electronic banking at home".

7. Bluetooth connection issues with hardware barcode scanners.
   “Press and hold till the light flashes blue, three times.”

8. Simply not ruggedised enough.
   “Oops, sorry boss.”

9. How to keep your workforce of Candy Crush and Pokemon Go?
   “How many points did you get in the first shift?”

If the number of devices was larger than a few, this became soon a nightmare to manage. Especially as time goes by and entropy kicks in.

1. More brands

2. More models

3. More configurations

4. More firmware versions

And how about security? How can you secure your business, if you have no idea which security patches are installed on your devices? Ransomware, anyone?

Operating Systems for the Workforce

To be honest, there is only one operating system left for our Enterprise Workforce devices, and that is Android.

So here we are. We now have Enterprise devices with a consumer OS and tools that are mostly used to build apps for consumers.

This is not necessarily a bad thing. The quality of the tools, like Flutter, is extremely high, with a great developer experience. Maybe that quality would not have been reached if the market was not so big.

But there is a constant tension:

Android introduces ways to improve battery life, protect the end-user privacy and add ways to secure their monetisation with the play store.

Enterprise devices manufacturers seek ways keep the operating system open, productive and usable for their customers workforce.

This is something that you have to keep in mind when developing apps for workforces.

Consumer apps versus Workforce apps

In my view, the last two factors are the key distinctions between consumer apps and workforce apps.

App logging

We use logging extensively. If a customer has a question, we can download the logging an trace step-by-step what happened. As the software is on the edge of the process, it is also the place where the user encounters issues.

With logging we can proof:

1. Bad response times of the backend.

2. Issues with the network or endpoints.

3. User errors.

4. Basically always show that the issue is not ours 🫢

Main goal

The main goal for most consumer apps is to please and monetise the consumer. Therefore they have to offer a super smooth experience where the user is always in control. Chances are great, if the user has to wait too long or too often, your app gets deleted and gets a bad review.

The main goal for most workforce apps is to support a workflow and to prevent mistakes. Therefore, if we have to wait for confirmation from the backend, there is not much else we can do then to wait. If we have to protect the workflow by locking the UI, then thats it, we lock it.

With consumer apps, the consumer is king. With workforce apps, the workflow is king. That’s basically it.

This means that you most likely will distribute your app as an APK and not as an "App Bundle".

In this post, I will discuss two pitfalls that you might encounter:

• versionCode: the version number on which Android decides which version of the APK is newer.

• keystore: each app is signed by a cryptographic key and that key has to be the same to allow app upgrades.

versionCode

The versionCode is what Android uses to determine the version of an app.

Let's consider this part of the pubspec.yaml file that is present in any Flutter app.

 version: 1.0.0+1

In the sample here above, 1.0.0 is the versionName and 1 is the versionCode. The versionName is a String and is only used for display purposes. What counts for Android is the versionCode, which is an integer. A higher number means a newer version and a lower number means an older version.

Normally it is not allowed to downgrade an app on Android. The only solution to that is to deinstall the app first which, depending on the setup, can happen automatically. A deinstall causes all local data and local configuration to get lost. This can be quite dramatic in Enterprise environments if the employees did not upload their work first.

So in an Enterprise Environment, when you deploy a new version, the versionCode of the new app must be higher than any released older versions.

This might sound like a trivial step, you just have to change the +1 in the sample above to +2, but there is a catch.

It is not 100% guaranteed that the versionCode that you specify in the pubspec.yaml file is the number that ends up in the generated APK.

Assume this build of a Flutter app, which creates a 'fat APK'.

% flutter build apk
Running Gradle task 'assembleRelease'...                           72.5s
✓  Built build/app/outputs/flutter-apk/app-release.apk (22.1MB).

Let's examine the versionCode of the generated app-release.apk.

% aapt dump badging ./build/app/outputs/flutter-apk/app-release.apk           
package: name='com.example.demo' versionCode='1' versionName='1.0.0' compileSdkVersion='33' compileSdkVersionCodename='13'

Here the versionCode = 1, exactly what we expected with version: 1.0.0+1 in the pubspec.yaml file.

Now consider this build of a Flutter app, which creates an APK for each platform (ABI). You might want to do this to shrink the size of the APK and because you think it might not hurt if you only target ARM64 devices.

% flutter build apk --split-per-abi
Running Gradle task 'assembleRelease'...                           15.3s
✓  Built build/app/outputs/flutter-apk/app-armeabi-v7a-release.apk (7.7MB).
✓  Built build/app/outputs/flutter-apk/app-arm64-v8a-release.apk (8.0MB).
✓  Built build/app/outputs/flutter-apk/app-x86_64-release.apk (8.1MB).

Let's examine the versionCode of app-arm64-v8a-release.apk.

% aapt dump badging ./build/app/outputs/flutter-apk/app-arm64-v8a-release.apk
package: name='com.dalosy.warehouse_app' versionCode='2001' versionName='1.0.0' compileSdkVersion='33' compileSdkVersionCodename='13'

Here the versionCode = 2001, this is not what we expected 🤯.

This is of course by design, see the following issue: flutter build apk --split-per-abi generates apk with wrong version code.

In this issue the following is referenced: https://developer.android.com/build/configure-apk-splits#configure-APK-versions

Here we can read the following:

Because the Google Play Store doesn't allow multiple APKs for the same app that all have the same version information, you need to ensure that each APK has a unique versionCode before you upload to the Play Store.

In the same article, a solution is discussed where the versionCode on each platform is incremented with a multiple of 1000 and so overcomes the Play Stores' limitation.

This is exactly how it is implemented in the toolchain of Flutter. Because of the open nature of Flutter, you can find the code that does this yourself.

In the file flutter.gradle you can find on row 897 the following code that makes this happen:

if (shouldSplitPerAbi()) {
    variant.outputs.each { output ->
        // Assigns the new version code to versionCodeOverride, which changes the version code
        // for only the output APK, not for the variant itself. Skipping this step simply
        // causes Gradle to use the value of variant.versionCode for the APK.
        // For more, see https://developer.android.com/studio/build/configure-apk-splits
        def abiVersionCode = ABI_VERSION.get(output.getFilter(OutputFile.ABI))
        if (abiVersionCode != null) {
            output.versionCodeOverride =
                abiVersionCode * 1000 + variant.versionCode
        }
    }
}

So, what does that mean, for us, the Enterprise Line of Business app programmers?

1. Keep using the same kind of APK for each of your existing projects. Do not switch from an "APK per abi" to a fat APK as this might result in unexpected app uninstalls and data loss for your customers.

2. Consider using fat APKs for all your projects, even though the APK has an increased size. Only this type of APK has the expected original versionCode.

3. Using "fat APKs" also prevents unexpected reinstalls while installing a debug version on a device that has a release build on it. Debug builds always use the same original versionCode as fat APKs.

Keystore

Each Android app is signed with a cryptographic key.

On large projects, with a lot of developers, or on high-profile apps, you do not want to store the cryptographic key with your source files. In that case, it is better to have the app signed by a CI/CD pipeline.

But if you are developing an app that is not distributed by the Play Store and is not a high-profile app, setting up a CI/CD pipeline is overkill and complicates the workflow for the developer without bringing reasonable benefits.

And if the release APK is signed with a different key than the debug APK, it will not be possible to install a debug version over a release version. The installed version is then uninstalled before the debug version is installed. This causes the loss of data that you might want to keep for your debugging session.

Therefore I choose the approach as explained here in the Flutter documentation.

1. Create a keystore with keytool and place that in ./android/keystore.

2. Create a key.properties file in ./android .

3. Change the build.gradle file so the local keystore is used.

This solution will not work cross-platform, due to the different path conventions between Windows, macOS, and Linux.

Therefore I changed the build.gradle a bit to make it work cross-platform too.

./flutter_app/android/key.properties
./flutter_app/android/keystore/upload-keystore.jks
./flutter_app/android/app/src/build.gradle

Sample key.properties:

storePassword=comedown-twiddle-hoax
keyPassword=comedown-twiddle-hoax
keyAlias=upload
storeFileWindows=..\\keystore\\upload-keystore.jks
storeFileLinux=../keystore/upload-keystore.jks
storeFileMac=../keystore/upload-keystore.jks

Here you see the different paths for Windows, Linux and macOS.

Sample build.gradle:

import org.apache.tools.ant.taskdefs.condition.Os
....
def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
} else {
    throw new GradleException("key.properties file not found, please define keystore file and password in key.properties")
}

def propertiesStoreFilename
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
    propertiesStoreFilename = file(keystoreProperties['storeFileWindows'])
} else if (Os.isFamily(Os.FAMILY_MAC)) {
    propertiesStoreFilename = file(keystoreProperties['storeFileMac'])
} else if (Os.isFamily(Os.FAMILY_UNIX)) {
    propertiesStoreFilename = file(keystoreProperties['storeFileLinux'])
} else {
    throw new GradleException("Unsupported OS Family: ${Os.os}")
}

def propertiesStorePassword = keystoreProperties['storePassword']
def propertiesKeyAlias = keystoreProperties['keyAlias']
def propertiesKeyPassword = keystoreProperties['keyPassword']
....

android {
....
    signingConfigs {
        debug {
            storeFile file(propertiesStoreFilename)
            storePassword propertiesStorePassword
            keyAlias propertiesKeyAlias
            keyPassword propertiesKeyPassword
        }
        release {
            storeFile file(propertiesStoreFilename)
            storePassword propertiesStorePassword
            keyAlias propertiesKeyAlias
            keyPassword propertiesKeyPassword
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
        }
        debug {
            signingConfig signingConfigs.debug
        }
    }
}

Now your APK will be signed with a local keystore, independent from the platform you are developing on.

I hope you had a fun read, let me know what you think! 💙

This works pretty well and you can find the official documentation here:

Internationalizing Flutter apps

I have some tips and tricks that I would like to share with you.

TIP 1: Know your options

If you want to know all the options there are for localization, it is a good idea to run this command and examine the output.

flutter gen-l10n -h

There are more configurable options than there are mentioned in the official documentation. For your convenience, this is the actual output:

johannesroest@WS-SW103 app % fvm flutter gen-l10n -h                                                                                         
Generate localizations for the current project.

Global options:
-h, --help                  Print this usage information.
-v, --verbose               Noisy logging, including all shell commands executed.
                            If used with "--help", shows hidden options. If used with "flutter doctor", shows additional diagnostic information. (Use "-vv" to force verbose logging in those cases.)
-d, --device-id             Target device id or name (prefixes allowed).
    --version               Reports the version of this tool.
    --suppress-analytics    Suppress analytics reporting when this command runs.

Usage: flutter gen-l10n [arguments]
-h, --help                                                      Print this usage information.
    --arb-dir                                                   The directory where the template and translated arb files are located.
                                                                (defaults to "lib/l10n")
    --output-dir                                                The directory where the generated localization classes will be written if the synthetic-package flag is set to false.

                                                                If output-dir is specified and the synthetic-package flag is enabled, this option will be ignored by the tool.

                                                                The app must import the file specified in the "--output-localization-file" option from this directory. If unspecified, this defaults to the same directory as the input directory specified in "--arb-dir".
    --template-arb-file                                         The template arb file that will be used as the basis for generating the Dart localization and messages files.
                                                                (defaults to "app_en.arb")
    --output-localization-file                                  The filename for the output localization and localizations delegate classes.
                                                                (defaults to "app_localizations.dart")
    --untranslated-messages-file                                The location of a file that describes the localization messages have not been translated yet. Using this option will create a JSON file at the target location, in the following format:

                                                                    "locale": ["message_1", "message_2" ... "message_n"]

                                                                If this option is not specified, a summary of the messages that have not been translated will be printed on the command line.
    --output-class                                              The Dart class name to use for the output localization and localizations delegate classes.
                                                                (defaults to "AppLocalizations")
    --preferred-supported-locales=<locale>                      The list of preferred supported locales for the application. By default, the tool will generate the supported locales list in alphabetical order. Use this flag if you would like to default to a different locale. For example, pass in "en_US" if you would like your app to default to American English on devices that support it. Pass this option multiple times to define multiple items.
    --header                                                    The header to prepend to the generated Dart localizations files. This option takes in a string.

                                                                For example, pass in "/// All localized files." if you would like this string prepended to the generated Dart file.

                                                                Alternatively, see the "--header-file" option to pass in a text file for longer headers.
    --header-file                                               The header to prepend to the generated Dart localizations files. The value of this option is the name of the file that contains the header text which will be inserted at the top of each generated Dart file.

                                                                Alternatively, see the "--header" option to pass in a string for a simpler header.

                                                                This file should be placed in the directory specified in "--arb-dir".
    --[no-]use-deferred-loading                                 Whether to generate the Dart localization file with locales imported as deferred, allowing for lazy loading of each locale in Flutter web.

                                                                This can reduce a web app’s initial startup time by decreasing the size of the JavaScript bundle. When this flag is set to true, the messages for a particular locale are only downloaded and loaded by the Flutter app as they are needed. For projects with a lot of different locales and many localization strings, it can be an performance improvement to have deferred loading. For projects with a small number of locales, the difference is negligible, and might slow down the start up compared to bundling the localizations with the rest of the application.

                                                                This flag does not affect other platforms such as mobile or desktop.
    --gen-inputs-and-outputs-list=<path-to-output-directory>    When specified, the tool generates a JSON file containing the tool's inputs and outputs named gen_l10n_inputs_and_outputs.json.

                                                                This can be useful for keeping track of which files of the Flutter project were used when generating the latest set of localizations. For example, the Flutter tool's build system uses this file to keep track of when to call gen_l10n during hot reload.

                                                                The value of this option is the directory where the JSON file will be generated.

                                                                When null, the JSON file will not be generated.
    --[no-]synthetic-package                                    Determines whether or not the generated output files will be generated as a synthetic package or at a specified directory in the Flutter project.

                                                                This flag is set to true by default.

                                                                When synthetic-package is set to false, it will generate the localizations files in the directory specified by arb-dir by default.

                                                                If output-dir is specified, files will be generated there.
                                                                (defaults to on)
    --project-dir=<absolute/path/to/flutter/project>            When specified, the tool uses the path passed into this option as the directory of the root Flutter project.

                                                                When null, the relative path to the present working directory will be used.
    --[no-]required-resource-attributes                         Requires all resource ids to contain a corresponding resource attribute.

                                                                By default, simple messages will not require metadata, but it is highly recommended as this provides context for the meaning of a message to readers.

                                                                Resource attributes are still required for plural messages.
    --[no-]nullable-getter                                      Whether or not the localizations class getter is nullable.

                                                                By default, this value is set to true so that Localizations.of(context) returns a nullable value for backwards compatibility. If this value is set to true, then a null check is performed on the returned value of Localizations.of(context), removing the need for null checking in user code.

TIP 2: Use l10n.yaml

I like to store the options in the l10n.yaml file and check it into version control.

This is the configuration I use:

arb-dir: lib/l10n/arb
output-dir: lib/l10n/generated
template-arb-file: intl_nl.arb
output-localization-file: l10n.dart
output-class: S
synthetic-package: false
nullable-getter: false
#untranslated-messages-file: l10n_errors.txt

TIP 3: Do not use a synthetic package

synthetic-package: false

I would like to set this value to false. So I can actually see and 'check in' the code that is generated.

This isn't fail-safe, as I sometimes have to flip this value to true for one compilation and back to false to fix a build error. I do not get this error a lot (it might be fixed in the meantime). I will update this post when I get this error again.

TIP 4: Configure the folders for the source and target files

arb-dir: lib/l10n/arb
output-dir: lib/l10n/generated

These are the folders where the localization files are stored. The arb-dir is the folder where the tool can find the 'source' arb files. The output-dir is the folder where the tool places the generated dart files.

Keep in mind, that the output-dir is only used when synthetic-package is set to false.

TIP 5: Name the output localization file

output-localization-file: l10n.dart

This defines the file that you will have to import in each dart file where you want to use localization. It is good to use something memorable. For me, this name works great with code completion when typing import 'l10n'.

import 'package:count_app/l10n/generated/l10n.dart';

TIP 6: Choose a short name for the localization class

output-class: S

By default, the class name for the generated localizations is named 'AppLocalizations'. While this name is accurate, I think it's way too long if you need it in many locations in your source code.

// A bit too long 
AppLocalizations.of(context)
// This look better 
S.of(context)

TIP 7: Don't generate nullable getters

nullable-getter: false

Unless you have some code that has to be compatible with nullable by default, I recommend setting this value to false. Otherwise, you will have to do a null check on each call to S.of(context)!, which is cumbersome and looks ugly.

TIP 8: Specify the template arb file

template-arb-file: intl_nl.arb

If you use placeholders in your translations, you need to specify the type (string, int etc) and the name of that placeholder. This information is not needed in every arb file, but only in the 'template' arb file.

  "s100LoggingOnToBranch": "Je gaat je aanmelden bij vestiging **{branchId}**.",
  "@s100LoggingOnToBranch": {
    "placeholders": {
      "branchId": {
        "type": "String"
      }
    }
  },

TIP 9: Translate per page and number your pages

I like to number my pages and translate per page. Although this gives some duplicated translation values, I like the flexibility that it gives.

A sample of page names are:

• s100_sign_in_ax_page.dart
• s200_main_menu_page.dart
• s300_select_document_page.dart
• s310_download_documents_page.dart
• s320_upload_documents_page.dart

I use this numbering, to group my translations. All translations for pages start with 'sxxx'. This makes refactoring also a bit easier. If I want to delete a page, I can easily delete the corresponding translations as well. Or if I want to change a translation I can easily see on which page that translation is (supposed to be) used.

It also narrows down the translations to choose from while working on a specific page, as all the translations on that page will start with the same identifier, e.g. s100*.

TIP 10: Regenerate the translations while programming

Flutter does support 'hot reload' when adding or changing localizations while debugging. This is awesome, but the code is not generated on each change when there is no debug session running.

You can force the code to be regenerated with this command:

flutter gen-l10n

This way you can easily add translations and enjoy code completion while programming.

TIP 11: Get an overview of missing translations

Uncommenting the line #untranslated-messages-file and running flutter gen-l10n, will help you to find translations that are not yet translated for all languages.

#untranslated-messages-file: l10n_errors.txt

TIP 12: Sort the arb files alphabetically with arb_utils

You can only compare arb files comfortably if the order of the translations in each arb file is the same. It is really cumbersome and error-prone to manage the order of translations by hand.

Luckily there is a package that you can use to sort the arb files. It also keeps the placeholder lines in the template arb file together with the corresponding translation line.

https://pub.dev/packages/arb_utils

This command will sort the contents of an arb file alphabetically.

dart pub global run arb_utils:sort lib/l10n/arb/intl_nl.arb;

The result will be a sorted arb file 🎉

  "s110DialogPincodeErrorTitle": "Waarschuwing",
  "s110LoggingOnToBranch": "Je gaat je aanmelden bij vestiging **{branchId}**.",
  "@s110LoggingOnToBranch": {
    "placeholders": {
      "branchId": {
        "type": "String"
      }
    }
  },
  "s110SubTitle": "Meld je aan",

TIP 13: Script it!

To support my workflow, I have added a script to my Flutter project in a /scripts folder. Although this script is for macOS, the intentions are clear and obvious, so it would not be too difficult to change this for a Windows environment.

This script sorts all my arb files, and after that, it calls flutter gen-l10n to generate the dart translation classes.

Now it is super easy to sort the arb files and generate the dart code by just executing a simple script.

#!/bin/zsh
pushd ..;
dart pub global run arb_utils:sort lib/l10n/arb/intl_fr.arb;
dart pub global run arb_utils:sort lib/l10n/arb/intl_nl.arb;
fvm flutter gen-l10n
popd;

This article is about exchanging data with a fixed-length data format. It will tell you about the pros and cons of this data format. It shows and demonstrates an implementation in Dart that is easy to read and maintain. The implementation supports characters that consist of more than one code unit like e.g. emojis. It will also show that the standard functions like String.length and String.substring may fail on emojis.

Pros and Cons of the fixed-length data format

Data can be interchanged between systems in many different formats. The most well known format nowadays is json, but other popular formats are xml, csv and fixed-length.

This article is about the fixed-length data format. It has some advantages over the other ones.

• No need to load all data into memory before the data can be used. This is especially useful when importing large datasets. The data can be read and processed in chunks.
• No need to use escape characters, like you have to do with csv files. With csv files, there is always a problem when you want to use the character in the data that is also used to separate the values.

Of course, there are also downsides to using a fixed-length data format.

• The sender and the receiver have to agree on the order of values and length of each value.
• Each field has to be padded with trailing spaces or leading zeroes.
• Each field is (obviously) fixed in length. An increase in length would need work on both the source and destination.

Data definition

It is important to document the format, so the source and destination are both aware of the format used. A simple document could look like this:

Sample data

----------------------------------------------------------
1234567890123456789012312345678901234512345678901234567890
Sander    Roest     049Rotterdam      The Netherlands     
Sandra    Roest     042Rotterdam      The Netherlands     
Jeffrey   Roest     009Rotterdam      The Netherlands     
Lucas     Roest     007Rotterdam      The Netherlands     
----------------------------------------------------------

Implementation in Dart

Writing the code to parse fixed-length data seems like an easy job. At first, it looks like you just have to substring all the fields out of the data. This is in fact true, but it might get messy and difficult to maintain when the data definition changes.

Another issue to consider is that the String.length and String.substring functions might not work in the way you think.

The String class works with code units. This means that you will get the length of a string in code units and not characters.

You can read all about it in this excellent post Dart string manipulation done right 👉.

To overcome both problems, you can use this helper class:

class FixedLengthParser {
  FixedLengthParser(String value) : _characters = value.characters;

  final Characters _characters;
  var _index = 0;

  String getByLength(int length) {
    var value = _characters.getRange(_index, _index + length);
    _index += length;
    return value.string.trim();
  }
}

The usage of this class makes it easy to match the code with the data definition. If the length of a field changes, you will have to change it only in one place.

final parser = FixedLengthParser(line);
final firstName = parser.getByLength(10);
final lastName = parser.getByLength(10);
final age = parser.getByLength(3);
final city = parser.getByLength(15);
final country = parser.getByLength(20);

Dartpad sample

With the dartpad sample you will be able to:

• Test the FixedLengthParser class (renamed to FixedLengthParserCharacters)
• Observe that String.substring fails on Emojis
• See a fun usage of the new constructor-tear-off functionality in Dart to use the same code with a working (characters) and a failing (string) implementation.

https://dartpad.dev/?id=f4e6612c9f3ef3b5eb3e439923fe8a46

The output looks like this where you can see that the String implementation fails on emojis.

Parse the data using characters:
-------------------------------------------------
Firstname (10): 1234567890
Lastname (10): 1234567890
Age (3): 123
City (15): 123456789012345
Country (20): 12345678901234567890

Firstname (6): Sander
Lastname (5): Roest
Age (3): 049
City (9): Rotterdam
Country (15): The Netherlands

Firstname (10): 🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇
Lastname (10): 🥈🥈🥈🥈🥈🥈🥈🥈🥈🥈
Age (3): 🎂🎂🎂
City (15): 🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘🏘
Country (20): 🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱🇳🇱

Parse the data using string (faulty):
-------------------------------------
Firstname (10): 1234567890
Lastname (10): 1234567890
Age (3): 123
City (15): 123456789012345
Country (20): 12345678901234567890

Firstname (6): Sander
Lastname (5): Roest
Age (3): 049
City (9): Rotterdam
Country (15): The Netherlands

Firstname (5): 🥇🥇🥇🥇🥇
Lastname (5): 🥇🥇🥇🥇🥇
Age (2): 🥈�
City (8): �🥈🥈🥈🥈🥈🥈🥈
Country (10): 🥈🎂🎂🎂🏘🏘🏘🏘🏘🏘

Happy parsing!

Theming your Flutter app can be a challenge. This post will try to help you with the following:

1. Provide sensible theme defaults for both light-mode and dark-mode.
2. Customize the default theme.
3. Extend the default theme.

This post comes with a sample app on Github. You might want to check it out because the code snippets in this post will make a lot more sense in the full context of the sample app.

Sample app:

Provide sensible theme defaults

If you want a quick start, I recommend using Mike Rydstrom's FlexColorScheme package.

This truly amazing package will give you sensible defaults for light-mode and dark-mode by providing at least one color.

app_theme.dart

ThemeData get _theme => _flexColorSchemeFactory(
  colors: FlexSchemeColor.from(
    primary: _basePrimaryColor,
    secondary: _baseSecondaryColor,
    error: _baseErrorColor,
  ),
  visualDensity: FlexColorScheme.comfortablePlatformDensity,
).toTheme

With that package initializing the theme in your will be as simple as:

main.dart

MaterialApp(
  title: 'Flutter Demo',
  theme: const AppThemeDataLight().theme,
  darkTheme: const AppThemeDataDark().theme,
   home: const MyHomePage(title: 'Flutter Demo Home Page'),
);

Customize the default theme

If you want to change the default theme, you can use the copyWith method on the ThemeData class. This method allows you to swap some parts of the theme with your own.

app_theme.dart

ThemeData get _theme => _flexColorSchemeFactory(
  colors: FlexSchemeColor.from(
    primary: _basePrimaryColor,
    secondary: _baseSecondaryColor,
    error: _baseErrorColor,
  ),
  visualDensity: FlexColorScheme.comfortablePlatformDensity,
).toTheme.copyWith(
  elevatedButtonTheme: _elevatedButtonThemeData(),
  outlinedButtonTheme: _outlinedButtonThemeData(),
  textButtonTheme: _textButtonThemeData(),
);

Extend the default theme

Sometimes you want to add custom colors and properties to the theme. With an extension method on ThemeData, this worked out pretty simple.

app_theme.dart

extension AppTheme on ThemeData {
  AppThemeData get appTheme => brightness == Brightness.dark
      ? const AppThemeDataDark()
      : const AppThemeDataLight();
}

With this extension method, getting custom colors and properties becomes really easy and intuitive.

'custom_button.dart'

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:yapb_theme/classes/app_theme.dart';

class CustomButton extends ConsumerWidget {
  const CustomButton(
    this.text, {
    Key? key,
    this.onPressed,
  }) : super(key: key);
  final String text;
  final VoidCallback? onPressed;

  @override
  Widget build(context, ref) {
    return OutlinedButton.icon(
      style: OutlinedButton.styleFrom(
        minimumSize: const Size(48, 48),
        padding: const EdgeInsets.all(8),
        side: Theme.of(context).appTheme.customButtonBorderSide,
      ),
      label: Text(
        text,
        style: TextStyle(
          fontWeight: FontWeight.w400,
          color: Theme.of(context).appTheme.customButtonColor,
        ),
      ),
      icon: Icon(
        Icons.flag,
        color: Theme.of(context).appTheme.customButtonColor,
      ),
      onPressed: onPressed,
    );
  }
}

About the sample app

In the sample app I have used the techniques from other posts in this blog. Key elements in this sample app are:

1. Set up a mono repository with this dart script
2. Replace getter and setter blocks with a oneliner when using ChangeNotifier.
3. Flutter Riverpod
4. Flex color scheme

Although it might not be so obvious at first glance, this keyword makes it possible to simplify getter and setter blocks when using a ChangeNotifier to update values on the screen.

Normally a getter and setter block does look like this.

int _counter = 0;

int get counter => _counter;

set counter(int value) {
  if (_counter != value) {
    _counter = value;
    notifyListeners();
  }
}

This code is not complicated. It consists of:

• a private backing variable
• a public getter and setter
• some logic that tests if the value has changed and calls ‘notifyListeners’ when needed

There are also some drawbacks:

• You can access the backing variable directly (by accident).
• It is easy to make mistakes like checking or assigning the wrong backing variable, especially when you have more than 3 pairs of getters and setters.
• The code is boring (error-prone) and takes up too much space.
• Don’t repeat yourself (DRY) principle is not respected.

Now with the ‘late’ keyword, we can replace the code above with this one-liner:

late final counter = Property(0, notifyListeners);

Without the ‘late’ keyword this would not have been possible, because it is not allowed to access member functions (in this case notifyListeners) in an initializer. With the late keyword, initialization is deferred until the property is first referenced.

The implementation of the Property class is simple and solves all drawbacks of a regular getter and setter block.

class Property<T> {
  Property(T initialValue, this.notifyListeners) {
    _value = initialValue;
  }

  late T _value;
  final void Function() notifyListeners;

  T get value => _value;

  set value(T value) {
    if (_value != value) {
      _value = value;
      notifyListeners();
    }
  }
}

This makes it possible to reduce the business logic of the default Flutter counter app to these few lines:

class MainController extends ChangeNotifier {
  late final counter = Property<int>(0, notifyListeners);

  void incrementCounter() => counter.value++;
}

Source code to test this out can be found here:
https://github.com/jsroest/property_for_changenotifier

Open a terminal and go to the packages folder.

Go to the packages folder

cd ~/repos/0000000-demo_mono_repo_app-rubigo/packages

Create a Flutter package

fvm flutter create -t package --org com.example --project-name my_package ./my_package

Open/restart Android Studio

Android studio might not detect the new folder. Restarting Android Studio fixes that.

Commit package

From now on we will use Android Studio to review and commit files.

Choose “Commit”

Add package as a module

Android Studio => File -> Project Structure => Modules => + => Import Module

Navigate to my_package folder and choose “Open”. Be aware that the initial folder that Android Studio suggests might not be part of your current project.

Select “Create module from existing sources”, choose “Next”Choose “Next”Choose “Next”Choose “OK”

Commit add a package as a module

Choose “Commit”

Add package as a dependency

Open demo/mono/repo/app/pubspec.yaml and add my_package, and run pub get.

Commit add a package as a dependency

Choose “Commit”

Change main.dart to use package

If you change the line _counter++ to the sample here below, the demo app will use the package to add the values. Hot reload also works while you make changes to the implementation in my_package, which is awesome.

Commit changes to main.dart

Choose “Commit”

Done

These are all the steps that are needed to add a package to the mono-repo.

Open a terminal and go to the packages folder.

Go to the packages folder

cd ~/repos/0000000-demo_mono_repo_app-rubigo/packages

Create a Flutter plugin

fvm flutter create -t plugin --platforms ios,android --org com.example --ios-language objc --android-language java --project-name my_plugin ./my_plugin

Open/restart Android Studio

Android studio might not detect the new folder. Restarting Android Studio fixes that.

Commit plugin

We will use Android Studio to review and commit files.

Choose Commit

Add plugin as a module

Android Studio => File -> Project Structure => Modules => + => Import Module

Navigate to my_plugin folder and choose “Open”. Be aware that the initial folder that Android Studio suggests might not be part of your current project.

Select “Create module from existing sources”, choose “Next”Deselect all lines, except the one with Flutter, choose “Next”Deselect all, choose “Finish”

Commit add plugin as a module

Choose “Commit”

Add plugin as a dependency

Open demo_mono_repo_app/pubspec.yaml and add my_plugin, and run pub get.

Commit add plugin as a dependency

Choose “Commit”

Change main.dart to use plugin

With some small changes, we can call MyPlugin.platformVersion, which gets information about the current OS.

Commit changes to main.dart

Choose “Commit”

Done

These are all the steps that are needed to add a plugin to the mono-repo.

The app final app can be downloaded from:
https://github.com/jsroest/0000000-demo_mono_repo_app-rubigo

I was intrigued by a blog post from Rémi Rousselet with the title Getting started: Creating your Flutter project. In this post, Rémi does an excellent job in explaining how to set up a Flutter project with the right rules, like enabling strong-mode, set up the linter, and disable warnings for generated files. A great way to start…. except for one thing, that I could not grasp fully. Rémi advises using the ‘/packages’ folder convention. Although I did understand the idea behind it, I could not find the right workflow to set this up. It always felt a bit like hacking and abusing the IDE, in my case Android Studio, until it worked.

In this blog post, I write about the workflow that I have found to set this up the right way, and with consistent results. ‘Consistent result’ you might think…. what? This is because Android Studio does more than just opening the folder when you open a Flutter project for the first time. It does search and index the whole tree and makes assumptions about how you probably want to use the project. It uses the data and file contents (like .gitignore) in your project folder, to guess the right settings. This means that if you do things in (a slightly) different order, the result is a bit different.

This blog post will help you to set up your Flutter project consistently and logically. You will have Flutter app project, with the possibility to extract your reusable code in separate packages (or plugins). With, of course, the ability to reuse these packages easily in other projects. You could even put these packages later on at pub-dev, and just update the reference in pubspec.yaml to use the published version.

There is also a companion repository on github to automate this process. You can read about it here: Make all these steps a one-liner

I use Flutter Version Management (FVM) by Leo Farias. If you have multiple Flutter projects that you have to support, this tool is mandatory. It keeps track of the Flutter version you have used for a specific project and it makes switching between these versions a breeze. You will never have to wait again for downloading the Flutter files when you switch to another project that uses another version of Flutter. It will improve your life as a developer.

FVM

Make sure you have FVM installed and applied the setup of paragraph “Set Global Version”.

Create project folder

mkdir 0000000-demo_mono_repo_app-rubigo

I use the following convention for the project folder:

• 0000000
  The customer id filled up with zeros to seven positions. Companies might change their name, but their id (as used in the ERP or financial system) does not change.
• –
  A separator between customer id and app name.
• demo_mono_repo_app
  This is the name of the app, only lowercase and underscores allowed
• –
  A separator between app name and the company name
• rubigo
  This is the name of the company, this makes it easy to search for a project in a folder

Go to the project folder

cd  0000000-demo_mono_repo_app-rubigo

Initialize git

git init

Caveat 1
You can also enable git via Android Studio:
Menu => VCS => Enable Version Control Integration…

But this does create a .git folder inside the Flutter project. This is not what we want. The goal is to have a mono-repo, which means multiple packages in one git repository. That’s why we have to do the git init in the top project folder

Create packages folder

mkdir packages

Change to packages folder

 cd packages

Create app project

fvm flutter create --org rubigo --project-name demo_mono_repo_app --ios-language objc --android-language java app

• fvm
  This is the Flutter Version Management program.
• flutter
  Because of FVM’s “Set Global Version”, the selected Flutter version will be used to execute the command.
• create
  This instructs Flutter to create a new app project
• –org com.rubigo
  The company to use. This is used (with the project name) for Android’s application id and iOS’s product bundle identifier.
• –project-name demo_mono_repo_app
  This is the name of the app, only lowercase and underscores are allowed. I keep this identical to the name of the app in the project folder name.
• –ios-language objc
  It’s my preference to use objective c as the language for the iOS runner. Choose as you like.
• –android-language java
  It’s my preference to use java as the language for the Android runner. Choose as you like.
• app
  This is the name of the folder for the app project that is created inside the packages folder. If it’s always ‘app’ across projects then it’s always easy to find.

Change to app folder

cd app

Commit .gitignore

git add .gitignore
git commit -m "[app] Initial commit"

Because we will edit the gitignore file, we will commit it first to have a complete history correct.

Change .gitignore for IntelliJ IDEA

# IntelliJ related
-*.iml
-*.ipr
-*.iws
-.idea/
+.idea/**/workspace.xml
+.idea/**/tasks.xml
+.idea/**/usage.statistics.xml
+.idea/**/dictionaries
+.idea/**/shelf
+.idea/**/libraries

The new .gitignore allows sharing of modules and run configurations between developers.

Commit .gitignore

git add .gitignore
git commit -m "[app] Change .gitignore to include important .idea files"

The changes are committed.

Commit Flutter project

git add -A
git commit -m "[app] Initial flutter project"

Now the freshly created Flutter project is committed.

Init fvm for project

fvm use 1.22.6

This adds the .fvm folder to the project. This folder contains a file with the flutter version to use and a symlink to the selected Flutter version.

Change .gitignore for FVM

# FVM related
/.fvm/flutter_sdk

These lines are needed to explicitly exclude the flutter_sdk folder from git. Otherwise, you have the risk of adding a complete Flutter SDK to your repository.

Change demo_mono_repo_app.iml

<content url="file://$MODULE_DIR$">
 <sourceFolder url="file://$MODULE_DIR$/lib" isTestSource="false"/>
 <sourceFolder url="file://$MODULE_DIR$/test" isTestSource="true"/>
 <excludeFolder url="file://$MODULE_DIR$/.dart_tool"/>
 <excludeFolder url="file://$MODULE_DIR$/.fvm/flutter_sdk"/>
 <excludeFolder url="file://$MODULE_DIR$/.idea"/>
 <excludeFolder url="file://$MODULE_DIR$/.pub"/>
 <excludeFolder url="file://$MODULE_DIR$/build"/>
</content>

This excludes the flutter_sdk path in Android Studio. Otherwise, search results will also include results in the Flutter SDK.

Caveat 2

If you try to add this line via the Android Studio menus File=>Project Structure=>Modules, Android Studio will bite you. During startup, all folders are indexed, including the .fvm/flutter_sdk folder. You will end up with countless excluded folders from the SDK folder in the demo_mono_repo_app.iml file.

Commit FVM changes

git add -A
git commit -m "[app] Init FVM 1.22.6"

Remove android.iml from modules.xml

<modules>
  <module
  fileurl="file://$PROJECT_DIR$/demo_mono_repo_app.iml"
  filepath="$PROJECT_DIR$/demo_mono_repo_app.iml" />
  -- <module
  --  fileurl="file://$PROJECT_DIR$/android/demo_mono_repo_app_android.iml"
  --  filepath="$PROJECT_DIR$/android/demo_mono_repo_app_android.iml" />
</modules>

Remove the demo_mono_repo_app_android.iml module in the file .idea/modules.xml. It is not needed.

Commit modules.xml

git add -A
git commit -m "[app] Remove demo_mono_repo_app_android.iml from modules.xml"

Mono repo setup is finished

This is it, the flutter mono repo is successfully set up.

Make all these steps a one-liner

If you want to make these steps above a one-liner you can use this dart cli project: https://github.com/jsroest/create_flutter_mono_repo

dart create_flutter_mono_repo.dart --root-path /<your repos folder> --customer-id 0000000 --project-name demo_mono_repo_app --customer-name rubigo --org com.example --ios-language objc --android-language java --flutter-version 1.22.6

Always open the app folder

Remember to always open the app folder in Android Studio if you want to work on your Flutter app or one of the local packages that you will add later. The app folder will contain links to the other packages so that you can edit all your Flutter code from one place.

This year (2020) we delivered our first Line Of Business app that's built with Flutter to one of our customers.

The launch of the app was a success. The app went live without issues and the app was accepted by the users with ease.

We thought this app is a great way to demonstrate our app craftmanship of Line of Business Apps to a broader audience. That is why we decided to put a demo version of this app in the play store, app store, and on the web.

You can download the app for your device, or even try it out in your browser.

Sample barcode sheet (pdf)

The creation of the demo app

Although the customer was using the app successfully in production, it was not ready yet to serve as a demo app.

We needed to make the ‘demo’ experience better:

• Replace customer’s logos and icons
• Add iOS and Web as a target
• Internationalize the app
• Use the camera as a barcode scanner
• Mock the communication with the backend
• Final words and screenshots

Replace customer’s logo and icons

This was not the most fun part. Normally these assets are delivered to us by a designer, but now I had to figure it out by myself (again). Nothing too hard, but tedious as I remembered how it was in the past.

Add iOS and Web as a target

Now the fun started. Support for iOS was already there, or at least for the most part. Adding Web support was as easy as switching to Flutter’s beta branch.

The only major part that had to be rewritten for the web was the datastore. We like to have the power of SQL in our line of business apps, but SQL support on the web is just not there, or at least not in the way we like it. Because this application is not too difficult, we reworked the datastore from SQLite tables to hive tables. This took roughly 2 days but was straightforward and easy.

Internationalize the app

The original app was only in Dutch. To internationalize the app we used localizely. Localizely is an ide plugin that uses arb files for input and generates code that follows the same pattern to localize apps as the rest of the Flutter framework. Any literal string in the code can be easily extracted to the arb files by pressing ALT-ENTER.

After that, I created a Google sheet where I could import the English arb file (which is a JSON formatted file) and machine translate the texts to other languages. With the help of some Google sheet plugins, the result can be extracted as arb/JSON files again. This was a bit sensitive to errors, but it got the job done. For larger projects, I would recommend a more professional workflow than Google sheets.

Use the camera as a barcode scanner

The original app was designed for a Zebra TC57 touch computer.

This is a ruggedized Android device with a dedicated barcode scanner. The barcode scanner of this device performs excellently.

On other devices, we wanted to use the camera as a fallback option. This is where things got a bit complicated.

The opensource ZXING barcode scan library is abandoned. Any plugin based on that is not future-proof.

Commercial libraries are performing very well, but are very expensive and have a subscription model. You will have to pay for the number of users per year. This is far from ideal for a demo app.

We ended up implementing the barcode recognition with Google’s ML-Kit. At this time ML-Kit is still in beta, but there is a working Flutter sample from the firebase team. We used this sample as a starting point.

On Zebra devices, we normally enable ‘picklist mode’. When in picklist mode, the crosshairs projected on the target (red laser-lines) determine the barcode that is scanned. This makes it easier to scan the right barcode when more barcodes are visible at the same time. For example when barcodes are printed on a sheet of paper.

To make it easier for the user to scan the right barcode with the camera, the user can suspend the recognition by touching the screen You can then position the barcode under the square. When you release your finger, the barcode recognition is active and barcodes are scanned. A green square indicates that the recognition is suspended, a red square indicates that the recognition is active.

Because every type of phone has different camera characteristics like resolution and autofocus, the barcode scanning performance can be tweaked in the settings of the app.

I think that iPhone users will be most satisfied with the barcode scanning performance.

Mock the communication with the backend

The production app communicates with a backend to exchange data. Of course, the demo app has to be able to function without a backend. Therefore there is a setting ‘Demo mode’ in the app. For the demo app, this setting is enabled by default. When enabled, the communication functions inside the app are replaced with default reasonable responses. That’s why you can test the app without a backend.

Final words and screenshots

We had a really good time, building this app in Flutter. I had great plans of explaining every detail of it on this blog. Unfortunately, COVID-19 made this impossible. Thankfully not because of illness, but because of lack of time.

Thank you all for reading and trying out the demo.

For questions about the app, you can contact me.
If you want a quotation for your Line Of Business app, contact us here.

Consumer apps

• Collect application crashes/warnings
• Narrow down problems to specific manufacturers, hardware, os versions
• Get insights on how much the app is installed/used across the globe
• Get insights on how the app is used
• Get insights on how the monetization of the app can be improved

Line Of Business apps

• Collect application crashes/warnings
• Narrow down issues with backend services
• Narrow down issues reported by individual users
• Enterprises do not like Line Of Business apps that leak info to Google, Apple, or other Application Monitoring or Tracking Software

On the other hand, logging for Line Of Business apps is quite simple:

• Logging is written to local persistent storage (text file or database)
• Add logging to strategic points in the app, so you can follow the usage of the app
• Each log line has a timestamp, loglevel, message and stacktrace (if available)
• When the max amount of logging is reached, delete old logging
• When a problem is reported, download the logging with an EMM and analyze it

Async challenges

The async nature of Flutter does make logging a bit more complicated than it was in the synchronous world.

We want to log things as soon as the application starts, but to store the logging, we are dependant on an async filesystem/database that needs time to initialize.

To be able to log events before it can be written, I split the logging service into two parts:

• Logging service
• Logging service file (persistent part)

The logging service is the first service that is started. This means that all other services can log messages. As long as the ‘Logging service file’ is not started, the ‘Logging service’ keeps the logging in memory.

As soon as the ‘Logging service file’ is started, it registers its ‘writer’ function in the Logging service. As soon as this is registered, the cached logging is purged to this ‘writer’ function. From now on, the ‘logging service’ uses this ‘writer’ function directly instead of its memory cache.

Initialization of the LoggingServiceFile and registering its writer function:

  Future<void> onStart() async {
    await Provider.of<VersionService>(context, listen: false).init();
    await Provider.of<SoundService>(context, listen: false).init();
    await Provider.of<ConfigurationBoxService>(context, listen: false).init();
    await Provider.of<ConfigurationLoader>(context, listen: false).init();
    await Provider.of<LoggingServiceFile>(context, listen: false).init();
    Provider.of<LoggingServiceFile>(context, listen: false).connectLogWriter();
    await Provider.of<DatawedgeService>(context, listen: false).init();
    await Navigator.pushReplacement(context, TimeRegistrationPage.Route);
  }

The implementation of LoggingService:

import 'package:enum_to_string/enum_to_string.dart';
import 'package:flutter/foundation.dart';

enum LogLevel {
  debug,
  information,
  warning,
  error,
  critical,
}

class LoggingService {
  LoggingService() {
    _start();
  }

  final int _maxCacheRows = 1000;

  var _cacheLog = List<Logging>();

  void _start() {
    log(LogLevel.information, "$runtimeType started");
  }

  void Function(Logging logging) _writer;

  void setWriter(void Function(Logging logging) writer) {
    _writer = writer;
    _cacheLog.forEach((a) => _writer(a));
  }

  void log(LogLevel logLevel, String message, {String stackTrace = ''}) {
    var logging = Logging(
      id: null,
      timestamp: DateTime.now().toUtc().toIso8601String(),
      logLevel: logLevel,
      message: message,
      stacktrace: stackTrace,
    );
    debugPrint(logging.toString());
    if (_writer == null) {
      _cacheLog.add(logging);
      if (_cacheLog.length > _maxCacheRows) {
        _cacheLog.removeRange(0, _cacheLog.length - _maxCacheRows);
      }
    } else {
      _writer(logging);
    }
  }
}

class Logging {
  Logging({
    this.id,
    this.timestamp,
    this.logLevel,
    this.message,
    this.stacktrace = '',
  });

  final int id;
  final String timestamp;
  final LogLevel logLevel;
  final String message;
  final String stacktrace;

  @override
  String toString() {
    var result = List<String>();
    result.add(
        '[LOGGING] ${EnumToString.parse(logLevel)} $timestamp Message: $message');
    if (stacktrace.isNotEmpty) {
      result.add('[LOGGING StackTrace: $stacktrace]');
    }
    return result.join('\n');
  }
}

The implementation of LoggingServiceFile:

import 'dart:io';

import 'package:flutter/cupertino.dart';
import 'package:intl/intl.dart';
import 'package:app/services/hive/configuration_box_service.dart';
import 'package:app/services/logging_service.dart';
import 'package:path_provider/path_provider.dart';
import 'package:path/path.dart';

const String externalLogFilename = "cc600_log.txt";
const String externalBackupLogFilename = "cc600_log_1.txt";

class LoggingServiceFile {
  LoggingServiceFile(this._log, this._configurationBoxService) {
    _start();
  }

  final LoggingService _log;
  final ConfigurationBoxService _configurationBoxService;

  File _logFile;
  String _logFilename;
  File _backupLogFile;
  String _backupLogFilename;

  void _start() {
    _log.log(LogLevel.information, "$runtimeType started");
  }

  Future<void> init() async {
    var directory = await getExternalStorageDirectory();
    _log.log(LogLevel.information, 'External path reported: ${directory.path}');
    _logFilename = join(directory.path, externalLogFilename);
    _logFile = File(_logFilename);
    _backupLogFilename = join(directory.path, externalBackupLogFilename);
    _backupLogFile = File(_backupLogFilename);
  }

  void connectLogWriter() {
    _log.setWriter(_writer);
  }

  void _writer(Logging logging) {
    if (!_configurationBoxService.logging) {
      return;
    }
    try {
      if (_logFile.existsSync() && _logFile.lengthSync() > 1000000) {
        if (_backupLogFile.existsSync()) {
          _backupLogFile.deleteSync();
        }
        _backupLogFile = _logFile.renameSync(_backupLogFilename);
        _logFile = File(_logFilename);
      }
      _logFile.writeAsStringSync(
        '${DateFormat('dd-MM-yyyy HH:mm:ss').format(DateTime.now())} ${logging.message}\r\n',
        mode: FileMode.append,
        flush: true,
      );
    } catch (e) {
      debugPrint('error while writing to log ${e.toString()}');
    }
  }
}

Note that the LoggingServiceFile could be easily exchanged with a LoggingServiceDatabase. Only the signature of the writer function has to be the same.

1. Bootstrapping the native platform code
2. Bootstrapping the Flutter code
3. Normal application state where user interaction is allowed

Bootstrapping the native platform code

The first thing that happens when a Flutter app starts, is the bootstrapping of the native platform code. This piece is responsible for showing the splash screen and creating a container where the Flutter app can live. As soon as everything is ready, the main function in the /lib folder is executed. This main function is responsible for bootstrapping the Flutter code.

Bootstrapping the Flutter code

The bootstrapping of the Flutter code is where things might get complicated due to the async nature of Flutter and the usage of Provider to provide services and state. The reason for this is:

1. When using Provider for services and state, these services and state are part of the widget tree.
2. Some services are initialized asynchronously. For example Sqflite and all other services that are using method channels to access the underlying platform.
3. The widget tree must build to have a user interface
4. The building of the user interface depends on services and state defined in step 1

To complicate things even further, some services are dependant on other services and the order of initialization of the services might matter.

One might try to initialize all the services before runApp(MyApp()) is called.

Future<void> main() async {
   await initAllServicesAndState();
   runApp(MyApp());
}

This has some major downsides:

• There is no widget tree yet, getting the services into the widget tree from this point is hacky.
• If something fails during initialization and you want the user to decide how to recover, there is no easy way to show some UI.

Another approach is to initially build a user interface that is not dependant on any services or state. The only responsibility of this page is to initialize things. In my project, this is called AppStartPage.

AppStartPage

I decided to take the following approach:

1. Let Provider create the services and states
2. Set AppStartPage as ‘home’ in the MaterialApp
3. Let AppStartPage initialize the services
4. When initialization is done, replace the AppStartPage with the HomePage of your app

class AppStartPage extends StatefulWidget {
  @override
  \_AppStartPageState createState() => \_AppStartPageState();
}

class \_AppStartPageState extends State<AppStartPage> {
  @override
  void initState() {
    super.initState();
    onStart();
  }

  Future<void> onStart() async {
    await Provider.of<VersionService>(context, listen: false).init();
    await Provider.of<SoundService>(context, listen: false).init();
    await Provider.of<ConfigurationBoxService>(context, listen: false).init();
    await Provider.of<ConfigurationLoader>(context, listen: false).init();
    await Provider.of<LoggingServiceFile>(context, listen: false).init();
    Provider.of<LoggingServiceFile>(context, listen: false).connectLogWriter();
    await Provider.of<DatawedgeService>(context, listen: false).init();
    await Navigator.pushReplacement(context, HomePage.Route);
  }

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

In this sample, the AppStartPage is an empty container. In a real app, you might want to show a page that informs the user what is going on, like ‘Loading….’.

A downside is that the app now has two splash screens. The first is coming from the Android/iOS project. The second one is AppStartPage.

But the advantages of an AppStartPage are obvious:

1. Everything is initialized properly and in the right order when the app starts
2. No user interaction is possible before the initialization is done, so no-undefined state.
3. When there is a problem during initialization, you can ask the user in a pop-up what to do.
4. It is super simple….

At the time I was programming apps for Windows CE and Windows Mobile, we used SQL CE. It integrated nicely with the Visual Studio tooling at that time and it was easy to work with. The downside of SQL CE was the likelihood of database corruption. The corruption could occur if the battery was pulled, forced reboot, or if the SD card was ejected. On some hardware, the SD Card was ejected (in software) if the device went to sleep. So this was a nightmare.

Can you imagine what happens to customer satisfaction when he loses a whole day of work?

When looking for alternatives, I found SQLite. There was no compiled executable for Windows CE at that time, but I found a source, ready for compilation to Windows CE.

SQLite has proved its value since that day, more than 10 years ago. I never encountered a corrupt database anymore.

Why a local SQL datastore

In today’s connected world, one might ask why there is a need for a local SQL datastore on the device. There is a difference between the requirements of a consumer app and a Line of Business app.

• Network connectivity
• Batch applications
• Speed
• Large datasets
• Complex queries
• Data integrity
• Database versioning
• Downsides

Network connectivity

The work that needs to be done with Line of Business apps is not always at places with a fast or even present network connection. Think of basements, old warehouses, container yards or the countryside. A company wants to use the app reliably at 100% of the locations. Therefore, a lot of Line of Business apps are batch applications.

Batch applications

Batch applications work in cycles. A sample of a cycle is here below:

Speed

With manual data entry, the speed of a lookup is not very important. If it took a user 8 seconds to type a number, it does not matter much if checking the number by the app takes 2 seconds.

But most Line of Business apps that I write, run on hardware with dedicated barcode scanners. Scanning a barcode is almost instant. Waiting 2 seconds for the app to respond is not acceptable in this use case.

Looking up data in an SQLite database is very fast and generally a matter of milliseconds. Even a million rows of master data is accessed without a noticeable delay.

This kind of speed is needed when an employee scans items in a retail shop to order at their supplier.

Large datasets

The consequence of a batch application is that you have to download all the needed master data to the device. Sometimes this is just a few lines, but in some cases, it might be a million rows of data.

An approach is to download the dataset as a zip file. A zip file has the following advantages:

• Size of the transfer
  Improves speed over slower network connections
• Detect data corruption
  When the zip files extract successfully, you have a high degree of certainty that the data is complete and not corrupted
• Have a coherent dataset
  With a zip file, you can download several files at once and be certain to have a coherent dataset.

It may take a minute to (batch) insert large datasets into an SQLite database. Normally this is not an issue, as it only happens once a day. You can also automate this process in software by starting the download automatically before the workers start their day.

Complex queries

A big advantage of using an SQLite datastore is that you can run complex queries against it.

An application might start simple with a few tables, relations, and statuses. But as the customer explores the power and benefits of the app in their logistical process, it is almost certain that the customer will ask for more functionality. With the power of SQL and SQLite, you can be certain that there will be no limitation on the complexity of the queries.

Data integrity

Data integrity is as important as the integrity of the source code of the app. If the data is corrupted, the program might get in a loop, behave unexpectedly or even crash your application. The size of the database might also get out of control.

A good data model with the right (composite) primary keys and foreign keys will help you to keep your data valid.

Database versioning

As the requirements of the customer changes, it will also influence your data model. It is good to know that SQLite can help you to upgrade and/or downgrade the version of your data model.

With the onUpgrade and onDowngrade methods, you can update or downgrade the data model. Although this is something that you have to write manually, you can take measures that the data in the tables are transformed in the right way.

Downsides

Of course, there are also downsides to a local SQLite datastore:

• Skills needed
  You need to know how to design and query SQL databases. This can be a complex and challenging subject and can be done wrong in more than a thousand ways.
• Async data access
  Every call to the database is asynchronously. Be prepared that when you navigate to a page, the data will always come later. This will make your application more complex.
• No web support
  There is no direct SQLite support for the web at this time. There are some proof of concepts, like Moor which might be useful for demo purposes. But I don’t expect that serializing the database after each update does anything good for performance and reliability.

When I started exploring Flutter, there was (and there still is) a lot of discussion about state management. At that time, Google promoted Inherited Widget as the way to propagate information down the widget tree. I tried Inherited Widget, and indeed with some extra code, you could use it to make your state accessible to your widgets. But it involved quite some boilerplate, which was not easy to read and understand. It felt overly complex and likely to introduce errors that are difficult to spot.

After that, I tried get_it. That was easy and simple. It looked a lot that I was used to when I was working in C#. But I was not sure. I found a lot of happy users of get_it. But there were also a lot of people calling the foundation of get_it an anti-pattern. Although I did not really understand the discussion at that time, the choice was made for me by Google. They explicitly recommended Provider in their talk Pragmatic State Management in Flutter (Google I/O’19)

Provider

With Provider, you can wrap your class with one statement into an Inherited Widget.

In the code below, a Provider of an S080StateService is created. When this S080StateService is created, it’s dependencies are injected via its constructor. Provider is used to find these dependencies in the tree above.

  Provider<S080StateService>(
    create: (BuildContext context) {
      return S080StateService(
        Provider.of<LoggingService>(context, listen: false),
        Provider.of<LadenLossenBoxService>(context, listen: false),
        Provider.of<ConfiguratieBoxService>(context, listen: false),
        Provider.of<UnloadingStateService>(context, listen: false),
        Provider.of<CommunicatieBoxService>(context, listen: false),
        Provider.of<NotInteractiveCommunicationService>(context, listen: false),
        Provider.of<NavigatorService>(context, listen: false),
      );
    },
  )

Below this provider, the instance of the S080StateService is accessible by:

var state = Provider.of<S080StateService>(context);

The way this works is readable and easy to understand until you have a lot of services, that depends on a lot of other services.

Avoid super-nesting

When your code is dependent on many services, the code gets easily unreadable. Every Provider creates a parent-child relationship and therefore indents your code.

The indentation can easily be solved by using the MultiProvider widget. When you supply a list of widgets to the MultiProvider widget, the MultiProvider will take care of the parent-child relationship at runtime.

In code:

• MultiProvider
  • Provider1
  • Provider2
  • Provider3
  • Provider4

At runtime:

• MultiProvider
  • Provider1
    • Provider2
      • Provider3
        • Provider4

This improves readability a lot.

Another improvement can be made to move the list of Providers that you feed to the MultiProvider to a separate file.

class S080UnloadingSignaturePage extends StatefulWidget {
  static get Route => RouteEx<S080UnloadingSignaturePage>(
        builder: (context) => S080UnloadingSignaturePage(),
      );
  @override
  _S080UnloadingSignaturePageState createState() =>
      _S080UnloadingSignaturePageState();
}

class _S080UnloadingSignaturePageState
    extends State<S080UnloadingSignaturePage> {
  final SignatureController _controller =
      SignatureController(penColor: CompanyColor.companyBlue);

  @override
  Widget build(BuildContext context) {
    double bottomHeight = 80.0;
    return MultiProvider(
19 => providers: providers,
      child: Builder(builder: (BuildContext context) {
        var unloadingStateService = Provider.of<UnloadingStateService>(context);
        var state = Provider.of<S080StateService>(context);
        return Scanner(

Here the list of providers is just one line, on line 19. The actual list of providers is in a separate file:

List<SingleChildWidget> providers = [
  Provider<DialogService>(
    create: (BuildContext context) {
      return DialogService(
        context,
        Provider.of<ValidatorService>(context, listen: false),
        Provider.of<DatawedgeService>(context, listen: false),
        Provider.of<SoundService>(context, listen: false),
      );
    },
  ),
  Provider<S080StateService>(
    create: (BuildContext context) {
      return S080StateService(
        Provider.of<LoggingService>(context, listen: false),
        Provider.of<LadenLossenBoxService>(context, listen: false),
        Provider.of<ConfiguratieBoxService>(context, listen: false),
        Provider.of<UnloadingStateService>(context, listen: false),
        Provider.of<CommunicatieBoxService>(context, listen: false),
        Provider.of<NotInteractiveCommunicationService>(context, listen: false),
        Provider.of<NavigatorService>(context, listen: false),
      );
    },
  ),
];

Although I am not convinced that this is the very best way, it gets the job done. The code is readable and understandable. And, if you make a mistake, the error message is usually so well detailed, that finding and fixing the issue is easy.

Luckily I had a UX designer that provided all the assets in the right sizes.

Because I had all assets in the right sizes, I decided to do it manually for Android and iOS and not to use a package like https://pub.dev/packages/flutter_launcher_icons.

Splash screens and launch icons are platform-specific. Therefore I had to do the changes in the native solutions in Android Studio and Xcode.

Splash screen on iOS

For iOS, I choose to just adjust what the default iOS project already provided. In Assets.xcassets, there is a section LaunchImage with three empty spots with the names “1x”, “2x” and “3x”.

To add an image to the existing splash screen you have to add these three images, in my case these were:

ic_launcher.png   (393x137)
ic_launcher-1.png (524x182)
ic_launcher-2.png (786x273)

Before adding the files:

After adding the files:

The splash screen now looks like this:

After changing the background color, the splash screen looks fine:

Launch icons on iOS

To add the launch icons in iOS, you have to open the section AppIcon in Assets.xcassets. With a default Flutter project, it will look like this in Xcode:

After carefully dragging and dropping all icons to the right places, it will look like this:

At last, you would like to change the CFBundleName in the info.plist to something that you want to have as text below the launch icon.

Splash screen on Android

The process of adding a splash screen felt a bit easier on the Android side.

First I replaced all existing ic_launcher.png files with the ones that I received from my UX designer:

<flutter_project>/android/app/src/main/res/mipmap-mdpi/ic_splash.png
<flutter_project>/android/app/src/main/res/mipmap-hdpi/ic_splash.png
<flutter_project>/android/app/src/main/res/mipmap-xhdpi/ic_splash.png
<flutter_project>/android/app/src/main/res/mipmap-xxhdpi/ic_splash.png
<flutter_project>/android/app/src/main/res/mipmap-xxxhdpi/ic_splash.png

Add the file that specifies the background color of the splash screen:

<flutter_project>/android/app/src/main/res/values/colors.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="splash\_background">#012141</color>
</resources>

Edit the file that defines the splash screen to include the background color and the ic_launcher image:

<flutter_project>/android/app/src/main/res/drawable/launch_background.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- Modify this file to customize your launch splash screen -->
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@color/splash\_background" />

    <!-- You can insert your own image assets here -->
    <item>
        <bitmap
            android:gravity="center"
            android:src="@mipmap/ic\_splash" />
    </item>
</layer-list>

That’s it. The splash screen on Android is ready.

Launch icons on Android

I placed all the received assets in the following folder:

<flutter_project>/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png
<flutter_project>/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png
<flutter_project>/android/app/src/main/res/mipmap-xxhdpi/ic_launcher_round.png
<flutter_project>/android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png
<flutter_project>/android/app/src/main/res/mipmap-xhdpi/ic_launcher_round.png
<flutter_project>/android/app/src/main/res/mipmap-xhdpi/ic_launcher.png
<flutter_project>/android/app/src/main/res/mipmap-mdpi/ic_launcher_round.png
<flutter_project>/android/app/src/main/res/mipmap-mdpi/ic_launcher.png
<flutter_project>/android/app/src/main/res/mipmap-hdpi/ic_launcher_round.png
<flutter_project>/android/app/src/main/res/mipmap-hdpi/ic_launcher.png
<flutter_project>/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml
<flutter_project>/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml
<flutter_project>/android/app/src/main/res/drawable/ic_launcher_foreground.xml
<flutter_project>/android/app/src/main/ic_launcher-web.png

At last, you would like to change the android:label in the AndroidManifest.xml to something that you want to have as text below the launch icon.

• Colors
• Fonts (Name, Size, Style)
• Margins and padding of the elements

As in the Flutter counter-sample project, I started in my project with changing the primary color:

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // This is the theme of your application.
        //
        // Try running your application with "flutter run". You'll see the
        // application has a blue toolbar. Then, without quitting the app, try
        // changing the primarySwatch below to Colors.green and then invoke
        // "hot reload" (press "r" in the console where you ran "flutter run",
        // or simply save your changes to "hot reload" in a Flutter IDE).
        // Notice that the counter didn't reset back to zero; the application
        // is not restarted.
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

But then I quickly realized that the primary color is a specific value in a range of colors, a ColorSwatch.

 static const MaterialColor blue = MaterialColor(
    _bluePrimaryValue,
    <int, Color>{
       50: Color(0xFFE3F2FD),
      100: Color(0xFFBBDEFB),
      200: Color(0xFF90CAF9),
      300: Color(0xFF64B5F6),
      400: Color(0xFF42A5F5),
      500: Color(_bluePrimaryValue),
      600: Color(0xFF1E88E5),
      700: Color(0xFF1976D2),
      800: Color(0xFF1565C0),
      900: Color(0xFF0D47A1),
    },
  );
  static const int _bluePrimaryValue = 0xFF2196F3;

Such a simple task, changing the primary color, was just not so simple anymore. How do I generate a range of colors from one specific color that was specified by the UX designer?

After some googling, I found the website: http://mcg.mbitson.com/. Here you can delegate the burden of creating a ColorSwatch. If you specify the primary color, this website will generate the color variants for you. Great!

I ended up copying the code of Colors.blue and changed it with the values from that website. Together with some other specific colors, I put that into a class:

class CompanyColor {
  static const MaterialColor primaryColor = MaterialColor(
    _primaryColor,
    <int, Color>{
      50: Color(0xffe1e4e8),
      100: Color(0xffb3bcc6),
      200: Color(0xff8090a0),
      300: Color(0xff4d647a),
      400: Color(0xff27425e),
      500: Color(_primaryColor),
      600: Color(0xff011d3b),
      700: Color(0xff011832),
      800: Color(0xff01142a),
      900: Color(0xff000b1c),
    },
  );

  static const int _primaryColor = 0xff012141;

  static const Color companyBlue = Color(0xff063a65);
  static const Color companyOrange = Color(0xfff98c1b);
  static const Color companyWhite = Color(0xffffffff);
  static const Color companyBlueLight = Color(0xff8fa1b7);
  static const Color companyBlueText = Color(0xff124370);
  static const Color companyRed = Color(0xffcd3631);
  static const Color companyGreen = Color(0xff008a57);
  static const Color companyYellow = Color(0xfffcc634);
  static const Color companyGrey = Color(0xffe4e8ed);
}

This was good. Now I had one place to put all the custom colors. But this was still not good enough. The UX designer has designed a consistent user interface, but I was repeating myself all over the place.

Referencing the colors by hand did not feel like applying the D.R.Y. principle. There had to be a better way. And, of course, there was: “Make a custom theme”. And the good news is that a theme is not only for colors but also for fonts, padding, etc.

Changing the theme is quite easy. Identify the object that you want to customize application-wide. Drill down to the Flutter source code.

For example for changing the cursor color:

  /// The color to use when painting the cursor.
  ///
  /// Defaults to [ThemeData.cursorColor] or [CupertinoTheme.primaryColor]
  /// depending on [ThemeData.platform].
  final Color cursorColor;

You can change that in a custom theme like this:

ThemeData companyTheme(BuildContext context) {
  var theme = Theme.of(context);
  return theme.copyWith(
    primaryColor: CompanyColor.primaryColor,
    iconTheme: theme.iconTheme.copyWith(
      color: CompanyColor.companyWhite,
    ),
    cursorColor: CompanyColor.companyOrange,
    inputDecorationTheme: theme.inputDecorationTheme.copyWith(
        contentPadding: EdgeInsets.only(bottom: 7.0, top: 4.0),
        enabledBorder: UnderlineInputBorder(
          borderSide: BorderSide(
            color: CompanyColor.underLineInputColor,
          ),
        ),
        focusedBorder: UnderlineInputBorder(
          borderSide: BorderSide(
            color: CompanyColor.underLineInputColor,
          ),
        ),
        focusedErrorBorder: UnderlineInputBorder(
          borderSide: BorderSide(
            color: CompanyColor.companyPink,
          ),
        ),
        errorBorder: UnderlineInputBorder(
          borderSide: BorderSide(
            color: CompanyColor.companyPink,
          ),
        ),
        errorStyle: TextStyle(
          color: CompanyColor.companyRed,
          fontFamily: 'Lato-Bold',
          fontSize: 14.0,
        )),
  );
}

Apply this theme in your MaterialApp:

  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: providers(isZebra: isZebra, scanWithCamera: scanWithCamera),
      child: Builder(
        builder: (BuildContext context) => MaterialApp(
          localizationsDelegates: [
            GlobalMaterialLocalizations.delegate,
            GlobalWidgetsLocalizations.delegate,
            GlobalCupertinoLocalizations.delegate,
          ],
          supportedLocales: [const Locale('nl')],
          title: 'Ferwerda BV',
          theme: companyTheme(context),
          navigatorObservers: [
            Provider.of<RouteObserver>(
              context,
              listen: false,
            ),
          ],
          home: S005StartupPage(),
        ),
      ),
    );
  }

That’s it. Now you have all theming in one place.