fix(treatments): keep focused input visible above the keyboard - #1238
fix(treatments): keep focused input visible above the keyboard#1238Sjoerd-Bo3 wants to merge 1 commit into
Conversation
The treatments entry list relies on the system's default keyboard avoidance to keep the focused field visible. This is unreliable: the list height changes with user settings (e.g. the Reduced Bolus / Super Bolus toggles add a row), and on some devices the bolus field ends up hidden behind the keyboard. A user can then type "11" instead of "1" without seeing it, which is a safety concern. Wrap the list in a ScrollViewReader and explicitly scroll the focused input row into view (centered above the keyboard) whenever focus changes, so the user can always see what they are entering regardless of which optional rows are shown. Fixes nightscout#1115
|
@LiroyvH olease stamp this with a approval if it works |
|
While the issue was also present in the local iPhone 16 Pro SIM, defining a separate .safeAreaPadding(.bottom: 50) for the List at line 398 seems to fix this. Also, this elevates the text input a bit further from the keyboard close button. Seems to be device consistent, see screenshots of iPhone 16 Pro SIM and iPhone 17 Pro. I only tested this for the 16 and 17 pro so i don't know if that fix is also consistent on smaller iPhone models, here maybe the original fix of @Sjoerd-Bo3 would be better. 16: |
|
Defining a pixelike area is tricky when dealing with a lot of devices and aspect ratios. It will not work somewhere. So thats why I went the builtin way instead of that. I agree, yours looks cleaner on your device, but that may vary unfortunately... |
|
Okay good to know. That's where I did not knew, if these type of areas are consistent for different devices.Considering that using a scrollview is way more consistent. 👍 |
|
Could be, but you are hand defining that 50px, so that probably doesnt scale i GUESS.. |
|
@EJM0 With it scrolled down as like in your screenshot, you cannot see the warning text for dangerous low glucose as its dropped behind the keyboard. Enter a high amount of units (without carbs to compensate) to see what I mean. |
The first version (cfe02c5 or a42620e depending on where you look) works, yup - have been using it ever since (also in latest dev, 112fe88). Screenshots are here: #1115 (comment) The second version (I think 810da2a) didn't work and actually made matters worse. I see now there appears to be another modification shown here in this PR, 5add693, that I have not tested and I'm not sure which iteration (1st or 2nd) it augments. Seems to be a minor modification but I'm unsure to what and which version. Unfortunately I'm not quite able to tell which version actually ended up being submitted for PR now... Sorry. Hopefully @Sjoerd-Bo3 can clarify that. Sorry for being vague but I'm not entirely sure which one has been submitted. if it's the first version then I can confirm it works fine. Any other version: I'd have to testdrive it. |
|
Thanks for adding some context @LiroyvH . |
5add693 to
cfe02c5
Compare
|
Version 1/3 were the same, cleaned up the PR and removed commit 2/3. So we are back where @LiroyvH and I tested for 2 weeks. |
|
@Sjoerd-Bo3 @dnzxy It would seem the latest dev version fails to build with these changes. To exclude this as the culprit:
It built fine before this, but I cannot get it to build this at all anymore with the latest dev version. |
5 participants
The treatments entry list relies on the system's default keyboard avoidance to keep the focused field visible. This is unreliable: the list height changes with user settings (e.g. the Reduced Bolus / Super Bolus toggles add a row), and on some devices the bolus field ends up hidden behind the keyboard. A user can then type "11" instead of "1" without seeing it, which is a safety concern.
Wrap the list in a ScrollViewReader and explicitly scroll the focused input row into view (centered above the keyboard) whenever focus changes, so the user can always see what they are entering regardless of which optional rows are shown.
Fixes #1115