Confronto tra Corona, PhoneGap, Titanio

StackOverflow https://stackoverflow.com/questions/1482586

Domanda

Sono uno sviluppatore web e voglio spostare i miei prodotti di Internet per iPhone. Uno dei prodotti è come Google Maps:. Mostra mappa sullo schermo del telefono, è possibile trascinare o ridimensionare la mappa e visualizzare alcune informazioni che si aggiunge alla mappa

So che ci sono alcune tecnologie che vi permette di utilizzare HTML, CSS e Javascript per sviluppare applicazioni iPhone native. Ho identificato alcuni:

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

È stato utile?

Soluzione

Mi sono iscritto con StackOverflow solo per lo scopo di commentare la risposta per lo più votato sulla parte superiore. La cosa brutta è StackOverflow non permette nuovi membri per inviare commenti. Quindi devo fare questo commento occhiata come una risposta.

La risposta di Rory Blyth contiene alcuni punti validi sui quadri mobili a due javascript. Tuttavia, i suoi punti chiave sono corretti. La verità è che il titanio e PhoneGap sono più simili che diversi. Entrambi esporre le funzioni di telefonia mobile attraverso una serie di API JavaScript, e la logica dell'applicazione (HTML, CSS, JavaScript) viene eseguito all'interno di un controllo WebView nativo.

  1. PhoneGap non è solo un involucro nativo di una web app. Attraverso la PhoneGap JavaScript API, il "web app" ha accesso alle funzioni di telefonia mobile come Geolocation, Camera accelerometro, contatti, database, file system, ecc Fondamentalmente qualsiasi funzione che il telefono cellulare SDK fornisce può essere "ponte" al World JavaScript. D'altra parte, una web app normale che gira sul browser web mobile non ha accesso alla maggior parte di queste funzioni (sicurezza è il motivo principale). Pertanto, un'applicazione PhoneGap è più di un app mobile di una web app. Si può certamente utilizzare PhoneGap per avvolgere una web app che non utilizza le API di PhoneGap a tutti, ma non è quello che è stato creato per PhoneGap.

  2. Titanium non compilare il codice HTML, CSS o JavaScript codice in "bit native". Sono confezionati come risorse per il fascio eseguibile, molto simile a un file di immagine incorporato. Quando l'applicazione viene eseguita, queste risorse vengono caricate in un controllo UIWebView e correre lì (come JavaScript, non bit nativi, ovviamente). Non v'è alcuna cosa come un compilatore javascript-to-native-code (o per-Objective-C). Questo viene fatto allo stesso modo in PhoneGap pure. Dal punto di vista architetturale, questi due quadri sono molto simili.

Ora, essi sono diverso? Sì. In primo luogo, titanio sembra essere più ricco di funzionalità di PhoneGap colmando più funzioni di telefonia mobile per javascript. La più evidente, PhoneGap non espone molte (se presenti) i componenti dell'interfaccia utente nativi a JavaScript. Titanio, d'altra parte, ha un'API di interfaccia utente completi che possono essere chiamati in javascript per creare e controllare tutti i tipi di controlli dell'interfaccia utente nativi. Utilizaing queste API dell'interfaccia utente, un'applicazione di titanio può guardare più "nativa" di un'applicazione PhoneGap. In secondo luogo, PhoneGap supporta più piattaforme di telefonia mobile di titanio fa. API PhoneGap sono più generici e può essere utilizzato su diverse piattaforme come iPhone, Android, Blackberry, Symbian, ecc titanio è principalmente di targeting per iPhone e Android, almeno per ora. Alcune delle sue API sono piattaforma specifica (come le API di iPhone UI). L'uso di queste API ridurrà la capacità di cross-platform della vostra applicazione.

Quindi, se la vostra preoccupazione per la vostra applicazione è quello di rendere più "nativo" cercando, titanio è una scelta migliore. Se si vuole essere in grado di "porta" la vostra applicazione ad un'altra piattaforma più facilmente, PhoneGap sarà migliore.

Aggiornamento 8/13/2010: Link ad un La risposta di dipendente titanio alla domanda di Topolino.

Aggiornamento 12/04/2010: Ho deciso di dare questo post una revisione annuale per mantenere la sua attuale informazioni. Molte cose hanno cambiamenti in un anno che ha fatto alcune delle informazioni nel post iniziale obsoleto.

Il più grande cambiamento è venuto da titanio. All'inizio di quest'anno, Appcelerator Titanium rilasciato 1.0, che partì drasticamente da sue precedenti versioni dal punto di vista architettonico. In 1,0, il controllo UIWebView non è più in uso. Invece, si chiama API di titanio per le funzioni di interfaccia utente. Questo cambiamento implica un paio di cose:

  1. La tua app UI diventa completamente nativo. Non c'è più web UI nel vostro app in quanto il nativo Titanium API assumere il controllo di tutte le vostre esigenze di interfaccia utente. Titanium merita un sacco di credito da pioniere sulla frontiera "Cross-piattaforma nativa UI". Dà i programmatori che preferiscono il look and feel nativo dell'interfaccia utente, ma non amano la lingua ufficiale di programmazione alternativa.

  2. Non sarà in grado di utilizzare HTML o CSS nella vostra applicazione, come la visualizzazione Web è andato. (Nota: è comunque possibile creare visualizzazione Web in titanio Ma ci sono alcune caratteristiche di titanio che si possono trarre vantaggio nella visualizzazione Web..) Titanium Q & a: Che cosa è successo in HTML e CSS

  3. Non sarà in grado di utilizzare biblioteche popolari JS come jQuery che assumono l'esistenza di un oggetto DOM. Si continua a utilizzare JavaScript come lingua di codifica. Ma questo è praticamente l'unica tecnologia web è possibile utilizzare se si arriva a Titanium 1.0 come un programmatore web.

video di titanio:. Cosa c'è di nuovo in titanio 1.0

Ora, non Titanium 1.0 compilare il JavaScript in "bit nativi"? No. Appcelerator finalmente pulito su questo tema con questo blog degli sviluppatori: Guide Titanium Progetto:. JS Ambiente siamo programmatori sono le persone più genuine rispetto a quelli del reparto marketing, non è vero? :-)

Procedere con PhoneGap. Non ci sono molte cose nuove da dire su PhoneGap. La mia percezione è che lo sviluppo PhoneGap non era molto attiva fino IBM ha saltato a bordo entro la fine dell'anno. Alcune persone, anche sostenuto che IBM sta contribuendo più codice per PhoneGap di Nitobi è. Che sia vero o no, è bene sapere che PhoneGap è essere attiva sviluppata.

PhoneGap continua a basarsi su tecnologie web, vale a dire HTML, CSS e JavaScript. Non guardare come PhoneGap ha alcun piano per colmare funzionalità dell'interfaccia utente native a JavaScript come titanio sta facendo. Mentre utente web è ancora indietro nativo dell'interfaccia utente sulle prestazioni e il look and feel nativo, tale divario si sta rapidamente chiuso. Ci sono due tendenze nelle tecnologie web che garantiscono caratteristica luminosa al Web mobile interfaccia utente in termini di prestazioni:

    motore

  1. JavaScript passando da un interprete a una macchina virtuale. JavaScript è JIT compilato in codice nativo per l'esecuzione più veloce. motore di Safari JS: SquirrelFish estrema

  2. di rendering delle pagine Web si spostano da fare affidamento su CPU a utilizzare l'accelerazione GPU. attività ad alta intensità grafici come pagina di transizione e animazione 3D diventano molto più agevole con l'aiuto di accelerazione hardware. GPU Accelerated Compositing in Chrome

Tali miglioramenti che sono originati da browser desktop vengono consegnati al browser mobile in fretta. Infatti, dal momento che iOS 3.2 e Android 2.0, il Mobile Control visualizzazione Web è diventato molto più performante e HTML5 amichevole. Il futuro del web mobile è così promettente che ha attirato un bambinone in città: JQuery ha recentemente annunciato il suo quadro web mobile Con jQuery mobile fornendo gadget UI, e PhoneGap fornendo funzioni del telefono, hanno due combinate crea una perfetta piattaforma mobile web a mio parere.

Vorrei anche ricordare Sencha tocco come un altro quadro gadget interfaccia utente web mobile. Sencha tocco la versione 1.0 è stato recentemente rilasciato in un modello a doppia licenza che include GPLv3. Sencha tocco funziona bene con PhoneGap proprio come fa jQuery Mobile.

Se sei un GWT programmatore (come me), si consiglia di controllare le GWT mobile , un progetto open source per la creazione di applicazioni web mobile con GWT. Esso comprende un involucro PhoneGap GWT che consente l'utilizzo di PhoneGap in GWT.

Altri suggerimenti

Da quello che ho raccolto, qui ci sono alcune differenze tra i due:

  • PhoneGap genera fondamentalmente involucri native per quelli che sono ancora in applicazioni web . Sputa fuori un progetto WhateverYourPlatformIs, si costruisce, e distribuire. Se stiamo parlando di iPhone (che è dove trascorro il mio tempo), non sembra molto diverso dal creare un lanciatore web app (una scorciatoia che ottiene la propria icona Springboard, in modo da poter lanciare come ( come ) un'applicazione nativa). L ' "app" in sé è ancora html / js / etc., E viene eseguito all'interno di un controllo del browser ospitato. Che PhoneGap prevede di là di questo è un ponte tra JavaScript e le API native dei dispositivi. Quindi, si scrive JavaScript API contro PhoneGap, e PhoneGap quindi effettua la chiamata nativa corrispondente adeguata. A questo proposito, è è diverso da distribuzione di una pianura vecchio web app.

  • fonte di titanio viene compilato verso il basso per bit native. Cioè, il tuo html / js / etc. Non sono semplicemente collegato a un progetto e poi ospitato all'interno di un controllo browser Web - sono trasformati in applicazioni native. Ciò significa, per esempio, che l'interfaccia di vostra applicazione sarà composta da nativo componenti dell'interfaccia utente. Ci sono modi di ottenere nativa look-and-feel senza avere un'applicazione nativa, ma ... beh ... che incubo che di solito si rivela essere.

I due sono simili in quanto si scrive tutte le tue cose utilizzando tecnologie web tipici (html / js / css / bla bla bla), e che è possibile accedere a funzionalità native attraverso le API JavaScript.

Ma, ancora una volta, applicazioni PhoneGap (PhonGapps non so ... è che un nome stupido E 'più facile dire -?? So che molto) iniziano la loro vita come applicazioni web e alla fine la loro vita come applicazioni web. Su iPhone, i tuoi html / js / etc. è solo eseguito all'interno di un controllo UIWebView, e il PhoneGap JavaScript API tuoi js chiamate vengono instradate alle API native.

applicazioni titanio diventano applicazioni native - sono appena messo a punto utilizzando web dev tecnologia

.

Che cosa significa questo in realtà significa

  1. Un'applicazione Titanium sarà aspetto come un'applicazione "reale", perché, in ultima analisi, è un "vero" app.

  2. Un'applicazione PhoneGap sarà simile a una web app essere ospitato in un controllo del browser, perché, in ultima analisi, è una web app ospitato in un controllo del browser.

Il che è giusto per te?

  • Se si desidera scrivere applicazioni native utilizzando le competenze web dev, Titanium è la soluzione migliore.

  • Se si desidera scrivere un app utilizzando le competenze web dev che si potrebbe realisticamente la distribuzione a più piattaforme (iPhone, Android, Blackberry, e qualsiasi altra cosa decidono di includere), e se si vuole accedere a un sottoinsieme di funzionalità della piattaforma native (GPS, accelerometro, ecc) attraverso un'API JavaScript unificata, PhoneGap è probabilmente ciò che si desidera.

Si potrebbe chiedere: Perché dovrei scrivere un PhoneGapp (ho deciso di usare il nome), piuttosto che una web app che è ospitato sul web? Non posso ancora accedere qualche dispositivo nativo presenta in questo modo, ma hanno anche la comodità di una vera distribuzione web, piuttosto che costringere l'utente a scaricare il mio app "nativo" e installarlo?

La risposta è: Perché è possibile inviare il tuo PhoneGapp ad App Store e la carica per esso. Vedrete anche che un'icona di avvio, che rende più difficile per l'utente di dimenticare la vostra applicazione (io sono molto più probabile a dimenticare un segnalibro che l'icona di un'applicazione).

Si potrebbe certamente pagare per l'accesso al vostro web-hosted web app, ma quante persone sono davvero intenzione di passare attraverso il processo di farlo? Con l'App Store, prendo un app, toccare il pulsante "Acquista", inserire una password, e ho finito. Si installa. Pochi secondi dopo, lo sto usando. Se dovessi usare qualcun altro cellulare interfaccia transazione web una tantum, che probabilmente significa dover toccare il mio nome, indirizzo, numero di telefono, numero di CC, e altre cose che non voglio toccare, ho quasi certamente wouldn' t andare fino in fondo. Anche iofidarsi di Apple -. Sono fiducioso Steve Jobs non sta andando a registrare le mie informazioni e quindi caricare un gruppo di abbonamenti a riviste giocherellona alla mia CC per i calci

In ogni caso, tranne per il fatto che il web dev tecnologia è coinvolto, PhoneGap e Titanio sono molto diverse - fino al punto di essere solo superficialmente paragonabile

.

Odio applicazioni web, a proposito, e se leggete le recensioni di iTunes App Store, gli utenti sono abbastanza bravo a spotting loro. Non voglio fare nomi, ma ho un paio di "apps" sul mio telefono che appaiono e funzionano come spazzatura, ed è perché sono applicazioni web che sono ospitati all'interno di istanze UIWebView. Se volessi utilizzare una web app, mi piacerebbe aprire Safari e, si sa, passare a uno. Ho comprato un iPhone perché voglio le cose che sono iPhone-y. Non ho alcun problema utilizzando, per esempio, un snazzy Google web app all'interno di Safari, ma io sento ingannato se Google ha appena intrufolato un segnalibro sulla Springboard con la presentazione di una web app come un nativo.

Devo andare ora. La mia ragazza ha che potrebbe-you-please-stop-con-che-computer per-tre-secondi sguardo sul suo volto.

sto prendendo un corso di / sviluppo di iPhone Android e abbiamo trascorso 8 settimane con Titanium (tempo non pieno) (versione era Titanium 1.4.2 e il tempo è stato intorno a novembre 2010). Qui è la mia esperienza.

iPhone Android dual targetting

Anche se le guide API sostengono che la funzionalità è disponibile sia per Android e iPhone, non è questo il caso. Gran parte delle cose semplicemente non funzionano su una delle piattaforme. Alcune cose funziona in modo diverso.

Un sacco di persone nella classe ha fatto applicazioni per iPhone, e non possono farli funzionare su Android senza grandi riscritture. Ho sviluppato una semplice applicazione per bambini chiamato Animap (vedi Android Market / Appstore in Svezia) e ha iniziato a sviluppare in ambiente Windows. Una volta che l'obiettivo di Android stava lavorando Ho aperto il progetto su OS X. Non mostra alcuna roba di build per iPhone, solo per Android. È necessario avviare un progetto di destinazione dual sotto OS X. (Ok, ho copiato i file relativi a un nuovo progetto). Prossimo problema - le animazioni non funziona su iPhone (lavorano su Android). Gli eventi di scorrimento non funziona lo stesso su iPhone. (Cioè su Android si ottiene l'evento untouch quando l'utente smette di scorrere e rilascia il dito dallo schermo, ciò non accade su iPhone).

Poiché questo non è menzionato da qualche parte si fondamentalmente bisogno di fare prove e la programmazione di errore sul primo una piattaforma, poi sull'altra piattaforma. Per tentativi ed errori voglio dire che ci vorranno circa due giorni per ottenere un tale semplice App come Animap lavorare sull'altra piattaforma. Sarà inoltre necessario avere se (Android) quindi ... o se (iphone) ... tutto il codice ...

Download e configurazione

È necessario seguire le istruzioni alla lettera. Non cercare di usare Java a 64 bit. Non sarà compilare l'applicazione demo kitchensink 1.4.0. (1.3 funziona bene!) È necessario mettere i file direttamente sul disco C come lunghi percorsi renderanno il programma esterno non riceve tutti i parametri della riga di comando se ottengono a lungo. (Fine per piccoli programmi però) 1/3 dei tempi, la toolchain si ferma in modo semplice e si deve premere 'lancio' di nuovo. Allora sarà probabilmente funzionerà ... molto inaffidabile. Il simulatore non si troverà all'avvio e poi si deve semplicemente uccidere di adb.exe con Ctrl + Alt + Canc e riprovare.

Connessione di rete

In una WiFi-network a volte perde il collegamento dal vivo e titanio si blocca su di voi (la compilazione / implementare l'interfaccia) Se non si dispone di una connessione a Internet non si avvia in quanto non si può accedere ai loro server.

API

CSS, HTML e jQuery è un gioco da ragazzi rispetto a questo. Titanium assomiglia a qualsiasi altra vecchia API GUI, ed è necessario impostare alcune proprietà per ogni singolo tasto / campo / etc. Ottenere un campo sbagliato è solo per facile, ricordando tutte le proprietà che deve essere impostato? Forse si scrive con lettere maiuscole al posto giusto? (Come questo non e 'colto dal compilatore, ma sarà visto come un errore di runtime se si è fortunati a testare quella parte)

Nelle cose titanio semplicemente rompere quando si aggiunge un'altra vista sulla cima di un controllo o si fa clic da qualche altra parte nella GUI.

Documentazione

Diverse pagine API portano il simbolo di Android, ma torneranno solo null quando si tenta di creare il controllo. Essi non sono semplicemente disponibili sulla piattaforma Android, nonostante i simboli. A volte Android è menzione di non sostenere un particolare metodo, ma poi tutta l'API è mancante.

kitchensink

L'applicazione demo. Ho già detto che non viene compilato se lo metti nella cartella del progetto Eclipse perché il percorso è troppo lungo? Deve essere messo sull'unità C nella cartella principale. Attualmente uso un link Symbolik (mklink / J ...)

metodi privi di documenti

È necessario utilizzare propably cose come label.setText ( 'Ciao Mondo') per modificare l'etichetta affidabile, ma questo non è documentato a tutti.

Debug

Titanium.API.info ( 'La stampa è l'unico modo per eseguire il debug');

Editing

Le API non sono disponibili in ogni buon formato in modo non è possibile ottenere ordinaria completamento del codice, con l'aiuto, ecc in Eclipse. Aptana si prega di dare una mano!

Hardware

Sembra che il compilatore / strumenti non sono multithreaded in modo da un computer veloce con un hard disk veloce è un must, come è necessario fare un sacco di trial & error. Vi ho parlato della documentazione di poveri? Dovete provare tutto quello che c'è da non ci si può fidare!

Alcune cose positive

  • Open Source

  • Da progetti precedenti ho promesso io mai e poi mai usare di nuovo closed source come non si può semplicemente sistemare le cose semplicemente lanciando ore e manodopera a questo. Importante quando si è in ritardo nel progetto e la necessità di fornire un termine difficile. Questo è open source e sono stato in grado di vedere il motivo per cui di rottura della catena strumento ed effettivamente risolvere il problema pure.

  • Bugdatabase

  • E 'anche aperto. Si può semplicemente vedere che il vostro non da solo e fare una soluzione al posto di un altro 4 ore trascorse sul trial & error.

  • Comunità

  • Sembra essere attivi sul loro forum.

Bugs

  • Titanium 1.4 non è threadsafe . Questo significa che se si fanno uso di fili (utilizzare l'URL: proprietà in una chiamata createWindow) e programma come i fili stanno lavorando e inviare gli eventi con i dati avanti e indietro si esegue in un sacco di molto, molto strana roba - i gestori perso, perso finestre, troppi eventi, troppo pochi eventi, ecc ecc Questo è tutto dipende dalla tempistica, mettendo le righe di codice in ordine diverso potrebbe bloccarsi o guarire la vostra applicazione. L'aggiunta di una finestra in un altro file.js spezza l'esecuzione app.js ... Questo cestina anche Datastructures interne in titanio, come a volte possono aggiornare Datastructures interne paralell, sovrascrivendo un valore appena cambiato con qualcos'altro.

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

  • Javascript (che è nuovo per me) muore in silenzio sugli errori di runtime. Questo significa anche che le piccole e comuni insetti, come errore ortografico un nome di variabile o di lettura in un null-pointer non va in crash quando dovrebbe in modo da poter eseguire il debug. Invece parti del programma appena smettono di funzionare, ad esempio un EventHandler, perché fuori luogo / misstyped un personaggio.

  • Poi abbiamo più semplici insetti in titanio, come alcuni parametri non lavorano nelle funzioni (che è abbastanza comune sulla piattaforma Android, almeno).

    • velocità del ciclo

  • Trial and Error di debug Avendo eseguito Developer Titnium su diversi computer, ho notato che il collo di bottiglia è l'hard disk. Un disco SSD su un computer portatile rende il ciclo di accumulo di circa 3-5 volte più veloce rispetto a un drive 4200 giri al minuto. Su un desktop, avendo doppi dischi in RAID 1 (modalità striping) rende l'accumulo di circa il 25 per cento più veloce che su un singolo disco con una CPU po 'più veloce e batte anche il portatile drive SSD.

Sommario

  • Dai commenti in questa discussione sembra che ci sia una lotta per il numero di piattaforme uno strumento come questo possono offrire app per. Il numero di API sembra essere la vendita-punto chiave.

Questo traspare molto quando si inizia ad usarlo. Se si guarda al bugtracker aperta si vede che il numero di bug continua ad aumentare più velocemente del numero di bug risolti. Questo è di solito un segno che gli sviluppatori continuare ad aggiungere ulteriori funzionalità, piuttosto che concentrarsi su come ottenere il numero di bug verso il basso.

Come consulente cercando di fornire applicazioni piuttosto semplici per più piattaforme per un cliente - non sono sicuro che questo è in realtà più veloce di fare lo sviluppo di applicazioni native su due piattaforme. Questo è dovuto al fatto che quando si è fino a velocità sei veloce con titanio, ma poi improvvisamente si guarda verso il basso e trovare la vostraelfo in un buco così profondo non sai quante ore deve essere speso per una soluzione alternativa. Si può semplicemente non promette una certa funzionalità per un certo termine / tempo / costo.

Circa me: usando Python per due anni con wxPython. (Che GUI è inconsitent, ma mai si rompe come questo. Mi Potrebbe essere che non hanno capito il modello di threading utilizzato da JavaScript e titanio, ma io non sono solo in base alle loro forum di discussione aperti, gli oggetti GUI sono improvvisamente utilizzando il contesto sbagliato / non l'aggiornamento .. ???) prima che ho un background in C e ASM di programmazione per i dispositivi mobili.

[modifica - ha aggiunto parte di insetti e di non essere thread-safe] [Edit - ora avendo lavorato con lui per un mese +, per lo più su PC, ma un po 'su OS X pure. Aggiunto iPhone e Android dual targetting. Aggiunto di prova e la velocità del ciclo di debug errore.]

La Corona SDK (Ansca Mobile) utilizza Lua come linguaggio di codifica. Vedere lua.org per di più su Lua.

Mentre abbiamo in programma di aggiungere una maggiore integrazione web e gli elementi nativo dell'interfaccia utente, il nostro obiettivo tenderà ad essere in applicazioni grafiche, come lo sviluppo del gioco, al contrario di tecnologie web-based. In altre parole, noi non immaginiamo persone che scrivono applicazioni Corona interamente in JavaScript / HTML / CSS.

Ho lavorato con titanio per più di una settimana e sento come se avessi una buona sensazione riguardo la sua debolezza.

1) Se si spera si utilizza lo stesso codice su più piattaforme in bocca al lupo! Vedrai qualcosa di simile backgroundGradient e stupiti fino a scoprire la versione di Android non lo supporta. Poi deve tornare a utilizzare un'immagine di gradiente, tanto vale usarlo per entrambe le versioni per rendere il codice più facile giusto?

2) Un sacco di comportamenti strani, sul Android SDK Titanium è necessario capire che cosa una finestra "pesante" è solo per ottenere il pulsante di tornare al lavoro, o meglio ancora il monitoraggio degli eventi di orientamento. Questo non è come la piattaforma Android è davvero, il suo solo come titanio cerca di fare il loro lavoro API.

3) La tua gettato nel buio, le cose andranno in crash e si deve iniziare per commentare il codice e poi quando a trovarlo, non utilizzarlo. Ci sono alcuni bug evidenti, come l'orientamento e percentuali su Android che sono stati un problema per più di sei mesi.

4) Bugs .... ci sono un sacco di bug e saranno segnalati, sedersi intorno per mesi, si fissa in pochi giorni. Sono sorpreso che ancora hanno in programma di rilasciare uno SDK cellulare bacca nera, quando ci sono tanti altri problemi con Android.

5) di titanio Iphone contro motori JavaScript titanio Android sono completamente diversi. Sulla versione di Android è possibile scaricare i file remoti javascript, comprendere e utilizzare librerie come jQuery, MooTools e così via. Ero in paradiso quando ho trovato questo fuori perché non ho dovuto tenere la compilazione mio app Android. Il processo di installazione apk Android vuole tanto tempo! Iphone niente di tutto questo è possibile, anche la versione per iPhone ha un motore molto più veloce javascript.

Se stare lontano da un sacco di parti dell'interfaccia utente nativa, cioè invece utilizzare setInterval per rilevare i cambiamenti di orientamento, attaccando con le immagini pendenza, dimenticare il pulsante Indietro, costruire il proprio animazioni, dimenticare le intestazioni delle finestre, barre degli strumenti, e cruscotto. È davvero possibile fare un'API che funziona sia che non richiede di sacco di riscrittura. Ma a che punta la sua altrettanto lento come una webapp.

Quindi ne vale la pena? Dopo tutto il dolore, la sua vale ogni minuto. È possibile astratto della logica e solo costruire diversa interfaccia utente per ciascuna piuttosto che se elseing ovunque. Titanium consente di effettuare le applicazioni di fluidi, che si sentono veloce. Si perde i potenti abilità layout di ogni piattaforma, ma se si pensa semplice, le cose possono diventare fatto sotto un unico linguaggio.

Perché non una web app? Sui telefoni Android Market entry level sua terribilmente lento per generare un WebView e consuma molta memoria si potrebbero utilizzare per fare logica più complessa.

Ecco un più recente e un'analisi approfondita di Appcelerator e PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

Ed ecco ancora più dettagli su come si differenziano a livello di codice: http://savagelook.com/blog/portfolio / PhoneGap-è-web-based-Appcelerator-è-puro-javascript

MapKit nativo è supportato in titanio

Fare HTML5 widget tha apparire come i widget iphone è una cosa, ma facendo loro eseguire ugualmente bene è un altro paio di maniche. Prestazioni di animazioni HTML5 (anche Plain View transizioni), scorrimento lunghe liste, di risposta ai gesti sensazione di aderenza e scatti. Un utente iPhone noterà la differenza.

Ci sono anche alcune differenze nei tipi di gesti che sono supportati da dispositivi diversi, che si traduce in problemi di codice e di usabilità specifici di piattaforma pure.

Starò con applicazioni native per ora immagino.

Rhomobile Rodi ( http://rhomobile.com/products/rhodes ) è molto simile per approccio a PhoneGap, ma è l'unico quadro con:

  1. un pattern Model View Controller (come la maggior parte dei framework web forniscono)
  2. un Object Relational manager
  3. supporto per tutti gli smartphone più diffusi (tra cui Windows Phone 7)
  4. un servizio di sviluppo hosted (build non appena ospitato): http://rhohub.com
  5. un debugger completo e SDK-meno emulatore nel RhoStudio IDE
  6. supporto per i dati non in linea sincronizzati

Per chiunque sia interessato in titanio devo dire che non hanno una buona documentazione alcune classi, le proprietà, i metodi sono mancanti. Ma molto è "documentato" nella loro applicazione di esempio l'kitchensink quindi non è poi così male.

La mia comprensione di PhoneGap è che forniscono le API JavaScript per gran parte delle API di iPhone.

Il titanio sembra più facile per uno sfondo web developer. Si tratta di un semplice file XML per creare un'applicazione TabView base e poi tutto nell'area dei contenuti è controllato da HTML / JS. So anche che il titanio non fornire qualche accesso javascript per alcune delle strutture (in particolare l'accesso alle informazioni sulla posizione, l'identificativo del telefono, ecc).

UPDATE: Titanio aggiunto Maps API in versione 0.8 del loro quadro.

Si dovrebbe imparare c obiettivo e programmare applicazioni native. Non fare affidamento su queste cose che si pensa renderà la vita più facile. Apple ha fatto in modo che il modo più semplice è utilizzare i loro strumenti nativi e il linguaggio. Per i vostri 100 righe di javascript che posso fare lo stesso in 3 righe di codice o senza il codice a tutti a seconda dell'elemento. Guarda alcuni tutorial - se si capisce javascript allora Objective C non è difficile. Soluzioni alternative sono miserabili e Apple può staccare la spina in qualsiasi momento si desidera.

Tra le soluzioni che hai citato, nessuno di loro sembrano dare accesso diretto al quadro MapKit introdotta in OS 3.0.

Mentre i widget di Google Maps HTML non sono quasi buono come MapKit (vedi Google Latitude per un esempio), si sono probabilmente meglio fuori lo sviluppo di un'applicazione Cocoa Touch nativa, o la scelta di una soluzione è possibile estendere per aggiungere l'integrazione MapKit. PhoneGap è estensibile in questo modo (è open source quindi è di default), e alcune delle altre soluzioni potrebbe essere pure.

modifica: Titanio ora ha il supporto per MapKit

Ho provato corona. E 'stato bello fino a quando ho scoperto che non supporta l'audio mp3 in streaming. Così, mi sono fermato lì. Penso che se voglio davvero essere uno sviluppatore iPhone app dovrei imparare obj c. Tutto quello che volevo fare un app che ha una lista di stazioni radio e si fa clic su di essi si avvia la riproduzione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top