\n
![\"master-detail-the-right-way-01\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2012\/07\/master-detail-the-right-way-01.jpg\" "\\"master-detail-the-right-way-01\\"")
<\/a>\n<\/center><\/p>\n
Per chi fosse interessato questo mockup \u00e8 stato realizzato con Balsamiq, un software a pagamento (anche se la demo \u00e8 perfettamente funzionante) che trovate a questo indirizzo: http:\/\/www.balsamiq.com\/<\/a><\/p>\n Ok, abbiamo tutte le indicazioni che ci servono per realizzare la nostra app, quindi aprite XCode e iniziate a digitare…. FERMI TUTTI! La prima cosa da fare quando si parte con lo sviluppo di un’applicazione \u00e8 stare fermi e pensare cosa fare, poi quando crediamo di aver pensato abbastanza, ci fermiamo ancora e cerchiamo di capire se quello che abbiamo pensato \u00e8 giusto.<\/p>\n Iniziamoci a chiedere in quanti viewcontroller dividiamo l’applicazione.<\/p>\n La risposta potrebbe esere uno per la tabella, uno per i dettagli e…. e poi? Siamo sicuri che servano due viewcontroller per la foto e la mappa? non posso semplicemente sostituire una imageview con una mapview a seconda del tasto che ho premuto nella schermata precedente? Certo lo potrei fare… anzi potrei anche caricare tutto sullo stesso viewcontroller se volessi, perch\u00e9 non lo faccio? Ci sono dei pro\/contro in termini di prestazioni?<\/p>\n Non ci sono n\u00e9 pro e n\u00e9 contro puramente tecnici, ma le performance di un’applicazione sono soltanto uno degli obbiettivi del programmatore, il cui compito \u00e8 quello di scrivere codice chiaro e manutenibile. Se in un’azienda non ci fossero suddivisioni di ruoli e responsabilit\u00e0 a chi vi rivolgereste se aveste qualche problema? Allo stesso modo in un’applicazione, se non ci sono netti confini su chi fa una cosa e chi ne fa un’altra, si crea un caos nel quale \u00e8 impossibile anche solo manutenere il codice. Tornando quindi al numero dei viewcontroller la mia risposta \u00e8 cinque.<\/p>\n Cinque? Si cinque:<\/p>\n Adesso possiamo iniziare a programmare?<\/p>\n Non ancora, abbiamo visto i viewcontroller, ma non abbiamo parlato del model!<\/p>\n Il modello \u00e8 forse l’aspetto pi\u00f9 sottovalutato tra tutti i nostri utenti pi\u00f9 “giovani” nel mondo della OOP.<\/p>\n Alla base del concetto della programmazione OOP c’\u00e8 la volont\u00e0 di creare una rappresentazione della realt\u00e0 all’interno dei nostri programmi. Non parlo di realt\u00e0 aumentata, non fraintendetemi. Dico che uno degli scopi della programmazione OOP \u00e8 quello di renderla un’attivit\u00e0 pi\u00f9 simile a quello che il nostro cervello \u00e8 abituato a fare tutti i giorni: interagire e far interagire tra di loro gli oggetti.<\/p>\n Chi conosce almeno un linguaggio non ad oggetti, come ad esempio il C, sa bene che non si ha quasi mai a che fare con variabili che rappresentano qualcosa di “tangibile” o comunque appartenenti alla relt\u00e0, ma si ha a che fare con variabili char, int e via cos\u00ec. In OOP e nello specifico con iOS, invece, hai per esempio l’oggetto UIButton che cerca di mappare all’interno di un programma il concetto di “pulsante”.<\/p>\n Il nostro compito di programmatori \u00e8 muoverci in questo ambito, capire l’universo del problema che dobbiamo risolvere e creare i nostri oggetti che mappino le entit\u00e0 di questo universo.<\/p>\n Nel nostro esempio \u00e8 presto detto, visto che parliamo di clienti sar\u00e0 opportuno creare una classe Cliente e sar\u00e0 questa il nostro modello.<\/p>\n Adesso possiamo iniziare a programmare? Non ancora, abbiamo un’idea generale di quali classi aggiungere, ma prima di iniziare veramente a scrivere codice \u00e8 bene scendere in dettaglio ed esaminare propriet\u00e0 e metodi di ciascuna classe.<\/p>\n In questa applicazione il nostro concetto di cliente ha le seguenti caratteristiche:<\/p>\n Per quanto riguarda nome e cognome possiamo tranquillamente considerarle delle stringhe, l’avatar e la foto sono sicuramente due immagini, ma l’indirizzo?<\/p>\n Se abbiamo un p\u00f2 di lungimiranza sappiamo che per visualizzare il pin sulla mappa non \u00e8 sufficiente avere un indirizzo, ma questo indirizzo deve essere geolocalizzato, in pratica servono le coordinate geografiche di latitudine e longitudine.<\/p>\n Chi,secondo voi, dovrebbe occuparsi di fare questo lavoro all’interno de nostro programma?<\/p>\n Possono esserci pi\u00f9 risposte, pi\u00f9 o meno valide ed \u00e8 bene, quando ci si trova davanti ad un problema come questo, confrontarsi con qualche altro sviluppatore per esaminare attentamente pro e contro di ogni singola soluzione.<\/p>\n A me sono venute in mente un paio di soluzioni, alla fine ne ho scelta una, ma piuttosto che la pappa pronta voglio spiegarvi il ragionamento che mi ha portato a questa soluzione esaminando prima le varie possibilit\u00e0 che sono state scartate:<\/p>\n Servir\u00e0 per mostrare l’elenco dei clienti, avr\u00e0 come variabile di istanza un’array di clienti, ma non sar\u00e0 accessibile pubblicamente perch\u00e9 il viewcontroller provveder\u00e0 autonomamente a inserire all’interno di questa lista tutti i clienti memorizzati.<\/p>\n Chiediamoci che stato interno pu\u00f2 avere? E quali sono i suoi metodi che posso richiamare dall’esterno? Per i restanti due viewcontroller aggiungerei soltato una variabile di istanza di tipo UIImage e una di tipo NSString per memorizzare l’indirizzo da visualizzare.<\/p>\n Ragionando in questi termini abbiamo ottenuto una notevole seprazione dei ruoli, se volessimo ad esempio sostiture il viewcontroller delle mappe con uno pi\u00f9 complesso tutto il resto della nostra app resterebbe illeso!<\/p>\n Adesso finalmente possiamo iniziare a programmare. Apriamo quindi XCode e selezioniamo il template “master detail”, specifichiamo applicazione solo per iPhone e chiamiamola “learnMasterDetail”. Abilitate il supporto ARC e delezionate l’opzione per utilizzare CoreData.<\/p>\n Se non avete mai utilizzato questo template prendetevi qualche minuto per verificarne il funzionamento.<\/p>\n Il progetto si presenta con due file AppDelegate.h e .m e due viewcontroller, il MasterViewController e DetailViewController.<\/p>\n Iniziamo a creare le classi che costituiranno il nostro model, quindi file -> new -> file e scegliamo “Objective-C Class” chiamiamola Location e creiamola come subclass di NSObject.<\/p>\n Aggiungiamo quindi nel file Location.h la dichiarazione delle nostre property, il file completo \u00e8 questo:<\/p>\n Una volta dichiarate le property bisogna aggiungere il @syntetize, in questo caso ho deciso di segure la consuetudine che vuole che il nome della variabile di istanza sia precedura da un underscore, mentre il metodo ha il nome della property.<\/p>\n Il file .m completo \u00e8 questo:<\/p>\n Se vi state chiedendo del perch\u00e9 di questa dichiarazione, diciamo brevemente che in questo modo \u00e8 chiaro che se scrivo _lng = 0 accedo direttamente alla variabile di istanza, mentre se scrivo self.lng accedo al metodo.<\/p>\n Dobbiamo creare adesso la classe Cliente, seguiamo la stessa procedura fatta precedentemente e aggiungiamo i due file Cliante.h e Cliente.m.<\/p>\n Importiamo il file Location.h e dichiariamo le property. Ottimo, adesso che abbiamo le classi pi\u00f9 importanti del nostro model passiamo al primo viewcontroller, il MasterViewController.<\/p>\n Selezioniamo quindi il file MasterViewController.h e aggiugiamo in alto:<\/p>\n Questa classe sembra non avere alcuna variabile di istanza, ma invece non \u00e8 cos\u00ec. Per una maggiore pulizia del codice gli ingegnieri Apple hanno posto la variabile di istanza all'interno di una category (se non sapete cos`\u00e8 c'\u00e8 un articolo su devAPP<\/a>) troviamo infatti una variabile dichiarata nel file .m ed in particolare in questo blocco:<\/p>\n Il termine _objects \u00e8 abbastanza generico e possiamo riciclarlo per la nostra app, infatti questo array conterr\u00e0 l'elenco dei clienti da visualizzare.<\/p>\n Prima di continuare eliminiamo tutto ci\u00f2 che non ci serve da questo file, il quale contiene tutti i metodi per aggiungere delle righe a runtime, ma che a noi non servono.<\/p>\n Quindi partendo dal metodo viewDidLoad:<\/p>\n Lo riduciamo all'osso, con la sola chiamata alla superclass. Non l'ho tolto del tutto perch\u00e9 ci servir\u00e0 tra un attimo. Provate a compilare, se non avete eliminato nulla di fondamentale l'applicazione dovrebbe continuare a girare, con l'unica differenza che non sono pi\u00f9 presenti le funzionalit\u00e0 per modificare la tabella e per aggiungere una nuova riga.<\/p>\n Dobbiamo ora creare i nostri clienti, quindi all'interno del metodo viewDidLoad li creiamo e li memorizziamo all'interno dell'array _objects. Come funziona questo codice dovrebbe essere abbastanza chiaro, in pratica vengono creati 20 clienti e per ciascuno vengono settate le propriet\u00e0 con una sequenza come Nome_1, Nome_2.
\nPer raggiungere l’obbiettivo della chiarezza e semplicit\u00e0 del codice non si pu\u00f2 prescindere dal suddividere quanto pi\u00f9 possibile compiti e responsabilit\u00e0.<\/p>\n
\nQuando si parla di manutenibilit\u00e0 del codice spesso si tende a sottovalutare il problema, perch\u00e9 lo si pensa come qualcosa fissato in un ipotetico futuro lontano. Io dico che il problema della manutenibilit\u00e0 del codice \u00e8 presente in tutti i progetti che per essere completati richiedono pi\u00f9 di due ore, perch\u00e9 in un pomeriggio si pu\u00f2 scrivere tanto di quel codice che se non \u00e8 strutturato bene gi\u00e0 l’indomani mattina non riesci pi\u00f9 a prenderne le fila.<\/p>\n\n
Iniziamo con la classe Cliente.<\/h4>\n
\n
\n
\npro:<\/strong> sicuramente la soluzione pi\u00f9 semplice che si possa pensare, non modifichiamo la classe Cliente e siamo in grado di visualizzare qualsiasi indirizzo.
\ncontro:<\/strong> il contro pi\u00f9 evidente \u00e8 che ad ogni visualizzazione deve essere fatta una richiesta al server, si potrebbe ovviare con un meccanismo di cache, ma non sarebbe semplice da implementare.<\/li>\n
\npro:<\/strong> sembra un metodo piuttosto ragionevole, possiamo memorizzare i dati di lat e lng, la mappa riceverebbe direttamente le coordinate.
\ncontro:<\/strong> dal punto di vista dell’architettura la classe Cliente non ha proprio senso che includa del codice per la geolocalizzazione. Se oltre ai clienti dovessimo aggiungere anche i Fornitori dovremmo forse duplicare il codice? oppure fare una subclass solo perch\u00e9 mantengano la geolocalizzazione come metodo in comune? Se per ciascun cliente dovessi memorizzare pi\u00f9 di un indirizzo? Diciamo che domani voglio memorizzare un numero arbitrario di indirizzi per ciascun cliente… devo aggiungere quanti campi latitudine e longitudine per poterne tenere conto?<\/li>\n
\nCreo una specifica classe per l’indirizzo, che ha al suo interno la logica di geocoding e memorizzazione delle coordinate geografiche.
\npro:<\/strong> posso avere pi\u00f9 indirizzi per ogni cliente, o anche altre classi che non siano clienti e tutto funziona, ottengo un sistema di cache
\ncontro:<\/strong> non me ne vengono in mente \ud83d\ude09<\/li>\n<\/ol>\n
\n<\/a>
\n<\/center><\/p>\nIl Viewcontroller principale<\/h4>\n
Il viewcontroller di dettaglio<\/h4>\n
\nRagionando un p\u00f2 ci rendiamo conto che lo stato interno del viewcontroller cambia in funzione del cliente che deve essere visualizzato, quindi il viewcontroller avr\u00e0 un metodo che verr\u00e0 utilizzato per settare quale cliente visualizzare.<\/p>\nMappa e foto<\/h4>\n
\r\n#import
\r\n#import \"Location.h\"\r\n@implementation Location\r\n@synthesize address = _address;\r\n@synthesize lng = _lng;\r\n@synthesize lat = _lat;\r\n@end\r\n<\/pre>\n
\nRiporto qui i file completi .h e .m<\/p>\n\r\n#import
\r\n#import \"Cliente.h\"\r\n#import \"Location.h\"\r\n<\/pre>\n
\r\n@interface MasterViewController () {\r\n NSMutableArray *_objects;\r\n}\r\n@end\r\n<\/pre>\n
\nTogliamo del tutto il metodoo insertNewObject: e anche il metodo tableView:canEditRowAtIndexPath:
\nTogliamo anche il metodo:
\ntableView:commitEditingStyle:forRowAtIndexPath:<\/p>\n
\nUtilizziamo questo codice:<\/p>\n\r\n _objects = [[NSMutableArray alloc] init];\r\n for (int i = 0; i < 20; i++) {\r\n Cliente *c = [[Cliente alloc] init];\r\n c.nome = [NSString stringWithFormat:@\"Nome_%i\", i];\r\n c.cognome = [NSString stringWithFormat:@\"Cognome_%i\", i];\r\n c.thumb = [UIImage imageNamed:@\"thumb_%i.png\"];\r\n c.fullImage = [UIImage imageNamed:@\"fullsize_%i.png\"];\r\n \r\n Location *loc = [[Location alloc] init];\r\n loc.address = @\"Milano, piazza duomo\";\r\n \r\n c.defaultLocation = loc;\r\n \r\n [_objects addObject:c];\r\n \r\n }\r\n<\/pre>\n
\nIn questo modo ci risparmiamo di digitare nomi casuali e abbiamo anche un certo controllo sugli errori.<\/p>\n