Siamo arrivati all’undicesimo appuntamento con WWDC16 in Pillole. Per ricevere gratuitamente l’intera guida con i suoi 21 capitoli in formato ebook, lasciate il vostro indirizzo e-mail nell’apposito modulo alla fine di questo articolo!

11. Come migliorare la tua app (Parte Seconda)


Nel capitolo precedente (Come migliorare la tua app – Prima Parte) abbiamo visto in che modo agire per far sì che la nostra app segua gli standard dettati da Cupertino. Oggi proseguiamo il medesimo discorso e, in particolare, tratteremo di:

  • Versioni iOS da supportare
  • Swift Migration
  • Dependency Injection

Buona lettura!

11.1 Versioni iOS da supportare


Innanzitutto Apple ci consiglia di non supportare versioni iOS troppo arretrate, di arrivare al massimo fino ad iOS 8 perché, così facendo, si copre il 95% dei dispositivi in circolazione.

Va bene quindi retrocompatibilità… ma non esageriamo!

Il calcolo consigliato sulle versioni di iOS è il seguente. Supponendo di voler supportare la versione iOS 9.3 (anche se ormai è bella che passata da un po’ di mesi) il nostro deployment target non sarà di una versione indietro ma la 8.4. Secondo lo stesso ragionamento, supportando oggi la 10 abbiamo bisogno di supportare al massimo la versione minima a 9.3.

Questo perché così, oltre al nostro codice, includiamo anche le fix fatte da Apple sulle versioni nuove del sistema operativo iOS 9, che sono incluse con i rilasci successivi alla prima versione. Dunque non serve supportare la prima release dell’ultima versione ma la versione finale della major version minore da supportare.

11.2 Swift Migrator

Per avere il 100% di compatibilità, Apple consiglia di migrare il nostro codice a Swift 3. Chiaramente si fa una prova e si seguono i seguenti check: se il build funziona festeggiamo… ma se non così? Seguiamo i passi consigliati da Cupertino.

  1. Individuare l’origine del problema. Può trattarsi di conversione mal formattata (dovuto ad Apple) oppure del nostro codice, che in questo caso potremo sistemare.
  2. Come usiamo le API? Assicuriamoci di utilizzare le API nel modo corretto
  3. Funziona come prima? Assicuriamoci che anche lo Unit Test ci dia l’ok sul funzionamento del nostro codice.


Se non si è superato il test, meglio non migrare ancora. Come spiegato nella puntata precedente, Apple ci è venuta incontro e ci ha permesso di supportare anche Swift 2…. per ora! Quindi teniamoci pronti alla migrazione.

Se dopo aver indagato scopriamo che è un problema di Apple… aiutiamoli! Segnaliamo i bug, così nelle prossime release potranno e effettuare le fix necessarie per farci comodamente migrare a Swift 3. Basta andare qui https://bugreport.apple.com e seguire i passi 🙂 


11.3 Dependency Injection

La Dependency Injection è un Design Pattern che Apple consiglia di adottare. Si tratta di un design pattern utilizzabile nella programmazione OO e che quindi si consiglia di adottare anche nelle nostre app in Swift e Objective-C. Ma di cosa si tratta?

La Dependency Injection prevede di collegare due componenti in modo esplicito. Pensiamo in iOS, ad esempio, alla UITextField; questo oggetto è fortemente connesso al suo delegato e si può avere l’informazione su di esso tramite il metodo textFieldShouldBeginEditing che in input ci fornisce il riferimento all’oggetto UITextField stesso.

L’ascoltatore è sempre fornito nei metodi del delegato. È questo il Dependency Injection in Swift / Objective-C: una dipendenza tra il protocollo delegato ed il suo oggetto. Lo stesso si ripresenta in molti altri casi, ad esempio i metodi del protocollo delegato associato alla UITableView o all’ UIApplication (AppDelegate).

La connessione non è sempre bidirezionale, basti pensare che l’UIViewController è fortemente connesso all’AppDelegate (può richiamare i metodi dell’AppDelegate) ma l’AppDelegate non ha informazioni sull’UIViewController e non ci restituirà mai un oggetto UIViewController.

Questo perché comunque si adotta un design pattern in base a cosa realmente ci occorre: non è sempre necessario, dipende dalla situazione. L’idea in questo caso è che si dà all’UIViewController tutto ciò di cui ha bisogno per effettuare il suo ciclo di vita. Ciò però non ci deve indurre in tentazione, sappiamo che non è buona cosa usare l’AppDelegate come “bacinella” di dati per tutti gli UIViewController.

Se occorre che si condividano delle informazioni tra UIViewController serve connettere ad essi un oggetto Model, il quale dispone di un insieme di dati che, ad esempio, servono sia all’UIViewController attuale che al successivo.

Si deve fare in modo di passarlo direttamente seguendo la regola del Dependency Injection per cui gli UIViewControllers hanno una forte connessione tra loro e l’oggetto condiviso. In questo caso meglio renderle atomiche per poterle combinare come più ci piace, ad esempio se si vuole rappresentare insieme più schermate di un app per iPhone nella stessa pagina dell’app per l’iPad. Un esempio pratico: l’app delle mail.

La prima schermata sarà una UITableView composta da tante celle quanti sono i componenti dell’elenco di oggetti di tipo mail. Selezionando il dettaglio della mail avremo l’oggetto mail selezionato dalla UITableView della pagina precedente. Quindi due UIViewController che si passano un dato a cui sono fortemente connesse per la renderizzazione della loro UIView principale.

***

Per consultare la guida completa seguite il link (raccolta articoli completa).

Per ricevere l’intero ebook compila il seguente modulo con il tuo indirizzo mail!








NO COMMENTS

LEAVE A REPLY