Learning Flutter - Part 5 - Building out the UI and Incurring Technical Debt

In my last post, I wrote about the Provider class to separate presentation logic from other "business" logic.

My next step was to build out a UI to allow the user to select a vehicle make and model. At this point, I was only building broad categories (car, truck, motorcycle) and got familiar with gridlines and the various properties of common widgets to build UI:

Building the UI is where hot reload, Dart DevTools, and the screen painting functions (see the 2nd image above) really help. It is really quite quick to change a parameter and see the UI change almost immediately. It took me longer to look for data on vehicles (images, fuel efficiency, wear-and-tear cost estimates) - for the v1 it may be that I only get some basic 'generic' vehicle types like the above.

I also started playing with some icon designs - a few iterations thus far but nothing that looks at all good:

In this process, I've built up some technical debt:

• Magic numbers/strings within the code (though for UI/layout type items, some of these might be acceptable, for text strings they definitely are not); separating text strings is important both for maintainability and for internationalization
• Repetition of certain aspects of code (e.g. purple background colours); repetition makes code more difficult to change, for example when adding support for Dark Mode
• No unit tests or project tests

That said, given the project is quite young, having a bit of technical debt is not terrible and not surprising. Particularly as I'm just starting to work on the UI code, my process is to get it working then get it clean. Some of the technical debt is really just unimplemented features (e.g. the code does not yet support switching between metric and imperial units).

Avoiding too much technical debt is important - if you don't then you'll end up with something that isn't robust and that you can't change without spending (wasting) too much time cleaning up impacts of changes where the impacts really should be isolated.

Looking at the plan, I've made some progress - still lots to do and to learn!

• 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
• 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