Personal Reflections: Learning Flutter - Part 6

In my last post, I wrote about building a UI and technical debt.

The next step was to work though several parts of the functionality. In doing so, I realized that the styling I'd done did not make sense and reverted to mostly default background colours (i.e. white background) and will implement the use of the dark theme at a later time.

While I still have quite a bit of technical debt in the project, I've refactored some of the code as I've gone thorough and removed some duplication but magic numbers and strings still abound. The ability to hot reload is really great for testing, making the testing cycle so much faster.

In the last couple weeks I've also read The Phoenix Project, The Unicorn Project, and completed a course on DevSecOps. It is quite clear to me that CI/CD is a much superior model. The linkage of both books to the Lean Six Sigma process management disciplines provided a good number of useful insights.

In terms of using a DevOps approach for this Flutter project, I've not setup much in the way of developer tools nor written any unit testing. It makes sense to finish this small project first then look more into and test out a better approach (in other words, not bite off too much at once).

Back to the Learning Flutter project, more is implemented but the design still looks fairly terrible:

Selecting vehicles that are not 'average' which will require:

UI to select a vehicle make and model [DONE]
Vehicle data (icon image, fuel efficiency, wear-and-tear cost estimates) [STARTED ON BASIC 'GENERIC' TYPES]
Code within the model to use the parameters [USING SOME OF THEM, STILL MANY TODOs IN THE CODE - which, the Dart compiler helpfully gives warnings about]

Selecting and saving parameters such as metric vs imperial

UI to select parameters [DONE]
Ability to save parameters between runs of the app
~~Code within the model to respond to parameters (e.g. by displaying metric)~~ [THIS IS REALLY A REPEAT OF THE 3rd SUB-BULLET ABOVE]
Ability to pull defaults based on location (for imperial/metric, local fuel prices)

Support for 'trips'

Building a UI to start and stop trips [DONE]
Updating the model to enable starting and stopping the GPS [DONE]
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)~~ [DECIDED THAT INTERRUPTING A USER WHILE DRIVING IS NOT LIKELY A GOOD IDEA]