ZamariThomas /
flutter-clean-architecture-template
🚀 Kickstart your Flutter projects with a production-ready template that implements clean architecture, BLoC, and robust authentication features.
Loading repository data…
wednesday-solutions / repository
A Flutter template application showcasing - Clean architecture, Responsive design, State management, Decoupled widgets using the connector pattern, Dependency Injection, Widget, Unit, Golden and E2E testing, Navigation, Localization, Material 3 dynamic theming, Continuous Integration and Continuous Deployment.
We’re always looking for people who value their work, so come and join us. We are hiring!
Clone the repo and follow these steps to setup the project.
The template was build using dart null safety. Dart 2.19.2 or greater and Flutter 3 or greater is required.
Follow this guide to setup your flutter environment based on your platform.
First and foremost make sure you have Flutter 3 setup on your system. You can check the version by running
flutter --version
You should see output similar to this. Check if the version is 3.x.x.
Flutter 3.7.7 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 2ad6cd72c0 (13 days ago) • 2023-03-08 09:41:59 -0800
Engine • revision 1837b5be5f
Tools • Dart 2.19.4 • DevTools 2.20.1
If not run this command to update flutter to the latest version
flutter upgrade
This template uses derry as it's script manager.
Run this command to setup derry
dart pub global activate derry
Most of the scripts we will use are abstracted away by derry. If you want to know more about the scirpts, read the scripts documentation.
flutter pub get
derry generate all
You can skip this step if you just want to get the template running. If you skip this step, the weather search will not give you any results.
Sensitive information like api keys, credentials, etc should not be checked into git repos, especially public ones. To keep such data safe the template uses .env files. Each Flavor uses it's own .env file.
The tempalte uses weather api from openweathermap.org.
You can get your Open Weather API key from here.
Once you have the key, update the .env files with your api key. Replace YOUR_API_KEY with the key that you got from open weather api.
OPEN_WEATHER_API_KEY=YOUR_API_KEY
OPEN_WEATHER_BASE_URL=https://api.openweathermap.org/
With the setup done, we can get the app running.
The template comes with built-in support for 3 flavors. Each flavor has it's own .env file.
You can setup any environment specific values in the respective .env files.
To launch the app run the following command and specify the flavor name.
derry launch dev
On android studio, you will find pre defined run configurations.
Select a flavor from the dropdown
Select a device to launch on
Click Run to launch the app
The architecture of the template facilitates separation of concerns and avoids tight coupling between it's various layers. The goal is to have the ability to make changes to individual layers without affecting the entire app. This architecture is an adaptation of concepts from The Clean Architecture.
The architecture is separated into the following layers
lib/presentation: All UI and state management elements like widgets, pages and view models.lib/navigation: navigators to navigate between destinations.lib/interactor: provides feature specific functionality.lib/domain: use cases for individual pieces of work.lib/repository: repositories to manage various data sources.lib/services: services provide access to external elements such as databases, apis, etc.Each layer has a di directory to manage Dependency Injection for that layer.
The layers presentation, domain and services each have an entity directory.
lib/presentation/entity: Classes that model the visual elements used by the widgets.lib/domain/entity: Model classes for performing business logic manipulations. They act as an abstraction to hide the local and remote data models.lib/services/entity: Contains local models (data classes for the database) and remote models (data classes for the api).UI (eg: UICity).Local (eg: LocalCity).Remote (eg: RemoteCity).Apart from the main layers, the template has
lib/foundation: Extensions on primitive data types, loggers, global type alias etc.lib/flavors: Flavor i.e. Environment related classes.lib/app.dart: App initialization code.The presentation layer houses all the visual components and state management logic.
The base directory has all the reusable and common elements used as building blocks for the UI like common widgets, app theme data, exceptions, base view models etc.
State Management is done using the riverpod along with state_notifier. The class that manages state is called the View Model.
Each View Model is a subclass of the BaseViewModel. The BaseViewModel is a StateNotifier of ScreenState. Along with the ScreenState it also exposes a stream of Effect.
Implementations of the BaseViewModel can also choose to handle Intents.
ScreenState encapsulates all the state required by a Page. State is any data that represents the current situation of a Page.
For example, the HomeScreenState holds the state required by the HomePage.
Effects are events that take place on a page that are not part of the state of the screen. These usually deal with UI elements that are not part of the widget tree.
Showing a snackbar or hiding the keyboard are examples of an effect.
Intent is any action that takes place on a page. It may or may not be user initiated.
SearchScreenIntent has the actions that can happen on the SearchPage.
A page is a widget that the navigator can navigate to. It should return the BasePage widget.
The BasePage creates the structure for the page, initialises the ViewModel and provides the view model in the widget tree so that all the children have access to it. It also listens to the effects from the view model and notifies the page about it.
Each page accepts the Screen object as input.
Each destination has a widgets directory. It holds all the widgets that appear on a Page excluding the page itself.
Each widget the requires access to data from the view model it split into two dart files. The connector widget communicates with the view model, and the content widget has the actual UI. The connector widget passes all the required data to the content widget. Thus the content widget never depends on the state managent solution used. This helps in easy replacement of state management solution if needed and also makes it easier to test widgets.
A Screen is a class that represents a Page in the context of navigation. It holds the path used by the navigator to navigate to a Page and also holds any arguments required to navigate to that Page.
As you can read from the Architecture section, adding a new page in the app can require a lot of files to be created. The template uses mason as it's templating engine to automate some of this work.
To get started with mason, first activate mason globally
dart pub global activate mason_cli
Similar to using pub get we need to run mason get to setup the bricks (templates are called brick in mason).
mason get
You can learn more about mason here.
The template comes with a pre setup brick called destination.
Run the destination brick using the following command.
mason make destination -o lib/presentation/destinations/notes --name notesList
-o flag sets the output directory for the brick and --name is the name used for the files and classes. This brick generates the required file structure and runs build_runner (via mason hooks) to trigger code generation. After running the command, this is what you should see:
The template also includes a testing setup for
The test coverage and code quality reporting is done usin
Selected from shared topics, language and repository description—not editorial ratings.
ZamariThomas /
🚀 Kickstart your Flutter projects with a production-ready template that implements clean architecture, BLoC, and robust authentication features.