Project    |    Technologies    |    Overview    |    Implemented Views    |    Usage

✦ Project

This repository was created to be a mobile project that uses the Reso Coder's Flutter Clean Architecture Proposal™ using the current most popular technologies and approach's to make an project with a built-in authentication features made using good practices as clean code, SOLID and conventional commits. This project must be the base for my future projects.

✦ Technologies

This project was made using the tecnologies below:

• Flutter
• Dart
• Flutter Modular to dependency injection and routing. This package allows us to use a smart and modularized Structure to inject depencies and define routes. This way we improove understanding of features, faces less breaking changes and improve reuse.
• Flutter BLoC to the page's state management. BLoC allows for a clear separation between the UI components and the business logic and this helps to organize code and making it more maintainable and testable.
• Mockito as the Mock support to our tests.
• Flutter Tests the native option to make app unit tests.
• Get_Storage as our local storage.
• Firebase Rest API to authentication because we will not need to add any dependency.

✦ Overview

This project can be a good start to make your own app. The lib folder comports all our functionalities, being divided in core folder (common resources) and app folder (our features):

The following content explains how each feature was structured.

The auth feature will be used as example across this explanation.

Presentation

In top of flow, we have the presentation layer. It includes the UI components such as widgets, pages and presenters. Futhermore, the layer is responsible for rendering the user interface and handle user actions.

The presenter separation makes the UI code more maintainable and testable because it removes the Business Logic from the UI behaviour, avoiding coupled code's.

The project presentation layer's are divided in bloc, stateless widget's and the presenter orchestror file, a stateful widget that can uses native Flutter lifecycle and handles all other organisms:

Domain

Under the presentation layer on stack flow we've the domain layer. This layer basically contains business logic and entities. It represents the core functionality of the feature and has to be independent of any external elements. Build our domain like this helps to make the business logic independent of the UI and data sources:

The related folders are used to:

• usecases: Contains the application-specific business rules or use cases. These use cases represent the actions that can be performed within the application.
• protocols: Includes the interfaces or abstract classes that define the methods for data operations. These interfaces are implemented in the data layer, in repositories.
• entities: Holds the core data models or entities that represent the business objects and data structures used within the feature

Data

This layer deals with data handling, including data sources, repositories, models and remote data providers. It is responsible for retrieving and storing data from external sources such as databases, APIs, or repositories. It Abstracts the data sources and provides a unified interface to access and manipulate data. By separating data handling from the rest of the application, it allows us to isolate and manage data easier, swap data source if needed and data manipulation without impacting the business logic.

The data folders are:

• datasources: Contains classes responsible for interacting with remote data sources such as APIs or web services.
• repositories: Implements the interfaces defined in the domain layer. These concrete implementations handle data operations and serve as the bridge between the domain layer and external data sources.
• models: Holds the data models (derived from domain entities) that represent the data structures used for data manipulation within the application

Core

Besides the features, I created a core path that contains all shared components used across the application as errors, mixins, extensions, constants and common widgets:

Dependency Injection

The dependency injection follows the diagram on the beggining of this document, in other words, datasources are injected on repositories, repositories are injected on usecases and usecases are injected on the presentation. Modular made it easy, fortunately.

Is it coincidence?

Home feature injection example

You can implement as dependency just the what you feature needs. Modular will factory and dispose it automatically when the navigation actions triggers something.

✦ Implemented Views

The following images are from the authentication features (Home isn't listed because is just a simple page structure and will be replaced on other projects):

✦ Usage

To start using this template, fork this repo and start using. Make sure you created your .env on root path following .env.example. You need to follow the Firebase project's configuration configs to get your own firebase web key. After this, run the following command in the root path to start the proceed:

flutter pub get

You got the dependencies and, now, run the app using:

flutter run

Instead of this you can also generate your apk build and run in your own device with:

flutter build apk

✦ Start to use

Just fork it.