[AC-5583] iOS: Slow Option Dialog with big array of options
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | n/a |
|---|
| Status | Resolved |
|---|
| Resolution | Not Our Bug |
|---|
| Resolution Date | 2018-02-08T14:17:14.000+0000 |
|---|
| Affected Version/s | n/a |
|---|
| Fix Version/s | n/a |
|---|
| Components | n/a |
|---|
| Labels | array, ios, optiondialog, options |
|---|
| Reporter | Daniel Falcon |
|---|
| Assignee | Hans Knöchel |
|---|
| Created | 2018-02-08T10:17:53.000+0000 |
|---|
| Updated | 2018-02-08T14:17:14.000+0000 |
|---|
Description
I've found some issues when adding a big array of option to an Option Dialog in iOS. I'm adding a list of more than 250 countries to form a country selector using the option dialog. I've found that:
- When pressed the button that opens the selector it takes some time to load the selector, keeping the app freeze (from 1 to several seconds).
- When the selector is loaded, scrolling through the options is really slow and selecting a country that is at the bottom of the list is simply annoying.
The same code works perfectly in Android.
I've attached the app.js of the app for testing.
Attachments
Hey there! I feel like this is the native iOS behavior, here is why: - Natively, a
UIAlertActionis created for every option - The alert dialog and option dialog (same underlayingUIAlertControllerAPI) is not made to store a huge list of options - Apple recommends to use nested lists for those UX use-cases. For example, they use it as well when selecting a country in the settings If you still feel it's only Titanium, which would be okay, we would prepare a native test to reproduce it. What do you think?Hi Hans, Thanks for the prompt reply. Well, I would have expected the same behaviour in this case for iOS and for Android. In fact, I remember that in the past (can't recall when... but maybe 1 and a half years ago) this exact same thing was working perfectly in Titanium. But yeah, could be that they have changed how things work and we need to move to other solutions. Haven't tested this native in iOS, but it would be great that it worked fast and smooth like in android. If there isn't any other solution, I will move to use nested lists or search fields, instead. Thanks
Hey Daniel! I just tried it with a native project (Swift 4, iOS 11.2) and it's actually behaving exactly the same. I've also attached a quick video and the native project to try it out. I am sorry we cannot do more here as we are dependent on the native iOS side, but you might want to raise this as an iOS issue if it was faster on earlier versions - I'd be interested what they say. Let me know if you are okay with resolving the ticket, thank you anyway for raising this!
Hi Hans, Yeah, looks like an iOS issue. I will try to raise this straight to them. About it working on older versions... I think the best way to test would be an old iPhone 4 (with iOS 9) if someone has still one. But I remember this behaving really good when I started with titanium around 2015 and until mid 2016 (when iOS 10 was released). You can close this ticket. I will add a comment here whenever I know more about this issue. Thanks for your comments
Thanks! Maybe it broke between iOS 9 and 10? The native test (video) is with iOS 11.2 on an iPhone SE, so if it would perform natively, it would definitely do on that environment, which makes it pretty obvious to be an iOS-related issue. Let me know what they say!