feat(new reviewer): answer timer

[BrayanDSO]

localized below the Count numbers to avoid losing screen space

Approach

1. Add an improved subclass of Chronometer to handle configuration changes properly
2. Add the Timer below the Count numbers
3. Setup the timer

How Has This Been Tested?

Emulator SDK 35:

timer.mp4

Android 15 phone (Galaxy S23):

Screen_Recording_20250613_203446_AnkiDroid.mp4

Learning (optional, can help others)

1. Had heard before about ConstraintLayout Flow, but never used it until now
2. You can force the emission of the same value in MutableStateFlow by overriding equals() and hashCode() https://stackoverflow.com/questions/62331931/mutablestateflow-is-not-emitting-values-after-1st-emit-kotlin-coroutine

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[david-allison]

In the first video, the answer counts are not in a stable position on the screen. Can this be fixed?

[BrayanDSO]

the timer can be in the top left of the screen.

Screen_recording_20250613_212920.mp4

Both options are fine to me. I just don't want to lose vertical space.

With the toolbar on the bottom

[david-allison]

I prefer the timer below the counts. Very minor preference. Implementer's choice

My point was that It's distracting to have UI elements move in-between cards.

[BrayanDSO]

My point was that It's distracting to have UI elements move in-between cards.

In most use cases, the user either will never use the timer or always use the timer. If they have mixed deck options, and with the same parent deck, the vanishing/appearing timer calls the atention either way, and that may be even beneficial for that case, so the user notices that there is a timer.

[mikehardy]

@BrayanDSO - I think you mean "In most use cases, the user either will never use the timer or always use the timer" (never/always, vs never/never) ?

@david-allison I'm inclined to agree, I don't think most decks contain mixed note types, and I don't think most people that like the timer will only use it sometimes, and my guess at the intersection of those two guesses is pretty small and Brayan's argument it might even be a positive is somewhat persuasive. I'm inclined to go with Brayan on this one and go with it as-is

Needs consensus either way though ?

[david-allison]

I'm happy (to keep the moving UI elements), could we document the decision in the code?

[BrayanDSO]

In most use cases, the user either will never use the timer or always use the timer" (never/always, vs never/never) ?

Never/Always.