| ▲ | 650 5 days 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 5 days ago | parent | next [-] |
| 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. |
| |
| ▲ | garaetjjte 5 days ago | parent | next [-] | | > They're almost certainly not storing a static list of numbers. Probably. But I wouldn't bet on it. I once borrowed a car that would glitch if you pressed the cruise control buttons too fast. Normally + and - buttons increase and decrease the speed by 1 km/h. But if you do it too fast, it sometimes eats the entry, and starts skipping one position. Eg. it would increase from 105 to 107, and decrease from 107 to 105. It was persistent until cruise control was turned entirely off and on again. Eh? Making that bug must have taken more effort than doing it correctly. I guess it must be populating linked lists of possible speeds, and then screwing up the links when clicking too fast? (that was Jeep Renegade) | | |
| ▲ | tpmoney 5 days ago | parent | next [-] | | A lot of the digital cruise controls that I've used in cars increment by 1 for each press, but increment by jumps (3-5 IME) if you hold it down. I wonder if that bug is a state machine problem. Pressing fast enough puts it into the "holding" mode, but because you're not actually holding, it also doesn't register that you've "stopped" holding. | | |
| ▲ | garaetjjte 5 days ago | parent [-] | | Nope, it only affected that one position. Like in the previous example it would go 104->105->107->108. |
| |
| ▲ | 4 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | NobodyNada 5 days ago | parent | prev [-] | | Applying this to answer the question directly -- no, this doesn't waste CPU cycles or memory because UIPickerView only keeps the visible rows in memory and generates them lazily as you scroll. Thus, the number of rows does not affect the performance of the picker. All table- or list-like UI components across Apple's platforms work this way. |
|
|
| ▲ | SoftTalker 5 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | 5 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | eviks 5 days ago | parent | prev [-] |
| Technically you'd need precise measurements of specific implementations to determine that? |
