2012-06-27 12 views
8

Fondamentalmente ho bisogno del tuo consiglio i miei bravi amici dello stack: DDevo imparare lo sviluppo nativo iOS (Objective-C) o perfezionare le mie conoscenze in Javascript e Titanium Appcelerator?

Negli ultimi sei mesi sto esplorando/imparando/sviluppando app iOS con il framework mobile Titanium Appcelerator. Le mie esperienze sono per lo più buone o molto buone.

Alcune parti negative di Titanium potrebbero generare tempo, in particolare durante il test su un dispositivo. Quando si utilizza solo Xcode (nativo), l'app viene avviata immediatamente su un dispositivo, mentre con Titanium è necessario attendere un po '(1-2 minuti) per l'app da compilare e quindi installarla su un dispositivo (configurazione iTunes o iPhone Utilità).

Fondamentalmente tutto ciò che è possibile fare in modo nativo si può fare con Javascript + Titanium. Se Titanium non supporta alcune parti del framework iOS, puoi creare un modulo Objective-C nativo e avere queste caratteristiche nel tuo codice Javascript.

Ora mi sento davvero a mio agio usando Titanium Appcelerator e creando app con Javascript. Ho anche imparato alcuni Objective-C mentre creavo alcuni moduli per iOS. Per esempio. DeviceMotion che ho usato nella mia prima app per iOS Spellery.

Ora la domanda:

maggior parte delle società vuole solo gli sviluppatori nativi e sono scettico di titanio. Il titanio è diverso dagli altri SDK multipiattaforma (ad esempio PhoneGap) perché qui si utilizzano effettivamente componenti nativi (pulsanti, etichette, ecc.) E l'app non è in esecuzione in una WebView. Ma se la compagnia vuole un nativo, non puoi costringerli a usare il titanio.

Dal momento che mi piacerebbe sviluppare app mobili come lavoro, dovrei semplicemente lanciare i miei ultimi sei mesi di intensa esplorazione di Titanium e imparare a programmare quelle app in modo nativo?

Quali sono i tuoi pensieri su questo perché non vedo alcun punto nell'apprendimento/perfezionamento di entrambi?

Sono un grande fan di Appcelerator Titanium ora, quindi questa è una decisione molto pesante da prendere.

risposta

11

Francamente, vorrei ancora suggerire di imparare un po 'di Objective-C. È un linguaggio molto potente ed è progettato per consentire a molte cose che Apple considera le necessità molto più facilmente (ad esempio Animazione, Persistenza, Database, MVC). Apple ha progettato i loro framework attorno a Objective-C molto strettamente, e per usarli davvero bene, devi usarli dalla loro lingua. Inoltre, quali altre lingue conosci? Io, per esempio, ho trovato Objective-C molto più semplice dopo essere arrivato da C/C++ e da un linguaggio di scripting (Ruby). Tutto dipende davvero da quanto iOSness vuoi nella tua app. Persino Titanium può far sentire iOSy all'utente finale, il codice iOSy è davvero divertente da scrivere e mantenere. Può essere una struttura abbastanza bella.

+0

Le mie prime lingue che utilizzo sono Java e Javascript. Ho imparato un sacco di Javascript mentre imparavo Titanium e leggendo alcuni buoni articoli/libri. Penso che Objective-C sia buono e sta diventando sempre più popolare (6.nella lista delle lingue più popolari). – vale4674

+1

@ vale4674: Hm. Sfortunatamente, nessuno di questi ha nulla a che fare con Objective-C. Ma questo non è uno spettacolo, basta essere pronti per imparare un insieme completamente diverso di principi OOP. Objective-C è in realtà C + Smalltalk (o qualsiasi dei suoi discendenti). – Linuxios

+0

Conosco C (era la mia prima lingua che ho imparato insieme a Pascal) ma non l'ho usato per molto tempo. Objective-C è interessante da imparare e io redico un libro di Stephen G. Kochan [Programming in Objective-C] (http://www.amazon.com/Programming-Objective-C-Edition-Developers-Library/dp/0321711394/ ref = pd_sim_b_1) e comunque ho deciso di sviluppare con JS e Titanium. Ho anche guardato alcune presentazioni di Stanford su iTunesU sullo sviluppo di app iOS. Anche se non sono un principiante assoluto con Objective-C, ci vorrà del tempo per impararlo bene a sentirsi a proprio agio con esso. – vale4674

3

Guarda le offerte di lavoro che ti interessano e che dovrebbero rispondere alla tua domanda. Se i datori di lavoro sono alla ricerca di competenze XCode e non interessati a titanio quindi concentrarsi su XCode ...

+0

Se così facendo, la risposta sarebbe Xcode e nativo. Penso che tutti i segni puntino verso Xcode. – vale4674

3

Per aggiungere a @ eccellente risposta di Linuxios:

Dal momento che si stato che si desidera inserire sviluppo mobile come una carriera, allora la maggior parte sicuramente imparare Objective-C, XCode e l'SDK iOS. Alla fine, dipenderà da te, dal tuo datore di lavoro e in una certa misura dai tuoi clienti. Ma capire iOS è essenziale.

Inoltre, secondo la mia esperienza, se l'applicazione è complicata, nativo sarebbe la strada da percorrere, se per una ragione diversa dalla facilità di debug e, come si afferma, tempi di costruzione più brevi.

UPDATE: Un'altra cosa da aggiungere, se le prestazioni è la chiave (vale a dire il gioco), poi nativo (C/C++/Objective-C) è la strada da percorrere.

4

Scommetto che molti altri interverranno con post su altre domande "duplicate" e le loro opinioni furiose. Quindi lo lascerò a loro e fornirò solo la mia esperienza.

Penso che ci siano buoni motivi per conoscerlo entrambi profondamente. Ecco perché:

Titanium consente di creare applicazioni in modo molto rapido e diventa sempre più solido ogni giorno. Di recente ho creato un'app per confrontare direttamente i tempi di sviluppo tra Titanium, nativo e un paio di framework concorrenti. Nativo era circa una settimana e mezzo. Il concorrente era di circa 2 settimane. Il titanio era di 3 giorni. Questo mi ha dato un sacco di tempo per giocare con l'app e rendere un prodotto molto migliore rispetto ai concorrenti. Sono stato anche in grado di farlo funzionare altrettanto bene su Android e Mobile Web. Avevo circa 5 condizionali basati su piattaforma, quindi il codice aveva una buona parità.

Nativo ha i vantaggi che ha portato. Vorrei aggiungere che puoi anche accedere a qualsiasi piattaforma abbia da offrire. Conoscendo il nativo informerai su come costruisci le app (anche quando usi JavaScript) e su come costruisci i moduli per quelle app. Potresti anche provare ad aprire il progetto Xcode generato da Titanium e farlo funzionare direttamente sul dispositivo. Potrebbe essere necessario eseguire una compilazione pulita (in Xcode), ma è più veloce di eseguire iTunes.

Inoltre, penso che Objective-C sia un bel linguaggio in sé e per sé. È molto diverso dal codice con cui sono "cresciuto" con (Java, C#, PHP, VB e alcuni altri). Ci è voluto un po 'per abituarmi, ma sono contento per il tempo che ho investito.

Disclaimer: Lavoro per Appcelerator. Spero che tu possa differenziare opinioni e fatti in quanto sopra.

+0

È decisamente più veloce sviluppare con Titanium e ciò che mi piace di Titanium è che la community sta crescendo molto velocemente. Sono d'accordo che è bello conoscerli entrambi, ma penso anche che sia bello "perfezionare" te stesso con qualcosa e il modo migliore per farlo è usare intensivamente questo quadro. – vale4674

+0

Penso che il problema più grande sia che i clienti o le aziende non sono consapevoli di quanto Titanium Appcelerator sia potente. – vale4674

+0

Penso che gli sviluppatori siano i più influenti con la decisione su cosa usare. Questa è stata la mia esperienza. Anche se il verdetto finale viene tramandato dall'alto, la maggior parte delle prove proviene dagli sviluppatori che la useranno. –

6

Sono d'accordo con tutto ciò che è stato detto nelle risposte precedenti e sembra che tu abbia accettato di tornare al lato positivo - buona scelta!

Vorrei solo aggiungere questo: non guardare quei sei mesi come se fossero sprecati. Durante il tuo tempo con Titanium, hai imparato molti dettagli tecnici, oltre alle possibilità e ai limiti di iOS e questo dovrebbe rivelarsi utile quando passi a Objective-C.

+0

Mi ripeterò. Con Titanium puoi fare cose molto più velocemente (se Titanium lo supporta e non devi scrivere un modulo per questo). Quindi in pratica devo farmi una domanda: sono uno sviluppatore iOS o Android? Con Titanium posso fare entrambe le cose, entrambe le aziende hanno due team, uno per iOS e uno per Android e fanno solo native. – vale4674

6

Ahhhmmmm ... Non sono sicuro se la mia risposta verrà rimossa dall'amministratore di StackOverflow. Perdonami, prenderò alcuni minuti della tua lettura di questa lunga risposta (se sei interessato a continuare a leggere).

Ho iniziato la mia azienda nel 2010. Abbiamo lavorato solo su siti web php, mysql, html e jquery. Mentre la piattaforma mobile stava ottenendo più attenzione, abbiamo iniziato a lavorare su app mobili Sencha Touch + PhoneGap. Alla fine del 2011, ho formato i miei 12 sviluppatori in Sencha Touch + PhoneGap. Puoi capire quanto impegno sia stato di imparare e formare un team di 12 sviluppatori in un nuovo framework.

Dopo aver sviluppato più di due dozzine di app basate su PhoneGap professionali ci siamo resi conto che è molto lontano dalle app native. Basta un solo esempio: l'app PhoneGap impiega più tempo a caricare la pagina html iniziale nella webview. Una schermata bianca vuota è apparsa subito dopo la schermata iniziale (su Android è più orribile!). Nelle ultime versioni di PhoneGap è stato risolto. Ma chi sta lavorando con PhoneGap sa molto bene quanto sia lontano dalla vera app di obj-c.Abbiamo lavorato nel framework PhoneGap + Sencha Touch per un anno.

Abbiamo smesso di funzionare in PhoneGap e ho iniziato a studiare & allenando i miei 12 ragazzi in titanio. So quanto sia stato duro lavorare per iniziare un altro nuovo framework da zero. Abbiamo continuato a lavorare con il titanio per 2 anni, abbiamo sviluppato oltre 30 applicazioni professionali di successo in titanio sia per iOS che per Android. Siamo diventati esperti nello sviluppo di moduli in titanio. Solo per esempio abbiamo sviluppato il modulo di titanio PayPal su iOS e Android. (Devi ridacchiare, cosa c'è di così bello! È già stato sviluppato dal team di titanio). No, non usare la vecchia libreria MPL. Abbiamo utilizzato l'ultimo sdk 2.8.0 di Paypal e non è disponibile alcun modulo online.

A metà 2014 abbiamo iniziato a lavorare su un'app di tipo clone Tinder/Lovoo. Abbiamo sviluppato un modulo ti per animazioni simili (implementando UIView drawRect). Tutto andava bene. Ma quando viene eseguito su iPhone, il dispositivo diventa eccessivamente caldo e la batteria si scarica drasticamente nella pagina di animazione. Abbiamo creato un'app di Xcode dimostrativa di esempio e applicato la stessa animazione, testata su Instruments, tutto andava bene. Nessun sovraccarico su memoria o processore, il dispositivo è rimasto freddo, le prestazioni della batteria andavano bene. Abbiamo provato in ogni modo possibile per renderlo migliore nel modulo in titanio e senza fortuna. Infine, lo stesso titanio scoperto prende un'impronta enorme per far funzionare la propria struttura voluminosa e per ogni azione, spara un sacco di eventi proxy e continua ad ascoltare eventi non necessari. Le complesse animazioni di UIView rendono folle. È solo un esempio: su Android è una lunga storia.

Perché le aziende decidono di utilizzare il titanio? La prima risposta è che è multipiattaforma. Basta codificare in js e funziona sia su iOS che su Android. Ah ah .. un tale scherzo! Non è vero per una vera app professionale. Ci sono molte differenze e bug nella versione di Android ed è un carico di lavoro in più sulla versione di Android. E praticamente non potremmo mai utilizzare una copia esatta della stessa base di codice iOS per Android. Quindi quella teoria della multipiattaforma è vera solo per i progetti di classe. Se non mi credi, crea un semplice progetto Android in titanio per acquisire l'immagine, caricala sul server e poi visualizzala di nuovo dal server. Prendi una galassia S5, scatta una foto (Non in modalità verticale) in modalità orizzontale-destra (tasto home sul lato destro), puoi vedere che l'orientamento dell'immagine è rovinato. Oh! Dimenticavo, dall'app android di titanium se carichi l'immagine sul server, l'estensione dell'immagine diventa .txt

In Obj-C UINavigationController popToRootViewController Un metodo stimato è una funzionalità fondamentale per tornare alla pagina iniziale. Questo stesso metodo non è disponibile in Titanium!

Abbiamo speso centinaia di ore in più per risolvere questo tipo di problemi scomodi. Il mio team di sviluppo si è stufato del titanio.

Definitivamente mi chiederete ora, perché mai all'inizio non abbiamo avviato Obj-C? La risposta è la stessa di tutti gli sviluppatori di titanio: Javascript è semplice e gli sviluppatori web lo conoscono già. Questo è un grosso errore. Prendiamo l'app per iPhone come app web. Un'app Web viene eseguita su un browser Web, in particolare su iPhone che viene eseguito all'interno di Safari di iPhone. "Safari" è di per sé un'app mobile e ci aspettiamo che l'applicazione web debba funzionare come animazioni visive simili con lo stesso ritmo, il che non è mai possibile. Le animazioni CSS3 non possono mai essere le stesse animazioni UIView basate su vettori iOS.

iOS NON è un framework o una libreria, è un sistema operativo. Il titanio è un framework che è scritto in Obj-C. Non è possibile utilizzare lo strumento di progettazione dell'interfaccia utente di Xcode Storyboard in titanio. Gli sviluppatori Xcode sanno quanto sia sexy il "vincolo" per la progettazione dell'interfaccia utente. E questo richiamo visivo all'utilizzo del vincolo è totalmente assente in Titanium. Sebbene ti stia affermando che possiamo fare le cose con vincoli usando Ti.UI.FILL/SIZE ecc. Ma dopo esserci spostati in Obj-C nativo sappiamo quanto è potente questo sistema di vincoli!

Mi tiro fuori i capelli e rimpiango perché mi sono spaventato a guardare quelle sintassi Obj-C con parentesi quadre e sono tornato al titanio.Sembra che tu stia tornando indietro di decenni nell'età moderna, osservando la sintassi non familiare di Obj-C. Fortunato che Swift sia lì ed è ora molto più facile codificare in Xcode. Anche se sarebbe necessario del tempo per ottenere le famose librerie Obj-C più famose, come AFNetworking, MBProgressHUD, OpenCV migrate a Swift.

Per essere onesti, sento davvero che i framework in cross-platform Titanium, PhoneGap, Xamarin ecc. Dovrebbero essere vietati. La loro licenza dovrebbe essere cessata. Il titanio ti offre funzionalità aggiuntive che non sono disponibili in iOS o Android nativi? Invece, ci sono molto meno funzionalità e più bug. Non capisco perché, come su questa moderna tecnologia all'avanguardia stanno riportando la gente ai vecchi tempi e non c'è nessuno che li fermi! Come potrebbe essere legale guidare gli sviluppatori nella direzione sbagliata? Se iOS 9 viene rilasciato "oggi", Titanium ti fornirà tutte le nuove API entro la prossima settimana? Mai. Ti tengono semplicemente indietro e ti obbligano a usare il loro set limitato di API buggy, devi pagare per i moduli, che possono essere fatti facilmente nel codice nativo.

Se conosci bene javascript, in senso logico, credimi, puoi imparare Obj-C in un tempo molto breve. Nel momento in cui gli sforzi di & si perderebbero i problemi di debug in titanio, è possibile diventare più efficienti nell'Obj-C nativo. Ummm .. su Android non dirò che in alto. Perché Android non è mai paragonabile a iOS. iOS nasce da Mac OS, un sistema operativo desktop consolidato. E tu sai di Android.

Non cadere nella trappola del dilemma cross-platform. I carichi delle API di Titanium sono solo per iOS, sai perché, i dispositivi Android sono economici, l'hardware è economico, non è possibile eseguire animazioni senza problemi.

Infine, stare lontano da qualsiasi tipo di piattaforma e attenersi al puro sistema operativo nativo, non importa quanto sia difficile all'inizio, sarete a lungo pagati, credetemi!

Per il team di titanio, ho esaminato il codice sorgente Obj-C e Java. Rispetto voi ragazzi, siete davvero molto esperti e ben esperti in Obj-C, Java, node.js, python e javascript. Ma perché? Perché stai portando le persone nella direzione sbagliata? Sai molto bene quanto tempo è sprecato per costruire un modulo android/ios in titanio e testarlo. Perché non metti i tuoi sforzi in qualcosa di meglio.

+0

Non sono d'accordo perché ci deve essere un modo in cui la cross-platform può funzionare. Una buona soluzione JavaScript dovrebbe rendere entrambe le codifiche semplici per entrambe le piattaforme. – SmallChess

+0

@StudentT, per definizione 'multipiattaforma' significa - può essere utilizzato su diversi tipi di SO. Ma iOS non ha tutte le funzionalità di Android e viceversa. Ad esempio http://goo.gl/tIb29K Split Windwo è disponibile per iOS, non per Android in titanio api. Con Android Java nativo puoi realizzarlo usando Fragments. Frammento è un concetto solo per Android, iOS non ce l'ha! Allora come puoi aspettarti qualcosa in multipiattaforma quando non esistono realmente su entrambe le piattaforme native! Ci sono centinaia di differenze tra piattaforme diverse, come puoi unificarle tutte? Impossibile per app complesse! – Adnan

+0

Recentemente ho sviluppato ionic 2 app, ha circa 25 schermi, la schermata bianca appare dopo la schermata iniziale. il tempo di sviluppo su ionic 2 è molto veloce. Ci deve essere un modo per evitare, ma non ho potuto trovarlo su internet. dopo che mi sono trasferito su xamarin.android, sembra poco impressionante fino ad ora. –

1

Dal mio punto di vista è sempre molto utile imparare lo sviluppo di app native, iOS e Android. Come hai già detto, la maggior parte delle aziende è alla ricerca di sviluppatori di app nativi, dal momento che non vogliono dipendere troppo da aziende o framework esterni, a parte gli effettivi sviluppatori della piattaforma (Android, iOS e così via). Penso anche che, una volta in grado di sviluppare app native, è molto più semplice che usare un framework come Titanium o PhoneGap. Inoltre è sempre bene migliorare le tue abilità e in particolare lo sviluppo di app native è un campo in cui puoi imparare molto. Non solo sulla lingua, ma anche sull'architettura del sottostante sistema operativo mobile. E in particolare per Apple, penso che sia fondamentale imparare a sviluppare nativi. Hanno risorse molto buone sul proprio portale per gli sviluppatori e lì si impara anche molto sulla progettazione dell'interazione dell'utente.

Ultimo ma non meno importante, ti consiglierei di andare avanti con Swift. È un linguaggio grande e potente, che fissa molti dei punti deboli di Objective-C. Puoi fondamentalmente iniziare a formare scratch con Swift senza bisogno di Objective-C. L'API Cocoa completa è accessibile tramite Swift. Ma se vuoi, puoi comunque combinare Objective-C e Swift. Ad esempio se hai bisogno di usare una libreria esterna che non è ancora implementata in Swift.

Spero di poterti aiutare un po '.

Problemi correlati