- Android
- iOS (Not confirmed)
- Aquire an OpenWeatherMap API Key - I will provide mine in the email
- Create a .env file in the root directory by renaming
example.envto.envand update the value to reflect the API key from OpenWeatherMap - Run the following commands to update project with the required environment variables:
dart run build_runner clean
dart run build_runner build --delete-conflicting-outputs
- To run the tests run
flutter test
- DO NOT USE ChatGPT for code generation
- DO NOT USE FlutterFlow for UI generation
- No no-third parties JSON parsers or HTTP clients (such as json_serializable), just pure vanilla Dart Development, You are allowed to use Dart’s own dart:convert
- Third-party dependencies through pub.dev can be used for cross-cutting concerns (such as logging, linting, dependency injection) and platform resources access (such as location and contact services) not for functional or UI components.
- No freezed
- No riverpod
- No HookConsumerWidget
- Preferably the project has to be in Dart with null safety, If you use a dependency not supporting null safety, please state which one and why?
- Please do not perform dependency override
- The architectures options are: Bloc, Cubit and Provider + ChangeNotifier/StateNotifier
- If you use Bloc or Cubit as your architecture, please use flutter_bloc or your custom solution
- Please provide a comprehensive ReadME which contains:
- Conventions, architecture, and general considerations
- Exhaustive list of third-parties alongside their respective purposes
- How to build the project
- Any additional notes that can demonstrate your knowledge
- 7 Days to complete
-
Please upload the complete solution to a Git repository hosted on either GitHub, Bitbucket or GitLab.
-
Send through a public link to the solution and a downloadable app file
The Architecture I went with was a variation of MVVM minus the ViewModel. All the business logic (In theory) should be sitting in the repositories. All the repositories do the calling of API's such as OpenWeatherMap and the Location API's.
The screens mostly focus on simply rendering the data received.
Release Dependencies: provider: Used to create Objects such as the repositories and have the widgets react based on actions within the objects. Example: When an API call is done, notify all Consumers of the Provided Object that a change has happened http: Basic networking library envied: Used to retrieve variables from .env files google_fonts: To render the Roboto font. I am guessing thats the font used in the screenshots provided location: Used to retrieve the devices location
Dev Dependencies: envied_generator: Used to generate the classes for the envied library mocktail: Used to mock objects for testing purposes golden_toolkit: Used to generate screenshots or snapshots of widgets or screens in order to do pixel by pixel testing See test/home/goldens
- I wanted to implement better error handling. I started implementing it for the location errors but didn't have enough time to complete that
- I wanted to improve the visual aspect of a loading indicator
- I made some changes to the colours given in the documentation due to the fact that it didnt quite match up to the style of the image (for the sunny screenshot)
- I have implemented GitHub actions which will run the tests and then build the app. It won't build the app if any of the tests have failed.
- When a change is made on the 'Release' branch. A github Action is executed which builds that APK and publishes it to the Releases page of the repo. You are able to download the files from there.
- There is a known bug that crashes the app because the android system for location has not been enabled by the time it gets here Note: This only happened when running the app in release mode (-_-) See: https://stackoverflow.com/questions/67663357/flutter-location-package-generates-platform-exception-on-call-to-serviceenabled Affected File: https://github.com/stillie/weather-app/blob/main/lib/location/location.dart