💾 Archived View for skyjake.fi › gemlog › 2022-01_ios-top-tap.gmi captured on 2024-08-18 at 18:58:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
For the longest time I've been wondering how to implement the iOS platform convention of scrolling to top when tapping the status bar.
The problem is that since Lagrange has a custom UI, the system doesn't see the need to send any notifications about taps on the status bar. Even when using standard UI controls, this behavior is provided only by UIScrollView and fully handled by the operating system — the status bar is a system-managed UI element after all.
Of course, a solution could be found by consulting the revered oracles of hallowed StackOverflow. In other words, after a few minutes on DuckDuckGo I stumbled on this nice piece of information:
How to detect touches in status bar
In short, it suggests using a hidden UIScrollView to fool the system into notifying about taps on the status bar. I gave this a go, but unfortunately it didn't work as intended, probably because an SDL app only has a single UIView and nothing can be hidden behind it. On the upside, if the fake scroll view was visible over the SDL view, the system did send notifications about status bar taps.
The UIScrollView has to be on top, then. After a few minutes of perusing the API documentation I found that one can hide the scroll indicators, and if a background color is not set, the control is essentially invisible. But unfortunately, if I place this fake scroll view on top of the Lagrange UI, it prevents any taps and swipes from reaching my UI widgets in that area.
But hey, the status bar area is anyway outside my UI, so why don't I just put the fake scroll view there?
You can't see it, but there's now an invisible UIScrollView under the status bar.
And it works! 🎉
This is available now for testing in TestFlight build 1.10 (12).
📅 2022-01-28
CC-BY-SA 4.0
