Perché è difficile rendere un programma Java 'apparire nativo'?

Isn't it only a matter of designing buttons that look like 'native' buttons?

Bene - sorta di, per i pulsanti. Ma questo potrebbe essere più difficile di quanto immagini. In questi giorni la grafica utilizzata per rappresentare i componenti della GUI non è così semplice come i bitmap casuali che vengono allungati (poiché questi non si adattano molto bene) - sono spesso grafica basata su vettori con un sacco di casi d'angolo programmati in loro ( quindi, quando il pulsante raggiunge il bordo dello schermo, potrebbe sembrare leggermente diverso, ad esempio.) E, naturalmente, avrai bisogno di una grafica diversa quando si fa clic su un pulsante. Per ragioni di copyright, gli sviluppatori spesso non possono utilizzare questa grafica esistente a priori, quindi devono essere ricreati - e mentre fanno un buon lavoro per la maggior parte, inevitabilmente alcune cose vengono perse data l'enorme varietà di componenti grafici là fuori. Questo è molto meno severo di quanto fosse un tempo - in questi giorni, se imposto l'aspetto della piattaforma predefinita in Swing, noto molto poco che sembra strano.

Sto dicendo tutto quanto sopra basato su Swing, che è ovviamente un leggero toolkit GUI non nativo. Si specifica che SWT non sembra nativo, il che è un po 'strano, perché SWT è nativo. È un toolkit che usa JNI sotto per chiamare i componenti nativi - quindi se qualcosa non sembra proprio lì, non è sarà per via dell'aspetto.

Ci sono letteralmente una mezza dozzina di toolkit che possono essere considerati "nativi" su alcuni sistemi. Alcuni di questi hanno concetti o funzionalità piuttosto unici e la loro replica in un toolkit multipiattaforma è noioso. Il look & la sensazione di un'applicazione non è determinata solo da una "pelle", ma anche dal layout e da come si comporta. Alcune considerazioni:

• In una finestra di dialogo, da quale parte si trova il pulsante "OK", a sinistra oa destra? Giusto, costruiamo una finestra di dialogo separata per ogni sistema.
• Come contrassegniamo il pulsante predefinito su uno schermo? Colorare i colori, caratteri in grassetto, ingrandendo il pulsante? Giusto, inseritelo in un foglio di stile.
• Su Windows, il concetto di "Ribbon" è piuttosto nativo. Come sarebbe stato tradotto questo in Mac, dove la barra multifunzione non è comune? Abbastanza corretto, dimentichiamo il layout esatto dei pixel e forniamo una diversa implementazione della barra degli strumenti per ogni sistema.
• La barra dei menu fa parte della finestra (Windows, opzionalmente KDE), oppure si trova nella parte superiore dello schermo (Mac, Unity)? Abbastanza corretto, scriviamo un'implementazione diversa per ogni sistema, dato che abbiamo già eliminato il layout esatto dei pixel
• Come vengono visualizzati i caratteri? Più croccante possibile, o liscia e antialias? E quale font dovrebbe essere usato? Tieni presente che i diversi tipi di carattere hanno metriche diverse, pertanto lo stesso paragrafo reso alla stessa larghezza potrebbe avere un numero diverso di linee a seconda del carattere.
• Lo sfondo di una finestra è un singolo colore, un'immagine o una sfumatura? Inseriamo anche questo in un foglio di stile.
• Come appaiono le barre di scorrimento? Dove sono i pulsanti - se ne hanno? Quanto sono ampi, o sono rivelati solo quando il puntatore si sposta in una determinata regione?
• Come incorporiamo altri schemi di colori?
• Cosa dovrebbe essere trascinabile? Dove sono previsti i menu di scelta rapida?

Questi problemi non possono essere risolti attraverso un semplice foglio di stile quando toccano il comportamento o il layout generale dell'applicazione. L'unica vera soluzione è riscrivere l'applicazione per ciascun sistema (ignorando così i vantaggi di multipiattaforma di Java). L'unica soluzione realistica è quella di dimenticare il layout esatto dei pixel e di scrivere su un'interfaccia comune che riassume i toolkit specifici del sistema. La soluzione adottata da Swing è quella di emulare vari sistemi, che falliscono in modo spettacolare.

E poi c'è coerenza tra piattaforme, l'idea che la tua app possa apparire esattamente uguale su tutti i sistemi (spesso scelta dai giochi, dove questo aumenta l'immersione). Sulle applicazioni desktop, questo è solo fastidioso e rompe le aspettative degli utenti.

Sì, va più in profondità.

Costruire un pulsante che assomiglia a un pulsante Windows o OS X è facile, quando si crea solo questo pulsante. Ma il pulsante deve "comportarsi" come quelli originali, il che potrebbe non essere facile: forse c'è più spazio in una versione disponibile, ma non nell'altra, forse il colore è più adatto per il tuo progetto nella versione Windows, ecc.

Questo è excarberated quando si ha un'intera GUI: un programma OS X presenta il suo contenuto in modo diverso rispetto a un programma Windows. Questo è quasi impossibile da catturare in una GUI - avresti bisogno di due GUI, ma non molte applicazioni fanno così tante storie. Invece puntano a "sembra ok sulla maggior parte dei sistemi" - questo sembra ancora un po 'alieno, ma è utilizzabile e molto più facile da sviluppare.

Non è difficile creare un pulsante che assomigli ad un pulsante OSX, a un pulsante di Windows o a qualsiasi altro toolkit. Ma le linee guida dell'interfaccia utente per la maggior parte degli ambienti non sono così semplici come le basi di "questo è come appare un pulsante". Ci sono molte differenze più sottili, dalla spaziatura tra gli elementi dell'interfaccia all'ordine in cui alcune azioni ben note dovrebbero apparire in una lista alla posizione esatta della finestra di dialogo Preferenze / Opzioni nel sistema di menu. Si possono automatizzare i casi più comuni per interfacce utente molto semplici, ma molte, se non la maggior parte delle operazioni di interfaccia utente, richiedono un tocco molto più raffinato.

SWT ha cercato di automatizzarlo in una certa misura e, ancora una volta, è perfetto per le semplici attività dell'interfaccia utente. Ma non esiste una soluzione valida per tutti, e quindi quando le interfacce utente diventano più complesse, i metodi di base che utilizza cominciano a crollare. In genere è possibile riportarlo in linea con il lavoro manuale accurato dell'interfaccia utente, ma questo non è qualcosa che la maggior parte dei programmatori è in grado o disposto a fare per tutte le piattaforme.

L'approccio di Swing a questo era semplicemente quello di evitare i toolkit nativi quando possibile. Non è nativo, e non prova ad essere: invece, cerca di creare qualcosa che sembrerà (quasi) lo stesso indipendentemente da dove viene eseguito. Piuttosto che cercare (futilmente) di accontentare tutti, ha cercato di accontentarsi, e mentre è riuscito fino a quel punto, ci si può chiedere quanto sia efficace il risultato per la più ampia comunità di utenti.

C'è un compromesso tra l'aspettarsi che la tua applicazione sia il più naturale possibile su ogni sistema e aspetta che la tua applicazione funzioni allo stesso modo su ogni sistema. Non esiste una scelta "giusta".

Inoltre, anche se scegli il lato "dall'aspetto naturale", potresti voler proteggere gli utenti del tuo kit di strumenti grafici contro i "miglioramenti" nei componenti e API nativi sottostanti che potrebbero interrompere la loro applicazione in modo imprevisto.

Questo è il motivo per cui alcuni sviluppatori di toolkit GUI preferiscono fornire i propri componenti che imitano quelli nativi, ma forniscono la loro implementazione. D'altra parte lo sviluppo di un toolkit GUI funzionalmente completo è uno sforzo significativo e le considerazioni economiche possono portare a tagliare alcuni bordi.

Si noti che questo problema non è specifico di Java, ma è affrontato da ogni azienda che produce toolkit indipendenti dalla piattaforma.

È tutto merito della cronologia.

Sun desiderava che tutto il software Java funzionasse allo stesso modo su tutte le macchine.

Perché il software "appaia nativo" deve funzionare come un altro software sul sistema operativo specificato.

Sun ha fatto tutto ciò che era in suo potere per rendere difficile la scrittura di software Java integrato in un sistema operativo, in quanto qualsiasi integrazione con un sistema operativo avrebbe consentito al software di funzionare in modo diverso su ciascun sistema operativo.

In questi giorni pochissimi programmatori Java si preoccupano di qualsiasi cosa che non sia il software basato su server web.

Sun ha ucciso Java sul desktop incanalando tutti i programmatori che utilizzavano i sistemi basati su java di Microsoft, quindi fare in modo che qualsiasi programmatore che scelga Java nei primi giorni sembrasse scadente.

Chiunque stia scrivendo software desktop a cui interessa "apparire nativo" ha imparato molto tempo fa a non utilizzare Java e le sue opinioni sono rinforzate ogni volta che usano un qualsiasi software Oracle.

Quindi di questi tempi non vi è alcuna richiesta che "appaia nativo" sul software desktop dai programmatori Java.

Quello che pensi è native è in realtà app native che fanno le loro cose mentre toolkit come SWT seguono gli standard pubblicati per l'interfaccia utente di quel sistema operativo. Il problema è che nessuno costruisce app seguendo quegli standard così quando si attiva un'applicazione Java. Sembra non essere nativo. Ad esempio, quasi tutti i progetti di Microsoft (Office, Outlook, ecc.) Non possono essere riprodotti visivamente utilizzando i controlli standard di Windows.

Andrà ancora peggio dato che sia Microsoft che Apple aggiungono funzionalità UI dinamiche alle loro piattaforme OS. Permettendo agli sviluppatori di applicare skin / style alle loro app nello stesso modo in cui i web design creano stili per i siti web.

Java sulla piattaforma Android sta seguendo questo percorso. Rendere gli elementi dell'interfaccia utente per Android definiti in XML con stili modificabili.

Java non è mai stato molto popolare come piattaforma desktop. Di conseguenza questi cambiamenti nel settore non si propagano ai tempi del desktop. Non ci sono abbastanza sviluppatori disposti a perdere tempo per risolvere il problema.

Quale sistema operativo vuoi sembrare "nativo" anche?

Solo non puoi essere nativo per tutti loro il 100% delle volte.

SWT ecc. sono l'approccio migliore per apparire come nativi per tutti loro quando arriva quando devi raggiungere alcuni compromessi .

E infatti, questo compromesso inizia a diventare sempre più difficile da raggiungere; non tanto a causa dei sistemi operativi, ma a causa dei dispositivi di input. Per i touchscreen, devi in effetti progettare in modo diverso, perché non c'è il pulsante destro del mouse. Pertanto, è necessario fornire la stessa funzionalità altrimenti.

Non ci sarà mai un pulsante magico che sposta la funzionalità "intuitivamente" dal pulsante destro del mouse su guest, senza tu specificando ogni aspetto dettagliato per ogni singolo dispositivo di input (a quel punto, sei nativo ad ogni piattaforma che hai considerato, ma comunque non-nativo per nessuno dei quali hai non considerato).

Davvero una buona domanda. Mi sono sempre chiesto questo per alcuni anni successivi in passato, ho pensato che ci fosse qualche ragione legittima, ma non ce n'è davvero.

Penso che la risposta sia piuttosto semplice, e molte risposte non stanno davvero analizzando il problema.

Se il tuo linguaggio consente di disegnare piexel sullo schermo, è possibile creare al 100% un framework gui basato su di esso che imiterà i controlli del form di Windows. sentire esattamente.

Poiché Java è multipiattaforma, è anche possibile assicurarsi che, in base al tipo di sistema corrente in esecuzione (Mac / Windows), l'interfaccia utente scelga di apparire diversa su entrambe le piattaforme, facendo corrispondere lo stile della piattaforma di runtime.

Come puoi vedere in XAML, ad esempio, l'interfaccia utente può essere facilmente presentata in una forma e in una lingua molto strutturati. La scelta dei comportamenti "nativi" è anche possibile se si impiega tempo per farlo.

Quindi sarebbe possibile creare un framework GUI che consentirebbe agli sviluppatori Java di ottenere applicazioni che sembrerebbero native su Mac e Windows.

Quindi arriviamo a Swing, questo è solo un framework GUI dal potenziale infinito di framework GUI che potrebbero essere creati per Java. Si comporta come è stato programmato, che non segue il processo di cui sopra e ottieni app stranamente su entrambi i sistemi. Questa è la scelta fatta dagli sviluppatori di Swing, nessuno li ha obbligati a farlo e a comportarsi in quel modo.