Web version is available at https://orion-1.web.app
maincurrently only
WeatherServiceThemedAppWidget- instantiateMaterialAppwith default material3ThemeData
DefaultTabControllerScaffold⤴ - a child ofThemedAppWidgetthat adds aDefaultTabControllerto the widget tree with 3 tabs(screens) -PrecipitationWidget⤴ - a screen that shows precipitation data (bar chart) -MinMaxTemperatureWidget⤴ - a screen that shows min/max temperature data (line chart) -WindroseWidget⤴ - a screen that shows windrose data (radar chart)
The screens have the similar structure:
ViewModelProvider⤴ -
a widget that provides (with ChangeNotifierProvider) a view model (a subclass of
ChangeNotifier) to the widget tree.
Consumer⤴ -
a widget that listens to the view model and rebuilds its child widgets when the view model changes.
View models expose an instance of
Resource⤴ class that identifies the state of data: Loading, Success, Error.
switch⤴
among the resource states:
-
Loading⤴ -
show a loading indicator
-
Error⤴ -
show an error message
-
Success⤴ -
show the auxiliary widget, responsible to convert domain data to chart data.
- Chart-specific widget⤴
lib⤴:
main.dart⤴: the entry point of the applicationdi.dart⤴:MultiProviderconfiguration withWhetherServicedependencyca⤴: stands forClean Architecture- non-UI code.repositories⤴: assumed to implement caching, unifying data representation from different sources and effective data fetching.currently only
WeatherRepository⤴ andMeasurementModel⤴ are implemented.weather/datasources⤴: contains sources of raw data responsible for fetching data from different sources (e.g. REST API, local storage, etc.) and converting it to a unified data model.
domain⤴: business logic, manipulating data received from repositories and converting data models to domain entities.
presentation: UI-related code.scaffolds⤴: top-level widgets for the different features of the application. Currently onlyDefaultTabControllerScaffoldis implemented because the application has only 1 feature.screens⤴: widgets that represent the top-level (having not back button) screens of the feature. Currently onlyPrecipitationWidget,MinMaxTemperatureWidget,WindroseWidgetare implemented.widgets⤴: widgets that are used in the screens (views).viewmodels⤴: view models( ChangeNotifiers) that are used in the screens.
The data provided by the view models are wrapped into
Resource⤴ class that identifies the state of data: Loading, Success, Error. This way the UI can react to the states and be sure about their availability.theme: currently unmodified theme data suggested by default flutter project.
math⤴: contains helper functions for mathematical operations (calculates "good" numbers⤴ of ticks for the charts).
For the demo purposes the http client is mocked with
AssetClient⤴
implementation that reads the data from the
json file⤴ from the assets folder and uses it as a
seed for the random data generation (assuming each next day has a bit of
different⤴
measurements from the previous).
For the sake of testability and reproducibility, the fixed random generator instance is used whenever the random data
is needed. The seeds for the random generators are set in
di.dart⤴
file.
Few tests are located in the test⤴ folder.
The project is set up with GitHub Actions⤴ to build⤴ and deploy⤴ web target for the quick reviews. The workflow is set up to be triggered manually⤴.
- Assumed per-day aggregation(sum) of the precipitation data. Is it correct?
- The speed of wind is assumed to be ignored on the wind diagram. Is it correct?
- I assume the data can be missing for some days/hours. Is it correct?
- The ChangeNotifier is used for the view models. Is it an expected implementation? Should we discuss the alternatives?
- The ViewModels are instantiated as close to the views as possible. Alternatively,
they can be instantiated in the
AppDependenciesProviderand provided to the views. Should we discuss this? - I want to add the "Refresh" button to the screens and "Polling mode" to automatically refresh the data. Can 1 work day be approved for this?
- I want to add the reactive source of the data (e.g., WebSocket). Does it make sense?
- The task assumes up to 7 days of data, but the sample JSON suggests the data for 1 day. I generate the data for the next days — is it acceptable?
- I believe that grouping and aggregation can be performed more effectively on the server side rather than on the application level. Does the team agree?
-
ViewModels/Data:
- Days of the week are completely erased, they should be kept and shown.
-
Theming:
- Colors are hardcoded
-
Bar chart:
- The left and right padding should be removed from the painter area.
- The paddings should be added to the container.
- Top labels seem to be cut off by 1px.
- Labels (days of the week) at the bottom should be added.
- Hardcoded text style should be replaced with the theme.
-
Line chart:
- Min/max should have different colors.
- Grid lines should be labeled.
- Measurements should be labeled.
-
Windrose:
-
Wrong scale of the wind vertices. The vertices are too small.
-
Circles' color should be brighter.
-
WE & WS labels are wrongly placed.
-
Polygon is not filled correctly.
-
Others:
-
"Nice numbers" are too naive, tend to be bigger than needed, should be improved.
-
Android doesn't obey safe area insets.