Orden de los botones OK / Cancel en ICS
Desde el SDK 14, la orden preferida es Cancel / OK en oposición a OK / Cancel 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 la nueva orden para los dispositivos con SDK> = 14 dándole la siguiente Lint
- Alinea horizontalmente dos vistas de texto en un diseño
- Arsenal de botones onclicklistener
- Aliasing de un recurso de diseño con el mismo nombre sólo calificador de pantalla diferente
- RecyclerView con elementos de contenido de ajuste
- Android: ScrollView no se desplaza con el teclado fuera
El diseño utiliza el orden de botones incorrecto para API> = 14: Cree un archivo layout-v14 / layout.xml con orden contrario: El botón Cancelar debe estar a la izquierda (fue "@ string / send | Cancel" Cadena / enviar ")
OK, me quedo con eso, esto no es un problema para mí y entiendo que debo seguir el consejo a fin de evitar molestar a los usuarios.
Pero aquí está la cosa … En mi Samsung Galaxy S II, que se ejecuta en ICS, la interfaz del sistema en sí parece no seguir el nuevo orden. Aquí hay algunos ejemplos de captura de pantalla:
La orden es la antigua. 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 funcionando ICS oficial). La única diferencia que veo es el tema (los diálogos que utilizan el tema de Holo tienen el nuevo orden, los otros, el antiguo). Aquí hay una captura de pantalla de un DatePickerDialog de la configuración (para establecer la fecha del sistema) y de mi aplicación con Holo:
Esto es bastante inquietante. Parece que el orden de los botones está relacionado con el tema y no con la versión. ¿O simplemente Samsung no sigue los patrones de diseño de Android?
Creo que las actividades (cuando tienen botones OK / Cancel) también deben seguir el mismo orden. Y aquí, de nuevo, en mi teléfono la actividad Crear Evento del Calendario tiene el orden equivocado (Y la actividad no usa el tema Agujero):
Voy a utilizar el tema de Holo en mi aplicación para dispositivos como de Honeycomb de todos modos, así que voy a mantener el nuevo pedido de SDK> = 14. Sólo me gustaría entender esto.
Gracias.
- El mismo diseño para dispositivos grandes y grandes
- Agregar marco o borde a ImageView y Drop-Shadow
- ¿Cómo obtener la referencia attr en el código?
- ¿Cómo configurar AutoCompleteTextView desplegable fondo transparente en Android?
- ¿Por qué textStyle italic no se aplica en el diseño de Android para otros tipos de caracteres que serif?
- Carga lenta del diseño
- Cómo crear Android ActionBar con vista personalizada y pestañas
- FloatingActionButton en Fragmento oculto en la barra de herramientas colapsando
Sí, el cambio de botón es bastante irritante y acabo golpeando cancelar más que el botón de ok. Pero esto es lo que puedes hacer. Crear su propio cuadro de diálogo personalizado para que mantenga el control de qué botón viene donde, de lo contrario, el usuario averiguar por la lectura. Lo único que tenemos que hacer como programadores es tan a él que cuando se presiona cancelar, en realidad cancela y no OKays! Para arrojar más luz sobre por qué Ok-Cancel fue cambiado, esto fue para evitar la infracción de patente con Apple, ya que también siguen Ok-Cancelar. Así que cambiar Cancel-Ok no significaría ninguna infracción (Silly, pero guarda Google Millions!)
Samsung tiene esta extraña idea de mantener la apariencia de Touchwiz desde Android 2 en dispositivos Android 4.x. Es la única cosa más molesta acerca de Samsung 4.x ROMs para mí personalmente como ICS / JB UI es mucho más agradable. Es más notable en los diálogos (utilizando la disposición de los botones 2.x como se mencionó) y las pestañas (utilizando pestañas 2.x en lugar de las pestañas 4.x mucho más agradable).
Incluso los dispositivos 4.x más recientes, como el SGS3 (supongamos que la nota 2 también que acaba de ser lanzado) todavía tiene este portado ridículo de los componentes de la interfaz de usuario de Android 2.
Sospecho que esto no es un problema para los usuarios finales, así como es molesto para los desarrolladores que tienen muchos dispositivos y notar las diferencias.
Sí, parece que el orden de los botones está relacionado con el tema, no con la versión. En la diferencia con el diseño "alert_dialog.xml", el "alert_dialog_holo.xml" pone "button1" (positivo) a la derecha y "button2" (negativo) a la izquierda.
El diseño está determinado 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);
El atributo del tema "alertDialogStyle" se refiere a un estilo de "AlertDialog", que es un conjunto de atributos que describen el tema de AlertDialog, el atributo "layout" puede apuntar a un recurso de diseño, de lo contrario se utiliza layout / alert_dialog.
En la fuente android se puede ver que "Theme.Holo" utiliza "AlertDialog.Holo" que a su vez se refiere a "layout / alert_dialog_holo", mientras que "Theme" utiliza "AlertDialog" que no contiene diseño y por defecto al valor del código.
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 realmente utilizado parece estar definido por los defectos 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 que Samsung simplemente establece algo más aquí, para mantener su apariencia como Philio describió.
Tal vez es el Samsung que hizo cambios en su ROM para Galaxy S2. Siento que son un poco notorio cuando se trata de hacer la 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 Por lo que no me sorprendería si sólo sucede en los dispositivos de Samsung 🙂
- Coreógrafo NullPointerException
- ¿Es posible utilizar un BLE habilitado para Android / iPhone como un faro BLE?