Sino a qui, nulla di nuovo (almeno spero). Il punto da cui partiremo sar\u00e0 proprio questo. Come potete notare, infatti, a questo punto dell’esecuzione del nostro codice i due oggetti UIViewController (mainVC e mainVC2) sono correttamente allocati ed inizializzati; le loro istanze sono state aggiunte ad un array che, a sua volta, \u00e8 stato assegnato come property all’oggetto UITabBarController.
\nA questo punto, il normale utilizzo di UITabBarController, prevede di preoccuparsi solo delle viste e dei relativi controllori. La loro comparsa e scomparsa dallo schermo sar\u00e0 gestita, infatti, dalla barra in basso. Dal punto di vista dell’impiego della memoria, cosa succede? Da una rapida analisi, capiremo subito che, una volta apparse le relative viste a schermo, per ognuno dei controllori, queste rimarranno sempre presenti in memoria. Poco importa se ci sposteremo tra una view e l’altra; gli oggetti UIView (e tutti i sotto oggetti ad essi legati) rimarranno in memoria.<\/p>\n
Questo comportamento, sebbene a volte potrebbe essere desiderabile, altre volte pone delle serie ipoteche sulle performance ed affidabilit\u00e0 della nostra applicazione.
\nSupponiamo che la nostra applicazione abbia 4 oggetti UIViewController, ognuno dei quali influisce sulla memoria di sistema con un peso di 4Megabytes. Supponiamo, inoltre, che il mantenere le relative viste in memoria sia assolutamente inutile ai fini del corretto funzionamento della nostra applicazione. L’utente, infatti, non ne avrebbe nessun giovamento perch\u00e8, quando \u00e8 concentrato su un UIViewController, gli altri cessano di avere importanza.<\/p>\n
L’approccio lazy loading<\/h4>\n
E’ proprio in queste circostanze che entra in gioco, un pattern di programmazione molto interessante che va sotto il nome di “lazy loading”. In cosa consiste questa tecnica di programmazione? E’ molto semplice. Si tratta di caricare i nostri oggetti (e quindi le nostre UIView e relativi sotto oggetti) solo quando serve. Da cui il nome “lazy”, “pigro”. In questo contesto, i nostri oggetti UIViewController, non caricheranno MAI oggetti non indispensabili senza una esplicita richiesta da parte dell’utente. Cerchiamo di capire meglio cosa vogliamo realizzare.<\/p>\n
Quando scriviamo:<\/p>\n
\r\n[window addSubview:myTabBarController.view];\r\n<\/pre>\nScateniamo una serie di messaggi delegati che arrivano al primo UIViewController, inserito nell’array di cui sopra. In particolare, l’aggiunta a schermo (addSubview:) di un oggetto UIView, implica il messaggio: -(void)loadView sull’oggetto target (il nostro UIViewController). Sar\u00e0 quest’ultimo a creare una vista e mostrarla a schermo:<\/p>\n
\r\n\/\/ Implement loadView to create a view hierarchy programmatically, without using a nib.\r\n- (void)loadView {\r\n\tUIView *tmpView = [[UIView alloc] initWithFrame:[[UIScreen mainScreen] bounds]];\r\n\t[tmpView setBackgroundColor:[UIColor redColor]];\r\n\r\n\tmyLabel = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 320, 80)];\r\n\t[myLabel setText:@\"hello, world\"];\r\n\t[myLabel setFont:[UIFont systemFontOfSize:24]];\r\n\t[myLabel setTextAlignment:UITextAlignmentCenter];\r\n\t[myLabel setBackgroundColor:[UIColor clearColor]];\r\n\t[tmpView addSubview:myLabel];\r\n\t[myLabel release];\r\n\t\r\n\tmyField = [[UITextField alloc] initWithFrame:CGRectMake(0, 200, 320, 80)];\r\n\t[myField setBackgroundColor:[UIColor yellowColor]];\r\n\t[tmpView addSubview:myField];\r\n\t[myField release];\r\n\tmyField.delegate = self;\r\n\t\r\n\t\r\n\tUIButton *tmpButton = [UIButton buttonWithType:UIButtonTypeCustom];\r\n\t[tmpButton setImage:[UIImage imageNamed:@\"SantaClaus.jpg\"] forState:UIControlStateNormal];\r\n\t[tmpButton setFrame:CGRectMake(0, 100, 178, 72)];\r\n\t[tmpButton addTarget:self \r\n\t\t\t\t action:@selector(buttonPressed:) \r\n\t\tforControlEvents:UIControlEventTouchUpInside];\r\n\t\r\n\t[tmpView addSubview:tmpButton];\r\n\t[buttonSet setObject:tmpButton forKey:@\"primo\"];\r\n\tself.view = tmpView;\r\n\t[tmpView release];\r\n}\r\n<\/pre>\nLe ultime due istruzioni, sono fatidiche. E’ a quel punto, infatti, che assegniamo alla property view del controllore, l’oggetto UIView creato in precedenza che, se rispetta il paradigma di retaining della memoria, sar\u00e0 l’unico responsabile per tutti gli oggetti ad esso aggiunti (addSubview:). Questo vuol dire che, se eliminiamo l’oggetto dallo schermo (removeFromSuperview), con esso andranno via anche tutti i sotto oggetti. Proviamo ad estendere questo concetto.<\/p>\n
Un watcher per la memoria<\/h4>\n
La classe UIViewController, come tutti gli oggetti che ereditano da NSObject, permette di rispondere ad un metodo molto interessante: -(void)didReceiveMemoryWarning. Questo messaggio viene lanciato dall’istanza singletone di UIApplication, ogni qualvolta si presenta una situazione di carenza di memoria all’interno del sistema. Il messaggio viene propagato a tutti gli oggetti dell’applicazione, cosich\u00e8 ognuno di essi possa prendere iniziativa indipendente rispetto ad un problema di mancanza di memoria.
\nSar\u00e0 questo metodo a preoccuparsi per noi di “scaricare” la memoria, nel caso in cui ne avessimo bisogno durante l’esecuzione del nostro codice. Seguendo quanto ci siamo detti sopra, ci baster\u00e0 implementare qualcosa di questo tipo:<\/p>\n
\r\n- (void)didReceiveMemoryWarning {\r\n\t\/\/ Releases the view if it doesn't have a superview.\r\n [super didReceiveMemoryWarning];\r\n\t\r\n\tif(!(self.tabBarController.selectedIndex == myTag)) {\r\n\t\tNSLog(@\"remove self.view\");\r\n\t\t[self.view removeFromSuperview];\r\n\t\tself.view = nil;\r\n\t}\r\n}\r\n<\/pre>\nPer ottenere un memory warning “programmaticamente”, lanciamo il nostro simulatore e scegliamo l’opzione “Simulate Memory Warning”:<\/p>\n
\n![\"per-un-pugno-di-Kilobytes-Gestione-della-memoria-iPhone-iPad-devapp\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/12\/per-un-pugno-di-Kilobytes-Gestione-della-memoria-iPhone-iPad-devapp.jpg\" "\\"per-un-pugno-di-Kilobytes-Gestione-della-memoria-iPhone-iPad-devapp\\"")
<\/a>
\n<\/center><\/p>\nSe osserviamo la nostra console, ci accorgeremo che il nostro metodo \u00e8 entrato in azione. Cerchiamo di fare chiarezza su quello che sta accadendo. Ogni oggetto attualmente presente in memoria ricever\u00e0 un messaggio di didReceiveMemoryWarning. A questo punto, verr\u00e0 confrontato il proprio identificatore (myTag) con l’attuale UIViewController selezionato nella UITabBarController. Se i due indici coincidono, significa che l’UIViewController in esame \u00e8 proprio quello attualmente mostrato a schermo, quindi non faremo nulla. Tutti gli altri UIViewController, invece, effettueranno una removeFromSuperView del proprio oggetto UIView.
\nVisto che rimuovere dalla superview, significa anche decrementare il contatore d’uso dell’oggetto, questo porter\u00e0 a zero il retainCount degli oggetti UIView non visibili a schermo e, conseguentemente, essi verranno eliminati dalla memoria, lasciando spazio a nuovi oggetti.<\/p>\n
Facciamo diventare pigri i nostri oggetti<\/h4>\n
All’inizio di quest’articolo vi avevo promesso che avremmo reso “pigri”, ovvero capaci di effettuare un lazy-load, i nostri oggetti. In quest’ultimo paragrafo, cercheremo di usare quanto sopra appreso a nostro vantaggio per l’obiettivo preposto.
\nOgni oggetto che eredita da UIViewController, riceve tre messaggi molto importanti:<\/p>\n
\r\n-(void)viewDidAppear:(BOOL)animated;\r\n\r\n-(void)viewDidDisappear:(BOOL)animated;\r\n\r\n-(void)viewWillDisappear:(BOOL)animated;\r\n<\/pre>\nCome \u00e8 evidente, la loro implementazione permette di agire nelle fasi di comparsa e scomparsa della property view del controller. Questa \u00e8 un’ottima notizia per il nostro lavoro. Saranno questi messaggi, infatti, a gestire per noi il caricamento e scaricamento dinamico della memoria. Tutto quello che ci servir\u00e0 fare, sar\u00e0 reimplementare quanto detto sopra all’interno del metodo -(void)viewDidDisappear:(BOOL)animated:<\/p>\n
\r\n-(void)viewDidDisappear:(BOOL)animated {\r\n\t[self.view removeFromSuperview];\r\n\tself.view = nil;\r\n}\r\n<\/pre>\nA questo punto, ogni qualvolta l’UIViewController, perder\u00e0 il focus perch\u00e8 l’utente ha selezionato un’altra opzione dall’oggetto UITabBarController in basso, la property view verr\u00e0 rimossa dallo schermo e, con lei, tutti gli oggetti associati avranno un retainCounter pari a zero. Quindi, potranno essere purgati dalla memoria.<\/p>\n
Alcune considerazioni<\/h4>\n
Perch\u00e8 tutto funzioni \u00e8 necessario legare agli indici dell’array i tag dei nostri viewcontrollers, in maniera da essere sempre sincronizzati su dove l’utente e’ posizionato. Questo viene effettuato durante la fase di inizializzazione dell’appDelegate.
\nIl codice sorgente allegato, illustra tutte le caratteristiche di cui sopra con un codice d’esempio funzionale. A tal proposito, provate ad inserire un testo all’interno del viewController, premendo sulla barra gialla e scrivendo qualcosa. Il risultato sar\u00e0 la comparsa della nostra frase in alto al centro. Questo vuol dire che abbiamo manipolato le istanze degli oggetti presenti in memoria. Senza simulare un memory warning, provate a spostarvi tra un UIViewController e l’altro. Interessante vero? Gli oggetti continuano a mantenere lo stato precedente perch\u00e8 sono ancora in memoria. Se, viceversa, effettuiamo una simulazione di memory warning, ci accorgeremo che una volta tornati sul controllore precedente, quest’ultimo avr\u00e0 perso memoria dello stato e sar\u00e0 stato “resettato” al suo aspetto originale. Questo avviene perch\u00e8 esso viene caricato “dinamicamente” alla richiesta dell’utente (pressione sull’icona in basso dell’UITabBar). Il controllore, infatti, seguendo quanto specificato nel metodo di didReceiveMemoryWarning, scaricher\u00e0 il suo contenuto ad ogni occorrenza di questo messaggio.
\nSe invece, implementiamo il metodo di viewDidDisappear, il risultato sar\u00e0 che ad ogni perdita di focus del controllore, il suo contenuto verr\u00e0 eliminato dalla memoria. Non avremo piu’, quindi, quella sorta di memoria di stato tra un viewcontroller e l’altro.<\/p>\n
La morale della favola \u00e8: fate molta attenzione alla memoria. Averne in abbondanza non ci autorizza a sprecarla. Un occhio di riguardo ai vecchi dispositivi (iPhone 2G\/3G), non potr\u00e0 che aiutare tutti: utenti, ambiente, le nostre tasche. <\/p>\n
Buon natale e\u2026buona programmazione!<\/p>\n
Costantino Pistagna<\/p>\n
![\"\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/05\/download_icon.png\")
<\/a> Se avete problemi con il progetto, questo \u00e8 il nostro file di esempio.<\/a><\/p>\n
\n![\"bn-Allerta-Soglie-per-tre-iphone-devapp\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/11\/bn-Allerta-Soglie-per-tre-iphone-devapp.jpg\" "\\"bn-Allerta-Soglie-per-tre-iphone-devapp\\"")
<\/a>
\n<\/center><\/p>\n","protected":false},"excerpt":{"rendered":"L’utilizzo dell’oggetto UITabBarController pu\u00f2 sollevarci da grosse problematiche relativamente ad applicazioni con oggetti UIViewControllers multipli e scambio…<\/p>\n","protected":false},"author":476,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[8],"tags":[479,527,331,524,525,526],"class_list":["post-5365","post","type-post","status-publish","format-standard","hentry","category-guide-varie","tag-costantino-pistagna","tag-gestione-memoria-ipad","tag-gestione-memoria-iphone","tag-lazy-loading","tag-uitabbarcontroller","tag-uiviewcontrollers"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/users\/476"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/comments?post=5365"}],"version-history":[{"count":11,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5365\/revisions"}],"predecessor-version":[{"id":5378,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/5365\/revisions\/5378"}],"wp:attachment":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media?parent=5365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/categories?post=5365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/tags?post=5365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}