timer: Add launcher with recent timer history

[vkareh]

Replace timer UI with launcher screen showing 4 quick-start options:

• Three most recently used timers
• Add button for manual entry

Recent timers display MM:SS format and auto-start when selected. Usinga recent timer moves it to front of history. The + button opens timer UI to allow the user to set a new timer manually.

Fixes #985 Fixes #1991

[github-actions[bot]]

Build size and comparison to main:

Section	Size	Difference
text	383812B	1032B
data	952B	8B
bss	22632B	0B

Run in InfiniEmu

[tituscmd]

Beautiful! Very nice idea!

[tituscmd]

Im gonna get this onto my watch and daily drive it. Partly because of testing purposes, partly because I really like the look ;D

[minacode]

Nice work! 🙂

I have two nitpicks I want to discuss:

1. Would it be better for the three values to always be sorted from short to long? Does it make it easier to gather?
2. Can we find a more intuitive icon for "custom"/"other"/"new"? A simple plus sign may do the trick.

[vkareh]

@minacode

1. Would it be better for the three values to always be sorted from short to long? Does it make it easier to gather?

We can discuss here, sure. I like the idea of the latest one being first, like a circular buffer, but I can see it may make sense to have them sorted. What do other folks think?

2. Can we find a more intuitive icon for "custom"/"other"/"new"? A simple plus sign may do the trick.

Yes!! I struggled to find the right "icon" for this. The plus sign makes sense (so simple, should have thought of that :facepalm:). I've made the change:

I've also made a few changes to make the code leaner, it's a lot smaller now too.

[minacode]

I can see that 1. may be a question of personal taste. We could also go with the circular buffer for now and discuss this separately in a new PR. That will also make it easier to try out both implementations and better compare them.

Yes!! I struggled to find the right "icon" for this. The plus sign makes sense (so simple, should have thought of that 🤦). I've made the change:

Looks good! Sometimes it is easier with an outside perspective 😄

I've also made a few changes to make the code leaner, it's a lot smaller now too.

Nice, thank you!

[minacode]

Two things about the code:

1. In #1367 the persistance was implemented with a state file managed by a controller and not by the settings controller. I think that this would be a little cleaner here, because the buffer is not really a setting. I know that this is also overhead. Maybe it's time for me to work on #2171 again.
2. In src/utility is an implementation of a circular buffer. Maybe it's useful here.

[vkareh]

@minacode

1. In Alarm persist to flash #1367 the persistance was implemented with a state file managed by a controller and not by the settings controller. I think that this would be a little cleaner here, because the buffer is not really a setting. I know that this is also overhead. Maybe it's time for me to work on WIP: Generic memory persistence class #2171 again.

Yeah this is a good point. I was debating internally whether we need persistence at all here. For alarms, persistence is critical. For a timer MRU list... not so much? :shrug:

I can just make the defaults be part of the Timer app and remove them from the settings. This will be cleaner and take up less room - also less wear on the flash storage.

2. In src/utility is an implementation of a circular buffer. Maybe it's useful here.

Technically this is not a circular buffer, but an MRU list. A circular buffer would end up always creating a new timer entry and pushing the oldest one. You can't pop one form the middle of the array to move it to the front, you can only pop the last one out and either discard it or push it to the front (which treats it as a new timer setting). Very useful for streaming data, but not keeping track of "the most recently used timer". You'd be either duplicating the timer settings, or moving them in the wrong order.

The MRU list pops the last used timer from its current position (which can be in the middle of the array) and moves it to the top. New entries get added to the top and push the last one out. Significantly simpler for this.

[minacode]

If you go for persistence over app usages but not over reboots, you could use the timer controller to store the data. However, in #2365 there was some talk about keeping it generic. Not sure, what exactly the plan is.

You are right, a ring buffer is not correct here.

[vkareh]

@minacode

If you go for persistence over app usages but not over reboots, you could use the timer controller to store the data. However, in #2365 there was some talk about keeping it generic. Not sure, what exactly the plan is.

I removed the persistence across reboots. The timer history is just stored in a static variable in the Timer app itself (not in the controller, as that should remain generic like you said). Since it's just an MRU list, persistence is not really critical.

[tituscmd]

Quick chime in from me after using it for a while:

This PR is really a game changer! I only use the same 2 or 3 timers so this saves me a bunch of time I would spend just holding my finger on the +-sign, love it!

Regarding the sorting of the presets, I would personally go with recency rather than sorting by value. I reckon that way it's more intuitive for the user.