Confronto tra Corona, Phonegap, Titanium


310

Sono uno sviluppatore web e voglio spostare i miei prodotti Web su iPhone. Uno dei prodotti è come Google Maps: mostra la mappa sullo schermo del telefono, puoi trascinare o ridimensionare la mappa e visualizzare alcune informazioni che aggiungiamo alla mappa.

So che ci sono alcune tecnologie che ti consentono di utilizzare HTML, CSS e Javascript per sviluppare app native per iPhone. Ne ho identificati alcuni:

Ci sono altri prodotti simili? Quali sono le differenze tra loro? Quale dovrei scegliere?


1
C'è anche Adobe Flex, che può generare applicazioni per iPhone a partire da giugno 2011. adobe.com/products/flex
neoneye

1
Controlla. Amico ecco un confronto diretto. savagelook.com/blog/portfolio/…
Hikmat Khan,

Risposte:


368

Mi sono registrato con StackOverflow solo allo scopo di commentare la risposta più votata in alto. La cosa negativa è che stackoverflow non consente ai nuovi membri di pubblicare commenti. Quindi devo rendere questo commento più simile a una risposta.

La risposta di Rory Blyth contiene alcuni punti validi sui due framework mobili javascript. Tuttavia, i suoi punti chiave non sono corretti. La verità è che Titanium e PhoneGap sono più simili che diversi. Entrambi espongono le funzioni del telefono cellulare tramite un set di API javascript e la logica dell'applicazione (html, css, javascript) viene eseguita all'interno di un controllo WebView nativo.

  1. PhoneGap non è solo un wrapper nativo di un'app Web. Tramite le API javascript di PhoneGap, la "web app" ha accesso alle funzioni del telefono cellulare come geolocalizzazione, accelerometro, contatti, database, file system, ecc. Fondamentalmente qualsiasi funzione fornita dall'SDK del telefono cellulare può essere "collegata" al mondo javascript. D'altra parte, una normale app Web in esecuzione sul browser Web mobile non ha accesso alla maggior parte di queste funzioni (la sicurezza è il motivo principale). Pertanto, un'app PhoneGap è più un'app mobile che un'app Web. Puoi certamente utilizzare PhoneGap per racchiudere un'app Web che non utilizza alcuna API PhoneGap, ma non è per questo che PhoneGap è stato creato.

  2. Titanium NON compila il tuo codice html, css o javascript in "bit nativi". Sono impacchettati come risorse per il bundle eseguibile, proprio come un file di immagine incorporato. Quando l'applicazione viene eseguita, queste risorse vengono caricate in un controllo UIWebView ed eseguite lì (come javascript, non bit nativi, ovviamente). Non esiste un compilatore javascript-to-native-code (o to-goal-c). Questo viene fatto allo stesso modo anche in PhoneGap. Dal punto di vista architettonico, questi due quadri sono molto simili.

Ora sono diversi? Sì. Innanzitutto, Titanium sembra essere più ricco di funzionalità di PhoneGap collegando più funzioni del telefono cellulare a JavaScript. In particolare, PhoneGap non espone a javascript molti componenti dell'interfaccia utente nativi (se presenti). Titanium, d'altra parte, ha una API dell'interfaccia utente completa che può essere chiamata in javascript per creare e controllare tutti i tipi di controlli nativi dell'interfaccia utente. Utilizzando queste API dell'interfaccia utente, un'app Titanium può apparire più "nativa" di un'app PhoneGap. In secondo luogo, PhoneGap supporta più piattaforme di telefonia mobile rispetto a Titanium. Le API di PhoneGap sono più generiche e possono essere utilizzate su piattaforme diverse come iPhone, Android, Blackberry, Symbian, ecc. Titanium si rivolge principalmente a iPhone e Android almeno per ora. Alcune delle sue API sono specifiche della piattaforma (come le API dell'interfaccia utente di iPhone).

Quindi, se la tua preoccupazione per la tua app è di renderla più "nativa", Titanium è una scelta migliore. Se vuoi essere in grado di "trasferire" la tua app su un'altra piattaforma più facilmente, PhoneGap sarà migliore.

13/08/2010 aggiornato: collegamento alla risposta di un dipendente Titanium alla domanda di Topolino.

Aggiornato il 12/04/2010: ho deciso di dare a questo post una revisione annuale per mantenere aggiornate le sue informazioni. In un anno molte cose sono cambiate e alcune delle informazioni contenute nel post iniziale sono obsolete.

Il cambiamento più grande è arrivato da Titanium. All'inizio di quest'anno, Appcelerator ha rilasciato Titanium 1.0, che si è discostato drasticamente dalle sue versioni precedenti dal punto di vista architettonico. In 1.0, il controllo UIWebView non è più in uso. Invece, chiamate API Titanium per qualsiasi funzione dell'interfaccia utente. Questo cambiamento significa un paio di cose:

  1. L'interfaccia utente dell'app diventa completamente nativa. Non vi è più interfaccia utente Web nella tua app poiché le API native di Titanium assumono il controllo di tutte le esigenze dell'interfaccia utente. Il titanio merita molto credito pionieristico sulla frontiera dell'interfaccia utente nativa multipiattaforma. Offre ai programmatori che preferiscono l'aspetto dell'interfaccia utente nativa ma non amano l'alternativa al linguaggio di programmazione ufficiale.

  2. Non sarai in grado di utilizzare HTML o CSS nella tua app, poiché la visualizzazione Web è sparita. (Nota: è ancora possibile creare una visualizzazione Web in Titanium. Ma ci sono alcune funzionalità di Titanium che è possibile sfruttare nella visualizzazione Web.) Domande e risposte su Titanium: cosa è successo a HTML e CSS?

  3. Non sarai in grado di utilizzare librerie JS popolari come JQuery che presuppongono l'esistenza di un oggetto DOM. Continui a utilizzare JavaScript come linguaggio di codifica. Ma questa è praticamente l'unica tecnologia web che è possibile utilizzare se si arriva a Titanium 1.0 come programmatore web.

Video Titanium: le novità di Titanium 1.0.

Ora, Titanium 1.0 compila il tuo JavaScript in "bit nativi"? No. Appcelerator ha finalmente risolto il problema con questo blog per sviluppatori: Titanium Guides Project: JS Environment. Noi programmatori siamo persone più autentiche di quelle del dipartimento Marketing, no? :-)

Passa a PhoneGap. Non ci sono molte cose nuove da dire su PhoneGap. La mia percezione è che lo sviluppo di PhoneGap non sia stato molto attivo fino a quando IBM non è salito a bordo entro la fine dell'anno. Alcune persone hanno persino sostenuto che IBM sta fornendo più codice a PhoneGap di Nitobi. Che sia vero o no, è bene sapere che PhoneGap è in fase di sviluppo attivo.

PhoneGap continua a basarsi sulle tecnologie web, ovvero HTML, CSS e JavaScript. Non sembra che PhoneGap abbia in programma di collegare le funzionalità dell'interfaccia utente nativa a JavaScript come sta facendo Titanium. Mentre l'interfaccia utente Web è ancora in ritardo rispetto all'interfaccia utente nativa in termini di prestazioni e aspetto nativo, tale divario viene rapidamente colmato. Esistono due tendenze nelle tecnologie Web che garantiscono funzionalità brillanti all'interfaccia utente Web mobile in termini di prestazioni:

  1. Motore JavaScript che si sposta da un interprete a una macchina virtuale. JavaScript è JIT compilato in codice nativo per un'esecuzione più rapida. Motore Safari JS: SquirrelFish Extreme

  2. Il rendering delle pagine Web passa dall'affidarsi alla CPU all'utilizzo dell'accelerazione GPU. Le attività grafiche intense come la transizione di pagina e l'animazione 3D diventano molto più fluide con l'aiuto dell'accelerazione hardware. Composito accelerato GPU in Chrome

Tali miglioramenti che provengono dai browser desktop vengono consegnati rapidamente ai browser mobili. In effetti, da iOS 3.2 e Android 2.0, il controllo della visualizzazione Web mobile è diventato molto più performante e compatibile con HTML5. Il futuro del web mobile è così promettente che ha attratto un bambino grande in città: JQuery ha recentemente annunciato il suo framework web mobile. Con JQuery Mobile che fornisce gadget dell'interfaccia utente e PhoneGap che fornisce le funzionalità del telefono, le due soluzioni combinate creano una piattaforma Web mobile perfetta secondo me.

Dovrei anche menzionare Sencha Touch come un altro framework di gadget per l'interfaccia utente Web per dispositivi mobili. Sencha Touch versione 1.0 è stata recentemente rilasciata con un modello di doppia licenza che include GPLv3. Sencha Touch funziona bene con PhoneGap proprio come JQuery Mobile.

Se sei un programmatore GWT (come me), potresti voler dare un'occhiata a GWT Mobile , un progetto open source per la creazione di app Web mobili con GWT. Include un wrapper PhoneGap GWT che consente l'uso di PhoneGap in GWT.


10
Ehm ... dici che "PhoneGap non è solo un wrapper nativo di un'app Web". Continui a discutere dell'accesso che ti dà alla funzionalità del dispositivo nativo. Penso di averlo trattato quando ho scritto: "Ciò che PhoneGap fornisce oltre a questo è un ponte tra JavaScript e le API dei dispositivi nativi. Quindi, scrivi JavaScript contro le API di PhoneGap e PhoneGap effettua quindi la chiamata nativa corrispondente appropriata. A tale proposito, è diverso dalla distribuzione di una semplice vecchia app Web. " Se ti sei registrato solo per confutare la mia dichiarazione, avresti dovuto leggerlo nella sua interezza. So che i miei post sono lunghi, ma ... comunque.
Rory Blyth,

5
Avrei potuto essere più chiaro, ma i dettagli di quali API sono complicate dal momento che è variato nel tempo da dispositivo a dispositivo, cosa è possibile fare (è migliorato molto, ma la matrice di funzionalità per piattaforme diverse ha subito parecchie revisioni). Ho scritto su una delle differenze chiave e ciò che ho scritto è corretto - in effetti, è in accordo con quello che hai scritto. Hai semplicemente approfondito le API a cui puoi accedere.
Rory Blyth,

9
Per quanto riguarda Titanium e "bit nativi", immagino che il mio errore sia stato leggere questo sul loro sito - proprio sulla prima pagina di Appcelerator: "funzionano alla grande perché abbiamo compilato Titanium in codice nativo per le massime prestazioni". Forse dovresti scrivere loro per far loro sapere che hanno torto. Dai
Rory Blyth il

6
Per ulteriori informazioni, consulta le Domande frequenti su Titanium - il primo argomento, "Sono queste webapp mobili o applicazioni mobili native", tratta in modo succinto il problema. Ripubblicerei un preventivo qui, ma penso che preferiresti ottenerlo direttamente dalla società, poiché sono, credo, le autorità sul loro prodotto: tinyurl.com/ya9topg
Rory Blyth,

4
Dennis, grazie per l'ottima risposta. Stai ancora sviluppando con Titanium? Puoi commentare ora che l'1.7 è atterrato?
PaulM,

193

Da quello che ho raccolto, ecco alcune differenze tra i due:

  • PhoneGap genera fondamentalmente wrapper nativi per quelle che sono ancora app web . Sputa un progetto AnyYourPlatformIs, lo costruisci e lo distribuisci. Se stiamo parlando dell'iPhone (che è dove trascorro il mio tempo), non sembra molto diverso dalla creazione di un lanciatore di app Web (un collegamento che ha la sua icona Springboard, quindi puoi avviarlo come ( come ) un'app nativa). La "app" stessa è ancora html / js / ecc. E funziona all'interno di un controllo del browser ospitato. Ciò che PhoneGap offre oltre a ciò è un ponte tra JavaScript e le API dei dispositivi nativi. Quindi, scrivi JavaScript contro le API di PhoneGap e PhoneGap effettua quindi la chiamata nativa corrispondente appropriata. A tale proposito, è diverso dalla distribuzione di una semplice vecchia app Web.

  • La sorgente di titanio viene compilata in bit nativi. Cioè, il tuo html / js / etc. non sono semplicemente collegati a un progetto e quindi ospitati in un controllo del browser Web, ma trasformati in app native. Ciò significa, ad esempio, che l'interfaccia dell'app sarà composta da componenti dell'interfaccia utente nativi . Ci sono modi per ottenere l'aspetto nativo senza avere un'app nativa, ma ... beh ... che incubo che di solito si rivela.

I due sono simili in quanto scrivi tutti i tuoi contenuti utilizzando le tipiche tecnologie web (html / js / css / blah blah blah) e ottieni l'accesso alla funzionalità nativa tramite API JavaScript personalizzate.

Ma, di nuovo, le app PhoneGap (PhonGapps? Non lo so ... è un nome stupido? È più facile dirlo - lo so molto) che iniziano la loro vita come app web e finiscono le loro vite come app web. Su iPhone, il tuo html / js / ecc. viene appena eseguito all'interno di un controllo UIWebView e le API JavaScript di PhoneGap le tue chiamate js vengono instradate verso API native.

Le app di titanio diventano app native: sono state sviluppate usando la tecnologia di sviluppo web.

Che cosa significa questo in realtà significa ?

  1. Un Titanium app sembrare come un'applicazione "reale", perché, in ultima analisi, è un'applicazione "reale".

  2. Un'app PhoneGap avrà l'aspetto di un'app Web ospitata in un controllo browser perché, in definitiva, è un'app Web ospitata in un controllo browser.

Qual è giusto per te?

  • Se vuoi scrivere app native usando le abilità degli sviluppatori web, Titanium è la soluzione migliore.

  • Se desideri scrivere un'app utilizzando le competenze di sviluppo web che potresti realisticamente distribuire su più piattaforme (iPhone, Android, Blackberry e qualsiasi altra cosa decidano di includere) e se desideri accedere a un sottoinsieme di funzionalità della piattaforma nativa (GPS, accelerometro, ecc.) tramite un'API JavaScript unificata, PhoneGap è probabilmente ciò che desideri.

Potresti chiederti: perché dovrei voler scrivere una PhoneGapp (ho deciso di utilizzare il nome) anziché un'app Web ospitata sul Web? Non riesco ancora ad accedere ad alcune funzionalità del dispositivo nativo in quel modo, ma ho anche la comodità di una vera distribuzione Web piuttosto che forzare l'utente a scaricare la mia app "nativa" e installarla?

La risposta è: perché puoi inviare PhoneGapp all'App Store e addebitarlo. Ottieni anche quell'icona di avvio, che rende più difficile per l'utente dimenticare la tua app (è molto più probabile che dimentichi un segnalibro che un'icona di app).

Potresti sicuramente pagare per l'accesso alla tua app web ospitata sul web, ma quante persone passeranno davvero attraverso il processo per farlo? Con l'App Store, scelgo un'app, tocco il pulsante "Acquista", inserisco una password e ho finito. Si installa. Pochi secondi dopo, lo sto usando. Se dovessi utilizzare l'interfaccia di transazione web mobile unica di qualcun altro, il che probabilmente significa dover toccare il mio nome, indirizzo, numero di telefono, numero CC e altre cose che non voglio toccare, quasi certamente non lo farei non ci riesco. Inoltre, mi fido di Apple: sono sicuro che Steve Jobs non registrerà le mie informazioni e quindi caricherà un sacco di abbonamenti a riviste cattive sul mio CC per i calci.

Ad ogni modo, tranne per il fatto che è coinvolta la tecnologia di sviluppo web, PhoneGap e Titanium sono molto diversi, al punto da essere solo superficialmente comparabili.

Odio le app Web, a proposito, e se leggi le recensioni su iTunes App Store, gli utenti sono abbastanza bravi a individuarle. Non nominerò alcun nome, ma ho un paio di "app" sul mio telefono che sembrano e funzionano come spazzatura, ed è perché sono app Web ospitate all'interno delle istanze di UIWebView. Se avessi voluto usare un'app Web, avrei aperto Safari e, sai, ne avrei spostato uno. Ho comprato un iPhone perché voglio cose che sono iPhone-y. Non ho problemi ad usare, ad esempio, un'app Web Google sgargiante all'interno di Safari, ma mi sentirei ingannato se Google avesse semplicemente inserito un segnalibro su Springboard presentando un'app Web come nativa.

Devo andare ora. La mia ragazza ha quello che potresti-per-smettere-di-usare-quel-computer-per-tre-secondi sul suo viso.


22
Il problema con la risposta è che è per lo più SBAGLIATO. Vedi la risposta di DennisJZH di seguito.
jbwiv,

9
@jbwiv - Il problema con il tuo commento è che si basa principalmente sulla risposta di DennisJZH, che è per lo più SBAGLIATA. Vedi le mie risposte di seguito. Per evitare ulteriore confusione, suggerirei a entrambi di dare un'occhiata alla documentazione ufficiale per i prodotti e di leggere il mio post per intero . Grazie mille.
Rory Blyth,

15
@Matthew - Oh, la ragazza ha sicuramente la priorità :) Per quanto riguarda queste domande essendo sostanzialmente irrilevanti perché il cambiamento accade (se ho frainteso il tuo significato, mi scuso), il fatto è che le persone vogliono risposte a problemi che esistono in questo momento. Potremmo sostenere che nulla di tutto ciò conta dal momento che la Terra verrà semplicemente cotta in futuro dal Sole mentre brucia il suo combustibile e si espande, distruggendo il nostro pianeta, ma ... questo ci dà qualcosa da fare mentre aspettiamo.
Rory Blyth,

2
@Matthew - Inoltre, questa persona è disposta a provare cose nuove. Potrebbe non essere il modo che preferisci, ma è ancora nuovo. Devi ancora conoscere lo sviluppo di iPhone (leggi i documenti sulle linee guida dell'interfaccia utente, ecc.) Non c'è motivo giustificabile per cercare di allontanare qualcuno dal tentativo di realizzare qualcosa solo perché non ne vedi il valore. Ad esempio, odio i funghi, ma non provo a impedire ad altre persone di mangiarli. Capisco che a loro piacciono i funghi allo stesso modo in cui amo lo zafferano e so che non voglio che nessuno cerchi di togliermi lo zafferano solo perché non gli piace.
Rory Blyth,

1
Sì, ma se sei un vero mago della tecnologia web, sono sicuro che nessuno sarà in grado di realizzare che la tua "app web" non è in realtà un'app nativa. Nei casi in cui è ovvio che un'app è una "app Web" racchiusa in UIWebView, ciò significa che il creatore non si è preso il tempo o si è preoccupato abbastanza per renderlo di qualità abbastanza elevata.
trusktr,

62

Sto seguendo un corso sullo sviluppo di Android / iPhone e abbiamo trascorso 8 settimane con Titanium (non a tempo pieno) (la versione era Titanium 1.4.2 e il tempo era intorno a novembre 2010). Ecco la mia esperienza

iPhone Android doppio targeting

Anche se le guide API affermano che la funzionalità è disponibile sia per Android che per iPhone, non è così. Gran parte delle cose semplicemente non funzionano su una delle piattaforme. Alcune cose funzionano diversamente.

Molte persone della classe hanno realizzato applicazioni per iPhone e non possono farle funzionare su Android senza importanti riscritture. Ho sviluppato una semplice app per bambini chiamata Animap (vedi Android Market / Appstore in Svezia) e ho iniziato a sviluppare su Windows. Una volta che il target Android funzionava, ho aperto il progetto su OS X. Non mostra alcun elemento di build per iPhone, solo per Android. È necessario avviare un progetto a doppia destinazione in OS X. (Ok, ho copiato i file pertinenti in un nuovo progetto). Prossimo problema: le animazioni non funzionano su iPhone (funzionano su Android). Gli eventi a scorrimento non funzionano allo stesso modo sull'iPhone. (ad es. su Android ricevi l'evento intoccato quando l'utente smette di scorrere e rilascia il dito dallo schermo, ciò non accade su iPhone).

Dal momento che questo non è menzionato da qualche parte, in pratica è necessario eseguire la programmazione di tentativi ed errori su una prima piattaforma, quindi sull'altra piattaforma. Per tentativi ed errori intendo che ci vorranno circa due giorni per far funzionare un'app così semplice come Animap sull'altra piattaforma. Dovrai anche avere if (android) quindi ... o if (iphone) ... in tutto il tuo codice ...

Download e configurazione

È necessario seguire le istruzioni alla lettera. Non tentare di utilizzare java a 64 bit. Non compilerà l'applicazione demo KitchenSink 1.4.0. (1.3 funziona bene!) È necessario inserire i file direttamente sull'unità C poiché i percorsi lunghi impediranno al programma esterno di non ricevere tutti i parametri della riga di comando se diventano troppo lunghi. (Va bene anche per piccoli programmi) 1/3 delle volte, la toolchain si interrompe semplicemente ed è necessario premere nuovamente 'launch'. Quindi probabilmente funzionerà ... molto inaffidabile. Il simulatore non verrà trovato all'avvio e quindi devi semplicemente uccidere di adb.exe con Ctrl + Alt + Elimina e riprovare.

Connessione di rete

Su una rete wifi a volte perdi la connessione live e Titanium si arresta in modo anomalo su di te (l'interfaccia di compilazione / distribuzione) Se non disponi di una connessione Internet funzionante, non si avvierà in quanto non è possibile accedere ai loro server.

API

CSS, HTML e jQuery sono un gioco da ragazzi rispetto a questo. Titanium assomiglia a qualsiasi altra vecchia API della GUI ed è necessario impostare alcune proprietà per ogni singolo pulsante / campo / ecc. Sbagliare un campo è semplicissimo, ricordando tutte le proprietà che devono essere impostate? L'hai scritto con lettere maiuscole nel posto giusto? (poiché questo non viene rilevato dal compilatore, ma verrà visualizzato come errore di runtime se si è fortunati a provare quella parte)

In Titanium le cose si rompono semplicemente quando aggiungi un'altra vista sopra un controllo o fai clic da qualche altra parte nella GUI.

Documentazione

Diverse pagine API riportano il simbolo Android, ma restituiranno un valore null solo quando si tenta di creare il controllo. Non sono semplicemente disponibili sulla piattaforma Android nonostante i simboli. A volte si dice che Android non supporta un metodo particolare, ma manca l'intera API.

Lavandino della cucina

L'applicazione demo. Ho già detto che non si compila se lo metti nella cartella del tuo progetto Eclipse perché il percorso diventa troppo lungo? Deve essere inserito nell'unità C nella cartella principale. Attualmente uso un link symbolik (mklink / J ...)

Metodi non documentati

È necessario utilizzare le cose come label.setText ("Hello World") per modificare un'etichetta in modo affidabile, ma ciò non è affatto documentato.

Debug

Titanium.API.info ('Le stampe sono l'unico modo per eseguire il debug');

La modifica

Le API non sono disponibili in nessun formato valido, quindi non è possibile ottenere il normale completamento del codice con aiuto ecc. In Eclipse. Aptana, per favore, dai una mano!

Hardware

Sembra che il compilatore / gli strumenti non siano multithread, quindi un computer veloce con un hard disk veloce è un must, dato che devi fare un sacco di tentativi ed errori. Ho già parlato della scarsa documentazione? Devi provare tutto lì perché non ti puoi fidare!

Alcune cose positive

  • Open Source
  • Da progetti precedenti mi sono ripromesso di non usare mai più il codice sorgente chiuso, dato che non puoi semplicemente aggiustare le cose semplicemente lanciando ore e forza lavoro. Importante quando sei in ritardo nel progetto e devi consegnare per una scadenza rigida. Questo è open source e sono stato in grado di capire perché la catena di strumenti si rompe e anche di risolverlo.

  • Bugdatabase

  • È anche aperto. Puoi semplicemente vedere che non sei solo e fai una soluzione alternativa invece di altre 4 ore trascorse in prova ed errore.

  • Comunità

  • Sembra essere attivo sui loro forum.

bugs

  • Il titanio 1.4 non è sicuro per i thread . Ciò significa che se usi i thread (usa la proprietà url: in una chiamata createWindow) e programmi come i thread funzionano e invii eventi con dati avanti e indietro, ti imbatti in un sacco di cose molto, molto strane - gestori persi, perso finestre, troppi eventi, troppo pochi eventi, ecc. ecc. Tutto dipende dai tempi, l'inserimento di righe di codice in ordine diverso potrebbe causare l'arresto anomalo o la correzione dell'applicazione. L'aggiunta di una finestra in un altro file.js interrompe l'esecuzione di app.js ... Ciò elimina anche le strutture di dati interne in Titanium, poiché a volte possono aggiornare le strutture di dati interne in parallelo, sovrascrivendo un valore appena modificato con qualcos'altro.

Gran parte dei problemi che ho avuto con Titanium proviene dal mio background su sistemi in tempo reale come OSE che supportano centinaia di thread, eventi e passaggio di messaggi. Questo dovrebbe funzionare in Titanium 1.4 ma semplicemente non lo fa in modo affidabile.

  • Javascript (che è nuovo per me) muore silenziosamente per errori di runtime. Ciò significa anche che piccoli e comuni bug, come l'ortografia errata di un nome di variabile o la lettura in un puntatore null, non si arrestano in modo anomalo quando dovrebbe, quindi è possibile eseguire il debug. Invece parti del programma smettono di funzionare, ad esempio un gestore di eventi, perché hai smarrito / errato un personaggio.

  • Quindi abbiamo dei bug più semplici in Titanium, come alcuni parametri che non funzionano nelle funzioni (che è abbastanza comune almeno sulla piattaforma Android).

  • Velocità del ciclo di debug di prova ed errore Avendo eseguito Titnium Developer su diversi computer, ho notato che il collo di bottiglia è il disco rigido. Un'unità SSD su un laptop rende il ciclo di costruzione circa 3-5 volte più veloce rispetto a un'unità a 4200 giri / min. Su un desktop, avere due unità in RAID 1 (modalità striping) rende la build circa il 25 percento più veloce rispetto a una singola unità con una CPU un po 'più veloce e batte anche il laptop dell'unità SSD.

Sommario

  • Dai commenti in questo thread sembra esserci una lotta per il numero di piattaforme per cui uno strumento come questo può fornire un'app. Il numero di API sembra essere il punto di forza chiave.

Questo brilla molto quando inizi a usarlo. Se guardi il bugtracker aperto vedi che il numero di bug continua ad aumentare più velocemente del numero di bug corretti. Questo di solito è un segno che gli sviluppatori continuano ad aggiungere più funzionalità, piuttosto che concentrarsi su come ridurre il numero di bug.

Come consulente che cerca di fornire app piuttosto semplici a multipiattaforma per un cliente, non sono sicuro che questo sia effettivamente più veloce rispetto allo sviluppo di app native su due piattaforme. Ciò è dovuto al fatto che quando sei in velocità sei veloce con Titanium, ma poi all'improvviso guardi in basso e ti ritrovi in ​​una buca così profonda da non sapere quante ore devono essere impiegate per una soluzione alternativa. Non si può semplicemente promettere una certa funzionalità per un determinato termine / tempo / costo.

Su di me: utilizzo Python da due anni con wxPython. (che la GUI è incoerente, ma non si rompe mai in questo modo. Potrei essere io che non ho capito il modello di threading usato da Javascript e Titanium, ma non sono solo secondo i loro forum di discussione aperti, gli oggetti della GUI stanno improvvisamente usando il contesto sbagliato / non si aggiorna .. ???) prima di allora ho un background in programmazione C e ASM per dispositivi mobili.

[modifica - aggiunta parte con bug e non thread-safe] [Modifica - ora ci ho lavorato per un mese +, principalmente su PC ma anche su OS X. Aggiunto il doppio targeting per iPhone e Android. Aggiunta della velocità del ciclo di debug di prova ed errore.]


1
Con la versione 1.4 di Titanium ho ora esaminato i file .apk forniti da Titanium e semplicemente non sono molto buoni. Funzionano, ma la directory di compilazione completa è un po 'compressa insieme. Ciò significa che piccoli difetti di costruzione come la copia della schermata iniziale in tre diverse posizioni durante la generazione consumano improvvisamente, poiché ho una grande immagine schermata iniziale, circa 1 megabyte di spazio di archiviazione nel telefono. E questo è solo per una variante molto semplice del ciao-mondo. Il codice sorgente javascript viene anche copiato nelle build e nei file .apk e quindi consegnato a tutti i clienti.
user288299

La versione 1.5 è ora disponibile e si dice che sia la riscrittura principale per la piattaforma Android. Non lo proverò perché ora devo imparare lo sviluppo nativo di Android.
user288299

La versione 1.5 è ora disponibile e si dice che sia la riscrittura principale per la piattaforma Android. Non lo proverò perché ora siamo passati a imparare lo sviluppo nativo di Android. Dato che oggi ci è stato insegnato il ciclo di vita di Android nativo, credo che i problemi che ho avuto con alcune finestre che hanno perso contenuto variabile la seconda volta che sono stati visualizzati sia stato causato da Titanium che non ha salvato lo stato prima dello stato onPause () del ciclo di vita. developer.android.com/guide/topics/fundamentals.html#lcycles . Chiamare Titanium.Map.MapView.hide () e successivamente show () potrebbe semplicemente uccidere le variabili locali per la mappa
user288299

1
Ho appena giocato con 1.7, la tua descrizione è così giusta. Questa piattaforma è molto incostante, con prestazioni orribili e innumerevoli ore di lavoro in giro per la ricerca. Se hai le risorse all'inizio di un progetto, crea nativo per ogni piattaforma.
Jonathon Kresner il

25

Corona SDK (Ansca Mobile) utilizza Lua come linguaggio di codifica. Vedi lua.org per ulteriori informazioni su Lua.

Mentre prevediamo di aggiungere ulteriori elementi di integrazione Web e interfaccia utente nativa, la nostra attenzione tenderà a concentrarsi su applicazioni ad alta intensità grafica, come lo sviluppo di giochi, al contrario delle tecnologie basate sul web. In altre parole, non immaginiamo che le persone scrivano app Corona interamente in Javascript / HTML / CSS.


Hai un piano o una scala temporale per gli script nativi dell'interfaccia utente. Ho fatto parecchio con Lua e voglio davvero amare Corona. Per lo sviluppo non di gioco Titanium sembra un po 'avanti.
uroc,

4
Ciao Uroc. Abbiamo funzionalità dell'interfaccia utente nativa in arrivo nella versione 1.1 (ETA alla fine di questa settimana!) E altre ancora seguiranno a breve. Tuttavia, il mio senso di Titanium è che hanno fatto un buon lavoro nell'esporre un gran numero di elementi dell'interfaccia utente nativi, mentre ci concentreremo sugli elementi dell'interfaccia utente più critici mentre spingiamo più impegno ingegneristico nelle funzionalità di animazione e rendering. Il ragionamento è che (i) ci sono già buoni prodotti per le app solo per l'interfaccia utente, (ii) l'interfaccia utente è la parte più amichevole di Cocoa (relativamente parlando!), Ma (iii) tutto ciò che coinvolge l'animazione OpenGL è un punto dolente su iPhone al momento.
Evan Kirchhoff

sembra che Corona sia adatta a sviluppare giochi invece di app, vero?
anticafe,

18

Lavoro con Titanium da oltre una settimana e mi sento come se avessi una buona idea della sua debolezza.

1) Se speri di usare lo stesso codice su più piattaforme, buona fortuna! Vedrai qualcosa come backgroundGradient e rimarrai stupito finché non scoprirai che la versione di Android non lo supporta. Quindi devi tornare a utilizzare un'immagine sfumata, potresti anche usarla per entrambe le versioni per rendere il codice più semplice, giusto?

2) Molti comportamenti strani, su sdk Android Titanium devi capire che cosa è una finestra "pesante" solo per far funzionare il pulsante Indietro, o anche un migliore monitoraggio degli eventi di orientamento. Questo non è come è realmente la piattaforma Android, è solo come Titanium cerca di far funzionare la loro API.

3) Sei gettato nell'oscurità, le cose andranno in crash e dovrai iniziare a commentare il codice e poi quando lo troverai, non usarlo mai. Ci sono alcuni ovvi bug, come l'orientamento e le percentuali su Android che sono stati un problema per oltre sei mesi.

4) Bug .... ci sono molti bug e verranno segnalati, resteranno in giro per mesi, verranno risolti in pochi giorni. Sono sorpreso che stiano anche pianificando di rilasciare un sdk mobile a bacca nera quando ci sono molti altri problemi con Android.

5) I motori javascript Titanium Iphone contro Titanium Android sono completamente diversi. Nella versione Android è possibile scaricare file javascript remoti, includere e utilizzare librerie come mootools, jquery e così via. Ero in paradiso quando l'ho scoperto perché non dovevo continuare a compilare la mia app Android. Il processo di installazione dell'apk Android richiede così tanto tempo! Iphone nulla di tutto ciò è possibile, anche la versione per iPhone ha un motore javascript molto più veloce.

Se stai lontano da molte parti dell'interfaccia utente nativa, ovvero utilizza setInterval per rilevare i cambiamenti di orientamento, attenersi alle immagini sfumate, dimenticare il pulsante Indietro, creare animazioni personalizzate, dimenticare l'intestazione della finestra, le barre degli strumenti e il dashboard. Puoi davvero creare un'API che funzioni su entrambi, che non richiede molta riscrittura. Ma a quel punto è pigro come una webapp.

Ne vale la pena? Dopo tutto il dolore, vale ogni minuto. È possibile astrarre la logica e creare un'interfaccia utente diversa per ognuno piuttosto che se altro ovunque. Il titanio ti consente di realizzare applicazioni fluide, che sembrano veloci. Si perdono le potenti capacità di layout di ciascuna piattaforma ma se si pensa semplice, le cose possono essere fatte in una sola lingua.

Perché non un'app Web? Sui telefoni Android di fascia bassa è orribilmente lento nel generare una visualizzazione web e consuma molta memoria che potresti usare per fare una logica più complessa.




8

Creare widget HTML5 che assomigliano ai widget per iPhone è una cosa, ma farli funzionare altrettanto bene è un'altra cosa del tutto. Le prestazioni delle animazioni html5 (anche semplici Transizioni vista), lo scorrimento di lunghi elenchi, la reattività ai gesti si sentono appiccicosi e a scatti. Un utente iPhone noterà la differenza.

Ci sono anche alcune differenze nei tipi di gesti supportati da diversi dispositivi che si traducono in codice specifico della piattaforma e problemi di usabilità.

Starò con le app native per ora suppongo.


7

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) è molto simile nell'approccio a PhoneGap, ma è l'unico framework con:

  1. un modello Controller vista modello (come prevede la maggior parte dei framework Web)
  2. un gestore relazionale di oggetti
  3. supporto per tutti gli smartphone più diffusi (incluso Windows Phone 7)
  4. un servizio di sviluppo ospitato (non solo build ospitato): http://rhohub.com
  5. un debugger completo e un emulatore senza SDK nell'IDE di RhoStudio
  6. supporto per dati offline sincronizzati

6

Per chiunque sia interessato a Titanium devo dire che non hanno un'ottima documentazione mancano alcune classi, proprietà, metodi. Ma molto è "documentato" nella loro app di esempio KitchenSink, quindi non è poi così male.


5

La mia comprensione di PhoneGap è che forniscono API Javascript a gran parte delle API di iPhone.

Il titanio sembra più semplice per uno sfondo di sviluppatori web. È un semplice file XML per creare un'applicazione TabView di base e quindi tutto nell'area del contenuto è controllato da HTML / JS. So anche che Titanium fornisce un accesso javascript ad alcuni dei framework (in particolare l'accesso alle informazioni sulla posizione, l'ID del telefono, ecc.).

AGGIORNAMENTO: Titanium ha aggiunto l'API di Maps nella versione 0.8 del proprio framework.


Secondo il "Titanium sembra più facile per uno sfondo di sviluppatori web". dichiarazione. Intendi più facile del nativo giusto? Dato che PhoneGap sembra essere più in linea con qualcuno con un background da sviluppatore web rispetto a Titanium ...
Serhiy,

4

Dovresti imparare obiettivi c e programmare app native. Non fare affidamento su queste cose che pensi possano rendere la vita più facile. Apple si è assicurata che il modo più semplice sia usare gli strumenti e il linguaggio nativi. Per le tue 100 righe di JavaScript posso fare lo stesso in 3 righe di codice o nessun codice a seconda dell'elemento. Guarda alcuni tutorial - se capisci javascript allora l'obiettivo c non è difficile. Le soluzioni alternative sono miserabili e Apple può staccare la spina ogni volta che lo desidera.


3
Apple potrebbe staccare la spina ... questo è quello che mi preoccupa
Mickey Shine,

6
Citazione: "Apple si è assicurata che il modo più semplice sia usare gli strumenti e la lingua nativi". Davvero no. Se avessero voluto farlo, avrebbero fornito, diciamo, supporto Python. Ci sarebbe la garbage collection (che da sola ridurrebbe la frequenza degli arresti anomali - la maggior parte delle app per iPhone sono terribilmente scritte). Scavo ObjC e, come te, preferirei usarlo piuttosto che js, ma non era questa la domanda dell'op. Inoltre, MonoTouch rende lo sviluppo più semplice di una qualsiasi di queste opzioni. Posso creare una proprietà in una riga; ottenere un riferimento alla cartella Documenti con una riga ... e così via. I bit di Apple potrebbero essere notevolmente migliorati.
Rory Blyth,

6
Una buona soluzione sarebbe che Apple fornisse la propria alternativa ObjC. Qualcosa per le app che non richiedono il livello di controllo offerto da ObjC. Soprattutto per le app aziendali in cui gli sviluppatori dovrebbero concentrarsi sulla funzionalità piuttosto che sul conteggio dei riferimenti e sugli attributi delle proprietà. O almeno automatizza la maggior parte di ciò con Xcode e il compilatore. Dammi un interruttore che consenta di fare alcune ipotesi e che possa essere bypassato nel codice in cui lo sviluppatore sceglie (come: retain e @synthesize le proprietà dei miei oggetti di default - e, come il "reale" ObjC 2.0, crea i miei locali di supporto per me). Ecc.
Rory Blyth,

2
Fondamentalmente quello che stai dicendo è, lasciaci scrivere app per iPhone in C #. :)
Justin

3

Delle soluzioni che hai citato, nessuna sembra darti accesso diretto al framework MapKit introdotto in OS 3.0.

Dato che i widget HTML di Google Maps non sono quasi buoni come MapKit (vedi un esempio di Google Latitude per un esempio), probabilmente stai meglio sviluppando un'applicazione touch Cocoa nativa o scegliendo una soluzione che puoi estendere per aggiungere l'integrazione di MapKit. PhoneGap è estensibile in questo modo (è open-source quindi è di default), e anche alcune delle altre soluzioni potrebbero esserlo.

modifica: Titanium ora ha il supporto per MapKit


Grazie. Ma c'è qualche differenza essenziale tra PhoneGap e Titanium?
Mickey Shine,

1
MapKit è stato disponibile nativamente in titanio per un periodo piuttosto lungo.
jhaynie,

@jhaynie: grazie. Ho rivisto questa risposta per riflettere che Titanium ora ha supporto (non è stato quando è stato scritto a settembre)
rpetrich

1

Ho provato Corona. È stato buono fino a quando ho scoperto che non supporta lo streaming audio mp3. Quindi mi sono fermato lì. Penso che se voglio davvero essere uno sviluppatore di app per iPhone dovrei imparare obj c. Tutto quello che volevo creare un'app con un elenco di stazioni radio e fai clic su di esse per iniziare a giocare.


2
Corona supporta la riproduzione di file MP3 ( developer.anscamobile.com/reference/index/mediaplaysound )
Luc Stepniewski,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.