The real nasty bug (or feature, not sure) in the alarm app is that you have to wait for the wheel to bounce and come to a stop before the AM/PM part "sticks". If you just swipe and click save, it will keep the previous setting and then your important 7am alarm stays as 7pm and you're late for work.
Google’s Clock app seems to do most of the things: sliders on main screen, circular time picker (though I’m not exactly a fan), and a toast notification with the time until the alarm fires. The only thing missing are the every day/never options.
jeremyloy_wt 27 minutes ago [-]
Funnily enough, the Sleep Schedule settings screen on iOS (accessed through the Health app) looks very similar to this.
losvedir 53 minutes ago [-]
The Android clock app is pretty solid and looks something like that.
As a switcher to iPhone earlier this year, so many UI quirks drive me utterly bonkers. Can't stand these slow rotating dials, and for alarms specifically, I miss the confirmation that Android shows you "going off in 12 hours" or whatever, to make sure you didn't get the AM/PM or day of the week wrong.
But mostly, these numeric spinners are just terrible. In the Hilton app I have to put my kids ages all the time and it drives me crazy spinning the stupid little things to set their ages. Sigh.
I don't know how iOS got this reputation as magical and delightful and intuitive. I'm ready to go back to my Pixel, I think.
frizlab 16 minutes ago [-]
I think you can just tap the rotating thingies now and just enter the number on a keyboard.
EDIT: Just tested, yes it works.
ahartmetz 1 hours ago [-]
A good smartphone, really. Crying shame that Nokia gave up just when they had the best product in a long time.
BiteCode_dev 52 minutes ago [-]
Many people nowaday can't read clocks with hands, so if you want to sell to the mass, you need to take that into consideration.
riffraff 2 minutes ago [-]
really? I admit I don't deal with many youngsters, but I never met anyone who can't read clocks with hands, I think they may teach it in primary school here. This is deeply surprising to me.
jeroenhd 25 minutes ago [-]
While that's true, the numbers are still clearly readable and their position alongside a circle still makes a lot of sense. The alarm itself is also listed in digital time.
sieabahlpark 19 minutes ago [-]
[dead]
anotherhue 2 hours ago [-]
If we perfect the design we'll be out of the job!
stirlo 2 hours ago [-]
I wonder if this is because the code was just never looked at again after it was written or if it actually survived rewrites?
The limitation comes from the UIPickerView system level UI component. I have a similar "bug" in my app.
kadoban 2 hours ago [-]
That's just a solid hack to avoid having to have a custom widget. Well done, random engineer.
layer8 28 minutes ago [-]
I wish that at least the minutes/seconds were short lists, so you can quickly go to 00 instead of always overshooting and having to go back.
On PalmOS there was the app BigClock [0][1], where tapping on the upper part of a digit would increment it and tapping on the lower part would decrement it. That way you could quickly and predictably select any time with a few precise taps, without needing to rely on visual feedback like you have to with bouncy scroll wheels.
One of the things I find most interesting is that the implementation for the Timer is distant from the Alarm. In the alarm you can roll over on the minute but you can't on the timer. Why these aren't implemented similarly is beyond me. Same with why it isn't circular.
Sounds like junk code that's adding unnecessary complexity.
quotemstr 6 minutes ago [-]
Am I the only one mildly surprised but not bothered by this implementation choice?
Sure, making a true circular list is easy enough both computationally and code-wise. Nevertheless, it's still something "weird" and "unusual", yet another thing that has to be tested and understood and debugged. A linear list is on the happy path, and the difference isn't going to matter for anyone in the real world.
I'd personally have made it circular anyway just for the sake of my inner sense of correctness, but making it linear and finite is, IMHO, a defensible engineering choice.
ayhanfuat 59 minutes ago [-]
Reminded me all the hacks we had to use to emulate loops in Excel formulas. Good times.
eviks 2 hours ago [-]
If only they took it as a hint that the whole linear-circular design is bad as it removes any predictable fixed points... But no, let's do bad hacks instead
thakoppno 2 hours ago [-]
Anyone done the tedious work of figuring out the list length?
Just wondering how they determined the length was enough? Was it constrained by a datatype or just an assumption on user behavior?
busymom0 2 hours ago [-]
The time picker is implemented using a UIPickerView.
Tutorial for "UIPickerView - Loop the data" involves "simply create a picker view with a large enough number of repeating rows that the user will likely never reach the end".
I guess Apple didn't think OP would reach the end.
I think you could fake it by automatically snapping the user back to the middle when they reach the top or bottom. Still not “infinite scroll”
arjvik 2 hours ago [-]
If you’re reading this on your iPhone, go to the alarm app, press the + button in the Alarms tab, and try to scroll to the top or bottom of the time picker
650 2 hours ago [-]
Technically aren't the CPU cycles required to make it circular (via logic) a tradeoff to a list of 500 numbers stored statically (small size)
tpmoney 50 minutes ago [-]
They're almost certainly not storing a static list of numbers. As others have noted, they're using a UIPickerView. The delegate for that class has two methods that are particularly relevant for this, one that gets the value at "current row number" and one that says how many rows are in the model. The logic for the "current row" is almost certainly the normal modulo logic we're all familiar with. But since the component needs a "size" value for the data set, they pick something arbitrarily large on the (reasonable) assumption that no one will actually ever scroll that far unintentionally.
SoftTalker 2 hours ago [-]
Yep something that years ago would have been worth the memory savings but now memory is cheap and even the CPU cycles are a non-issue: it's about what was faster for the developer to implement.
eviks 50 minutes ago [-]
Technically you'd need precise measurements of specific implementations to determine that?
2 hours ago [-]
jahnu 1 hours ago [-]
In case anyone else hasn’t discovered this, you can long press on the digits to bring up keyboard entry.
I hate that I had to find that by accident.
atopal 37 minutes ago [-]
It’s terrible discoverability, but a single click seems to do the trick, no long press necessary.
eviks 48 minutes ago [-]
Agree the discoverability is awful. Any chance you've discovered how to make keyboard entry the default?
whateveracct 2 hours ago [-]
Feels like an API that was backed by lazy cons lists like Haskell's would give you actual circular lists for free here.
Jaxan 35 minutes ago [-]
It would still have a beginning. And it would not be “for free” as the used/seen part of the data structure would remain in memory.
unsnap_biceps 2 hours ago [-]
The time selector in a new calendar event is another case where it's a long list, not circular.
animanoir 27 minutes ago [-]
[dead]
neuroelectron 40 minutes ago [-]
It's no wonder iOS apps are so bloated and shitty. Is implemting a loop that difficult? No. It's just "cheaper" to outsource it. Apple is a hollow company led by a hollow man. Most overrated company in history.
MangoToupe 31 minutes ago [-]
> It's no wonder iOS apps are so bloated and shitty.
Compared to what?
Rendered at 18:47:02 GMT+0000 (Coordinated Universal Time) with Vercel.
Discussion on it: https://news.ycombinator.com/item?id=19597253
As a switcher to iPhone earlier this year, so many UI quirks drive me utterly bonkers. Can't stand these slow rotating dials, and for alarms specifically, I miss the confirmation that Android shows you "going off in 12 hours" or whatever, to make sure you didn't get the AM/PM or day of the week wrong.
But mostly, these numeric spinners are just terrible. In the Hilton app I have to put my kids ages all the time and it drives me crazy spinning the stupid little things to set their ages. Sigh.
I don't know how iOS got this reputation as magical and delightful and intuitive. I'm ready to go back to my Pixel, I think.
EDIT: Just tested, yes it works.
Back in the day the iPhone was notorious for messing up alarm timezones and failing to activate with DST changes… https://www.abc.net.au/news/2011-01-03/alarm-failure-leaves-...
The limitation comes from the UIPickerView system level UI component. I have a similar "bug" in my app.
On PalmOS there was the app BigClock [0][1], where tapping on the upper part of a digit would increment it and tapping on the lower part would decrement it. That way you could quickly and predictably select any time with a few precise taps, without needing to rely on visual feedback like you have to with bouncy scroll wheels.
[0] https://palmdb.net/app/bigclock
[1] http://www.gacel.de/bigclock/bigclock.htm
Speaking of practical solutions, right?
Sounds like junk code that's adding unnecessary complexity.
Sure, making a true circular list is easy enough both computationally and code-wise. Nevertheless, it's still something "weird" and "unusual", yet another thing that has to be tested and understood and debugged. A linear list is on the happy path, and the difference isn't going to matter for anyone in the real world.
I'd personally have made it circular anyway just for the sake of my inner sense of correctness, but making it linear and finite is, IMHO, a defensible engineering choice.
Just wondering how they determined the length was enough? Was it constrained by a datatype or just an assumption on user behavior?
Tutorial for "UIPickerView - Loop the data" involves "simply create a picker view with a large enough number of repeating rows that the user will likely never reach the end".
I guess Apple didn't think OP would reach the end.
https://stackoverflow.com/questions/26063039/uipickerview-lo...
I hate that I had to find that by accident.
Compared to what?