To create visually stunning and color-consistent apps, designers and developers need to be on the same page about using color schemes in Flutter app design. 

As a Google-made app development framework, Flutter utilizes the power of Google’s Material Design for its theming capabilities. In this blog post, we’re going to focus specifically on color schemes and what designers and developers can expect when working together on Flutter projects. 

Our approach to implementing colors in Flutter app development can be applied to any kind of design and various use cases. Of course, it is not the only way to go about implementing colors in Flutter, but these suggestions are the result of our experience and come with several benefits:

The starting point for tackling Flutter design is the Theme widget and the ThemeData class. The latter is the class that holds all the colors and allows the developer to set around 60 colors.

There are 60 colors available because Flutter supports both old and new coloring systems. Managing them all is somewhat complicated, but luckily, we can create ThemeData from the Material color scheme. This way, we only need to define 10 colors.

Tip for developers:

Use ThemeData.from(colorScheme: colorScheme) to construct the ThemeData from the color scheme.

The colors in Material schemes come in pairs. First, there is the color itself, and then there’s the color of text or other content on that color.

In 2015, the Dart Developer Summit saw the introduction of Sky, an experimental UI framework for writing Android apps using Dart. It started with Android, but the technology was architectured to run on any device – web, desktop, car, refrigerator, anything with a screen.

Sky was eventually renamed to Flutter, and the list of supported platforms gradually expanded to include iOS, web, and desktop. However, this is hardly the end of the road for Flutter, so the question that comes to mind is: what’s next? My guess is embedded devices.

I will illustrate that by running Flutter on a Raspberry Pi to show some interesting use cases.

The Flutter team started with just Android, but they were able to add support for other platforms by writing the embedder. An embedder is not one program, but rather a whole system consisting of various tasks such as:

These tasks require extensive knowledge of the platform we are embedding into. It’s mostly low-level code, not suitable for beginners. Full-fledged embedders have 15-30k lines of source code. You can find more information on Flutter’s web page.

Currently, there are three default embedders written by the Flutter team: Android, iOS, and web, while desktop embedders for Mac, Linux, and Windows are in beta. Anyone can write an embedder, for example desktops started with the unofficial embedder go-flutter and the official support was added later.

Embedded devices is a very broad term, but not every device is suitable for Flutter. First off, a device is not an application, it has both hardware and software. This means that it requires an embedded engineer and someone to design the circuit board.

When you find an appropriate device and the hardware is ready, you need to build the software to power the UI. With the current state of technology, this is a challenging task. The hardware has limited performance, and the current tools you can use to build UI interfaces have their own drawbacks. This is where Flutter provides a solution.

I’ve chosen Raspberry Pi for demonstration purposes, although you can use any similar device. Raspberry Pi is a small single-board low-cost computer and running Flutter on it can make for some very interesting use cases.

We could run Flutter on Raspberry Pi using the default Linux embedder that comes with Flutter because Raspberry Pi can run Linux, but I chose not to do that. The main reason is that the Linux embedder is more suitable for a real desktop experience with multiple windows and different apps, like Windows or Mac. We are going to use flutter-pi which is a light-weight embedder for Raspberry Pi. It doesn’t require a window system or a desktop at all, it will run on no-desktop Raspberry Pi OS Lite.

In our first use case we will try to make a screen for a fast food restaurant that can be used to order food without interacting with the restaurant personnel. For this we will need a Raspberry and a touchscreen. I used a Raspberry Pi 3B+ and a 7-inch touchscreen.

We build a simple Flutter app and follow the flutter-pi instructions to run it on Raspberry Pi. Here is a preview of the app with the whole setup running:

With Flutter we are able to create a great-looking app that runs smoothly with all the animations on Raspberry Pi. Flutter-pi gives it a real embedded feel because the user is unable to exit the app, interact with the Linux OS or turn the whole system off.

The real power of this setup with Raspberry Pi is that you can connect external devices and communicate with them. They can connect with Raspberry Pi over WiFi, Bluetooth, USB or wires (GPIO). To demonstrate, we are going to control a small LED light using Flutter over GPIO.

There are few ways to control GPIO pins. For this example, I skipped the Python programs and used the simplest way, which is echoing value (0 or 1) into a designated file. There’s one file for each GPIO pin on location with a path like /sys/class/gpio/gpio27/. If we echo 1, it means it will let the power through the pin so the light will turn on, and 0 will cut the power off.

With that info, we can build an app that will invoke the process command to turn the LED light on or off:

We could listen to button presses in the same way, or interact with various sensors, for example a temperature or a distance sensor. We could run a servo motor, printer or whatever, since there is almost no limit with GPIO, it’s just a matter of effort.

Of course, there are other ways to build a product that satisfies the use cases above. Let’s see how they compare with the embedded Flutter solution.

Since we’re using a touchscreen, it might seem a good idea to use an Android or an iOS tablet simply. However, it’s not. Here’s why:

There are other alternatives that can run on Raspberry Pi, for example the Chromium Kiosk mode or the Electron app. Although the setup is different, both solutions allow you to use popular web technologies (HTML, JS) to build the app. However, the downside is that there’s a lot of overhead when running these, which might impact the performance.
For example, in Chromium Kiosk mode you need to run full desktop Linux with the Chromium browser on top. The browser then runs your app, while with flutter-pi your app runs on “bare metal” Linux.

Another downside is that communication with the native platform and the external devices is limited. For example, communicating from Javascript to the bluetooth module requires complex bridging as Javascript was never intended to perform such things.

Qt works similar to Flutter, although it’s more focused on desktop and embedded devices. You write Qt apps in C++, which is a less popular and lower level language.

Qt is better integrated with the platform so it’s somewhat easier to communicate with the native platform and the external devices.

Other than language, Qt’s downside is that it’s not completely free. Also, it’s much older than Flutter, and Flutter brings some improvements in terms of performance and UI building.

When Flutter was first introduced, it could only run on iOS and Android. The first time I tried Flutter for desktop, I used a third-party embedder in a similar way as with Raspberry Pi. Today, Flutter desktop has an official beta release, so we can only expect it to continue to evolve and support embedded platforms in the same way.

I believe Flutter will become one of the best solutions for embedded devices with a screen. With examples like Toyota’s infotainment systems that will be powered by Flutter and Google’s Nest Hub that comes with Flutter running on Fuchsia OS, the future’s looking bright.

Perhaps you’ve heard about Flutter lately. It’s a pretty hot topic in mobile development, specifically cross-platform mobile development.

“Oh, another cross-platform solution? This is becoming like all those new JS frameworks”, you might think. It was my first reaction and probably the reaction of many others.

Don’t judge too quickly though because Flutter is not “another solution”.

It’s a new approach.

Let’s take a look at how cross-platform mobile development evolved.

Android and iOS SDKs were both published in 2008. Apps developed with these SDKs are usually called “native apps”. Already in 2009, the first cross-platform solution appeared — PhoneGap. You might’ve heard of Cordova, that’s basically the core of PhoneGap that’s open-sourced.

Making an app with Cordova is like making an app that’s a web browser that only opens your page. It doesn’t deliver the best user experience a native app can do and that’s why both Google and Apple are not really fans of these apps flooding their stores.

Then there’s Ionic, which uses Cordova as a core. Introduced in 2013, it’s a better, well-rounded solution packed with modern JS frameworks. The downside is that it has the same limitations.

Moving on to…

In 2009, we also see the start of a different kind of cross-platform development. Around the same time, a lesser-known solution was introduced – Appcelerator Titanium. Instead of just showing everything as a web page, it can show native views just like native apps.

For example, in Titanium you can write <Label>Hello World</Label> (yes, you can write in HTMLish) and this would use UILabel on iOS and TextView when running on Android.

At first, this looked great. You’re writing your code once and it works just like a native application on both platforms. No wonder other solutions decided to use a similar approach.

The first one to follow into the steps of Titanium was Xamarin in 2013 (later acquired by Microsoft). After Xamarin, React Native came out in 2015. As I write this, React Native is the most popular cross-platform solution.

It’s important to note that React Native still runs JavaScript. This means it needs to be interpreted and data needs to pass the bridge from the JS interpreter to the native environment. This results in lower performance. If you don’t know what you’re doing, you might pass this bridge every frame, which can result in dropped frames and jank.

It can work for simple cases, like the binding of that label in Titanium. But for any real-world app, bindings are not always that straightforward and what you end up with is being able to share only the business logic part of your codebase, and writing separate UI for each platform.

One example is the good ol’ button. In Android, there is no border property to change it for the button. Instead, you need to use shape XML, so you need reimplemented native views or custom renderers to overcome this limitation. This was really tricky for Xamarin which tried to support all kinds of platforms besides iOS and Android, like Windows Phone and Tizen OS.

That’s why it is not only difficult but also not advised to write UI for two platforms. React Native has a philosophy of “Learn once, write anywhere,” which means often you’ll write UI part of your code two times for both platforms.

Xamarin also isn’t advised for advanced apps that require native feel or custom UI:

And then came Flutter. Not part of web-based or native-bind solutions, but completely different. For starters, it’s a UI framework and it’s not trying to replace native development. The code is not run by a separate interpreter, as Javascript might do. It’s compiled to machine code, just like the native apps.

How do native apps draw to screen anyway? Well, they are all just drawing graphic primitives on a canvas – think tiny lines, circles, and rectangles. TextView and UILabel are drawing text on the canvas and extending View or UIView.

The native-bind solutions (React Native, Xamarin…) have abstraction on the level of view, e.g. Label will be TextView or UILabel. Flutter works on a different level, the canvas is abstracted. When you use Text, that view (or widget as it is called) is rebuilt from the ground up by the Flutter team on this new abstracted canvas. It will look the same in both apps since all canvas operations work the same.

In fact, every component is rebuilt from the ground up on that new canvas. This was the only way to achieve a true cross-platform way of “writing once, running everywhere”.

For the Flutter team, this also meant that they need to copy the look and feel of native apps into their new rebuilt components.
For example, Android TextView has 14k lines of code and all its behaviors had to be recreated from the clear canvas in this new Text widget. Every component like button, checkbox, switch, app bar and even scroll behaviors are copied down to pixel-perfection.

One might conclude that drawing in Flutter is the same as what the now deprecated Adobe Flash or game engines like Unity are doing. It’s true that they both take the whole canvas and then work in a way that can run the same code and draw to that canvas (whichever platform it is).

But they were never about mobile phones. Flash performance was notoriously bad so it was restricted on iOS way back in 2010. Unity started on desktop and struggles with resources on mobile.

Flutter came just at the right time. The idea of compilation to ARM and machine code, LLVM compiler, and using the Dart engine with all the performance optimizations and memory management makes it possible to finally achieve a native look and feel on mobile while writing once.

It has been in development for a few years now – in December 2018, it hit 1.0. The only thing that’s missing now is wide adoption.

The difference is even bigger for non-developers, like business stakeholders. Since the industry is talking about native and React Native, they can see Flutter as a risky new technology. But bear in mind, React Native was once also in this state. In case you need more than a hunch to believe 2020 could be the year when Flutter takes off, here’s a bone to chew on – it has already passed React Native in stars on Github, signaling strong popularity.

When it comes to showing maps in your Flutter application, there are two main options. You can either use flutter_map which is a Leaflet implementation for Flutter and will work with a number of free and paid map providers, or use google_maps_flutter if you want the more popular Google Maps.

For this blog post, I will be using google_maps_flutter, which is made and maintained by the Flutter team at Google.

If this is your first time using Google Maps I recommend checking out Google codelab for maps in Flutter. What I needed was to draw some custom markers like those in the image below.

You would expect that you could pass a Widget for marker, just like when using anything else in Flutter. But it’s not that easy as Marker accepts BitmapDescriptor for the icon. I’m going to explain how you can achieve that.

What is the BitmapDescriptor? If you’ve ever worked with iOS or Android native Google Maps SDK this will not surprise you.

BitmapDescriptor is an object that defines bitmap which can then be used by Google Maps to draw it on a map. It is used in both platforms and it’s the only way you can add custom icons for markers. So, this limitation comes from the native Google Maps SDK which google_maps_flutter uses, as there is no full flutter implementation for a complex widget like maps yet.

BitmapDescriptor will accept an asset image or a bitmap. For our case, marker text is dynamic, so static asset image is not a good fit. As for a bitmap, in native Android/iOS there’s a way to convert your View to Bitmap (or UIView to UIImage) and you can pass that to BitmapDescriptor.

You can do it the same way in the Flutter, but it’s a bit trickier. Mostly because you cannot inflate/load a widget somewhere on the side and convert that to bitmap. You need to draw a widget in the screen view hierarchy and then fetch its painted bitmap.

The key thing you need to know is that each Widget is more like data class and you access bitmap in its associated RenderObject, which gets created during the build phase.

Draw your widget to the screen. This is from some widgets build method that will inflate our markers. We use GlobalKey so we have reference to this widget after it’s built.

Now you can put that GlobalKey to use after the widget is built:

Uint8List is basically a list of unsigned integers that represents bitmap in this case as there is no special Bitmap class in the dart. BitmapDescriptor will also accept Uint8List so we need to do some converting to get from RenderObject to Uint8List. I have all that in the following method:

I’ve shown you how to get RenderObject and convert it to Uint8List, but when do you call this method?

We need to get our bitmaps right after they are drawn. There are multiple ways to do this, I use tiny AfterLayoutMixin available here.

There you have it. Create the Marker with Uint8List and plug it into the Google Map:

You should end up with something like this:

I have extracted all this in one simple-to-use class MarkerGenerator. It’s a bit more advanced than the guide explained here. It uses an overlay to build marker widgets and provide List<Uint8List> through the callback. The gist is available here.

Copy it to your project. Then you use MarkerGenerator this way:

When working in Flutter, some things take more time as opposed to writing them in native Android/iOS, as it happened this time with custom map markers. But overall, I believe that Flutter is definitely a timesaver and a great choice for most apps.

In mobile development, usually, developers are the ones who will set up and maintain CI/CD. In that sense, the best CI is the one they waste the least time on so they can focus on development more.

The Android team here at Infinum have been using CircleCI for a few years and recently migrated the majority of projects to Bitrise—a newer continuous integration and delivery (CI/CD) service made for mobile apps. This means that it’s focused just on that and provides great service in that field.

On the other hand, while CircleCI provides a more generic solution suitable for any type of project, it might require just a bit more configuration.

In CircleCI’s free option you get one container with 1000 build minutes per month. Meanwhile, the free option in Bitrise features somewhat limiting 10 minutes per build.

For concurrencies, both Bitrise and Circle have similar pricing:

If you need 2 or 3 concurrencies, you might want to consider the difference in the pricing, as Circle can be cheaper. Otherwise, both are in the similar price range so that shouldn’t be the deciding factor.

There’s no point in comparing the pricing without looking at what you get for the money.

Both machines have similar Intel Xeon and you’ll get 2 vCPU. The only difference is that on Bitrise you’re getting 8GB of RAM compared to Circle 4GB, which can be a big deal. These are the standard options and you can pay for additional ones.

Need more power? Bitrise standard option with 8GB of RAM should be enough for most projects. If you need more power, you can get elite machines which are pretty much double the resources (4 vCPU, 16GB RAM) for double the money.

This doesn’t mean that your build times will be two times as fast. Gradle tasks don’t fully utilize all the resources and multithreading so from our experience you can expect about 20% faster builds.

On CircleCI, the standard option with 4GB might just not be enough for some bigger projects. Unlike Bitrise that has only 2 options (standard and elite), CircleCI has 5 resource classes:

Something you should be aware of is that there is no public pricing for CircleCI resource classes. You need to personally contact them to gain access. In our case, we got them for free for a limited time but then got unpleasantly surprised with the full price of the extra resources.

The way CI was setup usually involved writing configuration files in JSON or YAML notation. For bigger projects, this config file would grow to levels that are hard to maintain.

Bitrise has a somewhat different approach to configuration. To start with, you don’t need to have a configuration file in your repo—you can just hold it in their web app. But Bitrise’s edge is the visual configuration editor which makes the whole setup much easier.

Each step is represented as one block in the editor. And with this, you don’t need to edit configuration files directly, you can just click through the visual editor. This is also much easier for developers who have never worked with a CI before. It takes time to learn how to read and write configuration file, and the editor is self-explanatory. Some of my colleagues didn’t like this editor as they were used to handwriting YAML files and didn’t want to switch. They can still continue to write files without using the visual editor.

Bitrise comes with the library of steps which contains a lot of predefined steps you might need, like Install missing Android dependencies, Android Build, Android Lint, etc. You can write your own step and open a request to merge it into the library.

Similar to the Bitrise library of steps are the CircleCI orbs. You have a public registry of orbs. Orbs are part of CircleCI 2.1, so they are a pretty recent thing. The problem I see here is that users don’t really need orbs and don’t want to bother updating to 2.1, so the adoption of orbs is low. Currently, there is just one useful orb for Android while on Bitrise there already are a lot of useful steps, with new ones coming regularly.

One thing I would like to see is the possibility to write and share a step internally within the organization, which currently isn’t possible on either Bitrise or CircleCI.

For some projects, we need to build several flavors of application. For these, we use parallel builds. Both Bitrise and CircleCI support parallel builds and are easy to set up. For Bitrise, you would have one workflow that initiates all the parallel workflows and waits for them to finish. This way, one container will always be used just to wait for others, which is not the case on CircleCI. That’s a plus for Circle!

UI testing has always been one of the trickier things to set up on your CI/CD servers. A few years back, you had to create emulator image and start it, run UI tests, and then read text reports and somehow fetch that result back into the CI report.

There was a lot of room for this process to fail just because something went wrong while starting an emulator, and then your tests would be reported as failed. Plus, running emulator required a lot of resources on the build server.

In 2016, Firebase Test Lab was announced, which made things easier because it eliminated the need to work with an emulator. Still, it continued to be a pretty lengthy setup. There were multiple requirements—a Firebase project, hooking up the Google Cloud keys (for remote access to your project), and then running a few commands to send apk and run tests. This was the standard procedure in CircleCI, and this alone would add 30 lines to your .yml configuration.

With Bitrise, setting up UI testing is simple as it gets. There are two steps ready: “Android Build for UI Testing” and “[BETA] Virtual Device Testing”. You add these and that’s it.

If you want to fully automate the whole process, you will probably want to deploy directly to Play Store from your build server. Using CircleCI, the best approach would be either to use fastlane or some bash script you can find online that does all the communication with Play Store to publish the .apk.

This is simplified on Bitrise with Google Play Deploy step. It accepts .apk or .aab and Play Store Service Account JSON (which is required for any remote access to the Play Store). So there’s another plus for Bitrise!

Bitrise workflow editor is a really innovative approach that saves us from .yml files and brings a simple interface that I enjoy using. The focus on mobile development is a big advantage and I can see this paying off even more in the future.

CircleCI looks to be taking a different approach. With 2.x, there are some changes that you really don’t need but can be very helpful in complex environments. Finally, if you don’t have a CI/CD and you are doing mobile development, Bitrise should be your first choice.