(info) The documentation is compatible with User App v1.5.3 and will be updated and added to gradually.

How to Run the App:

  1. Flutter and Dart Versions:

  2. Back End Compatibility:

  3. GraphQL Schema Update:

  4. Run Build Process:

  5. Launch the App:

By following these steps, you ensure that your development environment is properly configured, and the app is launched with the necessary dependencies and configurations.

App Structure

Introduction:

Architecture Overview:

State Management:

Application Structure:

At the Application level, we centralize providers and actions to streamline the management of web, mobile, and tablet applications within a single project. This unified approach ensures that all events are consolidated and stored in the 'actions' folder. This design choice serves two key purposes:

By housing all events in a centralized 'actions' folder, we minimize the effort required to support and maintain the project. This unified structure promotes a cohesive codebase that is easier to manage and enhances overall project efficiency.

Given that our project encompasses web, mobile, and tablet applications, consolidating events at the Application level guarantees consistent execution across devices of different types and operating systems (OS). This uniformity simplifies development and testing processes, ensuring a seamless experience for end-users across various platforms.
In essence, this architectural decision reflects our commitment to a streamlined and consistent development approach, promoting ease of maintenance and a unified user experience across diverse devices and operating systems.

Infrastructure Layer:

The Infrastructure layer plays a pivotal role in our application, encompassing both the Repository and GraphQL components.

Developers download the GraphQL schema (schema.graphql), providing a foundational blueprint for data interactions.

Developers create request files (*.graphql files) that encapsulate specific data requests and operations.

Running build_runner generates additional files, incorporating the specified GraphQL schema and request files. This automated process ensures that the application is equipped with the necessary components for efficient GraphQL interactions.

For a more comprehensive understanding of the ferry library, developers can refer to the official ferry page. In essence, this integration streamlines GraphQL communication, contributing to a robust and efficient data interaction mechanism within our application.

Presentation

In the Flutter Presentation layer, the focus is on widgets, catering to the diverse layouts required for different platforms within our extensive project. To enhance organization and ease of development, we've implemented a structured widget division scheme:

Widget Division Structure:

Overall Project Structure:

The entire project is strategically distributed across key modules:

This meticulous organization within the Presentation layer underscores our commitment to a scalable, maintainable, and platform-aware Flutter project structure, optimizing development workflows and ensuring a cohesive user interface across various platforms.

Local Data Storage with Hive:

In our project, we leverage the power of Hive to efficiently store various data on the user's device. The primary role of the local database is to safeguard critical information, as exemplified by the storage of configuration data in https://{ENDPOINT_URL}/static/config.json.

Hive serves as the central repository for storing essential data locally on the user's device. This includes critical configurations encapsulated in https://{ENDPOINT_URL}/static/config.json

The use of Hive boxes is a strategic choice to mitigate the risk of data loss due to state loss, a challenge occasionally encountered in Flutter web applications. By persistently storing data in Hive boxes, we ensure a reliable and resilient data management system.

All relevant boxes are registered and initialized in the main.dart file when Hive adapters are set up. This centralized registration ensures that the application is ready to interact with the local database across its various components.

By adhering to this structured approach, we optimize data storage, mitigate Flutter web-specific challenges, and establish a reliable foundation for handling local data within our project. Hive, as a lightweight and efficient NoSQL database, contributes to a seamless and responsive user experience across different platforms.

Assets Management:

The application relies on locally stored fonts located in assets/fonts. Caution is advised when making changes to fonts; always update or add entries in pubspec.yaml under the fonts section.
WARNING: When modifying fonts, ensure to replace or add entries in pubspec.yaml under the fonts section to reflect the changes accurately.

All graphic assets, including *.png, *.jpg, *.svg, etc., are centralized in assets/icons. To maintain a systematic approach, each asset's path is recorded in constant variables within lib/presentation/constants/assets_path.dart.
WARNING: When adding or removing assets, it's crucial to update assets_path.dart with the appropriate entries. Avoid directly referencing the full path to the asset within the widget.

By adhering to these asset management guidelines, we establish a robust system for handling fonts, icons, and images. This practice not only ensures a well-organized and maintainable project structure but also streamlines the asset update process, minimizing the risk of errors and enhancing overall development efficiency.

Localization Setup:

For efficient localization, our application utilizes the easy_localization library. The localization JSON files are stored in assets/lang. To introduce a new locale, follow these steps:

  1. Create a New JSON File:

  2. Update Supported Locales:

Example:

// lib/presentation/helpers/capitalize.dart
List<Locale> supportedLocales = [
  Locale('en', 'US'), // Example: English (United States)
  Locale('es', 'ES'), // Example: Spanish (Spain)
  // Add your new locale below:
  Locale('fr', 'FR'), // Example: French (France)
];

Additional Considerations:

By adhering to these steps, you ensure seamless integration of new locales into the application's localization system. The use of easy_localization simplifies the process, providing a user-friendly and efficient mechanism for supporting multiple languages within the project.

Server Deployment Configuration: https://{ENDPOINT_URL}/static/config.json

Screenshot from 2024-01-30 07-55-30.png

When deploying to the server, the DevOps team must specify the values in the configuration file. This strategic approach empowers the team to make configuration adjustments without necessitating a rebuild of the application.

Key Benefits:

  1. Flexibility:

  2. Dynamic Configuration:

Procedure:

  1. Config File Modification:

  2. Server Restart:

All customization and changes that differentiate the custom version of the product from the master branch are listed here.

build.yaml

This configuration file so that build_runner knows which generators to run and where to find our GraphQL schema (watch ferry_generator).

analysis_options.yaml

Configuration file for linter. We are constantly working on the quality of the code, so we are constantly adding new rules to make the code more qualitative and productive.

.gitlab-ci.yml

Setting up CI/CD for Gitlab.

Dockerfile

Configuration file for building a docker image. IMPORTANT! If a different version of flutter will be used for development, you need to replace it here as well, so that there are no problems during deployment.

.gitignore

A list of files that should not be stored in the repository.