Quale approccio seguire per lo sviluppo di applicazioni rivolte a più piattaforme?

A parte i litigi tra Oracle / Apache / Google, è ancora difficile battere la JVM per questo scopo. È davvero di altissima qualità su molte piattaforme, universale, e hai un buon numero di lingue tra cui scegliere (Java, Clojure, Scala ecc.). Ti consente di scegliere come target una singola architettura della macchina (la VM) e non preoccuparti troppo dell'hardware specifico dell'utente finale.

Detto questo, ci sono alcuni tipi di applicazioni che potrebbero non essere adatti per: il networking di basso livello mi viene in mente, così come l'elaborazione grafica / video pesante.

Vai per HTML5. Qualsiasi piattaforma con un browser HTML5 può eseguire la tua applicazione. Sebbene HTML5 non sia ancora pronto per il grande momento, l'approccio dell'applicazione Web è.

Nell'editor audio di Audacity utilizziamo wxWidgets come libreria multipiattaforma. Dal momento che dobbiamo collegarci alle librerie C, e abbiamo bisogno di velocità e accesso di basso livello, un approccio JVM non funzionerebbe per noi. Il codice GUI è uguale al 95% su tutte le piattaforme. Usiamo #ifdefs per le piccole variazioni. Tuttavia, riteniamo essenziale avere uno sviluppatore che lavori su ciascuna delle tre piattaforme (Mac, Windows Linux), perché anche usando la libreria multipiattaforma è troppo facile cambiare una macchina per rompere le cose su un'altra.

Se riesci a ottenere le prestazioni di cui hai bisogno, vai su JVM. Se non puoi, usa QT o wxWidgets, e ti suggerirei QT su wxWidgets poiché è meno faticoso farlo sembrare bello.

Come sviluppatore in tempo reale, ho utilizzato con successo un'opzione simile a 2 - moduli specifici della piattaforma separati con un'API comune utilizzata dalla logica principale. Tuttavia, nulla di ciò che ho fatto ha avuto un'interfaccia utente - networking, audio, streaming di dati - in questo caso è l'interfaccia hardware di basso livello specifica per la piattaforma.

L'ho fatto in questo modo per diversi motivi:

1) Per ottenere le prestazioni ottimali su ogni piattaforma

2) Per sfruttare le funzionalità offerte solo su 1 piattaforma

3) (J) VM non esistevano per alcune piattaforme (sistemi embedded, console di gioco ...)

Dipende da cosa è importante per te:)

Quando abbiamo affrontato questa scelta per un'app per Mac / Windows multipiattaforma circa 10 anni fa, abbiamo dato un'occhiata alle varie opzioni multipiattaforma: Java, Qt, wxWidgets ecc. Il problema era che il look e la sensazione dell'interfaccia utente era davvero importante per noi, e tutte le app "cross-platform" apparivano, beh, compromesse. Abbiamo finito per mordere il proiettile e costruire il nostro core multipiattaforma, con un'interfaccia utente personalizzata per ogni piattaforma in cima (scritto in PowerPlant per Mac e MFC su Windows). Nel corso del tempo siamo stati abbastanza bravi in questo, e la parte "multipiattaforma" è diventata più spessa senza compromettere l'interfaccia utente.

Ora stiamo esaminando nuovamente questa decisione per un nuovo progetto. Guardando le opzioni ora, probabilmente andrei con Qt - è gratis e sembra davvero maturato bene. Java potrebbe essere un'opzione, ma non possiamo davvero prendere il colpo di prestazioni (stiamo facendo l'elaborazione 3D delle immagini).

Se l'interfaccia utente è davvero importante per te, ho il sospetto che dovrai investire un bel po 'di tempo per sistemare le cose su ciascuna piattaforma, indipendentemente dal fatto che tu usi qualcosa come Qt o fai il rollup. Per un'app interna o specialistica in cui gli utenti potrebbero accettare più facilmente un'interfaccia utente meno sofisticata, potrebbe andar bene!

Ognuno di noi fa un gran baccano su linguaggi come Java essendo "multipiattaforma", ma quello di cui stanno realmente parlando è che puoi compilare una volta ed eseguire ovunque. Anche in un linguaggio come Java (o C # / mono) hai ancora bisogno di livelli di astrazione per gestire i dettagli specifici del sistema operativo in alcune aree.

C ++, e in effetti la maggior parte delle lingue, sono multipiattaforma, devi solo compilare per scegliere come target ciascuna piattaforma.

La chiave è il processo piuttosto che gli strumenti / le lingue:

1. Assicurati di avere un processo di compilazione integrato che costruisca ed esegua i test unitari per tutte le piattaforme di destinazione .
2. Assicurati che ogni sviluppatore esegua test su tutte le piattaforme di destinazione prima di effettuare il check-in - Questo ovviamente significa assicurarsi che lo sviluppatore abbia sempre accesso al numero appropriato di macchine / vms.
3. Estratto bene. Riassumi tutto ciò che chiama in apis nativo. Scrivi librerie che avvolgono queste chiamate.
4. Se stai facendo qualcosa che va oltre l'interfaccia utente di forme abbastanza semplici che si rivolge solo al minimo comune denominatore, accetta solo che il codice GUI non sia multipiattaforma. Riassumi la tua GUI / livello di presentazione e codificalo separatamente per ogni piattaforma. Sì, ci sono toolkit GUI multipiattaforma, che vanno bene per le app semplici, ma se stai facendo qualcosa di più avanzato vorrai codificare le funzionalità della piattaforma nativa.

Questi passaggi sono gli stessi indipendentemente dalla lingua / set di strumenti / framework che usi.

Sfrutta il Web!

Seriamente, se vuoi IL PIÙ BELLO per il tuo dollaro, scrivi un'applicazione web.

Perché?

• I client Web non richiedono in genere molta potenza del PC.
• I client Web sono OVUNQUE. Non solo PC / MAC / Linux, ma su telefoni, dispositivi mobili e altro.
• Niente di più da scaricare per gli utenti! (In genere, a meno che tu non voglia qualcosa di sofisticato e usi Flash o Silverlight)
• Tutti i componenti comuni sono sul lato server e possono essere Java, .NET, PHP o un miscuglio di componenti esistenti che hai. Il cliente non dovrebbe preoccuparsi!

Anche i due approcci che hai menzionato sono molto simili. Il browser Web esegue il rendering HTML per più architetture sottostanti. Allo stesso modo, la JVM interpreta il codice Java in un modo che ha senso per l'hardware sottostante. Il web, tuttavia, ha semplicemente una base di clienti più ampia!

Ho avuto abbastanza fortuna con Mono. Posso scrivere lo stesso codice per macchine Windows come faccio per Macchine Linux, e per la maggior parte, funziona su entrambi. E posso usare le abilità che conosco già in C # e Winforms.

Fai prima una prova del concetto.

Se si tratta di un'applicazione ragionevolmente complessa, inchiodare una dimostrazione del concetto ti darà un'idea delle funzionalità linguistiche necessarie e di quali aree hai bisogno per sfruttare le librerie di framework o di terze parti.

Le caratteristiche linguistiche e le librerie necessarie determineranno quale lingua sceglierai (e quindi, come andrai ad approcciarti al supporto multipiattaforma)

Ho costruito un sistema, a partire da un'applicazione desktop, 15 anni fa, quando Java era ancora agli inizi e non era pronto per l'uso nella creazione di questo tipo di app. Sapevo che avevo bisogno di avere un core in C ++ e progettato dall'inizio per essere multipiattaforma, incluso l'utilizzo di tipi di dimensioni (ad esempio int32 anziché int o long), in modo che potesse essere eseguito su Mac, Windows e UNIX (pre-Linux giorni).

Quando ho provato a cercare un buon ambiente dell'interfaccia utente multipiattaforma, ce n'erano alcuni che includevano XVT. Ho seguito il corso di formazione per XVT e quando ho iniziato a creare un'app reale, mi sono reso conto che non sarei stato in grado di creare un aspetto e una sensazione nativi chiari sulla piattaforma (a partire dal Mac). Quindi ho rinunciato a questa idea e ho creato un'interfaccia utente nativa per Mac (PowerPlant) sulla parte superiore del nucleo portatile.

Un paio di anni dopo, ci siamo spostati su Windows (interfaccia utente in MFC). È stata più veloce la costruzione di un'interfaccia utente per la seconda volta, abbiamo mantenuto un Mac e l'interfaccia utente di Windows in parallelo per un breve periodo di tempo e poi sono passati a Windows. In seguito, il core è passato a varie versioni di UNIX e Linux, per consentirci di eseguire calcoli basati su server. Il core ha funzionato bene, con alcuni aggiustamenti quando lo abbiamo reso pronto per 64 bit.

Ora torno a utilizzare un Mac e vorrei poter tornare sul Mac, ma la dimensione e la complessità dell'app rendono questa scelta difficile. Ha ancora senso che gran parte di questa app sia un'app desktop: è come un ambiente CAD. Invece di costruire nuovamente l'interfaccia utente in un linguaggio C / C ++ specifico della piattaforma (e continuare a mantenere un'interfaccia utente basata su MFC), sono più incline a riscrivere l'intero stack in Java in modo che possa essere eseguito su più piattaforme.

Potrebbero esserci ancora motivi per eseguire un core non Java, ad esempio C ++ come abbiamo fatto. Ma vorrei essere in grado di eseguire test prestazionali precoci per vedere se fosse davvero necessario. E guarderei attentamente la mia interfaccia utente per vedere se potevo costruirla come un'app Web, connessa al nucleo tramite servizi Web, in modo da poter avere una vasta gamma di client: app desktop, app mobili, app web, ecc. Se avessi bisogno di un pezzo in C o C ++, potrebbe essere scritto sotto uno strato di Java? O come servizio web?

Un'altra considerazione: quanto durerà la tua app? Quanto sarà complesso diventare? Se hai qualche idea su questo, considera la possibile longevità di tutte le librerie UI che stai utilizzando e la tua capacità nel tempo di aiutare le persone a mantenerle. Questo può essere difficile da considerare ora, ma vale la pena pensarci.

- Alex

Se puoi renderlo un'app Web, rendila un'applicazione web. Utilizzando toolkit come ExtJS , è relativamente facile creare interfacce utente compatibili con i browser compatibili con la GUI.

Altrimenti, Java o QT + C ++ o C + Wx sono opzioni possibili per avere una fonte per tutti.

Il tuo secondo approccio è appropriato se vuoi che l'app sia originale su ogni piattaforma di destinazione. Le app native di Mac hanno un aspetto diverso rispetto alle app native di Windows, basta usare un altro skin e le keybind non saranno sufficienti a coprirlo.