Share
In questa intervista, parlo con il principale sviluppatore iOS Nick Lockwood sui suoi contributi open source, il suo flusso di lavoro di sviluppo e le risorse educative che ha trovato utili per padroneggiare l'SDK.
Nick Lockwood è uno dei principali sviluppatori iOS e autore di molti famosi progetti open source, tra cui iCarousel, iRate e FXBlurView.
Nick ha recentemente scritto il libro iOS Core Animation: Advanced Techniques, pubblicato da Addison-Wesley, e abbiamo fornito un estratto del Capitolo 5 insieme a questo post.
Ho iniziato a leggere un libro di programmazione quando avevo 12 anni. Non ricordo esattamente il nome del libro, qualcosa come "Programmazione di base su BBC Micro", ma è stato un momento cruciale nella mia vita.
Ho studiato ingegneria elettronica e poi informatica all'università. Il primo era interessante ma non particolarmente rilevante per la mia successiva carriera; Quest'ultimo mi ha insegnato i fondamenti delle strutture dati e degli algoritmi, che si sono dimostrati abbastanza utili.
Dopo la laurea ho creato la mia azienda Charcoal Design, vendendo semplici giochi per Mac e programmi di utilità scritti in REALbasic. Non ho fatto davvero soldi, quindi ho fatto dello sviluppo web freelance per far quadrare i conti.
Il mio primo vero lavoro è stato quello di sviluppatore web front-end, che inizialmente non sembrava avere molto a che fare con la programmazione, fino a quando JavaScript non ha raggiunto la maggiore età e lo sviluppo web front-end è diventato una vera e propria disciplina di ingegneria del software invece di riguardo a chi conosceva i bug esoterici di IE 6 CSS.
Ho visto che l'iPhone avrebbe avuto un impatto profondo sul web mobile quando è stato rilasciato, ma non ci ho pensato molto. Nel Regno Unito, in pratica nessuno ha acquistato l'iPhone di prima generazione: era troppo costoso e avevamo già dei telefoni di qualità piuttosto buoni (e molto più piccoli).
Ciò è cambiato da un giorno all'altro quando l'iPhone 3G è stato spedito. Ho ottenuto il mio primo iPhone nel luglio del 2008. E ho comprato lo sviluppo di iPhone 2 all'inizio, così ho potuto imparare a programmarlo. Mi sono già dilettato con Objective-C su Mac, quindi ho capito le basi abbastanza velocemente. Ho scritto Rainbow Blocks come app HTML5 in esecuzione su UIWebView a schermo intero (a quel punto mi sentivo ancora più a mio agio con jQuery che con UIKit) e l'ho rilasciato come open source.
Ho quindi avuto una buona occasione perché l'azienda per cui lavoro ha avuto l'opportunità di creare un'app per iPhone per uno dei nostri clienti e, come l'unica con esperienza iPhone, me l'ha data da costruire. Da allora sono uno sviluppatore iOS a tempo pieno. Da allora ho anche riscritto Rainbow Blocks come app nativa a sorgente chiusa.
Come molti programmatori, ho un difetto di carattere che mi fa sempre cercare di risolvere il caso generale anziché il requisito specifico. Ciò mi induce ad abbandonare quasi tutti i progetti che comincio perché mi impantaniamo cercando di risolvere un problema che è legato solo in modo tangenziale all'attività da svolgere.
Come molti programmatori, ho un difetto di carattere che mi fa sempre cercare di risolvere il caso generale anziché il requisito specifico.
Il mio disco rigido è disseminato di progetti a metà finiti (o appena avviati) che sarebbero stati la prossima grande cosa, ma non vedranno mai la luce del giorno. Ma ho scoperto che l'open source è un po 'un antidoto a questo problema. Se estraggo questi utili bit di codice, li documento e li attacchi su Github, quindi posso ancora recuperare qualcosa di prezioso dalle mie idee abbandonate.
Inoltre, gradualmente, poiché ho creato una libreria di componenti riutilizzabili, ho scoperto che creare app è diventato come assemblare mattoncini lego. Invece di "Sarebbe troppo complicato" trovo che posso rispondere alla maggior parte delle richieste di funzionalità con "Aha! Ho una libreria per questo".
Poiché ho creato una libreria di componenti riutilizzabili, ho scoperto che creare app è diventato come assemblare mattoncini lego.
Per quanto riguarda il motivo per cui li condivido? Non è particolarmente un atto di filantropia. Ottengo un enorme vantaggio personale dal farlo, sia in termini di feedback effettivo (segnalazioni di bug, correzioni e richieste di pull), ma anche di riconoscimento. Il mio open source è una vetrina per i miei servizi come sviluppatore.
Provo molta pressione per mantenere i miei progetti, ma me lo aspettavo - è parte del motivo per cui li ho rilasciati in primo luogo. Non sono molto bravo nell'auto motivazione e lavoro meglio quando ho un po 'di pressione esterna, quindi rilasciando codice alla comunità so che mi guideranno a migliorarlo.
La parte più difficile è sapere quando dire "no" alle funzionalità e alle richieste di pull. È difficile quando qualcuno ha speso diverse ore aggiungendo qualcosa a una delle mie librerie per dire "grazie ma no grazie", ma devo farlo per evitare il creep delle funzionalità che rende la libreria peggiore nel complesso.
Ho inviato alcuni di loro a siti come CocoaControls o Binpress e li ho proposti come risposte alle domande Stack Overflow come "Come posso fare un controllo come coverflow" o "Come posso chiedere agli utenti di valutare la mia app". iCarousel ha vinto il contest di sviluppo mobile di Binpress nel 2011, il che probabilmente ha aiutato un po 'la sua popolarità.
In questi giorni, per la maggior parte, ho appena postato un messaggio su "guarda cosa ho fatto" su Twitter e l'ho lasciato crescere da lì.
Non avevo mai fatto nulla con Core Animation prima di iCarousel. È stato un po 'il mio progetto "Hello World" per il framework Core Animation. È stato nel 2011, però, da allora ne ho fatto parecchio!
Il libro non era una mia idea; Pearson si è avvicinato a me e ha detto che stavano facendo una nuova serie di programmazioni mobili solo digitali e mi ha chiesto se sarei interessato a scrivere su Core Animation. Sembra che potrebbe essere divertente, quindi ho detto OK.
Poiché UIKit è così potente, molti sviluppatori si sentono un po 'a proprio agio all'interno dei propri confini e non si avventurano mai oltre. Penso che ci sia un equivoco sul fatto che se vuoi fare qualcosa di fantasioso come le interfacce 3D o gli effetti di mascheramento, allora devi andare giù a fare tutto con OpenGL.
Penso che ci sia un equivoco sul fatto che se vuoi fare qualcosa di fantasioso come le interfacce 3D o gli effetti di mascheramento, allora devi andare giù a fare tutto con OpenGL.
Molte delle soluzioni simili al coverflow che esistevano prima di iCarousel sono state scritte direttamente in OpenGL. Era una cosa abbastanza comune che le persone volessero fare, ma molti sviluppatori non hanno idea che Core Animation esista, o che sia una semplice API di alto livello che può fare facilmente questo tipo di effetti senza dover lavorare a livello di vertici e shader.
Molti sviluppatori semplicemente non hanno idea che Core Animation esista o che sia un'API di alto livello semplice che può fare facilmente questo tipo di effetti senza dover lavorare a livello di vertici e shader.
L'altra cosa che volevo affrontare con il mio libro era la performance. Le prestazioni sono così facili da sbagliare quando si ha a che fare con molte immagini o disegni vettoriali. Ho visto molte app che salta e salta perché gli sviluppatori non capiscono come usare la potenza dei thread e della GPU. Una buona conoscenza di come funziona Core Animation è fondamentale per ottenere buone prestazioni da un'app.
È rivolto ai lettori intermedi, ma non presuppone alcuna conoscenza di base dell'animazione core.
Si assolutamente. In effetti, uno dei motivi per cui ero così desideroso di farlo era a causa dell'opportunità di apprendimento. Non hai mai veramente capito qualcosa finché non hai provato a spiegarlo a qualcun altro. Ho trovato molte nuove proprietà e funzioni durante la ricerca del libro, oltre a chiarire molti dei miei malintesi. Ho dovuto riscrivere il capitolo 8 parecchie volte perché quando ho scritto gli esempi ho scoperto che le animazioni non funzionavano nel modo in cui pensavo di averle fatto (nonostante il fatto che le usavo da anni).
In realtà sono piuttosto prudente quando si tratta di utilizzare strumenti di produttività. Ho provato un sacco di cose, ma raramente mi attengo a loro.
Fornisco Podspecs per la maggior parte delle mie librerie, ma in realtà non le uso. Ciò è dovuto principalmente al fatto che odio le librerie statiche - quando possibile, importa direttamente i file sorgente in modo da poter tracciare i problemi all'interno di componenti di terze parti e apportare correzioni o miglioramenti.
Ogni volta che posso importare i file sorgente direttamente in modo da poter tracciare i problemi all'interno di componenti di terze parti, e apportare correzioni o miglioramenti.
Oltre a Xcode, utilizzo solo Tower (perché il supporto git di Xcode è instabile e non mi piace usare la riga di comando), Photoshop (perché non mi fido dei designer per tagliare le risorse), Resizer (per la conversione in batch di immagini Retina su standard) def quando sono troppo pigro per ridisegnarli), e SubEthaEdit (perché Xcode ha strane regole di indentazione per i file sorgente non-obj-C).
In realtà utilizzo raramente le librerie di terze parti. Il 90% delle librerie che uso sono mie, e se trovo che sono molto dipendente da una lib di terze parti, di solito finisco per scrivere la mia versione.
Ammiro molto il lavoro di Mattt Thomson, ma non ho l'ossessione di usare AFNetworking per ogni attività di accesso ai file di rete. Il download di un file in modo asincrono su una coda in background richiede una riga di codice. C'è sicuramente molto di più nell'interagire con i servizi web, ma soprattutto è altamente specifico per il servizio in questione. Devo ancora trovare una libreria di rete di terze parti che fornisca un vantaggio sostanziale rispetto al rollare uno stack di rete su misura, ma forse sono solo io.
Ultimamente sto usando Mantle e mi piace il modo in cui gestisce la mappatura delle proprietà JSON, ma l'ho avvolto in qualcosa di simile alla mia libreria BaseModel per ridurre lo standard di specifica dei percorsi dei file per la persistenza, ecc..
Non riesco a pensare a molte librerie di terze parti che ho usato su più di un progetto (SDWebImage, forse), ma ho un sacco di mie librerie personali che uso in quasi tutte le app che scrivo (StandardPaths, ViewUtils, BaseModel, AutoCoding).
Questo è qualcosa che mi viene chiesto molto in realtà. Lo raccomando senz'altro
A partire da iOS 6 Development (l'ultima edizione del libro da cui ho imparato) e iOS 6: Pushing the Limits. Vale anche la pena guardare molti dei video ufficiali del WWDC possibile. Il sito NSHipster di Matt Thomson merita sicuramente di essere letto. Ci sono molte altre buone risorse anche là fuori. Cocoa with Love, Cocoa is My Girlfriend, Cocoanetics, Ray Wanderlich e il blog di Mike Ash sono tutti da provare. Detto questo, tendo a utilizzare Twitter più di ogni singola fonte per rimanere aggiornato sulle cose.
Accentsconagua