About the artifact
For this enhancement, I continued building on the same Mere Metrics: Weight Tracker project I had been refining throughout the capstone. This is the Java Android app I originally created in a mobile architecture and programming course, developed in Android Studio. In the software engineering enhancement, I improved the structure of the app by refactoring it into clearer layers and replacing the manual history table with a RecyclerView-based design. In the algorithms enhancement, I expanded the application with analytics and insights based on the user’s saved weight history.
For this enhancement, I focused on the databases category by redesigning the persistence layer behind the app. The earlier version of the project stored data through a helper-based SQLite design. In this enhancement, I replaced that with a Room-based database structure that uses entities, DAOs, an @Database class, and explicit migration logic. The app now saves users, goal weights, daily weight entries, and SMS-related user settings through the Room layer. I also added migration support so older stored data can be upgraded into the newer database design instead of being lost during version changes.
Why I included this artifact
I selected this artifact again because it already had meaningful stored data and real user workflows, which made it a strong choice for a database enhancement. The app stores user accounts, goal weights, daily weight history, and SMS-related settings, so it gave me a practical starting point for improving schema design, data integrity, query behavior, and upgrade safety.
I improved the artifact by introducing a Room database with a clearer persistence structure built around UserEntity, GoalWeightEntity, DailyWeightEntity, and UserSettingsEntity. I also added DAOs for each of those areas and centralized database access through AppDatabase and AppDatabaseProvider. The app now uses explicit 2→3 and 3→4 migrations so older data can carry over into the current schema instead of relying on the older destructive upgrade behavior.
Another important improvement was converting stored weight dates from the earlier MM/dd/yyyy format into ISO yyyy-MM-dd storage inside the database. This lets the app sort and filter weight data more reliably at the query level while still showing dates to the user in the same familiar screen format. I also strengthened integrity rules in the schema by using foreign keys to connect goals, daily weights, and settings back to the owning user, and by enforcing a unique (user_id, entry_date) rule for daily weights so the app stores one daily weight record per user per date. During migration, older same-day duplicate rows are cleaned up before that rule is applied so the upgraded database stays consistent.
I also moved SMS settings and goal-notification state into a Room-backed UserSettings model and supported older preference-based values through a one-time legacy import path. That improvement made the persistence layer more consistent while still preserving older saved app data. Overall, this enhancement shows relational schema design, DAO and query design, migration planning, legacy data handling, and stronger data integrity in a real application.
Course outcomes alignment
This enhancement most directly supports course outcomes 4 and 5 and also supports outcomes 2 and 3. It supports outcome 4 because I used current tools and techniques to create a better persistence layer that adds practical value to the app, especially Room entities, DAO-based access, explicit migrations, and database-backed filtering. It supports outcome 5 because the enhancement improves the integrity and safety of stored data through foreign keys, unique constraints, normalized date storage, and migration logic that preserves user data during upgrades instead of deleting it. It supports outcome 3 because I had to evaluate trade-offs in how the database should be redesigned without breaking the features that already depended on stored users, goals, settings, and weight history. It also supports outcome 2 because I’m clearly explaining the enhancement, the design decisions behind the database changes, and the reasoning for those changes in this narrative and the rest of the supporting materials.
I don’t have any major changes to my overall outcome coverage plan, but this enhancement gave me a clearer and more concrete way to show the database-focused outcomes I originally identified in my initial enhancement plan.
Reflections on the enhancement process
Through this enhancement, I learned that database work in an application isn’t just about moving data into new tables. It also takes careful thinking about schema design, query behavior, migration safety, and how the rest of the app depends on the stored data underneath the user interface. One of the biggest things I learned was seeing how much stronger the app became once the persistence layer was built through Room entities, DAOs, and explicit migrations instead of the earlier helper-based approach.
One of the biggest challenges I faced was making the enhancement work for both fresh installs and upgraded users. I didn’t want the database redesign to only work on a brand-new app state. Because of that, I added migration logic and tests that seed older database states and then verify that users, goals, daily weights, and settings still carry over correctly after migration.
Another challenge was changing date storage in a way that improved ordering and filtering inside the database without changing how the dates are shown in the user interface. I also had to decide how to enforce integrity for daily weight entries, and I chose to structure the database around one daily weight record per user per date. That decision worked well with the app’s existing daily tracking design, but it also required handling older duplicate same-day rows during migration so the new schema could be applied safely.
I also learned that backend changes need to support existing features instead of forcing a complete rewrite of the app. The insights and analytics features were already in place before this enhancement, so the database enhancement needed to improve the persistence layer underneath them without changing the overall user-facing structure of the app. Working through those problems gave me more confidence in database schema design, migration planning, persistence testing, and using a more modern Android data layer in a way that still fits an existing project.
Overall, this enhancement strengthened the app by giving it a more modern, better-structured, and more reliable persistence foundation while keeping the application cohesive across all three enhancements.