Using three choices in showAlert() is not looking good

A few places in my app I use system.showAlert with more than two options. Typically I have a YES, NO, CANCEL situation. An example is shown below:

local function closeList(e) if (e.action == "clicked" and e.index == 3) then return end if (e.action == "clicked" and e.index == 1) then -- Copy items end -- Close end native.showAlert("Question", "Copy selected items and close?", {"Yes", "No", "Cancel"}, closeList)

The problem is that three options does not look good at all on the (Android) device. Here’s how it looks:

Is this a bug, or is it supposed to look like this? Is there a way to make the center option centered?


And while I’m at it: What’s the deal with the order of the “buttons”? I don’t get the system. It’s not reversed and it’s not in alphabetical order. It’s a mess.

To add to the confusion, the order shown in the simulator is CANCEL, NO, YES…

Also it’s written in the doc:

“The first button will have a unique color to suggest that the user should choose it by default.”

I’ll be the first to admit that I’m not sure what is the “first button” here. Is it the first in my list? Or is it the first button that happens to be shown first?

Anyway, I don’t see anything special with the colors of any of the buttons.

CoronaSDK v2016.2824

Device: Nexus 6P / Android 6.0.1

Hmmm… obviously it’s only me that experience this problem… Well then  :mellow:

Hi @runewinse,

You could try swapping the “No” and “Cancel” in your table of button labels and see if that helps. Otherwise, the order is not controllable at this time.

As for the “unique color” thing, I think that’s outdated material in the documentation, and it’s not a consistent fact on all platforms. I’m just going to remove it because it’s misleading and inconsistent.

Best regards,

Brent

If the order is not controllable, why should I put the strings in a specific order?

Hi @runewinse,

Sorry, my answer was misleading. I should have stated that the order is not predictable. For some reason, the order seems to change in various versions of Android, and iOS may have changed them too (although I have not tested it on iOS 6 vs. 7 vs. 8 vs. 9).

For example, the order has changed over time as follows:

  • prior to Android 3: “label1”, “label2”, “label3”
  • Android 3 through 4: “label3”, “label2”, “label1”
  • Android 5 and above: “label2”, “label3”, “label1”

Atop that, Android only supports 3 buttons laid out horizontally in a native alert. If you add more than 3, all of the buttons will be arranged vertically, but in the order specified.

Hope this clarifies the situation somewhat.

Brent

Ok, So in effect we have to do a check for the Android/iOS version and shuffle the entries accordingly?

Or maybe you could have done it inside the SDK so that we didn’t have to?

Hmmm… obviously it’s only me that experience this problem… Well then  :mellow:

Hi @runewinse,

You could try swapping the “No” and “Cancel” in your table of button labels and see if that helps. Otherwise, the order is not controllable at this time.

As for the “unique color” thing, I think that’s outdated material in the documentation, and it’s not a consistent fact on all platforms. I’m just going to remove it because it’s misleading and inconsistent.

Best regards,

Brent

If the order is not controllable, why should I put the strings in a specific order?

Hi @runewinse,

Sorry, my answer was misleading. I should have stated that the order is not predictable. For some reason, the order seems to change in various versions of Android, and iOS may have changed them too (although I have not tested it on iOS 6 vs. 7 vs. 8 vs. 9).

For example, the order has changed over time as follows:

  • prior to Android 3: “label1”, “label2”, “label3”
  • Android 3 through 4: “label3”, “label2”, “label1”
  • Android 5 and above: “label2”, “label3”, “label1”

Atop that, Android only supports 3 buttons laid out horizontally in a native alert. If you add more than 3, all of the buttons will be arranged vertically, but in the order specified.

Hope this clarifies the situation somewhat.

Brent

Ok, So in effect we have to do a check for the Android/iOS version and shuffle the entries accordingly?

Or maybe you could have done it inside the SDK so that we didn’t have to?