As you already know from several of my articles, in addition to year-round cycling and seasonal sports, I also have a passion for trying new technologies. However, the mobile ones were never close to me. Rather, I wanted to try to create a desktop app that would benefit not only me, but others as well. And it worked out!
The choice of technology is fundamental
For the past few years, I have been “eyeing” various technologies that make it possible to quickly and easily create a useful one-click application for everything. Kind of like a Swiss army knife for anything I need for everyday work. I was particularly interested in Electron.js due to its similarity to other web applications. But then I discovered Flutter. Although it’s primarily developed for universal mobile apps for Android and iOS, it also has a relatively good web flip. But I especially liked its stable support for desktop, more precisely for Linux, macOS and Windows. So the technology was clear. I just needed an idea.
From documentation to practice
It started like this – on March 1, 2023 I opened the documentation of the Dart language created by Google (retaliation for Microsoft’s Typescript). I read through it in 2 days and the next 2 I already tried installing, configuring and launching a Flutter project. Then I asked myself whether the “playing” still made sense, or whether I wanted to move on and test what Flutter can really do on something practical. Of course, option B won and I decided to create an app for our team CLI.
For you to know what it’s about: At bart, I’m part of our company’s largest team. We work on a medical project for a Belgian client called Crossuite, where a huge number of microservices, APIs and various types of front-ends and back-ends are already underway. Therefore, some time ago my colleagues prepared an application for the terminal in GoLang CLI (command-line interface), which is used to download, debug and run dockers, databases and management of the entire development and test ecosystem.
And while remembering and typing commands into the terminal is easy enough, I believed that it could be taken to an even higher level user-wise. I recalled the phrase, “If your team needs a large number of external applications, it’s time to start creating your own tools”, and I thought it was the right time to reduce some programs and combine several well-known services under one roof. So I started to expand our CLI with a set of installations, settings and various more demanding operations with the database and the docker containers themselves.
AI helpers
I wouldn’t be a good front end developer if I didn’t use at least some of the available AI tools in learning, testing and overall development 🙂
The first one I used was GitHub Copilot, which, although in the beginning it was worse than a high school student on steroids (i.e. it knows everything, wants everything and when something’s difficult, it tries with more force), over time it learned my style of writing code and provided me with quite relevant suggestions.
JetBrains AI also helped me, effectively designing various CLI commands and system scripts. And when I was lazy to the maximum and even Copilot or JetBrains AI couldn’t advise me, I turned to Google Bard. Not that I don’t like ChatGPT, but Bard can “think” and work with current data simply better.
And to add to the pile, I also used some AI image generators to create app icons. Although it’s just a cluster of various objects that resemble a desk, a monitor, containers and other abstract allusions to computers or development, it was enough to add the SDK text (software development kit) over them and the first sufficient sketch was born.
New feature every day
Once I had the icon, the development took a rapid turn. The basic layout as well as the prioritization and categorization of elements to be available immediately, began to be outlined.
Then I deployed the first big features, such as the ability to install necessary as well as optional applications to start the development environment. The goal was to enable new colleagues on the team with a completely blank computer to install everything they needed with one click.
Subsequently, it was time for creation and management of SSH keys and registration in private GitLabs. To those I also added an improvement in the form of an imaginary cleanAll function, which allows developers to delete folders, edit rights or set up the system.alebo nastavovať systém.
What’s included in the SDK?
Since my SDK was mainly supposed to be an extension over the CLI used, I tried to maintain all the principles and functionality of the commands. Thus, the configuration files remained unchanged and some commands are still directly called over the CLI from the SDK.
At the same time, however, I wanted the SDK to extend the CLI appropriately. For example, with the ability to update it, change its location so that it’s available globally, or verify that a developer has an up-to-date database installed.
Then I added some more:
- autoload of projects,
- the ability to turn Dockers on and off,
- or features to evaluate, verify and run the build of Docker images directly on our GitLab, and then download and run them.
By this point, I was so sure of the app that I started playing with tricks like:
- reload
- changing the colour theme,
- pinning projects,
- display of the Docker container output,
- changing the git branch over a project,
- or displaying configuration files with the ENV variables already added.
As a handy addition, I also added several colour indicators that tell developers when a container is working and whether it’s OK or how much RAM is in use. The red indicator means that something is malfunctioning or an error has occurred, orange indicates a partial or currently satisfactory condition, and the green is lit when everything’s working as it should.
After all this, in September I organized my own one-man show, presented the project to my colleagues and then just threw in beta-testers from among them, the number of which grew like weed 🙂 The SDK application, however, is created only for internal use and is available only to my colleagues and collaborators.
So what happens next?
The project changelog continues to change quite often. For example, I recently added full support for macOS and a Windows version is just about to be finished. I still have a challenge in the form of adding support for the older Crossuite project Gama, which, however, is still very important and deserves care. And I’m preparing separate sections for end-to-end and unit tests for the testers.
And because it’s still necessary to move forward even in a one-man project, I’ve recently created milestones and a complete CI/CD process for the development of the SDK – from code merging through tests and code quality control to the build. It works for Linux internally within the AWS worker, and for MacOS and Windows via a remote Codemagic builder.
How do I rate Flutter?
I can responsibly write that I’ve tried all the methodologies and possibilities of the Dart language itself and the Flutter framework during the development. And I rate it very positively. I like its versatility, universality in the field of mobile applications and surprising functionality and speed in desktop ones.
When it comes to the CPU load, the application is at the level of 0.5%, and that’s while several monitoring threads, such as Docker stats or healthcheck, run on it. The memory is in the range of 98-150 MB for Linux and 150-250 MB for macOS and Windows. Considering the size of the project, these values are really great – much better than with the available ready-made solutions of the same type.
Of course, you’ll never create a native app with Flutter. If you need to access native system or mobile requirements, such as a camera, a microphone or a video codec, you’ll always need to use an additional add-on or create a bridge between the native loader and the generated application. But I think it’s worth it.
In my opinion, Flutter has a chance to break through and gradually turn into something huge. And I believe that when it happens, all halfway solutions like Electron.js or Ionic will become a thing of the past.
Acknowledgements from the author 🙂
Although I write about the SDK as a one-man show, the truth is that no one is an island. Thanks for the fact that the application exists, belongs to my colleagues Martin Čuchta, Erik Sasák, Lukáš Pollák and Peter Sliacky. They prepared the basic principles of the functioning of the CLI, which was then taken over by a large part of the SDK. The dedicated volunteers who have tested the CLI and SDK, and last but not least, the whole bart and Crossuite, who are always happy to give me space for (responsible!) experiments, also deserve to be thanked.
SDK is now used by all developers, the QA team and several people from the management. My colleagues are now eagerly awaiting a version for their home Windows computers, and Belgians are looking for Gama support. In addition, the list of features that developers and/or testers would like to have deployed as soon as possible, also got quite full. Thanks to enough time between the holidays, I’m going to be adding one feature after another. I hope it’ll go at least as well as it has so far.
