This project is a proof of concept to test the Flutterando Clean architecture proposal (Clean-Dart) with different state managers handling data provided by the API of the Github using Flutter 3.
Overrall, the architecture of the software must follow clear contexts of maintainability and scalability, that being said, it is extremely important to evaluate the architectural structure of the product even before the development, to result in a more versatile application whereupon it improves the ability of the developers to improve or fixing features in a short time.
Following the Clean Dart principles, we must separate our project into 4 layers:
Presenter
Domain
Infrastructure
External
Highlighting that the Presenter
layer is responsible for allocating pages, widgets and state management , it becomes understandable to group Domain
, Infra
, External
layers and their respective unit tests in a single project being exported as a dependency, so we can have multiple separate repositories with different state management approaches using the same business logic and components.
Still with a top-down view, it's possible to notice that as the components and assets (fonts, images) of each project will be the same, so we can allocate the widgets in github_commons
as well.
The project works with the Github API through the requests:
GET
=> https://api.github.com/users/{username}GET
=> https://api.github.com/users/{username}/repos
These 2 requests will be called in Datasources (External Layer)
receiving data in Json format, being processed in the Repository (Infra Layer)
now with Model format and converted to Entity format.
As we already have the data available in entities, to allocate them to be worked in Usecases (Domain Layer)
, therefore, 3 usecases were created:
GetProfile
- get data from the first request flowGetRepositories
- get data from the second request flowGetLaguages
- creates statistics with the programming languages used in repositories, by parameter it receives the repositories list fetched in usecaseGetRepositories
These usecases are called in all projects in which they have their data handled differently and uniquely by each state manager
Project | Layers | State Management | Packages |
---|---|---|---|
github_mobx |
Presenter | Mobx - Library for reactively managing the state of your applications. Use the power of observables, actions, and reactions to supercharge your Dart and Flutter apps. |
mobx , flutter_mobx |
github_getx |
Presenter | Getx - Open screens/snackbars/dialogs without context, manage states and inject dependencies easily |
get |
github_bloc |
Presenter | Bloc - A predictable state management library that helps implement the Business Logic Component design pattern. |
bloc, flutter_bloc |
github_triple |
Presenter | Triple - an abstraction of the Segmented State Pattern that forces architectural barriers to individual reactivities. |
triple |
github_provider |
Presenter | Provider - A wrapper around InheritedWidget to make them easier to use and more reusable. |
provider |
github_inherited |
Presenter | InheritedWidget - Base class for widgets that efficiently propagate information down the tree. |
InheritedWidget class |
github_commons |
Domain, Infra, External | None | dio, flutter_svg, equatable, url_launcher, json_annotation, flutter_modular |
- Flutter has many other state managers available with different approaches (State Management Docs | List of state management approaches)
To run this project on your own, do the following:
- Clone this project.
- Open project
github_commons
and runflutter pub get
to install general dependencies. - Open the project that uses your preferred state manager and run
flutter pub get
to install specific dependencies. - Run the project using
flutter run
or debugging using your IDE's tools.