Ibox - One-stop R&d Workbench for Flutter

One-stop R&D Workbench for Flutter Introduction:

IBox - One-stop R&D Workbench for FlutterFlutter's one-code, multi-terminal feature frees up the manpower of classmates and improves R&D efficiency. However, various problems were found in the R&D link, such as the construction of the R&D environment, the double-end engineering environment, the cumbersome integrated release process, and so on. In order to gain an in-depth understanding of the pain points of the development students, the author's team initiated a questionnaire survey. This article will be based on the pain points identified in the survey and some of the challenges faced in addressing them.

One-stop R&D Workbench for Flutter a preface

One-stop R&D Workbench for Flutter, Flutter's one-code multi-terminal feature frees up the manpower of the students on the side and brings about the improvement of R&D efficiency. Due to the mismatch in the number of early two-terminal R&D students and the demand for R&D efficiency , Taote 's technical team is also the earliest in the Alibaba Group. One of the teams that have landed on Flutter in business.

One-stop R&D Workbench for Flutter, Although there is the convenience of one code and multiple ends, there are also various problems in the R&D link, such as the establishment of the R&D environment, the double-end engineering environment, the cumbersome integrated release process, and so on. In order to gain an in-depth understanding of the pain points of development students, we launched a questionnaire within the team.

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

The average score on the R&D Well-Being Index was 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.
One-stop R&D Workbench for Flutter,two problems and challenges
1 One-stop R&D Workbench for Flutter question
Among the problems affecting R&D happiness, the following three aspects are more prominent.

1) One-stop R&D Workbench for Flutter,R&D environmental issues

The configuration of the R&D environment is a prerequisite for coding, 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 configuration of the other end, 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 untimely updates of documents, all of which have greatly consumed the energy of the team.

2) One-stop R&D Workbench for Flutter,Engineering environmental issues

After solving the problem of the research and development environment, it is also necessary to solve the problem of the engineering environment. The double-end engineering structure is complex, and students who are not familiar with one end are difficult to solve the compilation problem. Many students even gave up the project of configuring another end, and usually only debugged on the end they were familiar with, which violated the concept of double-end development in Flutter.

Comments: From the research and interview of the team, a new student builds Flutter's R&D environment and engineering environment. It takes one day to build the basic environment first, and then two or three days to toss various compilation problems, especially the relevant environment of iOS is very important for For Android students, it is very laborious to run completely .

3) One-stop R&D Workbench for Flutter,Integration process issues

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

Comments: The existing Flutter module integration process is divided into six steps:
1. Module branch code merge ->
2. Module to generate a new Tag version ->
3. Main project to modify the module version number ->
4. Main project code merger ->
5. Main project generation version No. ->
6 Ferris wheel to submit the official package for packaging, the steps are cumbersome, you need to switch back and forth on Aone , MTL and other platforms, and manual operation of various version numbers can easily lead to online quality problems.

2 One-stop R&D Workbench for Flutter challenges

In order to solve these problems, some documents and scripts have been deposited before, but there are many steps and commands in the documents, and mistakes in any one of them may lead to errors in the environment setup. 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 this, and new students can also use this R&D workbench to quickly land. Happiness will be a qualitative improvement.
So we decided to build a desktop-side R&D workbench, and we also encountered many challenges in the process of achieving this goal.
1) How to reduce the access and use costs of developers

1.Access and usage costs. The R&D workbench is originally a tool software. If it is complicated to operate and needs 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.

2.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 and not change the existing usage habits of the development students is also a key consideration for us.
2) How to ensure the rationality of the architecture design

We want to make the R&D workbench an open platform that everyone can participate in and build. Because personal time is limited, the workbench itself, as an aggregation of toolsets, needs more students to participate, and more The idea has landed, so how to control warehouse permissions and design a good plug-in framework is very important.

3) One-stop R&D Workbench for Flutter, 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 section will talk about it). At present, the Flutter Desktop technology in China is not much implemented in the production environment, and the relevant experience is still relatively lacking. Some problems, you need to explore and solve 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 One-stop R&D Workbench for Flutter ,Technical research

The development status of the client R&D workbench in the industry. As follows:
Industry: EasyBox , MBox and other tools. The core aspect of these tools is to solve the problem of low development efficiency in the construction of the Native environment. On the other hand, it deeply encapsulates Git and Cocoapods , and unifies the development mode.
Tao Te: There are also some scattered scripting tools. However, as a 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 trying it, and Taote also has pain points and needs in the Flutter R&D link. Since desktop development is to be carried out, choosing a desktop development framework has become the first thing to consider. There are mainly the following two popular desktop development frameworks:
Electron for Frontend: Build desktop applications using JavaScript, HTML, and CSS.
Flutter Desktop for Clients: Use Flutter to build desktop applications.
Usually, when we do technology selection, we will think about it from the aspects of problem solving, team status, technology field, business trend and so on.
Problem solving: Both Electron and Flutter Desktop solutions can solve our problems. Although there are differences in performance, this is not our main concern.
Team status: Client-side students are familiar with Flutter, and client-side students have a lower start-up cost and do not rely on manpower from other terminals. From this point of view, Flutter Desktop would be better.
Technical field: Electron and Flutter Desktop are both moving forward. The Flutter 2.10 launched by the Flutter team this year officially brings the Windows platform into the stable version support, and will also complete the stable version support for Linux, MacOS and other platforms this year.
Business trend: The workbench may expand to the whole platform 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 Partner, and on the web side, it is a data board. From this point of view, Flutter Desktop will be better. In addition, we also want to display components such as UI on the workbench. If we do it based on Flutter, then we can achieve what you see is what you get, which will be a very good experience.
Based on the above thinking, we finally chose Flutter Desktop. With the development framework, let's take a look at the architecture design of iBox .

2 One-stop R&D Workbench for Flutter,Functional Design

One-stop R&D Workbench for Flutter, 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 . The core functions include workbench, R&D environment, engineering management, engine management, community ecology, change order management and toolbox.

iBox is divided into four major sections: workbench, R&D, release, and toolbox. Among them, R&D, release, and toolbox each contain many sub-module functions.
We will focus on the core functions such as 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 .

One-stop R&D Workbench for Flutter,workbench
It provides functions such as the latest change order and the shortcut entry of common platforms, so that common functions can be directly accessed with one click. In addition, the workbench also reserves the function of technical display banner, which can display some excellent technical outputs inside and outside the team. In the follow-up, we will also consider on-duty reminders, integrated reminders, and release reminders on the workbench.

R&D Environment and Engineering Management

R & D environment + engineering management solves the problem of how to quickly enter the local development. If a new person enters the team development, from getting the computer to entering the development, it generally needs to go through the 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, there are often times when the document is not updated in time, the operation reports an error, and if there is an error, you have to go to Google or ask your colleagues around you. The whole process is time-consuming. Again laborious.
The two functional modules of iBox 's R&D environment and engineering manager solve the above problems through one-click operation.
The first is that the R&D environment provides the function 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:

Not only let developers know what is wrong with their engineering environment, but also provide one-click repair for engineering environment problems. The one-click repair function will delete the cache (flutter clean, delete lock files, etc.), and then re-run according to the following process The entire project, ensuring that the project environment can be repaired, is as follows:
Then the project management provides functions such as shell engineering environment detection and one-click environment configuration under the mixed project, such as Flutter, Android, iOS, etc., which solves the problem that the environment configuration is complex and difficult to use, as shown below:

One-stop R&D Workbench for Flutter,Then the project management provides functions such as shell engineering environment detection and one-click environment configuration under the mixed project, such as Flutter, Android, iOS, etc., which solves the problem that the environment configuration is complex and difficult to use, as shown below:

One-stop R&D Workbench for Flutter,The two functional modules of R&D environment and project management cooperate with each other, which really solves 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 debug this end. and packing.

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, so developers need to search in the pub library when they need to use them.

And The community ecological function of iBox provides a display of the technical precipitation of the Flutter community (inside and outside the group) engine, UI components, routing, dynamization, etc., especially the UI components. Since iBox itself is developed based on Flutter, the Dart code can be displayed and interacted directly on iBox . This WYSIWYG experience is very good , as shown below:

One-stop R&D Workbench for Flutter,Change order management
In the previous development process, Flutter's R&D process was cumbersome, and these processes needed to be developed manually, as shown below:
•start developing
•Create Android Ferris Wheel Change Order
•Create an iOS Ferris Wheel Change Order
•Pull change branch
•the module dependency code of the main project of Flutter
•Associate Aone Requirements
•In development
•Android Packaging
•iOS Packaging
•Submit module code CR
•Local source code dependency modification
•complete development
•Module branch code merge
•The module generates a new Tag version
•The main project modifies the module version number
•Main project code merge
•Main project generation version number
•Ferris wheel submits official package for packaging
The change order function of iBox can help Flutter R&D students to quickly complete various operations of the R&D process, as shown below:

•Start development: iBox can create a change order with one click associated with Aone requirements, and create a new change branch at the same time to prepare the engineering environment required for the current change.
•In development: One-click to type Android & iOS double-ended packages, and one-click to submit CR of the changed warehouse.
•Complete the development: submit the integration with one click, and the above integration steps will be automatically completed during the submission process.

One-stop R&D Workbench for Flutter,These one-click operations not only improve the efficiency of Flutter's research and development, but also standardize Flutter's branch management and integration methods to avoid engineering problems caused by individual random operations.
The above is The function planned and completed in the first phase of iBox, it fundamentally solves the problems existing in the research and development link of the team mentioned above. At the same time, I would like to thank Xianyu students for the practical reference of the flying fish workbench provided for us in the integrated release.

3 One-stop R&D Workbench for Flutter,Architecture Design

iBox mainly focuses on the following issues:
•Question 1: As a GUI software with a certain scale, how can iBox organize the codes of various functional modules conveniently and safely.
•Question 2: Since iBox is for co-construction, how to ensure the development experience of iBox itself.
•Question 3: How does iBox ensure the overall quality and performance of the software while ensuring co-construction and openness.
By thinking about the above issues, we have adopted a vertical layered and horizontally modular design for iBox , specifically:
•Question 1: Different functions are modularized, and the module source code is independent of each other. In this way, the permissions of the source code repository can be finely controlled, and modifications between different modules will not affect each other.
•Question 2: Multi-repository 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 source code organization, state management scheme and other aspects, and through static scanning to ensure the implementation of these agreements.

•Restrict 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 the ^ sign will cause the last two versions to be automatically upgraded (when flutter upgrade and regenerate the pubspec.lock file), resulting in the use of some unexpected versions when packaging, causing quality problems (refer to the recent url_launcher 's url_launcher_macos automatic upgrade leads to the problem that the link cannot be opened issue1 issue2).
The overall architecture diagram 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, we will 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 multi-warehouse design is adopted in the overall project. The reason for this design is that iBox will involve cross-team development. Multiple warehouses can make the source code of each module independent of each other, and different modules will not interfere with each other.
iBox implements the management of multiple warehouses based on git-repo. 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 lines of simple commands to synchronize all the 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.
module design
The core function of each module is to handle UI interaction and logical interaction. Unlike the traditional client-side imperative UI framework, Flutter uses a declarative UI framework, and the state that drives the UI changes is as follows:

Image quoted from Start thinking declaratively
The state in Flutter refers to the data or information stored and transmitted between or within Widgets. It can be divided into two types: short-term state and application state.

•Short-term state ( exphmeral state ): also known as user UI state or partial state, is a state completely independent of the Widget. The rest of the widget tree does not need to access this state, nor does it 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-transitory state shared between parts of an application and the user retains this state for the duration of the session.
Therefore, state management is a problem to be faced when writing UI and logic core. It also affects the way we organize source code. In the official document of Flutter state management, 14 state management solutions are provided. Four, as for other solutions, those who are interested can go to the official documentation.
Let's first look at the two native state management methods:
•setState : Usually used to handle 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 the InheritedWidget , which can provide data and services for its descendant nodes.
setState is relatively limited in application scenarios, and InheritedWidget is too low-level for developers and 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 Provider improvements, it is a responsive state management and dependency injection framework, 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 by rearranging the letters of Provider. It was launched mainly to solve some functional defects of Provider, as follows:

One-stop R&D Workbench for Flutter, Based on the above comparison, we finally chose the solution of Riverpod , and thus designed the source code structure of the module, as shown below:

iBox module source code structure
|------------------------------------------------- ------------
|--- provider State management method based on Riverpod implementation (official recommendation)
|----- xxx.provider .dart provider
|--- Service interface request, data processing related implementation
|----- xxx.service .dart service
|--- ui pages and components
|----- xxx.screen.dart page
A common process for writing UI logic is as follows:
1.Write pages and components in the ui section.
2.Write data-related logic in the service.
3.Write the relevant provider class in the provider, which can call the functions in the service.
4.in the ui or any other required location to operate the related logic.
This method realizes the decoupling and separation of UI and logic. The UI part can be iterated freely, and the logic part is also reused.

The above is The overall architecture design of iBox is equivalent to a simplified version of the plug-in solution. How to have a richer plug-in ecosystem in the future? We will consider launching a plug-in market similar to VSCode , but for now, it is enough for us.
plug- in design makes it possible to freely assemble each module. Different teams need different module functions. We have introduced the function of app variant. Different app variants (variants) have different tab bar configurations. When packaging, you can create packages with different functions for different teams.

4 On-line effect
iBox before and after use on the core pain points of R&D links

iBox users have also given a lot of good feedback after using it for a period of time.
" One-click installation is still very easy to use, saving 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 full-running iBox , which is very cool to use."
"It greatly simplifies the configuration of the Flutter environment and the cumbersome integration."
In addition, iBox is still in its infancy, and we hope to iterate and operate it as a product. To this end, we also designed operation and maintenance indicators from different perspectives for iBox , as follows:
The Big Picture: The Whole Data
•PV of the whole station
•Total station UV
•Number of teams covered
•User coverage by team
•Top 10 most visited users
•Top 10 most visited pages
User Perspective: Features of Different Team/Individual Preferences
•Team -> Feature Module Visits
•Personal -> Function Module Visits
Business Perspective: Well done, popular features
•Hottest functional module ranking
operation and maintenance data system needs to be built for a long time. It has important guiding significance for our subsequent functional iteration and experience optimization. The developers are also users, and the functions that they come up with only by slapping their heads may not be recognized by everyone.

Four technical summary
Before doing iBox , I did some research on the principles of Flutter, and I compiled the article "From Architecture to Source Code: Understanding Flutter Rendering Mechanism in One Article", but there is no good opportunity to apply it in production practice. I learned a lot from this iBox development journey . Taking this opportunity, let's talk about the application of Flutter Desktop technology in production practice.
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 in between is also ups and downs , from the initial unsupported production environment to the current Flutter 2.10 release, officially announced To support the development of production environment apps on the Windows platform, the development process of Flutter Desktop is as follows:
•2018.02.15, submit the first initial commit in the flutter-desktop-embedding project.
•2019.12.05, supports MacOS platform.
•2020.07.08, the Linux platform enters the alpha stage.
•2020.09.24, the Windows platform enters the alpha stage.
•On 2021.03.05, Flutter 2 was officially released, and Flutter's support for the desktop side entered the preparatory stage of the stable version.
•2022.02.15, Flutter 2.10 is released, the Windows platform is the first to enter the stable version, which can be used for the development of production-level apps, and 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, bring support for mainstream desktop platforms to the stable channel, and finally realize Flutter's vision of "write once, run anywhere".

2 Community ecology of Flutter Desktop

Like 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, which is responsible for translating and sending messages from platforms such as Windows. The overall architecture is as follows:

Image quoted from Announcing Flutter for Windows
Comments: Other desktop platforms such as Linux and MacOS have similar implementation structures. For more in-depth details, please refer to the implementation of platform.
There are similarities between mobile applications and desktop applications, such as:
•GPU graphics acceleration
•rendering system
•text input

•UI components
This also makes most of the existing Flutter community components available on the desktop, but there are differences, such as:
•larger screen size
•Support mouse/keyboard input
•System-specific visual styles
•Interaction with the underlying system
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 products .
So, what application scenarios is Flutter Desktop suitable for?
•The tool software used within the enterprise, especially when the team is insufficient, want to quickly implement some tools and functions.
•Enterprise ToB applications, such as cash registers, Ele.me merchants, etc.
•The team itself already has a mobile application developed based on Flutter, and wants to extend some functions to the desktop.
Any technology has its pros and cons, and Flutter Desktop also has unsuitable application scenarios, as follows:
•Applications that rely heavily on the native capabilities of the desktop side, because the community ecological support for the desktop side is not as complete as the mobile terminal , and if you encounter the lack of capabilities, you need to build it from scratch.
Of course, technology is constantly evolving, and current problems may be solved in the future. The author is still very confident in the development of Flutter Desktop technology.
Five Conclusions
A piece of code in Flutter can run on multiple terminals while taking into account performance, which is its advantage and liberates productivity on the terminal. This is undoubtedly a boon, especially for teams with a serious imbalance in the proportion of iOS and Android classmates.
However, if you don't pay attention to the construction of supporting tools around the development of Flutter, from the initial environment construction, development and debugging, to integrated release without good tools to support, it will easily evolve into "Flutter from entry to abandonment". This is because the demands of the business team and the technical team are different. The technical team feels that the process of solving various problems of Flutter is a learning process, but the business team is under great business pressure. Their first demand is rapid development and rapid launch. If the peripheral supporting tools are missing, they are likely to choose to give up this plan, which is very detrimental to the promotion of Flutter .
We hope that the development students who are new to Flutter will have a smooth use experience, and they can be completed with one click. For example, we propose "complete the construction of the Flutter environment in one hour", "one-click configuration/repair the engineering environment", etc. Etc., these concepts also coincide with the "improving developer experience" in the annual plan recently released by the Flutter team.

Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00

phone Contact Us