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

Per le applicazioni destinate a più piattaforme, vedo principalmente due approcci di sviluppo:

• Scegli una piattaforma di sviluppo simile a JAVA. Avere una soluzione di codice e consentire al runtime intermedio di gestire piattaforme diverse. Se qualcosa va storto su qualsiasi piattaforma, modifica leggermente il codice. Ma mantienilo per tutti.

• Crea codice modulare che separa la logica di base e l'interfaccia utente. Sviluppa interfacce utente separate per le rispettive piattaforme che chiameranno le stesse librerie principali. Compilare l'applicazione separatamente per ciascuna delle piattaforme di destinazione.

Quindi, quale seguire? Lo so, la risposta inizierà con " Dipende ". Ma voglio sentire le tue opinioni su questi approcci e sui fattori da considerare per sceglierne uno qualsiasi.

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

Detto questo, ci sono alcuni tipi di applicazioni per le quali potrebbe non essere adatto: vengono in mente reti di basso livello, così come l'elaborazione grafica / video pesante.

Scegli HTML5. Qualsiasi piattaforma con un browser HTML5 può eseguire l'applicazione. Sebbene HTML5 non sia ancora pronto per un grande periodo, l'approccio all'applicazione Web lo è.

Nell'editor audio di Audacity utilizziamo wxWidgets come nostra libreria multipiattaforma. Dato che dobbiamo collegarci alle librerie C e abbiamo bisogno di velocità e accesso a 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 lavora su ciascuna delle tre piattaforme (Mac, Windows Linux), perché anche usando la libreria multipiattaforma è troppo facile per un cambiamento su una macchina spezzare le cose su un'altra.

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

Come sviluppatore in tempo reale, ho usato 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 - rete, audio, streaming di dati - in questo caso è l'interfaccia hardware di basso livello che è specifica della piattaforma.

L'ho fatto in questo modo per diversi motivi:

1) Per ottenere prestazioni ottimali su ciascuna piattaforma

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

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

Dipende da ciò che è importante per te :)

Quando abbiamo affrontato questa scelta per un'app Mac / Windows multipiattaforma circa 10 anni fa, abbiamo dato una buona occhiata alle varie opzioni multipiattaforma: Java, Qt, wxWidgets ecc. Il problema che abbiamo avuto era che l'aspetto e la sensazione di l'interfaccia utente era davvero importante per noi e tutte le app "multipiattaforma" sembravano ben compromesse. Abbiamo finito per mordere il proiettile e costruire il nostro core multipiattaforma, con un'interfaccia utente personalizzata per ogni piattaforma in cima (scritta in PowerPlant per Mac e MFC su Windows). Con il passare del tempo siamo diventati piuttosto bravi e la parte "multipiattaforma" è diventata più spessa senza compromettere l'interfaccia utente.

Ora stiamo esaminando di nuovo questa decisione per un nuovo progetto. Guardando le opzioni ora, probabilmente andrei con Qt: è gratuito e sembra davvero maturato bene. Java potrebbe essere stata un'opzione, ma non possiamo davvero subire il successo delle prestazioni (stiamo elaborando immagini 3D).

Se l'interfaccia utente è davvero importante per te, sospetto che dovrai investire un bel po 'di tempo per ottenere le cose che sembrano giuste su ogni piattaforma se usi qualcosa come Qt o fai il tuo. Per un'app interna o specializzata in cui gli utenti potrebbero accettare di più un'interfaccia utente meno nitida, potrebbe andare bene!

Tutti si preoccupano che lingue come Java siano "multipiattaforma", ma quello di cui stanno veramente parlando è che puoi compilare una volta ed eseguire ovunque. Anche in un linguaggio come Java (o C # / mono) avrai ancora bisogno di livelli di astrazione per gestire dettagli specifici del sistema operativo in alcune aree.

Il C ++, e in effetti la maggior parte delle lingue, sono multipiattaforma, devi solo compilare per indirizzare 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 il test su tutte le piattaforme di destinazione prima di effettuare il check-in del codice - Ciò ovviamente significa assicurarsi che ogni sviluppatore abbia accesso al numero appropriato di macchine / vms.
3. Estratto bene. Estrarre tutto ciò che chiama in api native. Scrivi librerie che avvolgono queste chiamate.
4. Se stai facendo qualcosa al di là dell'interfaccia utente dei moduli abbastanza semplice che si rivolge solo al minimo comune denominatore, accetta semplicemente che il codice GUI non sia multipiattaforma. Estrarre il livello di interfaccia grafica / presentazione e codificarlo separatamente per ciascuna piattaforma. Sì, ci sono toolkit GUI multipiattaforma, che vanno bene per le app semplici ma se stai facendo qualcosa di più avanzato vorrai codificare sulle funzionalità della piattaforma nativa.

Questi passaggi sono uguali, indipendentemente dal linguaggio / set di strumenti / framework utilizzato.

Sfrutta il Web!

Scherzi a parte, se vuoi il massimo 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 in più da scaricare per gli utenti! (In genere, a meno che tu non voglia qualcosa di elegante e usi Flash o Silverlight)
• Tutti i componenti comuni sono sul lato server e possono essere Java, .NET, PHP o un miscuglio di un gruppo di componenti esistenti che hai. Al cliente non dovrebbe importare!

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

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

Fai prima una prova di concetto.

Se si tratta di un'applicazione ragionevolmente complessa, la definizione di una bozza di concetto ti darà un'idea delle caratteristiche linguistiche di cui hai bisogno e delle aree di cui avrai bisogno per sfruttare il framework o le librerie di terze parti.

Le funzionalità linguistiche e le librerie di cui hai bisogno determineranno quale lingua finirai per scegliere (e, quindi, come affrontare il supporto multipiattaforma)

Ho creato un sistema, a partire da un'app 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 dovevo avere un core in C ++ e l'ho progettato fin dall'inizio per essere multipiattaforma, incluso l'utilizzo di tipi di dimensioni (ad esempio int32 anziché int o long), in modo che potesse funzionare su Mac, Windows e UNIX (pre-Linux giorni).

All'epoca ho provato a cercare un buon ambiente UI multipiattaforma, ce n'erano alcuni tra cui XVT. Ho seguito l'addestramento 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 pulito e nativo sulla piattaforma (a partire dal Mac). Così ho rinunciato a quell'idea e ho creato un'interfaccia utente nativa per Mac (PowerPlant) sul core portatile.

Un paio di anni dopo, siamo passati a Windows (UI in MFC). La seconda volta è stato più veloce creare un'interfaccia utente, abbiamo mantenuto per un breve periodo un'interfaccia utente parallela per Mac e Windows e poi siamo passati a Windows. Il core in seguito si è spostato su varie versioni di UNIX e Linux, per consentirci di eseguire calcoli basati su server. Il core ha funzionato bene, con alcune modifiche quando lo abbiamo reso pronto per 64 bit.

Ora sono tornato a utilizzare un Mac e vorrei poter tornare sul Mac, ma le dimensioni e la complessità dell'app rendono questa una scelta difficile. Ha ancora senso che gran parte di questa app sia un'app desktop - è come un ambiente CAD. Ma piuttosto che ricostruire l'interfaccia utente in un linguaggio C / C ++ specifico della piattaforma (e continuare a mantenere un'interfaccia utente basata su MFC), sono più propenso a riscrivere l'intero stack in Java in modo che possa funzionare su più piattaforme.

Potrebbero esserci ancora motivi per eseguire un core non Java, ad esempio C ++. Ma vorrei voler eseguire i primi test delle prestazioni per vedere se era davvero necessario. E guarderei attentamente la mia interfaccia utente per vedere se potevo costruirla come un'app Web, connessa al core tramite servizi Web, in modo da poter avere una 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: per quanto tempo rimarrà la tua app? Quanto diventerà complesso? Se hai qualche idea al riguardo, considera la possibile longevità di tutte le librerie dell'interfaccia utente che stai utilizzando e la tua capacità nel tempo di avere persone che le aiutano a mantenerle. Questo può essere difficile da considerare ora, ma vale la pena pensarci.

- Alex

Se riesci a renderla un'app Web, rendila un'app Web. Utilizzando toolkit come ExtJS , è relativamente facile realizzare interfacce utente compatibili con browser compatibili con l'interfaccia grafica.

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

Il tuo secondo approccio è appropriato se vuoi che l'app appaia e si senta nativa su ogni piattaforma di destinazione. Le app native per Mac hanno un aspetto diverso rispetto alle app native di Windows, solo l'utilizzo di un'altra skin e combinazioni di tasti non sarà sufficiente per coprirlo.