This application provides a succinct interface for recording vehicle mileage and reporting metrics such as fuel efficiency.
- Add/view/edit/delete vehicles
- Add/view/edit/delete mileage records
- Add/view/delete mileage attachments
- Notify the user if location accuracy is poor or unavailable.
- Compute and display average MPG in the vehicle UI.
- Compute and display price per gallon in the mileage UI.
- Display a list of vehicles on the home screen.
- Display mileage records in descending order on the vehicle screen.
- Render mileage records to indicate their non-exported status.
- Export mileage records.
- Maintainable application architecture utilizing Android best practices and recommendations.
- Version-controlled source code using Git.
- Public GitHub repository licensed under GPLv3.
- Test-driven development of the data layer, including integration tests for CRUD and ViewModel state holders, and unit tests for core business logic (e.g., average MPG calculation).
- Publish on the Play Store with a modest convenience fee.
- Android application written in Kotlin.
- Minimum SDK: Android 8.1 (API 27).
- Room (SQLite abstraction) for local persistence.
- Jetpack Compose for UI.
Timestamps are stored an UTC ISO-8601 Instant and further converted to LocalDate for display in the UI.
Location data for mileage logs are persisted in a related table mileage_location assisted by Android’s ~LocationManager~ which provides access to system location services, which returns a ~Location~ object fit for our table.
Forgoing time inclusion is a deliberate choice due in part of the fact that according the documentation, “no guarantee that different locations have times set from the same clock… providers may use any clock to set their time…”. Majorly, **location settings are an elective feature and not required** for the application to function.
All attachments are stored in shared storage and therefore accessable by other apps and **not deleted** when the app is uninstalled.
Photo picker provides a browsable interface for the user to select an image from their device, using ~PickVisualMedia~ to select a single media item.
Once the image has been selected, a copy is made to <ATTACHMENT LOCATION>> and its filepath is persisted in its respective vehicle_attachment or mileage_attachment table.
CameraX and its ~ImageCapture~ method. See codepen
Whether an vehicle or mileage attachment is identified using the photo picker or image capture methods, the resulting file’s URI is persisted the vehicle_attachment or mile_attachment tables. When the app needs to display either type of attachment, it’s just a matter of retrieving the image from the app-specific media store using direct file paths and the ~MediaStore~ API.
An acceptable location accuracy threshold (meters via Location.getAccuracy()) will be defined, and validation will be implemented to flag records that exceed the threshold.
According to the ~Location~ docs, horizontal accuracy radius is measured in float meters with a 68% chance the location is within that radius.
How small does our radius need to be, while residing outside of it ~30% of the time, for any system to infer which business a fuel-up occured at? Pretty far if we’re on our way to El Paso, but not so if we’re in town at the intersection of 2 or more stations…
In any case, location accuracy is included in the mileage_location record, and the threshold is implemented in the business logic and not enforced at the data layer.
The application queries the vehicle’s last 10 mileage records and computes average miles per gallon by dividing total miles driven by total gallons pumped. This is implemented in VehicleDAO.selectAverageMilesPerGallonLNR and exposed via VehicleRepository.getAverageMPG. Non-full-tank records are included as-is and Vehicle.isFullTank is retained as metadata, leaving options open for adjusting the algorithm.
The user taps the export button on the vehicle screen, selects either the latest (non-exported) records or a custom date range, and chooses CSV or JSON format. The application delegates export handling to a system activity (e.g., email, SMS). If all is successful, each record’s isExported flag is set to true.
Exports are requested via form employing conditionally rendered fields.
Initially, this is a device-local, single-user application. Migration to centralized cloud storage would improve data durability across device changes and data loss scenarios.
Currently, the application cannot determine the business where a fill-up occurred. Potential enhancements include:
- With the latitude/longitude and timestamp of the mileage record, the system could resolve the business against a public dataset.
- Using Optical Character Recognition (OCR) and AI to extract business information from receipt images.
Provide an option to export formatted PDF reports for either the latest (non-exported) mileage records or a custom date range. See Chore Buddy for implementation reference.