Orden de botones Aceptar/Cancelar en ICS

Question

Desde SDK 14, el orden preferido es Cancelar/Aceptar en oposición a Aceptar/Cancelar antes. No voy a entrar en el debate de si es una buena o mala idea, este no es el tema de mi pregunta.

La cosa es que el ADK le anima a utilizar el nuevo orden para los dispositivos con SDK> = 14 dándole la siguiente pelusa

Layout utiliza el orden botón equivocado de API> = 14: Crear una archivo/layout.xml diseño-V14 con el orden opuesto: Cancelar botón debe estar a la izquierda (era "@ string/enviar | Cancelar", debe ser "Cancelar | @ string/enviar")

De acuerdo, me apegaré a eso, esto no es un problema para mí y entiendo que debería seguirme oye el consejo para evitar molestar a los usuarios.

Pero aquí está la cosa ... En mi Samsung Galaxy S II, ejecutándose en ICS, la interfaz del sistema parece no seguir el nuevo orden. Aquí hay algunos ejemplos de pantalla:

El orden es el antiguo. Tenga en cuenta que utilizo la versión oficial de ICS para mi teléfono (no una ROM personalizada). Y el orden es el mismo en mi Galaxy Tab 2 (también funciona con ICS oficial). En algunos cuadros de diálogo, el orden es correcto (cancelar/aceptar) La única diferencia que veo es el tema (los diálogos que usan el tema Holo tienen el nuevo orden, los otros, el orden anterior). Aquí está una captura de pantalla de un DatePickerDialog de la configuración (para configurar la fecha del sistema) y desde mi aplicación utilizando Holo:

Esto es muy preocupante. Parece que el orden de los botones está relacionado con el tema y no relacionado con la versión. ¿O es solo que Samsung no sigue los patrones de diseño de Android?

Creo que las Actividades (cuando tienen botones Aceptar/Cancelar) también deben seguir el mismo orden. Y aquí, de nuevo, en mi teléfono de la actividad Crear eventos del calendario tiene un orden incorrecto (y la actividad no utilizar el tema del agujero):

Me va a utilizar el tema Holo en mi aplicación para dispositivos como Honeycomb de todos modos, así que mantendré el nuevo orden para SDK> = 14. Solo me gustaría entender esto.

Gracias.

Answer 1

Sí, el intercambio de botones es bastante irritante y termino presionando cancelar más que el botón Aceptar. Pero esto es lo que puedes hacer. Cree su propio cuadro de diálogo personalizado para que pueda mantener el control de qué botón viene, de lo contrario, deje que el usuario lo descubra mediante la lectura. Lo único que tenemos que hacer como programadores es que cuando se presiona cancelar, se cancela y no se acepta. Para arrojar más luz sobre por qué Ok-Cancel se intercambió, esto fue para evitar la infracción de patente de Apple ya que ellos también siguen Ok-Cancel. Así que el canje de Cancelar-Ok no significaría ninguna infracción (¡tonto, pero ahorra millones de Google!)

Answer 2

Quizás sea el Samsung quien hizo cambios en su ROM para Galaxy S2. Siento que son un poco notorios cuando se trata de hacer personalización.En el pasado, también había experimentado algunos problemas con las operaciones básicas de Bluetooth en sus ROMs para SGS2, xCover, etc. Así que no me sorprendería que solo ocurriera en dispositivos Samsung :)

Answer 3

Samsung tiene esta rara idea sobre el mantenimiento el aspecto y tacto Touchwiz de Android 2 en dispositivos Android 4.x. Es la cosa más molesta sobre los ROM 4.x de Samsung para mí personalmente, ya que la interfaz de usuario de ICS/JB es mucho más agradable. Es más notable en los diálogos (usando la disposición de botones 2.x como mencionas) y las pestañas (usando pestañas 2.x en lugar de las pestañas 4.x mucho más bonitas).

Incluso los dispositivos más nuevos de 4.x solo como el SGS3 (supongamos que la Nota 2 también acaba de ser lanzada) todavía tienen esta ridícula migración de los componentes de la IU de Android 2.

Sospecho que esto no es un problema para los usuarios finales tanto como es molesto para los desarrolladores que tienen muchos dispositivos y notan las diferencias.

Answer 4

Sí, parece que el orden de los botones está relacionado con el tema, no relacionado con la versión. A diferencia del diseño "alert_dialog.xml", "alert_dialog_holo.xml" pone "button1" (positivo) a la derecha y "button2" (negativo) a la izquierda.

La disposición está determinada por 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); 

atributo del Tema "alertDialogStyle" se refiere a un estilo "AlertDialog", que es un conjunto de atributos que describen un AlertDialog de tema, el atributo "diseño" puede apuntar a un recurso de diseño; de lo contrario, se utiliza el diseño/alert_dialog.

En la fuente de Android, puede ver que "Theme.Holo" utiliza "AlertDialog.Holo", que a su vez se refiere a "layout/alert_dialog_holo", mientras que "Theme" usa "AlertDialog" que no contiene diseño y está predeterminado al código valor.

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> 

El tema utilizado realmente parece estar definida por valores predeterminados del dispositivo.

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> 

supongo Samsung simplemente establece algo más aquí, para mantener su apariencia como Philio descrito.