dart run build_runner build --delete-conflicting-outputs
Running unit tests by flutter test and integration tests flutter test integration_test
ensure you have a device connected and run flutter run lib/entrypoint/main.dart
The layer that has most of the work since our app has the most complex functionalities in its UI, e.g. navigation, filtration, searching, multiple views, etc.
Contains Bloc state management, the built-in navigation solution from Flutter sdk, and our UI.
The layer in which specifies the domain of the app, but in our app has almost no business logic, but our entities serve as our own data models.
Contains Entities, Interactors (Use Cases), Gateways (Repositories).
The layer in which has technical details in fetching and mapping the data.
Contains Retrofit & Dio, Repository implementations, and mappers.
The DI solution used in the project is by using get-it service locator.
The State management solution used in the project is Bloc state management.
Found under the test folder, contains plain dart tests and UI widget tests.
Found under the integration_test folder, contains tests of the domain + data layer altogether.
I'm fetching articles remotely from the NY times API, and the filters (sections) locally as documented in the API docs.
I currently have the API key hard-coded, the best practices normally save those kind of keys locally on the developers machine and obfuscating the release builds, but for the sake of public usability I won't be hiding the key from the version control.
I normally unit test every every unit containing logic, but the domain and data layers had only routing/mapping logic, so I've written an integration which test both layers. No need for unit testing empty units.
If the UI component has no logic, I integrate test it with other components. For example: the ArticleGridItem and ArticleListItem are tested by widget testing their wrappers: ArticleListsToggler.
The states of the bloc are designed in a way that satisfy an initial full fetch (articles and sections; full page), and then other smaller fetches (filtered articles only).
I have kept everything as simple as possible, and separated as much units with their single responsibility as possible.
Since the NY times API does not provide a way to filter by string query parameter, I've implemented the search functionality locally.
The Error and empty handling are implemented using the LayoutError & LayoutEmpty, and LayoutError contains a retry button.