A one-stop workbench for Flutter

I. Introduction

Flutter's one-code and multi-terminal feature liberates the manpower of the students on the terminal and brings about the improvement of R&D efficiency. Because of the mismatch of the number of early double-terminal R&D students and the demand for R&D efficiency, the Taote technical team is also an early leader in the Alibaba Group. One of the teams that landed on Flutter in business.

Although there is the convenience of one code and multiple terminals, it is accompanied by various problems in the R&D link, such as R&D environment construction, dual-end engineering environment, cumbersome integrated release process, and so on. In order to gain an in-depth understanding of the pain points of the development students, we launched a questionnaire survey within the team.

We conducted a survey on the R&D happiness index and various problems encountered in the R&D link. The result is as follows:

The average score in the R&D Happiness Index is 3.38 (on a 5-point scale). We analyzed the issues that affect R&D happiness, and screened out some issues that are generally believed to affect R&D efficiency. Among them, the highest ranking is the construction of R&D environment + engineering environment (Flutter-related), development and debugging (Flutter-related) and other issues.

Next, let's take a look at the specific pain points of these problems, and some challenges faced when solving these problems.

2 Problems and challenges

1 question
Among the problems that affect the happiness of R&D, the following three aspects are more prominent.

1) R&D environment issues

R&D environment configuration is the pre-coding work, and it will also affect the first impression of newcomers on the team's R&D experience. Since Flutter involves the environment configuration of both Android and iOS, it is very troublesome for students who are not familiar with the other end to configure it, and it is difficult to get started. In addition, the local version of Flutter is inconsistent, the lack of Flutter version management tools, and the scattered and timely updates of documents all greatly consume the energy of the team members.

2) Engineering environmental issues

After solving the R&D environment problem, we also need to solve the engineering environment problem. The dual-end engineering structure is complex, and students who are not familiar with a certain end are difficult to solve the compilation problem. Many students even gave up on configuring the project on the other end, and usually develop only for debugging on the end they are familiar with, which violates the concept of Flutter’s dual-end development.

Comments: Judging from the team's research and interviews, a newcomer classmate needs a day to build the basic environment for Flutter's R&D environment and engineering environment, and then spends two or three days to toss various compilation issues, especially for iOS related environments. For Android students, it is very difficult to run completely.

3) Integration process issues

After the code development and testing is completed, there are many integration steps, switching back and forth between platforms, the integration process is fragmented, and a complete SOP has not been formed. The entire integration process is time consuming and prone to quality issues.

Comments: The existing Flutter module integration process is divided into six steps: 1 Module branch code merge -> 2 Module generates a new Tag version -> 3 Main project modifies the module version number -> 4 Main project code merge -> 5 Main project generated version No. -> 6 Submit the official package for the Ferris wheel. The steps are cumbersome, and you need to switch back and forth between Aone, MTL and other platforms, and manually operate various version numbers, which can easily cause online quality problems.

2 challenges

In order to solve these problems, some documents and scripts have been deposited before, but the documents have many steps and commands. If any one is wrong, it may lead to errors in environment construction. In addition, the documents are sometimes not updated in time.

We think that if there is a R&D workbench in the form of a desktop GUI, all kinds of problems encountered by R&D students in daily R&D can be solved on it, and new students can also use this R&D workbench to quickly land on it. Happiness will be a qualitative improvement.

So we decided to build a desktop-side R&D workbench. We also encountered many challenges in the process of achieving this goal.

1) How to reduce the access and use costs of developers

Access and usage costs. The R&D workbench is originally a tool software. If the operation itself is complicated and you need to read various documents, it will deviate from the original intention of the tool software to be simple and easy to use. Therefore, one-click complex operations must be done when doing related functions. , such as one-key configuration of software environment, one-key configuration of engineering environment, one-key integrated release, etc., many functions are done according to this idea.
Compatible with existing R&D environment and engineering environment. Except for the new students, most of the development students already have some environments on their computers. How to coexist with the existing environment without changing the existing usage habits of the development students is also a key consideration for us.

2) How to ensure the rationality of architecture design

We want to build the R&D workbench into an open platform that everyone can participate in and build together, because personal time is limited, and the workbench itself, as an aggregation of tool sets, requires more students to participate, and more The idea is implemented, so how to control the warehouse permissions and design a good plug-in framework is very important.

3) For the implementation of new technologies, related problems need to be explored and solved by themselves.

In the development of the desktop R&D workbench, we use the Flutter Desktop technology (as for the reason, the technical research part will talk about it). At present, there are not many Flutter Desktop technologies in the production environment in China, and the relevant experience is still relatively lacking. Sometimes, you need to explore and solve some problems by yourself.

Next, let's take a look at what core functions we have designed on iBox to solve these problems, and how these functions solve these problems.

Three technology panorama

1 Technical research

The development status of the client R&D workbench in the industry. As follows:

Industry: EasyBox, MBox and other tools. On the one hand, the core of these tools is to solve the problem of low development efficiency in Native environment construction. On the other hand, Git and Cocoapods are deeply encapsulated, and the development mode is unified.

Tao Te: There are also some scattered scripting tools. But on the whole, problems such as R&D environment configuration, development and debugging, and integrated release have not been solved.

On the whole, it is an opportunity for the client R&D workbench to land. There are teams in the industry who are trying, and Taote also has pain points and needs in the Flutter R&D link. Since desktop-side development is to be carried out, choosing a desktop-side development framework has become the first thing to consider. There are mainly two types of desktop-side development frameworks that are currently popular:

Electron for the Frontend: Build desktop apps with JavaScript, HTML, and CSS.

Flutter Desktop for Clients: Build desktop apps with Flutter.

Usually when we make technology selection, we will think about problem solving, team status, technical fields, business trends and other aspects.

Problem solving: Both Electron and Flutter Desktop solutions can solve our problems. Although there are differences in performance, this is not our most concerned point.

Current status of the team: The client-side students are familiar with Flutter, and the client-side students have a lower cost of getting started, and do not rely on manpower from other ends. From this point of view, Flutter Desktop will be better.

Technical field: Both Electron and Flutter Desktop are moving forward. The Flutter 2.10 launched by the Flutter team this year will officially bring the Windows platform into stable version support, and this year will also complete the stable version support of Linux, MacOS and other platforms.

Business trend: The workbench may expand to all platforms in the future. For example, on the desktop side it is a research and development workbench, on the mobile side (Android&iOS) iBox is an application widget set or an app similar to Ant Partners, and on the web side it is a data dashboard. From this perspective, Flutter Desktop will be better. In addition, we also want to display UI and other components on the workbench. If we do it based on Flutter, then we can achieve what you see is what you get. This will be a very good experience.
Based on the above considerations, we finally chose Flutter Desktop. With the development framework, let's take a look at the architecture design of iBox.

2 functional design

The Core Positioning of iBox

iBox is a one-stop, diversified and customizable R&D workbench based on the Flutter Desktop technology stack. Provide R&D support for the whole process from R&D environment to integrated release. Core functions include workbench, R&D environment, project management, engine management, community ecology, change order management and toolbox, etc.

In terms of functional design, iBox is divided into four major sections: workbench, research and development, release, and toolbox. Among them, R&D, release, and toolbox each contain many sub-module functions.
We will focus on the core functions of the workbench, R&D environment and project management, community ecology, and change order management, so that everyone can have a basic understanding of the overall functions of iBox.

workbench

It provides functions such as the recent change order, quick access to common platforms, etc., so that common functions can be accessed directly with one click. In addition, the workbench also reserves the function of technology display Banner, which can display some excellent technical output inside and outside the team. In the future, it is also considered to make on-duty reminders, integrated reminders, and release reminders on the workbench.

R&D Environment and Engineering Management

R&D environment + project management solves the problem of how to quickly enter local development. If a newcomer enters team development, from getting a computer to entering development, generally need to go through two processes of R&D environment configuration and engineering environment configuration.

In this process, you need to go to various places to read the documents and operate according to the documents. In the process of operation, the documents are often not updated in time, and the operation errors are reported. If there is an error, you have to go to Google or ask your colleagues around you. The whole process is time-consuming. And laborious.

The two functional modules of iBox's R&D environment and project manager solve the above problems through one-click operation.

The first is that the R&D environment provides the functions of checking and one-click configuration of the R&D environment of Flutter, Android, and iOS, so that students who are not familiar with a certain terminal can configure their own R&D environment more conveniently, as shown below:

Then, project management provides functions such as environmental detection of shell projects such as Flutter, Android, and iOS under mixed projects, and one-click environment configuration, which solves the problem of complex and difficult environment configuration, as shown below:

The complexity of the engineering environment lies in the fact that it involves the compilation of Flutter, Android, and iOS. The compilation process will also vary due to differences in the local environment. Various compilation errors are reported, which makes developers struggling to cope. iBox sorts out various error types from the environment to the project, and displays the error information, as follows:

Not only let the developers know what is wrong with their engineering environment, but also provide a one-click repair of the engineering environment. The one-click repair function will first delete the cache (flutter clean, delete the lock file, etc.), and then run the entire project again according to the following process project to ensure that the project environment can be repaired as follows:

The two functional modules of R&D environment and project management cooperate with each other to truly solve the problem of difficult environment configuration for development students. At the same time, it also breaks the threshold between Android and iOS, so that students who are not familiar with the other end can also carry out debugging on this end. and pack.

Community ecology

Both inside and outside the group have contributed a lot of functional components to Flutter, but there is no unified place to display these components, causing developers to search in the pub library when they need to use them.

The community ecological function of iBox provides a display of technical accumulation in various aspects such as the Flutter community (inside and outside the group) engine, UI components, routing, dynamics, etc., especially UI components. Since iBox itself is developed based on Flutter, these UI components The Dart code can be displayed and interacted directly on the iBox. This WYSIWYG experience is great, as shown below:

Change Order Management

In the previous development process, the development process of Flutter was relatively cumbersome, and these processes required the development of manual operations, as follows:

Start development: iBox can associate Aone requirements to create a change order with one click, and at the same time create a new change branch to prepare the engineering environment required for the current change.
Under development: One-click to open Android & iOS dual-end package, one-click to submit the CR of the change warehouse.
Complete the development: submit the integration with one click, and the above integration steps will be automatically completed during the submission process.
These one-click operations not only greatly improve the efficiency of Flutter R&D, but also standardize the branch management and integration methods of Flutter, avoiding engineering problems caused by personal random operations.

The above are the functions planned and completed in the first phase of iBox. It fundamentally solves the various problems in the team's R&D link mentioned above. At the same time, I would also like to thank Xianyu for integrating and releasing this flying fish workbench for us. Practice reference.

3 architecture design

The architecture design of iBox mainly focuses on the following issues:

Question 1: iBox is a GUI software with a certain scale, how to organize the code of each functional module conveniently and safely.
Question 2: Since iBox is oriented towards co-construction, how to ensure the development experience of iBox itself.
Question 3: How does iBox guarantee the overall quality and performance of the software while ensuring co-construction and openness.
Through thinking about the above issues, we adopted a vertically layered and horizontally modular design for iBox, specifically:

Question 1: Different functions are designed in modules, and the source codes of the modules are independent of each other. In this way, the permissions of the source code warehouse can be finely controlled, and the modifications between different modules will not affect each other.

Question 2: Multi-warehouse management based on git repo. You can use git to operate a single warehouse, or use git repo to perform code synchronization, code submission, code review and other operations on multiple warehouses, which ensures the development experience of iBox multi-warehouse collaboration.

Question 3: Agree on the basic architectural design of each module. Including the source code organization method, state management scheme, etc., and through static scanning to ensure the implementation of these agreements.

Limit the reference of the third-party library and specify the version of the third-party library (do not use the ^ sign to specify the version, for example: url_launcher: ^6.0.20). The version specified by ^ will cause the last two versions to be automatically upgraded (when flutter upgrade and regenerating the pubspec.lock file), resulting in the use of some unexpected versions when packaging, causing quality problems (refer to the recent url_launcher's The automatic upgrade of url_launcher_macos causes the problem that the link cannot be opened (issue1 issue2).
The big picture of the overall architecture is as follows:

From the above architecture diagram, it can be seen that auxiliary functions are used as basic modules to provide basic capabilities for other core functions. Next, let's talk about the specific design schemes in the order from project to module:

The first is the design of the overall project.
Then there is the design of specific modules.

engineering structure

The overall project adopts a multi-warehouse design. The reason for using this design is that iBox will involve cross-team development. Multi-warehouses can make the source code of each module independent of each other, and different modules will not interfere with each other.

iBox implements multi-warehouse management based on git-repo, and the warehouse structure is as follows:

ibox is the main project, ibox_common is the basic module, and other modules depend on ibox_common. Students who develop iBox only need a few simple commands to synchronize all source code projects of iBox.

Then you can develop and submit code in your own module without interfering with each other. After talking about the design of the overall project, let's take a look at the design of each module.

modular design

The core function of each module is to deal with UI interaction and logic interaction. Unlike the imperative UI framework of traditional clients, Flutter adopts a declarative UI framework, and what drives UI changes is the state (State), as shown below:

The state in Flutter refers to the data or information stored and transmitted between Widgets or internally. It can be divided into short-term state and application state.

Short-term state (exphmeral state): also known as user UI state or partial state, is a state that is completely independent in the Widget. Other parts in the Widget tree do not need to access this state, and it does not need to use the state architecture (ScopedModel, Redux) to manage this state, it only needs a StatefulWidget.

Application state (app state): It is a non-short-term state shared between multiple parts of an application, and the user retains this state during the session.

Therefore, state management is a problem to be faced when writing UI and logic core, and it will also affect the way we organize source code. In the official document of Flutter state management, 14 kinds of state management solutions are provided. We focus on discussing the official recommendation. Four, as for other solutions, those who are interested can refer to the official documents.

Let's first look at the two native state management methods:

setState: Usually used to handle the short-term state inside the Widget.

InheritedWidget: setState can only handle the short-term state inside the Widget. If you need to process the application state and communicate between the Widget trees, you need to use InheritedWidget. InheritedWidget can provide data and services for its descendants.

setState is relatively limited in application scenarios, and InheritedWidget is too low-level for developers, and it is more complicated to use. Since the official solutions have limitations, let's take a look at the more recommended solutions provided by the community.

Provider: It encapsulates the InheritedWidget component, making it easier to use and reuse.

Riverpod: Based on the improvement of Provider, it is a responsive state management and dependency injection framework, which is safe to compile, supports DevTools debugging, and does not depend on Flutter itself.

In fact, the authors of both Provider and Riverpod are Remi Rousselet. The name Riverpod is obtained after reordering the letters of Provider. It was launched mainly to solve some functional defects of Provider, as follows:

Based on the above comparison, we finally chose the Riverpod solution, and thus designed the source code structure of the module, as follows:

A common process for writing UI logic is as follows:

Write pages and components in the ui part.
Write logic related to data in service.
Write related provider classes in the provider, which can call the functions in the service.
Refer to the provider in ui or anywhere else needed to operate related logic.
This method realizes the decoupling and separation of UI and logic, the UI part can be iterated freely, and the logic part can also be reused.

The above is the overall architecture design of iBox, which is equivalent to a simplified plug-in solution. How to have a richer plug-in ecology in the future, we will consider launching a plug-in market similar to VSCode, but for us at present, it is enough used.

The plug-in design makes it possible to freely assemble various modules. Different teams need different module functions. We have launched the app variant (variant) function. Different app variants (variants) have different tab bar configurations. When packaging, you can create packages with different functions for different teams.

4 online effect

Comparison of iBox before and after use on the core pain points of the R&D link


After using it for a period of time, iBox users also gave a lot of good feedback.

"One-click installation is still very easy to use, which saves a lot of time for development. In the past, downloading, installing and configuring in various places, and solving the problem of version conflicts, wasted a lot of time."
"This version integrates the fully mobile iBox, which is very cool to use."

"Greatly simplifies the configuration of the Flutter environment, cumbersome integration and other issues."

In addition, iBox is still in its infancy, and we hope to iterate and operate it as a product. For this reason, we also designed operation and maintenance indicators from different perspectives for iBox, as follows:


Hottest function module ranking

The operation and maintenance data system needs long-term construction. It has important guiding significance for our subsequent function iterations and experience optimization. Developers are also users, and the functions that only rely on brainstorming may not be recognized by everyone.

Four technical summary

Before working on iBox, I did some theoretical research on Flutter. I compiled the article "From Architecture to Source Code: Understanding the Flutter Rendering Mechanism in One Article", but there was no good opportunity to apply it in production practice. I have learned a lot from this iBox development journey. Taking this opportunity, let's talk about the application of Flutter Desktop technology in production practice.

1 The development history of Flutter Desktop

It has been four years since the flutter-desktop-embedding project initiated by the Flutter team on February 15, 2018, and the process has been ups and downs. From the initial non-support for the production environment to the release of Flutter 2.10, it is officially announced Supports the development of apps in the production environment on the Windows platform. The development history of Flutter Desktop is as follows:

2022.02.15, Flutter 2.10 was released, and the Windows platform took the lead in entering a stable version, which can be used for the development of production-level apps. Other platforms are also actively preparing.
In 2022, the Flutter team plans to advance one by one in the order of Windows, Linux, and MacOS, bringing support for mainstream desktop platforms to the stable channel, and finally realizing the vision of Flutter "write once, run anywhere".

2 Community ecology of Flutter Desktop

Like its support for Android and iOS, Flutter also implements Embedder based on platforms such as Windows. The upper layer of Embedder is C++ Engine and Dart Framework. It is responsible for translating and sending messages on platforms such as Windows. The overall architecture is as follows:

Comments: Other desktop platforms such as Linux and MacOS also have a similar implementation structure. For more in-depth details, please refer to the implementation of platform.

Compared with desktop applications, mobile applications have similarities, such as:

This also makes most of the existing Flutter community components available on the desktop side, but there are differences between the two, for example:

Based on these differences, Flutter also provides targeted support for desktop platforms, as follows:

Image quoted from Announcing Flutter for Windows

During the development of iBox, we also used a lot of native capabilities. Here is a summary of some community components commonly used in Flutter Desktop, as follows:

The existing community components can basically meet our development needs.

3 Application Scenarios of Flutter Desktop

iBox is a meaningful exploration of Flutter Desktop technology, which brings more possibilities to our products and expands the boundaries of product reach.

So, what application scenarios is Flutter Desktop suitable for?

The tool software used inside the enterprise, especially when the team is short of personnel, wants to quickly implement some tools and functions.

Enterprise ToB applications, such as cash registers, Ele.me merchants, etc.

The team already has a mobile application developed based on Flutter, and wants to extend some functions to the desktop.

Any technology has advantages and disadvantages, and Flutter Desktop also has unsuitable application scenarios, as follows:

Applications that rely heavily on the native capabilities of the desktop end, because the community ecological support for the desktop end is not as complete as the mobile end, and if you encounter a lack of capabilities, you need to build it from scratch.

Of course, technology is also constantly developing, and the current problems may be solved in the future. The author is still very confident in the development of Flutter Desktop technology.