Flutter charts are a challenge to implement in mobile apps. Learn how to do it easier with this handy guide on creating charts that are ready for production. This article will help you navigate the abundance of charting libraries, showing you tricks for customization and smooth integration to bring your designer’s vision to life. Make your data pop in a fun and professional way for your mobile app.

It’s not a secret that apps collect user data. Insight into some of that data is also available for app users. An efficient way to present the information is using visuals, specifically graphs and charts.

They are easy to implement when it comes to Android or iOS, but for designers and engineers working with Flutter, it’s easier said than done due to a scarcity of chart templates at their disposal.

A possible solution is to create custom charts.

Unlike chart templates, charting libraries available at our disposal are abundant. For example, I stumbled upon more than 128 packages for the keyword “charts” when writing. They aren’t perfect, though – most are lacking in customization or require adding some UI elements, making it almost impossible to replicate designers’ ideas.

I’ve tested several available chart libraries, desperately trying to mold our data to fit in the chart and repeatedly failing because the developers had either missed or forgotten something. Don’t get me wrong, none of those libraries are bad per se, nor do developers like to reinvent charts that much.

Charts are challenging to make, especially when presenting an enormous amount of data in a neat visual that should be fully customizable and accurate. And that’s just half of what a chart is supposed to do. The next part would be displaying a legend for more straightforward data interpretation.

Leland Wilkinson has an excellent book about data representation called The Grammar of Graphics. It dissects in simple terms the repression of graphics and their rules into seven layers, from data to themes:

We can see that layers have their functions, namely they enable us to build new layers on top quickly. The book describes how to present any data in any way imaginable. Our library will be used mainly on mobile devices, so we will focus on drawing in rectangular coordinate space to save time.

We can also delegate some layers. For example, we have limited space on mobile where multiple charts in grid view might be overkill. That being said, we can delegate the facets layer to the developer. If necessary, it can be done using GridView and by adding multiple Chart widgets as children.

We wanted a simple Flutter chart that allows for a lot more UI customization. Making a scatter diagram or pie chart is technically possible using this lib, but it would require a lot of work.

Back to The Grammar of Graphics, how could we use those layers, and what layers do we need to create simple charts? Following this will allow us to implement missing layers later if required.

Now that we know what layers we need to handle immediately, it no longer looks so intimidating. With just four layers, we will be able to see our data.

Now that we know how to make our Flutter chart, we can start handling the data layer. ChartData will map data to chart items. There is also ChartData.randomBarValues that helps with testing when adding charts. Chart data is handling aesthetics as well for now – it will try to display all of the data in the list and scale the chart accordingly. You can change that with exact value by specifying the axisMin and axisMax, or you can change the valueAxisMaxOver. That will add ‘invisible’ data on the max value, acting as ‘padding’ on current data.

Geometry is a layer that takes the item and decides how and where to draw it in the chart. By using ItemPainter, we can draw different items while passing the same data. We could also expand our ChartItem<T> to show additional or other data.

Having geometry separated is useful since that way we can show the data we want without reinventing the whole chart. For example, if you need to show a custom chart item with five values, it can be done by extending ChartItem<T> and GeometryPainter<T> to draw and show any item you want. You can even add your own item options by extending ItemOptions.

DataStrategy is used to manipulate the data. Current strategies are DefaultDataStrategy and StackDataStrategy. For now, since we won’t be adding an Aesthetics layer at this time, ChartData will also handle the scale the data will use. Horizontal axis for the charts is by default linear.

Themes are just things that decorate the Flutter chart. In our case, we added “2” layers of decoration, front-ground and back-ground decorations. That way, we can also control the decorations shown on the front and back of the items. The neat thing is that we can use the decoration we make in multiple different use cases while also allowing complete customizability by extending DecorationPainter new Decorations can easily be added.

It’s not enough for charts to be customizable and flexible to satisfy the design and blend with the app. Usually, analytics screens will have filters or something similar that will change the chart. That chart should animate to a new state to keep the app looking fluid and smooth.

Making this was a bit of a challenge, but since we already had layers nicely set up, it was just a matter of getting layers to animate between states.

We added lerp functions to each layer. Making a new ImplicitlyAnimatedWidget would ensure users can add AnimatedChart, and it will automatically update when a change in chart state is detected.

We have significant experience building healthcare apps, and they always want to show data in some way. That gave us a chance to try our Flutter charts immediately in the app we were developing for the US market. It was a perfect test since the charts were complex, and each screen had a slightly different chart to show.

The library didn’t limit us in any way. We could easily create a custom extension and add it to the chart if something was missing. So, by using the library more and more, we added a variety of decorations that would later prove suitable for the charts we were yet to create.

Finally, to make sure we don’t break any of the existing decorations or item painters when adding new features, we added over 80 golden tests. Safety first!

Using charts in production can be tricky, but Flutter charts can help. Try it out and help us make it better with feedback!

Infinum is proud to be enlisted in Google’s Flutter Consultants Repository. If you need a Flutter app that will elevate your business, get in touch with us for top-notch development services.

Flutter logging proved inadequate for all our requirements as we started using Flutter more extensively in larger projects at Infinum.

Flutter had a great year in 2020 with over half a million developers using it daily. It has surpassed react-native, linux, and vscode by the number of stars on github.

Logging is a really important tool for any developer and any application. It can make debugging time significantly shorter and help developers figure out sooner what’s going on in the app.

Using the Flutter logger properly can be highly valuable when an app is in the production environment. It allows developers to analyze user actions and understand the cause of a problem.

As logging in Flutter is very bland by default, developers mostly rely on print. The main problem with print is that all messages are treated the same way. There is no distinction between info and critical log messages. Critical messages are easily overlooked.

There is also no ability to turn logging off when building a production version. That can be a big security concern since all prints would be visible and easily accessible.

We noticed this problem when we were developing an app with complex navigation with socket communication. Often, socket messages would overflood our console, and then removing them would take a while, and debugging if something went wrong in communication would take even longer.

We wanted a way to toggle logs depending on the feature we were working on, so we set up the following criteria for the logger. Firstly, we wanted to have multiple logger levels and types, because filtering just by levels is not sufficient. In addition to that, we would need filtering and the ability to easily toggle logging.

We would also try to find a logger that has as little setup as possible in order to get as much data as possible.

We tried almost every logging library that existed at the time. Even though all of them had implemented our criteria on multiple levels, none of them fitted all the criteria.

Filter by type was the hardest requirement to fulfil and it was either impossible or very difficult to implement. But we persisted on fulfilling that criteria as it would allow us to turn loggers on and off for a single feature, without affecting other loggers.

Filtering only by level would again lead us to the same path, and further down in app development more and more messages would become error or warning levels in order to become visible.

Some of the libraries had nice extra features which we wanted to include, but since none of them met all of our requirements, the only reasonable decision was to make our own Flutter logging library. Cue Flutter Loggy!

We decided to use mixins from dart to achieve quick setup, while keeping different types separated. Using mixins has a lot of practical usages, so we wanted to see if they could help us with our logging problems.

Since mixins can get calling class name, we used that to generate tags for logs, and we could make more types by making different mixins for different layers. Having multiple types would allow us to separate loggers for different layers of the application, which can be easily filtered.

We built the logger with mixins, and filtering them worked as expected – making new types was simple, and Loggy would come with 2 types – UiLoggy and NetworkLoggy. They are a great starting point and good examples for creating custom types later.

To use Loggy, simply add Loggy.initLoggy() before runApp(), and add with UiLoggy in any class where you need Loggy. That being done, it’s now time to log the messages loggy.debug, loggy.info, loggy.warning or loggy.error.

The library can be configured with initLoggy, from where it’s possible to add filters, levels and printer for logger.

With different types of logging and a habit of using networking in pretty much every app, we made an interceptor for the most popular networking library Dio. Dio interceptor can attach to Dio instance and log requests and responses.

This interceptor is useful because of ║, ╔ and ╚. Using these symbols, it is possible to set up the console to collapse all lines that contain them. This way, we will see the request and the response code, but the request body will be collapsed and can be expanded to show more details.

With Loggy, all of the problems we had before were gone. Now we can easily set up different printers, eg. instead of sending events to console the printer can send events to crashlytics for production builds or just disable logging completely.

When it comes to types, it’s simple to set up different ones, allowing for easy filtering by type in order to decide which to include in production builds.

Finally, using Loggy inside the app is convenient – simply by adding with UiLoggy and logging something a lot more info becomes available, and it’s possible to control priority or easily disable it without actually removing it.

We also managed to clear out our console while actually logging more stuff about the request, since they show up collapsed they take just 1 line of space, but they can be expanded to show whole request details.

All in all, we are pleased with the results, so give Loggy a try and let us know whether it made your Flutter logging easier!