My next step was to pull the GPS code into the prototype I'd made in part two of this series. To do so required understanding how to manage state within Flutter apps. Fortunately, Flutter.dev's section on state management is pretty well explained and the talk from Google I /O '19 on Pragmatic State Management in Flutter was helpful as well. As both of them recommended the Provider approach, that's the approach I chose.
Implementing Provider required (in addition to adding Provider as an import):
- Building a class to hold the GPS data and route data separate from the UI as a class that extends ChangeNotifier
- Putting a ChangeNotifierProvider at the top of the widget tree in main.dart
- Adding a Consumer in the builder that builds the distance display in the UI
None of the points above were too difficult.
Once I'd connected the pieces, I needed to link up the points to calculate distances (which worked but only in production - not in testing - see the next paragraph). Once I could calculate distances, I needed to hard-code some parameters into the model to calculate fuel use, fuel cost, wear and tear cost, and carbon footprint.
In building the model class (that held the GPS and route data) I tried to build a unit test. Unfortunately that did not work so well as the locationprovider package uses platform implementation to implement the distanceBetween method. So my unit tests were failing given that when I called them, the platform GPS had not been initialized. The code itself worked but the test cases did not. I did learn something about how the unit test framework in Flutter works though, which was useful.
I also added a FloatingActionButton to reset the trip to zero. What the project looks like thus far is below:
At this point, I'd say that I have an alpha version. The core functionality is there but it needs a lot of work and polish to enable use in a variety of circumstances (e.g. by selecting vehicles that are not average, to automatically decide on metric vs imperial and let the user change that, to allow for stopping and starting separate trips, and by persisting these data points). The UI also needs to look nicer and work on a variety of screen sizes. I'll also want to enable alerts to the user (as the app will normally be in the background) to tell the user when they've spent a particular amount of money (total or in gas costs).
To break the work up into bits of functionality to add:
- Selecting vehicles that are not 'average' which will require:
- UI to select a vehicle make and model
- Vehicle data (icon image, fuel efficiency, wear-and-tear cost estimates)
- Code within the model to use the parameters
- Selecting and saving parameters such as metric vs imperial
- UI to select parameters
- Ability to save parameters between runs of the app
- Code within the model to respond to parameters (e.g. by displaying metric)
- Ability to pull defaults based on location (for imperial/metric, local fuel prices)
- Support for 'trips'
- Building a UI to start and stop trips
- Updating the model to enable starting and stopping the GPS
- Persisting trips to the phone
- Viewing past trip data and total data
- Support for user alerts (as the app will normally be in the background)
- When the user has forgotten to turn the trip recording off (could be fancy AI but likely if the speed has just been low enough for long enough)
- Alerts based on cost parameters (e.g. every dollar of fuel cost or after 25 liters -- when you might need to refuel)
- Changes to the UI to make it look nicer and to adapt to various sized phones
- Unit tests to help keep the project relatively bug free
Eventually it might make sense to put a server back-end of the app but I don't think that would be in the v1.0 - not that a back-end would not be useful (you could see stats/cost online and not lose data when you upgrade your phone) but I think it will be a useful app without server functionality.
No comments:
Post a Comment