Daily Updates

October 7, 2024

I had my first committee meeting with both my primary and secondary advisor. It went alright; I was on track to finishing my Capstone on time. Apart from asking some questions about my project, my advisors encouraged me to publish my app on the Play Store during the Winter Break (mid-December).

The reason for this is two-fold: I'm assessed for impact (i.e. how many people have used the app?) and it's objectively easier to share a Play Store link than to set up USB debugging for my friends who are willing to be beta testers.

I'm not sure how I feel about this. This compresses my timeline by a lot—I have to finish most of my features by Week 8 - 10 in time for the Play Store submission—and it's stressful to think about. I'll see how much I can get done next week and re-evaluate progress in relation to this new goal.

(I also haven't submitted my PhD application :'))) help)

October 8, 2024

I attended a Shut Up & Write session in San Francisco's Richmond neighborhood and used the session to work on the Methodology section of my writeup. At the end of one and a half hours, I was able to finish justifying my technical choices:

• Developing only for Android
• Using Samsung Galaxy Watch 6
• Use of HealthConnect API (as opposed to lower-level APIs like WearOS)
• Use of React Native for development

I'm still left with:

• Explaining my Project Management Approach

  1. Agile Methodology: Working in weekly sprints, reflecting on each day's progress, and having retrospectives in the form of weekly reflections (like the one you're reading now!)
  2. Time-blocking and Communal Suffering: Blocking out 3 hours on Mondays, Wednesdays, and Fridays to work on my project; co-working with classmates and also strangers at Shut Up & Write
  3. Weekly Reflections: Reflecting on what worked, what didn't, and noting down the technical things I learned so I can reference them in the future.

• Explaining my Developmental Approach

  1. Delayed Prettification (as described in Week 2)

  2. Re-prioritizing Features on a Weekly Basis: The sudden move from Berlin to San Francisco threw me off track

  3. Retrospective Accounting for Edge Cases (see explanation here)

October 9, 2024

In ~1.5 hours, I managed to get the filtering function for menstrual symptoms working. However, I realized that something was funky with my database migrations; it was throwing an error that said my database tables had already been created, even when I'd done a fresh install of the app.

What was supposed to be a 3-hour work block eventually turned into a 5.5-hour one. If you're interested in the technical drama, check out technical learnings.

October 11, 2024

I was supposed to work on this day, but I screwed up one of my assignments and had to redo in time for re-submission to my professor.

What's left before merging kyurikotpq/self-report to main:

• Save selected symptoms to the database upon clicking the save button.
• Load selected symptoms for the specified day (Save button should be disabled unless changes were made)
• Display a list of the user's cycle history (starting with the cycle they're currently in, if indicated during onboarding) and allow edits or deletion to the cycle.

What worked?

I'm honestly unsure if anything worked this week apart from the Shut Up & Write session. Perhaps it's the stress of the semester catching up to me and making me very self-critical.

What didn't work, and what can I do better?

I think I could've done my debugging a little more systematically instead of uninstalling it 10 times in disbelief. This experience has revealed how much of an emotional coder I am; next time, I will take a break at the 5th uninstall so that I can tackle the issue with fresher eyes.

Technical Learnings

The error first showed up when I tried to initialize the database. I un-installed my app 10 times, trying a different setting each time to see if Drizzle Kit (the package I'm using for my database migrations) was the issue. At the 11th uninstall, I installed Drizzle Studio to examine my database and confirmed that my database persisted across un-installations.

That led me to a StackOverflow post on the allowBackup attribute in AndroidManifest.xml. By default, this attribute is set to true, and that causes the database to be persisted across uninstalls. Setting it to false finally resolved my issue—but not before burning an additional 2 hours of my time.