2012-05-17 15 views
38

Sono in cerca di alternative da sviluppare per più piattaforme mobili e ho trovato Codename One, che utilizza Java come lingua franca, anziché HTML/CSS/JS o linguaggi di scripting.Come funziona Codename One?

Quello che non ho trovato è come funziona. Raggruppa una JVM con l'applicazione per iOS e Win7 e utilizza Dalvik in Android? Traduce il codice sorgente in nativo e abbiamo accesso a questo codice sorgente? C'è altra magia, visto che promettono "nessun compromesso"? Quali limitazioni dovrei essere a conoscenza durante la codifica di Java agnostico?

Colpo preventivo: questa è una domanda su Codename One, non su quale multipiattaforma dovrei scegliere o se dovrei diventare nativo o se dovrei andare sul web.

risposta

66

Codename One utilizza un approccio basato su SaaS, quindi questo potrebbe (e probabilmente lo farà) cambiare in futuro per adattarsi a architetture migliorate. Si noti che Codename One fornisce anche un'opzione a build offline, il che significa che le società che hanno politiche che vietano tali architetture cloud possono ancora utilizzare Codename One con qualche sovraccarico/complessità aggiuntivi.

Attualmente su Android il codice Java standard viene eseguito così com'è. La sintassi di Java 8 viene tradotta usando retrolambda per tutte le piattaforme quando viene utilizzata. Ciò consente di essere compatibile con tutte le versioni di Android e altre porte.

Su iOS Nome in codice Uno costruito & open source ParparVM che è una VM molto conservativa. ParparVM presenta un GC concorrente (non bloccante) ed è interamente scritto in Java/C. Ciò significa che un progetto xcode viene generato e compilato sui server di compilazione in modo efficace come se si trattasse di un'app nativa e quindi "a prova di futuro" per le modifiche apportate da Apple. Per esempio. con modifiche recenti a 64 bit e bitcode alle build di iOS ParparVM non ha richiesto modifiche per soddisfare tali cambiamenti.

In passato Codename One utilizzava XMLVM per generare codice nativo in un modo molto simile ma la soluzione XMLVM era troppo generica per le esigenze di Codename One.

Le build di iOS sono compilate e firmate su Mac nel cloud utilizzando xcode (lo strumento di creazione Apple ufficiale). Ciò li rende compatibili con i cambiamenti attuali/futuri di Apple e consente agli sviluppatori di utilizzare Windows/Linux mentre si rivolge a iOS. Puoi leggere ulteriori informazioni sulla compatibilità di ParparVM su iOS here.

In passato Codename One supportava Windows Phone utilizzando un convertitore C# che si basava su XMLVM ma non era un approccio ideale. Si noti che il backend XMLVM che si traduce in C# è molto diverso da quello precedentemente utilizzato per la conversione in iOS. Codename One ha scelto discontinue that old backend in quanto non era potente come il nuovo backend UWP e non corrisponde agli obiettivi di Microsofts che vanno avanti e si concentrano su UWP (Universal Windows Platform).

Per supporto desktop e mobile per Windows 10 Codename One utilizza iKVM su target UWP (Universal Windows Platform) e ha aperto le modifiche al codice iKVM originale nello Codename One github repository.

noti che UWP si basa sono fatto su un Windows 10 macchine nel cloud permettendo così agli sviluppatori di utilizzare Mac/Linux o versioni precedenti di Windows quando si costruisce finestre native apps ...

JavaScript costruire obiettivi che sono disponibili su gli abbonati di livello enterprise utilizzano TeaVM per eseguire la traduzione staticamente. TeaVM fornisce supporto per il threading utilizzando JavaScript interrompendo l'app in modo piuttosto elaborato.Per supportare l'UI Codename complesso One utilizza l'API HTML5 Canvas che consente una flessibilità assoluta per la creazione di applicazioni.

Per le versioni desktop Codename One utilizza javafxpackager, poiché entrambi i computer Mac e Windows sono disponibili nel cloud la natura specifica della piattaforma di javafxpackager non è un problema.

Ciò che distingue Codename One è l'approccio che richiede all'interfaccia utente in cui utilizza una "architettura leggera" per consentire all'interfaccia utente di funzionare perfettamente su tutte le piattaforme e di essere sviluppata quasi interamente in Java. È accresciuto dalla capacità di incorporare i widget "pesanti" in posizione tra i "pesi leggeri". Puoi saperne di più su questo in questo blog post. Si noti che in questo momento peering is undergoing some improvements e ora supporta usi più elaborati come la stratificazione.

Un componente leggero è scritto interamente in Java, questo consente agli sviluppatori di visualizzare in anteprima l'applicazione con precisione nei simulatori & GUI.

Codename One raggiunge prestazioni veloci disegnando utilizzando le API di gioco native della maggior parte delle piattaforme, ad es. OpenGL ES su iOS.

Le tecnologie di base di Codename One sono tutte open source e includono la maggior parte delle funzionalità sviluppate da Codename One stesso, ad es. ParparVM ma anche full library, platform ports, designer tool, device skins ecc. È possibile ottenere ulteriori informazioni sull'utilizzo del Codename One source here.

FYI Shai Almog, l'autore di questa risposta, è l'amministratore delegato di Codename One.

+3

Grazie per l'attenzione, Shai! Penso che dovresti metterlo nelle tue FAQ, sappiamo che non c'è nessuna magia _real_ e che ti piace sapere come funziona la magia _perceived_. Probabilmente farò un tentativo in fase di valutazione! –

+4

Non esiste una fase di valutazione per Codename One, la nostra intenzione è di avere sempre un'opzione libera ragionevole per gli sviluppatori senza vincoli. Poiché il prodotto è open source, è importante per noi portare con sé parte di quella libertà anche nei servizi SaaS. –

+0

Mi spiace, mi sono espresso male: P Attualmente sto solo cercando alternative, poi avremo una fase di valutazione, per vedere come le tecnologie soddisfano le nostre esigenze. –

8

Codename one ha adottato un approccio molto equilibrato alla portabilità. Vorrei aggiungere un commento pragmatico.

Dal lato dell'interfaccia utente, CN1 dipinge tutta la sua interfaccia utente sulla tela fornita dalla piattaforma. Cerca di imitare l'aspetto e l'aspetto nativo della piattaforma, se lo si sceglie, ma ha lo stesso successo di Swing con il suo "aspetto nativo della piattaforma", poiché la piattaforma nativa cambia costantemente e "nativo l & f" manca sempre e nella maggior parte dei casi non sembra giusto.

Ma, se si sceglie l'aspetto indipendente dalla piattaforma (che è il tipo di tendenza attuale), non si è limitati dal set di componenti predefinito di Codenameone impostato in alcun modo: è proprio come Swing con il suo aspetto multipiattaforma e sentire ("Metallo" ecc.). Che è buono.

Dal lato della lingua: su iOS è java compilato in C che è quindi legato a Objective-C scritto a mano e non raggruppa VM, ma solo livello di portabilità. La cosa più importante qui è il fatto che java è compilato in C e non in Objective-C, che rendono più veloce il codice Objective-C idiomatico, perché fa invocazioni di metodo virtuali o, più spesso, dirette invece di lenta distribuzione di messaggi Objective C. Che è buono.

Potrebbe anche sembrare un po 'più veloce su Android, perché, mentre si utilizza Dalvik/Art, non utilizza l'interfaccia utente nativa di Android, che è ingombrante rispetto a quella di CN1. Questo può rendere la creazione di UI dinamica più veloce in runtime, il che è positivo.

Uno dei punti di forza dell'approccio CN1 è il suo emulatore (implementato su tela JavaFX desktop) che si utilizza per sviluppare software. L'emulatore utilizza le stesse API di interfaccia utente e portabilità come sulle piattaforme mobili e consente di utilizzare IDE di scelta per il debug. Si riavvia rapidamente e il ciclo di modifica della compilazione è molto sostenibile rispetto ad Android. Che è buono.

Secondo punto molto forte (quello principale!) è la natura aperta della loro libreria UI, tutto il codice nativo e il traduttore bytecode-c. Se dedichi qualche sforzo, puoi evitare di costruire porte Android/iOS nelle loro fattorie e slegarti dalla loro particolare revisione del prodotto (ma non da alcuni servizi a valore aggiunto che offrono, che non sono open source!). A seconda della situazione, questo potrebbe (o non potrebbe!) Essere abbastanza buono per te!

Punto debole di Codenameone è la sua maturità meno-poi-ideale, il che significa che puoi facilmente spararti nel piede usando i componenti di base dell'interfaccia utente, se li usi nel modo in cui non erano destinati ad essere usati. Significa anche che il suo livello di portabilità java non è abbastanza grande (e ha dei buchi) per coprire le necessità di tutti, e potresti dover usare nativo in alcuni posti, e portare anche altre librerie java pure.

Inoltre, lo stato corrente delle prestazioni grafiche non è ottimale; se si ottiene un mucchio di testo sullo schermo, si perderà facilmente 16msec fluid animation/repaint time limit, questo può essere aggirato dal doppio buffering, ma ha anche i suoi limiti. Fortunatamente, c'è ancora spazio per l'ottimizzazione nell'implementazione su entrambe le piattaforme principali, si spera che lo miglioreranno.

Nel complesso, Codenameone ha una buona nicchia come framework multipiattaforma per diverse classi di applicazioni; puoi trovare un valore anche nei loro servizi.