Many people, including me, have a problem with the layout of the FOLDERS of the Flutter project when they start their own demo project after learning the basics of Flutter.

Since I’m an iOS developer, in an iOS project, all I need to do is type in the header file. Such as: import manager. “h”

To import files into Flutter, import the relative path of the header file, e.g. Import ‘package:/pages/index_page.dart’;

Therefore, if you don’t plan for the directory up front, it can be a disaster to catalog some of the files as the project gets bigger

Let’s start by creating a brand new Flutter project called “FlutterDemo”. Depending on the editor you are using, the steps to create a new project are relatively simple and will not be described here. After creation, the project structure is as follows:

├─ Android ├─ Ios ├─ lib ├─ testCopy the code

Since we need to use external images and Icon resources, we create the “Assets” folder in the project root, and create “images” and “res”, the former for images and the latter for other resources such as fonts, PDF files, etc.

Then our code is mainly in the Lib folder, which can be optimized using the iOS common code directory

FlutterDemo ├ ─ ─ android ├ ─ ─ ios ├ ─ ─ assets ├ ─ ─ ─ ─ images ├ ─ ─ ─ ─ res ├ ─ ─ lib ├ ─ ─ ─ ─ constant ├ ─ ─ ─ ─ the HTTP ├ ─ ─ ─ ─ routers ├ ─ ─ ─ ─ utils ├ ─ ─ ─ ─ pages ├ ─ ─ ─ ─ ─ ─ home ├ ─ ─ ─ ─ ─ ─ the main ├ ─ ─ ─ ─ model ├ ─ ─ ─ ─ the widget ├ ─ ─ ─ ─ ─ ─ home ├ ─ ─ ─ ─ ─ ─ the main └ ─ ─ testCopy the code
folder role
assets Resource file
assets-images Image files
assets-res Other resources
constant Static constants
http Network interface classes, including interface name classes
routers Store all routing page classes
utils General utility class
pages All view interfaces in the App
model Dart Model class for the Json file
widget Widgets that are packaged within your App

In Pages and Widgets, it is best to sort pages by module creation subfiles. As items grow larger, it can be difficult to find related pages without categorizing them

Note that the use of different frameworks or technology selection will have different ways of organizing the code, therefore, the code organization structure in this article is set according to some of my experience and habits, but not fixed or “best”, in practice, you can adjust the source code structure according to the situation.

But no matter what source code organization you choose, clarity and decoupling is a general principle, and you should make your code clear for communication and maintenance.