Perché è difficile far apparire nativo un programma Java?

La maggior parte delle applicazioni Java non ha lo stesso aspetto delle applicazioni C / C ++. Swing potrebbe essere stato progettato apposta per avere un aspetto distinto, ma sulla base di ciò che ho letto, SWT, ad esempio, ha provato a "sembrare nativo", e non ha completamente successo.

La mia domanda è:

Perché è difficile per gli sviluppatori del linguaggio Java progettare un sistema GUI che copia esattamente l'aspetto delle GUI native? Cosa c'è di diverso nelle GUI native? Non si tratta solo di progettare pulsanti che sembrano pulsanti "nativi"? O va più in profondità?

Non si tratta solo di progettare pulsanti che sembrano pulsanti "nativi"?

Beh, una specie di, per i pulsanti. Ma questo potrebbe essere più difficile di quanto immagini. Al giorno d'oggi la grafica utilizzata per rappresentare i componenti della GUI non è così semplice come le bitmap casuali che sono allungate (poiché non si adattano affatto molto bene) - sono spesso grafiche basate su vettori con molti casi angolari programmati al loro interno ( quindi quando il pulsante raggiunge il bordo dello schermo può apparire leggermente diverso, ad esempio.) E, naturalmente, avrai bisogno di una grafica diversa quando si fa clic su un pulsante. Per motivi di copyright, gli sviluppatori spesso non possono semplicemente usare completamente questi elementi grafici esistenti, quindi devono essere ricreati - e mentre fanno un buon lavoro per la maggior parte, inevitabilmente alcune cose si perdono, data l'enorme varietà di componenti grafici là fuori.

Sto dicendo tutto quanto sopra basato su Swing, che è ovviamente un toolkit GUI leggero e non nativo. Si menziona specificamente SWT che non sembra nativo, il che è un po 'strano, perché SWT è nativo. È un toolkit che utilizza JNI sottostante per chiamare componenti nativi - quindi se qualcosa non sembra proprio lì, non sarà a causa dell'aspetto grafico.

Esistono letteralmente una mezza dozzina di toolkit che potrebbero essere considerati "nativi" su alcuni sistemi. Alcuni di questi hanno concetti o capacità piuttosto unici e replicarli in un toolkit multipiattaforma è noioso. Il look & feel di un'applicazione non è determinato solo da una "skin", ma anche dal layout e da come si comporta. Alcune considerazioni:

• In una finestra di dialogo, da quale parte appartiene il pulsante "OK" - a sinistra o a destra? Abbastanza giusto, costruiamo una finestra di dialogo separata per ciascun sistema.
• Come contrassegniamo il pulsante predefinito su uno schermo? Colorazione del colore, carattere grassetto, ingrandimento del pulsante? Abbastanza giusto, mettiamolo in un foglio di stile.
• Su Windows, il concetto di "Ribbon" è piuttosto nativo. Come verrebbe tradotto in Mac, dove la barra multifunzione non è comune? Abbastanza giusto, dimentichiamo il layout esatto in pixel e forniamo un'implementazione della barra degli strumenti diversa per ogni sistema.
• La barra dei menu fa parte della finestra (Windows, facoltativamente KDE) o si trova nella parte superiore dello schermo (Mac, Unity)? Abbastanza giusto, scriviamo un'implementazione diversa per ciascun sistema, poiché abbiamo già eliminato il layout esatto per pixel
• Come vengono visualizzati i caratteri? Più nitido possibile o liscio e antialiasing? E quale font dovrebbe essere usato? Si noti che caratteri diversi hanno metriche diverse, quindi lo stesso paragrafo reso alla stessa larghezza può avere un numero diverso di linee a seconda del carattere.
• Lo sfondo di una finestra è un singolo colore, un'immagine o una sfumatura? Mettiamolo anche in un foglio di stile.
• Come appaiono le barre di scorrimento? Dove sono i pulsanti - se ne hanno? Quanto sono larghi o vengono rivelati solo quando il puntatore si sposta in una determinata regione?
• Come incorporiamo altre combinazioni 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 multipiattaforma di Java). L'unica soluzione realistica è dimenticare il layout esatto dei pixel e scrivere su un'interfaccia comune che si astragga su toolkit specifici del sistema. La soluzione adottata da Swing è emulare vari sistemi, che falliscono in modo spettacolare.

E poi c'è coerenza multipiattaforma, l'idea che la tua app possa apparire esattamente la stessa 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 al tuo design nella versione di Windows, ecc.

Ciò viene escluso quando hai 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: sarebbero necessarie due GUI, ma non molte applicazioni fanno così tante storie. Invece mirano a "sembrare ok sulla maggior parte dei sistemi" - questo sembra ancora un po 'estraneo, ma è utilizzabile e molto più facile da sviluppare.

Non è difficile creare un pulsante che assomigli a un pulsante OSX, a un pulsante Windows o a quello di 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 è l'aspetto di un pulsante". Esistono molte differenze più sottili, dalla spaziatura tra gli elementi dell'interfaccia utente all'ordine in cui alcune azioni ben note dovrebbero apparire in un elenco all'esatta posizione della finestra di dialogo Preferenze / Opzioni nel sistema di menu. Si possono automatizzare i casi più comuni per interfacce utente molto semplici, ma molte attività della UI, se non la maggior parte, richiedono un tocco molto più fine.

SWT ha provato ad automatizzarlo in una certa misura e, ancora una volta, lo fa bene per semplici attività dell'interfaccia utente. Ma non esiste una soluzione unica per tutti, e quindi quando le interfacce utente diventano più complesse, i metodi di base che utilizza iniziano a cadere a pezzi. È generalmente possibile riportarlo in linea con un accurato lavoro di interfaccia utente manuale, 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 ogni volta che fosse possibile. Non è nativo e non cerca di essere: invece, cerca di creare qualcosa che sembrerà (quasi) lo stesso, indipendentemente da dove viene eseguito. Invece di provare (inutilmente) a piacere a tutti, ha provato a piacere a se stesso, e mentre ci è riuscito, ci si può chiedere quanto sia efficace il risultato per la più ampia comunità di utenti.

C'è un compromesso tra l'aspettarsi che l'applicazione appaia il più naturale possibile su ogni sistema e che si aspetti che l'applicazione funzioni allo stesso modo su ciascun sistema. Non esiste una scelta "giusta".

Inoltre, anche se scegli il lato "dall'aspetto naturale", potresti voler proteggere gli utenti del tuo toolkit grafico da "miglioramenti" nei componenti e nell'API nativi sottostanti che potrebbero interrompere inaspettatamente la loro applicazione.

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

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

È tutto dovuto alla storia.

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

Affinché il software "appaia nativo" deve funzionare allo stesso modo di altri software su un determinato sistema operativo.

Sun ha fatto tutto il possibile per rendere difficile la scrittura di software Java integrato con un sistema operativo, poiché qualsiasi integrazione con un sistema operativo avrebbe fatto funzionare il software in modo diverso su ciascun sistema operativo.

In questi giorni pochissimi programmatori Java si preoccupano di qualcosa di diverso dal software basato su web server.

Sun ha ucciso Java sul desktop bloccando tutti i programmatori che utilizzavano i sistemi basati su Microsoft Java, facendo apparire brutto qualsiasi programmatore che scelse Java all'inizio.

Chiunque scriva software desktop che si preoccupa di "apparire nativo" ha imparato molto tempo fa a non usare Java e ha le proprie opinioni rafforzate ogni volta che usano qualsiasi software Oracle.

Pertanto in questi giorni non c'è richiesta di "apparire nativi" sul software desktop da programmatori Java.

Quello che pensi è in nativerealtà app native che fanno le proprie cose mentre i toolkit come SWT seguono gli standard pubblicati per l'interfaccia utente di quel sistema operativo. Il problema è che nessuno crea app seguendo questi standard, quindi quando si avvia un'app 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à anche peggio quando Microsoft e Apple aggiungeranno funzionalità UI dinamiche alle loro piattaforme OS. Consentire agli sviluppatori di skin / style le loro app allo 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 personalizzabili.

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

Quale sistema operativo vuoi sembrare anche "nativo"?

Non puoi essere nativo di tutti loro il 100% delle volte.

SWT ecc. Sono l'approccio migliore per apparire come nativi di tutti loro come si arriva quando è necessario raggiungere un compromesso .

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 effettivamente progettare diversamente, perché non esiste un pulsante destro del mouse. Pertanto, è necessario disporre della stessa funzionalità altrimenti.

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

Davvero una bella domanda. Mi sono sempre chiesto a me stesso per alcuni anni successivi in ​​passato, ho pensato che ci fosse una ragione legittima dietro questo, ma in realtà non lo è.

Penso che la risposta sia piuttosto semplice e molte risposte non stanno davvero scavando nel problema.

Se la tua lingua consente di disegnare piexel sullo schermo, è possibile creare al 100% un framework gui basato su di esso che imiterà l'aspetto e il controllo dei moduli di Windows con precisione.

Poiché Java è multipiattaforma, è anche del tutto possibile assicurarsi che, in base all'interfaccia utente del tipo di sistema in esecuzione (Mac / Windows), sceglierebbe di apparire diverso su entrambe le piattaforme, adattandosi allo stile della piattaforma di runtime.

Come puoi vedere in XAML, ad esempio, l'interfaccia utente può essere facilmente presentata in forma e linguaggio molto strutturati. La scelta dei comportamenti "nativi" è anche possibile se si impiega del 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 potrebbe essere creato per Java. Si comporta come è stato programmato, il che non segue il processo sopra descritto e ottieni app dall'aspetto strano su entrambi i sistemi. Questa è la scelta fatta dagli sviluppatori di Swing, nessuno li ha costretti a fare questo e comportarsi in quel modo.