First, let's create a brand-new Flutter project named "github_client_app." The steps to create a new project may vary depending on the editor used by the reader, but they are relatively simple and will not be elaborated here. After creation, the project structure is as follows:
github_client_app ├── android ├── ios ├── lib └── test
Since we need to use external images and icon resources, we will create "imgs" and "fonts" folders in the project root directory. The former is used to store images, while the latter is for storing icon files. Readers can refer to the relevant content in Chapter 3 regarding images and icons.
As we need to transmit and persist data using JSON during network data transfer, we will need to convert JSON into Dart model classes during application development. We will use the method introduced in the "Json to Model" section in Chapter 11, so we will also create a "jsons" folder in the root directory to store JSON files.
For multilingual support, we will use the solution introduced in the "Internationalization" section, so we also need to create an "l10n" folder in the root directory to store the corresponding ARB files for various languages.
Now the project directory becomes:
github_client_app ├── android ├── fonts ├── l10n-arb ├── imgs ├── ios ├── jsons ├── lib └── test
Since all our Dart code will be in the "lib" folder, I have created the following directories under the lib folder based on technical choices and experience:
lib├── common ├── l10n ├── models ├── states ├── routes └── widgets
| Folder | Purpose |
|---|---|
| common | Contains utility classes, such as general method classes, network interface classes, and static classes for storing global variables. |
| l10n | Contains classes related to internationalization. |
| models | Dart model classes corresponding to JSON files will be in this directory. |
| states | Contains state classes that need to be shared across components in the app. |
| routes | Stores all route page classes. |
| widgets | Contains various widget components encapsulated within the app. |
Note that using different frameworks or technology choices will lead to different organizational methods for the code. Therefore, the code organization structure introduced in this section is not fixed or "best." In practice, readers can adjust the source structure according to their specific situations. However, regardless of the source organization structure adopted, clarity and decoupling are universal principles. We should aim for a clear code structure for better communication and maintenance.
