OK/Annulla ordine pulsanti in ICS

Question

Poiché l'SDK 14, l'ordine preferito è Annulla/OK in opposizione a OK/Annulla prima. Io NON entrerò nel dibattito se sia una buona o cattiva idea, questo non è l'argomento della mia domanda.

La cosa è che l'ADK ti incoraggia a usare il nuovo ordine per i dispositivi con SDK> = 14, dando la seguente Lint

layout utilizza l'ordine tasto sbagliato per API> = 14: Creazione di un file/layout.xml layout V14 con ordine inverso: Cancellare tasto dovrebbe essere sulla sinistra (è stato "@ string/inviare | Annulla", dovrebbe essere "Annulla | @ string/send")

OK, mi atterò a questo, questo non è un problema per me e capisco che dovrei foll devo consigliarti per evitare di annoiare gli utenti.

Ma ecco la cosa ... Sul mio Samsung Galaxy S II, in esecuzione su ICS, l'interfaccia di sistema stessa sembra non seguire il nuovo ordine. Ecco alcuni esempi screenshot:

L'ordine è quello vecchio. Nota che uso la versione ICS ufficiale per il mio telefono (non una ROM personalizzata). E l'ordine è lo stesso sul mio Galaxy Tab 2 (anch'esso in esecuzione ICS ufficiale). In alcune finestre di dialogo, l'ordine è corretto (cancella/OK) L'unica differenza che vedo è il tema (le finestre di dialogo che utilizzano il tema di Holo hanno il nuovo ordine, gli altri il vecchio ordine). Ecco uno screenshot di una DatePickerDialog dalle impostazioni (per impostare la data di sistema) e dalla mia app che utilizzano Holo:

Questo è abbastanza inquietante. Sembra che l'ordine dei pulsanti sia correlato al tema e non alla versione. Oppure Samsung non segue gli schemi di progettazione di Android?

Penso che le attività (quando hanno i pulsanti OK/Annulla) dovrebbero anche seguire lo stesso ordine. E qui, ancora una volta, sul mio cellulare l'attività Crea evento del calendario ha l'ordine sbagliato (e l'attività non utilizzare Hole tema):

Userò il tema Holo nel mio app per dispositivi come da Honeycomb, quindi terrò il nuovo ordine per SDK> = 14. Vorrei solo capire questo fatto.

Grazie.

Answer 1

Sì, lo scambio di pulsanti è piuttosto irritante e finisco per colpire annullare più del pulsante ok. Ma questo è quello che puoi fare. O crea la tua finestra di dialogo personalizzata in modo da mantenere il controllo di quale pulsante arriva, altrimenti lascia capire all'utente leggendo. L'unica cosa che dobbiamo fare come programmatori è fare in modo che quando viene premuto cancel, in realtà cancella e non va bene! Per fare più chiarezza sul motivo per cui Ok-Cancel è stato scambiato, questo è stato per evitare la violazione di un brevetto con Apple poiché anch'essi seguono Ok-Cancel. Così scambiare Cancella-Ok significherebbe nessuna violazione (Silly, ma consente di risparmiare Google Milioni!)

Answer 2

Forse il suo Samsung che ha fatto modifiche al loro ROM per Galaxy S2. Mi sento come se fossero un po 'famosi quando si tratta di personalizzazione.In passato, avevo anche riscontrato alcuni problemi con le principali operazioni Bluetooth nelle loro ROM per SGS2, xCover ecc. Quindi non sarei sorpreso se succedesse solo nei dispositivi Samsung :)

Answer 3

Samsung ha questa strana idea di mantenere l'aspetto touchscreen di Android 2 su dispositivi Android 4.x. È la cosa più fastidiosa di Samsung 4.x ROM per me personalmente poiché l'interfaccia utente ICS/JB è molto più bella. È più evidente nelle finestre di dialogo (usando la disposizione dei pulsanti 2.x come hai menzionato) e le schede (usando le schede 2.x piuttosto che le più belle schede 4.x).

Anche i nuovi dispositivi 4.x solo come SGS3 (si presume che anche la Nota 2 sia stata appena rilasciata) hanno ancora questo ridicolo porting di componenti dell'interfaccia utente Android 2.

Sospetto che questo non sia un problema per gli utenti finali, quanto è fastidioso per gli sviluppatori che hanno molti dispositivi e notano le differenze.

Answer 4

Sì, sembra che l'ordine dei pulsanti sia correlato al tema, non alla versione. A differenza del layout "alert_dialog.xml" il "alert_dialog_holo.xml" inserisce "button1" (positivo) a destra e "button2" (negativo) a sinistra.

Il layout è determinato da 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); 

attributo del tema "alertDialogStyle" si riferisce ad uno stile "AlertDialog", che è un insieme di attributi che descrivono un AlertDialog di tema, l'attributo "layout" può puntare a una risorsa di layout, altrimenti viene usato layout/alert_dialog.

Nella sorgente di Android è possibile notare che "Theme.Holo" utilizza "AlertDialog.Holo" che a sua volta fa riferimento a "layout/alert_dialog_holo", mentre "Theme" utilizza "AlertDialog" che non contiene layout e valori predefiniti al codice valore.

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> 

Il tema effettivamente utilizzato sembra essere definito da valori di default 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> 

Credo Samsung imposta semplicemente qualcosa di diverso qui, per mantenere il loro aspetto grafico, come descritto Philio.