Capt Compass E3 - Dev Lab

What is exactly a developer page? How is it helpful for us? Can we simply rely on Flutter’s hot reload? In this post, I describe why to build a developer page and provide examples of use-cases.

A developer page is simply a screen where developer settings are stored to enable hidden, or in most cases, unfinished features without the need to spin up the developer environment. These pages are helpful not just for developers but for testers to test builds easily.

At first, for developers, the code might be everything that we want. Later on, we would realise that going into the codebase is not as much fun and we start building tools around our own solutions. Flutter's fast hot-reload comes in handy in many of these situations. Although the experience might not be the same as using a great UI to drive the app’s behaviour. Building an internal screen for our own use is one step better than changing the code itself.

So take a look at examples where we could leverage the developer page!

One of the quick actions is to build a local override for feature flags into the app. Gaining control to update flags during runtime is a great benefit for testing. It removed the need to constantly update the code or to be around the code during testing.

Applying the same principle that we have seen at feature flags. Each page can have a local entry point that allows quick access by listing pages whether they are finished or unfinished. It makes the development process so much simple.

During the development, the design of a page can be updated iteratively without us wanting to expose it to the user. For this reason, creating a page entry in the Dev Lab is a great starting point to iterate on the implementation. It also removes the necessity to place the new page into the user journey before the project is ready. One example that I am currently working on is the task category page. First, I had multiple ideas on where to place the page inside the user journey. As the development progressed, I had spent more time finalising the journey rather than finishing the page. Having a specific corner of the app, where developer options can be hidden, helps to delay the decision-making process until we have more knowledge about our problems.

One last section is any actions that can influence the app behaviour. This can be any behaviour that would not make it a user-facing feature. Examples are resetting any user data or dumping database information to the developer. With more features added, actions will be a great asset to simply provide content by going into the dev lab.

We had a simple walkthrough of some features that can be easily added to the Dev section and help ourselves. As you might have guessed, Dev Lab page is not part of the released version and can only be reached from the developer build. Regardless, it was a great process and wanted to let you know about some behind the scenes work. Hope you enjoyed it!