OK / Cancel buttons in ICS

Question

Starting with SDK 14, the preferred order is Cancel / OK as opposed to OK / Cancel before. I am NOT going to enter into a discussion about whether this is a good bad idea, this is not a question of my question.

The fact is that the ADK recommends that you use the new order for devices with SDK> = 14, giving you the following Lint

The layout uses the wrong button order for API> = 14: Create a layout-v14 / layout.xml file with the opposite order: Cancel the button should be on the left (it was "@ string / send | Cancel", it should be "Cancel | @ line / send ")

Well, I will stick to this, this is not a problem for me, and I understand that I must follow the advice so as not to annoy users.

But here's what ... On my Samsung Galaxy S II, powered by ICS, the system interface itself doesn't seem to be in line with the new order. Here are some sample screenshots:

The order is old. Please note that I am using the official version of ICS for my phone (and not a custom ROM). And the order is the same on my Galaxy Tab 2 (official ICS also works). In some dialogs, the order is correct (cancel / OK) The only difference that I see is the theme (dialogs using the Golo theme have a new order, the rest are old). Here is a screenshot of DatePickerDialog from the settings (for setting the system date) and from my application using Holo:

This is pretty troubling. It appears that the order of the buttons is related to the theme, not the version. Or is it just that Samsung does not match Android design patterns?

I think that actions (when they have OK / Cancel buttons) should also follow the same order. And here, again, on my phone, the Create Event activity on the calendar is in the wrong order (and the Hole theme is not used in the action):

I will use the Holo theme in my application for devices like from Honeycomb, so I will keep the new order for the SDK> = 14. I just wanted to understand this information.

Thanks.

Answer 1

Yes, changing the button is pretty annoying, and I end up deleting more than the ok button. But this is what you can do. Or create your own dialog box so that you control which button goes there, otherwise let the user find out by reading. The only thing we need to do as programmers is that when the cancel is pressed, it is actually canceled, not OKEA! To shed more light on why Ok-Cancel was replaced, this was to avoid infringement of Apple patents, as they also follow Ok-Cancel. So replacing Cancel-Ok means no violation (stupid, but saves millions of Google!)

Answer 2

Samsung has this weird idea on how to support Touchwiz with Android 2 on Android 4.x devices. This is the most unpleasant thing for Samsung 4.x disks for me personally, since ICS / JB UI is much nicer. This is most noticeable in dialogs (using the layout of 2.x buttons, as you mentioned) and tabs (with 2.x tabs, rather than with much more convenient 4.x tabs).

Even new devices with 4 notes, such as SGS3 (suppose Note 2 is also just released), still have this ridiculous porting of Android 2. UI components.

I suspect this is not a problem for end users, as it annoys developers who have many devices and notice differences.

Answer 3

Yes, it seems that the order of the buttons is related to the theme, not the version. Unlike the layout "alert_dialog.xml", alert_dialog_holo.xml "puts" button1 "(positive) to the right and" button2 "(negative) to the left.

The layout is determined by com.android.internal.app.AlertController:

public AlertController(Context context, DialogInterface di, Window window) { TypedArray a = context.obtainStyledAttributes(null, com.android.internal.R.styleable.AlertDialog, com.android.internal.R.attr.alertDialogStyle, 0); mAlertDialogLayout = a.getResourceId(com.android.internal.R.styleable.AlertDialog_layout, com.android.internal.R.layout.alert_dialog); 

The Theme attribute "alertDialogStyle" refers to the "AlertDialog" style, which is a set of attributes that describe the AlertDialog theme, the "layout" attribute can point to a layout resource, otherwise layout / alert_dialog is used.

In the Android source, you can see that "Theme.Holo" uses "AlertDialog.Holo", which in turn refers to "layout / alert_dialog_holo", and in "Theme" uses "AlertDialog", which does not contain a layout and by The default value is the code value.

themes.xml:

 <style name="Theme"> <item name="alertDialogStyle">@android:style/AlertDialog</item> <style name="Theme.Holo"> <item name="alertDialogStyle">@android:style/AlertDialog.Holo</item> 

styles.xml:

 <style name="AlertDialog"> … </style> <style name="AlertDialog.Holo" parent="AlertDialog"> … <item name="layout">@android:layout/alert_dialog_holo</item> … </style> 

The actual theme used is apparently determined by the device’s settings.

themes_device_defaults.xml:

 <style name="Theme.DeviceDefault" parent="Theme.Holo" > <item name="alertDialogStyle">@android:style/AlertDialog.DeviceDefault</item> 

styles_device_defaults.xml:

 <style name="AlertDialog.DeviceDefault" parent="AlertDialog.Holo"> </style> 

I think Samsung is simply installing something else here to maintain their appearance, as Filio described.

Answer 4

Perhaps this is Samsung, which has made changes to its ROM for the Galaxy S2. I feel like they are a little notorious when it comes to customization. In the past, I also had some problems with the basic Bluetooth operations in their ROMs for SGS2, xCover, etc. Therefore, I will not be surprised if this happens only on Samsung devices :)