Making debugging and testing process easier with Flutter DebugView

Tired of the long and painful process of debugging the app just to see the server logs? Introducing our daily helper for Flutter apps - Chili DebugView - an open-source Flutter package we have developed for QA engineers and project managers to collect and monitor network logs more efficiently.

In everyday development process, it’s quite a hassle to check application logs on-the-go. It either requires testers to have the IDE running to monitor the logs or specific configurations for builds to then use adb commands to print out the logs in a pretty chaotic format. Testers and project managers have to deal with multiple requests by clients every day to ensure that certain features or functionality hasn’t been affected by back-end changes, or a “sudden” bug has appeared without even touching that functionality for a long time, although yesterday it worked perfectly well. Sounds familiar?

Here’s the story of how this idea came to life.

How it all began

The story begins with one of our developers encountering a crash on a client’s device that we couldn’t reproduce on our end. To investigate, this developer created an app wrap to gather information about requests and device details. This tool proved so useful that we decided to integrate it into every Flutter app for easier debugging. Clients often need insight into the request bodies we are sending, and this tool provides that transparency.

Initially, we envisioned this tool as the ultimate debugging solution. However, our current implementation focuses primarily on network requests using the Dio package, that we are using in our apps.

The process

How much time it took to bring it to life

Approximately four developers actively worked on the project, with an additional developer contributing ideas that were not included in the final product. Initially, we aimed to create a modular package where developers could include only the necessary modules. Although this idea was promising, it proved challenging to maintain and develop. As a result, we transitioned to a single repository with one module focused on network logs.

The entire process took around two weeks, including all fixes and changes in direction. With the benefit of hindsight, we estimate that the development could have been completed in just three days.

Obstacles on the way

We encountered several issues during development. The most significant problem was with a package that caused crashes on Android devices when running in the background. Ironically, this debug tool wasn’t even being used, so we opted to remove it instead of fixing the issue.

Another challenge was resolving dependencies. Although we have checked some older versions, we are still uncertain how the tool will behave for other users. This is an ongoing issue that we plan to address as we maintain the package.

Experimenting on-the-go

Initially, first projects where we tried it while developing apps were Banknote and Balcia. Immediately we understood that this tool was much easier to use on a daily basis, it just took some time to get used to it and the rest is history…

The end result and plans for the future

Features and benefits

• Huge time saver to check networks logs for QA engineers and project managers,
• Get all network logs related data on-the-go: check request and response bodies, track number of requests and measure response times with ease,
• No need to be wired to the computer or have the IDE running to see the logs,
• Select single or multiple logs to copy or export and share it wherever you need,
• Quick steps to implement in your project.

The use of DebugView internally

Currently this package is implemented in almost all of our ongoing Flutter projects that involve REST network requests using the Dio package. We apply DebugView for our staging app builds when testing the app before going live, and send builds with DebugView enabled to our clients, which allows them to verify network requests themselves.

In Chili, DebugView enabling/disabling is managed through environment configurations. Each project has configurations for different environments (staging, prod, etc.), and we control the DebugView setting through these configurations. In our CI/CD pipeline, we handle whether DebugView is enabled or disabled based on the environment. Here’s an example of how this is implemented in our code:

   static const enableDebugView = bool.fromEnvironment(
   'IS_DEBUG_VIEW_ENABLED',
     defaultValue: false,
   );

   DebugView(
     navigatorKey: navigatorKey,
     showDebugViewButton: EnvConfig.enableDebugView,
     app: app,
   );

What’s more to come?

Our nearest goal is to support other networking packages, specifically expanding compatibility to include not only Dio but also the http package. However, this will only be considered after requests from other developers.

We might consider expanding the package in the future, doing so would require incorporating more external dependencies, which is not ideal. However, currently, we are in a waiting mode and do not plan to add other debug tools. Adding features like checking or changing SharedPrefs values and getting device info would require more frequent updates to the package since we need to depend on different packages.

Summary

With Chili Debugview providing any data of API requests for clients has never been this easy. Starting from request and response body validation, as well as verifying the correct order and amount of requests sent, to measuring response times has proved to be a great helper in everyday development process. Quick export allows to collect and share the logs with a few clicks.

Make sure to check out Chili Debugview Flutter package in pub.dev platform.

We hope that this package will help your team to level up your debugging game! For any feature requests or issues reach out to us via GitHub.

---

 

-Kristaps & Maksims