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.]