Adding Grouping, 'Taken At' & some general improvements

[numericOverflow]

Hey @Futsch1 - I've coded up some changes to make some general quality-of-life improvements. I leaned on Claude for the actual coding, but I made the architecture decisions, bigger picture plan, and kept it from running amok.

FWIW, I've been using MyTherapy App daily for several years of med tracking and would really like to transition to this open-source project where users have actual control over their data & who can('t) access it.

I'd love to help with some of the work to make it a more user-friendly app. I think it's got a ton of great features and work, but could use some polish to simplify the workflow a bit to reduce the cognitive load on users.

I have a slug of PRs out there to push these changes, but can re-org them however you prefer merging them. I'm also open to feedback.

</humanGenerated>

Now for the AI generated overview of all the changes...:

Proposed Overview and reminder improvements for MedTimer

Hi, I am numericOverflow. I use MedTimer every day with several medicines that are due at the same time, and over a few weeks I collected a list of small things that made that daily routine slower or confusing, plus three real bugs. I built the changes with Claude Code, reviewed every change myself, and tested them on my own phones (including a spare Android 10 device for the Alarm settings crash). I know you did not ask for any of this, so I split everything into small, separate pull requests: you can accept, reshape or decline each one on its own, and nothing depends on you taking all of it.

What changes for users

All screenshots use synthetic test data only.

Same-time doses show as one block

Doses due at the same reminder time share one time header and one card in the Overview list, so a morning routine reads as one block; a single dose looks as it does today, and the card is a little lighter in dark theme. A new Display setting, "Group entries by reminder time in overview", turns it off. Relates to issue 1696.

Confirm all and a group menu

Each group header gets a "Confirm all" button that marks all still-open doses of that time as taken, and a menu with the actions that all doses in the group share (the same set as the selection bar). A group where everything is already logged shows neither. Relates to issue 1451.

Taken at, with a time-only picker

A new "Taken at..." action, next to "Taken", records the time you really took a dose, for one dose or a whole selection, with a picker that asks only for the time and offers "Change date" for another day (future times are rejected). A new Display setting, "Default taken time", chooses whether plain "Taken" records the time of logging (today's behavior, the default) or the scheduled time (never later than now). Relates to issues 1406 and 1232.

Resolved section

Groups where every dose is taken or skipped move into a collapsed "Resolved" section at the bottom of the day (it opens by itself when nothing is open or when you filter for taken or skipped), and in a partly done group the finished rows sit dimmed at its bottom. The section exists only while Overview grouping is on, so turning that one switch off brings back today's list exactly.

Filter label and a setting to hide the filters

The four status filter icons get a small "Filter" caption cut into their outline, like a Material outlined text field, so they no longer read like a legend. The caption reuses the existing translated "Filter" string. Separately, a Display setting "Show status filters" (on by default) hides the row for people who never use it; hiding it also clears any active filter, so no dose stays hidden by accident.

Reminder edits apply to today

Today, changing a reminder's time or amount, or a medicine's name, only affects future days, so the dose already showing today keeps the old values. With this change, open doses due today or later follow the edit and a showing notification updates without a new sound, while taken or skipped doses, earlier days and doses moved with Reschedule keep their time. All rules live in one JVM-tested file, and this may fix issue 1778.

Alarm settings no longer crash on Android 9 to 11

Opening Settings > Alarm settings crashes on Android 9, 10 and 11 (API 28 to 30) in v1.26.1. The ringtone preference used a call that only exists from Android 12. The fix uses the AndroidX helper instead and has a Robolectric test for SDK 28 to 30.

Combine notifications moves to Notification settings

The existing "Combine same time notifications" switch only changes notifications, but it sits in Display settings. It moves to Notification and reminder settings. Its key, default, text and every translation stay exactly as they are, so existing choices and backups keep working.

Two further PRs have no user-visible change: one fixes drift between AGENTS.md, the guidelines and the build files (D), and one gives debug builds their own application ID, com.futsch1.medtimer.debug, so they install beside the store app (K). Release names stay unchanged.

[numericOverflow]

Grouping by time in overview

Split the settings so we have separate "Combine Notification" and "Group Entries" settings

Adding a "Taken At..." instead of always current_timestamp

Adding a "resolved" section to focus only on remaining tasks

[Futsch1]

First of all: Thanks a lot for your contribution and the ideas you proposed! Very much appreciated.

Initial thoughts (but I will have to look at it more closely):

• Really like the grouping by time - would recommend to have it enabled by default
• I would not add "Taken at", since it increases complexity from my point of view. You can always select "Taken" and edit the taken time afterwards if this is important for you.
• The resolved section interferes with the filters from my point of view. I think we should either rework the filters or add the option to split the reminders in four sections and remove the filters.

[Amethice]

Big +1 for group by time - I similarly have a number of meds I take on certain longer intervals, and getting barraged by a half dozen or more notifications that I then need to confirm as taken individually, or snooze individually, or whatever just becomes a big hassle where back when I used other apps I could just do a "taken all" if I did, or open the app and select specific ones to exclude for the few times that was needed.

[numericOverflow]

@Futsch1

First of all: Thanks a lot for your contribution and the ideas you proposed! Very much appreciated.

Initial thoughts (but I will have to look at it more closely):

• Really like the grouping by time - would recommend to have it enabled by default

I 100% agree, group by default is a big improvement, but I didn't want to be too forward and completely change look w/out your input. :) I'll make it default for all.

---

• I would not add "Taken at", since it increases complexity from my point of view. You can always select "Taken" and edit the taken time afterwards if this is important for you.

Here's my major use case for dedicated "Taken at" function

• Some meds it's very important to track exactly when they were taken
• I often don't have a phone near when taking meds, I'll log it later.
• Some people just really like accurate historical data.
• I don't use it but I would assume your level/half-life calcs section needs accurate data to work properly
• Taken at time has major implications for any of the Interval reminders where "Interval starts when taken or skipped" picked
• When you have multiple/many meds that you need to track taken time, it's a massive burden without it. Here's a sanitized but real example for me:

Example test data if you want to play with it:
MedTimer_Backup_20261023_080000.json

MedTimer_example_meds_taken_at.mp4

• IMHO, the logging workflow should take absolute minimal friction possible otherwise people won't do it (new users) or tend to get annoyed while doing if it takes too many steps (myself in this case).

My personal, ideal UI/UX rules (unofficial):

Very common or default workflows should be:

• easy to do
• ideally quick to complete
• easy to *understand* the task with a glance & minimal thinking
• but, allow for complexity if situation requires it.

*NOTE* I'm not a UI/UX designer, but have assembled them through much experience

---

• The resolved section interferes with the filters from my point of view. I think we should either rework the filters or add the option to split the reminders in four sections and remove the filters.

I'm not a super fan of the filters as they work today, some of that is me coming from what I'm used to with MyTherapyApp, and minimal cognitive load. Some is actually functionality gaps in my usage (see example below)

• The filter bar eats a lot of vertical screen real estate in it's current form.
• I'm sure they could be useful, so don't want to toss them completely, but for me, moving things that are done "out of the way" just helps quickly lower the cognitive load for simplicity whenever possible.

Example scenario: I want to see easily see unresolved/active tasks

• Enable all filters except "checkmark"
• This works great today & future days
• BUT when I look at yesterday or history, it falls apart
  • Go to previous day, except nothing shows up (filtered to hide resolved items)
  • I remember that I need to mess with the filters.... what was the exact combo I need again....<thinks...>
  • I have to deselect my filters to see history (takes multiple clicks to adjust filters for history view)
  • I finally get info I needed
  • Now when I go back to the current or future...
  • Now resolved are showing up again (chancing filters unhid them)
  • I Remember that I need to mess with the filters.... what was the exact combo I need again....<thinks again...>
  • I have to re-enable filters back to "normal" for only unresolved (takes multiple clicks to adjust filters back)

Ouch - so much thinking & clicking for a simple task!
:)

I hear you on the "resolved" section adding complexity. I'm open to better implementations. I took claude's options and tried to implement best, so definitely open to any other or more elegant ways to do it or something similar

Thoughts?

[Futsch1]

Thinking about "Taken at": I see your point and I also see that the additional complexity is not so big. Let's do it.

Maybe you misunderstood me regarding the filters: I was not against adding a resolved section, I was just thinking to either rework the filters or add the section. So what might work then is a filter with three states: show all, show resolved, show open. We could have these buttons be expandable from a marker that is labeled "Filter", so that it does not consume vertical space per default.

My main concern with the "resolved" section is that it is not intuitive that reminders disappear when taken and users will have to scroll to find them again.

[Futsch1]

Oh, and by the way, I really like this one: "Confirm all and a group menu"

[JenerGomes]

Hello,

Grouping by time in the overview looks good; I would like it. I'm just a little worried about long lists of meds.
For example, in my case I have 16 items in my daily routine on Medtimer, distributed in 4 times per day, being a long list, and I was already wishing for a way to reduce the font size and the space between meds. With the grouping option, my wish increases a bit.

"Taken At..." would be amazing! I had to change the time of several meds per day, one by one, probably every day (at least every two days, if I'm lucky).
MedTimer_example_meds_taken_at.mp4 represents me.
For me, this is the best of these numericOverflow's contributions, this would save me time and several repetitive actions.

I'm curious about the "Resolved" section. Not a priority for me, I tap on Taken and Passed/Not Taken (I'm guessing the word in English) to see the hidden meds, but it could be useful.

Reminder edits apply to today: Y-es! The actual way takes me some time to adjust the reminders or the start/end intervals.

[Futsch1]

@JenerGomes As I was hesitant to accept the change for Reminder edits apply to today: Maybe I am not seeing the use case properly. Can you elaborate why this would help you?

[JenerGomes]

Of course! It's great to have the chance to give a feedback to the developer of anything, and even more of this great application.

Long story short, I had to erase all I wrote because I explained my experiences based on a previous Medtimer's behaviour; I tested it now, and everything worked fine!
If I change the name or schedule, Medtimer changes for future doses, which makes perfect sense.
So, I withdraw my previous comment about this idea.
"Skipped" is the correct term for my guesses "Passed/Not Taken".

By the way, a few days ago I noticed that the list of additional doses and the list of medicines are in sync; until some time ago, the list of medicines didn't have all the options of the additional doses list.
In the past, I had to register the previously scheduled medicine I changed on the same day as "Skipped ", and register the necessary dose as an additional one, even for the next. This was partially described in issue #1778, but the last time I saw this was months ago.

Thank you for your attention and for the great work keeping this app!

[Futsch1]

@numericOverflow Any plans on creating the PRs you proposed? I really like the grouping idea, so if you don't have time or lost interest, I would pursue this myself...

[numericOverflow]

YES! I'll work on it. Got sidetracked and hadn't see the discussion notifications of late.
I'll work on putting together a PR with just the grouping changes and confirm all and a group menu. I'll just hold off the "resolved" section logic for now.

You want me to wait until #1879 is merged and base of that?

[numericOverflow]

oops forgot to mention @Futsch1

[Futsch1]

@numericOverflow No need to wait for the PR, these are only small fixes following some tests I am doing right now.

[numericOverflow]

OK @Futsch1 - got the changes isolated for grouping and taken time. There are 2 PRs in draft (#1880 and #1881) and then after those merge, I'll rebase the third from this move-combine-notifications-setting branch in my fork and open that as the 3rd PR.

LMK if you want changes. I have an APK I build with all 3 PRs combined and am testing, can send your way if you want.

FOSS test build:
<\Human created content>

---

[Note: the AI summary of plan starts here...]
Here is how the three PRs from this discussion fit together. Each one can be reviewed and merged on its own terms, and the order matters only where noted.

PR	What it does	Base	Depends on
A: PR #1880 Group overview events by reminder time (#1696)	Groups doses of the same reminder time into one card, adds Confirm all and a group menu, fades taken and skipped rows, lightens the cards in dark theme	main	nothing
B: PR #1881 Taken at (#1406, #1232)	Records the time a dose was really taken, plus an optional Default taken time setting	main	nothing
C: PR-TBD Move Combine notifications	Moves Combine same time notifications to the notification settings	A	A merged first

A: grouping. The four commits each hold one feature, so you can drop any of them. Grouping uses an exact match on the reminder time and has its own Display setting, group_overview_events, which is on by default and is independent of combine_notifications. A single dose has no header. Long-press same-time selection now follows the grouping setting instead of combine_notifications. The PR description covers this change. The dark-card commit overlaps #1879; it is one line, so drop it if you prefer the #1879 look.

B: Taken at. Taken at… sits next to Taken, and a long press on Taken opens the same picker. The picker opens on the time, and Change date lets you pick another day. Times in the future are rejected, because they would shift interval and linked reminders. All taken paths record the time through one place, NotificationProcessor.setReminderEventStatus. The second commit adds the Default taken time setting (time of logging or scheduled time). You only agreed to Taken at, so drop that commit if you don't want the setting.

C: settings move. This PR only relocates the preference. The key, the default (off) and the strings stay the same. It waits for A, because A gives grouping its own setting, and after that combining is a notification-only choice.

Merge order. A and B are independent and both start from main. They touch the same preference, backup and string files, so whichever merges second needs a rebase, and I will do that rebase. If A goes first, B's group menu also offers Taken at…. C goes after A.

Not included. The resolved section and the hide-status-filters setting wait for the filter design you suggested (three states behind a Filter marker). I keep that code locally and will come back to it once we agree on the filter.

Translations. New strings have machine-drafted translations in all locales. Please treat them as drafts. No existing translation is changed.

Testing. I tested all three PRs together on a device, using one combined build.