{"id":7793,"date":"2011-10-17T11:21:58","date_gmt":"2011-10-17T09:21:58","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=7793"},"modified":"2011-10-17T11:21:58","modified_gmt":"2011-10-17T09:21:58","slug":"t102-download-asincrono-delle-immagini-con-il-proxy-design-pattern","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/t102-download-asincrono-delle-immagini-con-il-proxy-design-pattern\/","title":{"rendered":"T#102 – Download asincrono delle immagini con il proxy design pattern"},"content":{"rendered":"

\"tutorial-iOS-dev-advanced-devAPP\"<\/a> Come avrete intuito dal titolo l’argomento di oggi \u00e8 il download asincrono delle immagini. Pi\u00f9 o meno tutti ci siamo scontrati, nel realizzare le nostre applicazioni per iOS, con la necessit\u00e0 di recuperare informazioni ed immagini da internet e abbiamo scoperto ben presto che quando questa operazione di download non viene gestita correttamente, tutta l’applicazione smette di rispondere fintanto che il download non \u00e8 terminato.<\/p>\n

Il motivo di tutto questo \u00e8 semplice: in un’applicazione, se non diversamente specificato, tutto il lavoro viene svolto in un unico thread, il quale si occupa, tra l’altro, di aggiornare la GUI (Graphical User Interface) e rispondere agli events dell’utente. Se questo thread viene bloccato da una funzione molto lunga dai calcoli particolarmente complessi o un download da internet (in gergo vengono dette “chiamate bloccanti”) ecco che l’applicazione non \u00e8 pi\u00f9 in grado di svolgere altri compiti e quindi la GUI stessa resta bloccata, dando l’impressione all’utente che l’app abbia qualcosa che non va.<\/p>\n

La soluzione \u00e8 quindi quella di eseguire le chiamate bloccanti in un thread separato, cos\u00ec che il thread principale sia sempre<\/strong> in grado di aggiornare la GUI.<\/p>\n

iOS fornisce diversi strumenti per eseguire codice in un thread separato: NSThread, NSOperationQueue, di GDC… tutte tecnologie che in maniera pi\u00f9 o meno esplicita creano un thread per eseguirvi all’interno il nostro codice senza bloccare il main thread.
\n(Oltre alle tecnologie apple esistono inoltre alcuni framework di terze parti come AsiHttpRequest che risultano molto comodi per effettuare richieste asincrone Vedi: http:\/\/allseeing-i.com\/ASIHTTPRequest\/<\/a>)<\/p>\n

Questo \u00e8 un problema generale che non riguarda solo iOS e le immagini e una soluzione elegante passa per l’implementazione di un design pattern denominato “proxy”. Se caricare un oggetto risulta complesso come in questo caso in cui bisogna creare threads, gestire risposte etc, risulta pi\u00f9 comodo ed elegante istanziare un oggetto che faccia proxy che si occupi di tutto questo. Come sempre nella programmazione ad oggetti lo scopo \u00e8 quello di isolare le responsabilit\u00e0 e delegare compiti lunghi e inclini ad errori ad oggetti che siano testabili e riutilizzabili. <\/p>\n

Apple fornisce un ottimo esempio su come dovrebbe essere gestito il lazy loading a questo indirizzo
\nhttp:\/\/developer.apple.com\/library\/ios\/#samplecode\/LazyTableImages\/Introduction\/Intro.html<\/a>
\nLa classe IconDownloader di questo esempio pu\u00f2 a ragione essere considerata una classe Proxy per il download delle immagini da internet.<\/p>\n

Ovviamente nulla da dire sul codice apple, \u00e8 ottimo e fonte di ispirazione, ma mi sono chiesto se per problemi pi\u00f9 semplici non si potesse pensare ad una soluzione pi\u00f9 semplice. Ed \u00e8 per questo che ho provato a scrivere la classe che vedrete di seguito nell’articolo.<\/p>\n

La nostra classe “AutoDownloadImageView”<\/h4>\n

L’idea di base \u00e8 semplice: creare una classe da poter usare come una normale UIImageview che si occupi in autonomia<\/strong> di eseguire il download dell’immagine da internet. Quello che vorrei realizzare \u00e8 una classe proxy per una UIImageview che sia lei stessa una UIImageview.<\/p>\n

La classe \u00e8 ancora in fase di sviluppo, forse ci sono degli errori e sicuramente \u00e8 migliorabile ma quello che \u00e8 importante \u00e8 capire l’idea che ci sta dietro.<\/p>\n

La classe si chiama AutoDownloadImageView<\/em> e prima di pensare alla sua implementazione ho deciso che le istanze di questa classe comunicheranno al loro creatore l’esito del download dell’immagine, positivo o negativo che sia, in modo tale che il creatore possa comportarsi di conseguenza. Questo in genere viene fatto tramite l’istituzione di un protocollo. Se non sapete perch\u00e9 potete leggere questo nostro articolo http:\/\/www.devapp.it\/wordpress\/l014-un-contratto-tra-la-gli-oggetti-il-protocol.html<\/a><\/p>\n

Il protocollo prevede due metodi, uno viene richiamato se il download fallisce, l’altro se tutto va a buon fine. Questa \u00e8 la dichiarazione del protocollo:<\/p>\n

\r\n@class AutoDownloadImageView;\r\n\/**\r\n * Questo \u00e8 il protocollo che dovr\u00e0 implementare la classe che utilizza\r\n * oggetti di tipo AutoDownloadImageView contiene due metodi utili per eseguire\r\n * ad esempio un refresh dell'interfaccia\r\n *\/\r\n@protocol AutoDownloadImageViewDelegate\r\n\/**\r\n * Il download \u00e8 completato con successo. Il ricevente pu\u00f2 implementare questo metodo\r\n * eseguendo un refresh dello schermo.\r\n *\/\r\n- (void)autoDownloadImageViewFinishDownloading:(AutoDownloadImageView *)autoDowload;\r\n\r\n\/**\r\n * Il download \u00e8 terminato con un errore, Il ricevente pu\u00f2 eseguire l'operazione che \r\n * ritiene opportuna.\r\n *\/\r\n- (void)autoDownload:(AutoDownloadImageView *)autoDowload didFailWithError:(NSError *)error;\r\n@end\r\n<\/pre>\n
Per quanto riguarda le variabili di istanza della classe, dobbiamo aggiungere:<\/p>\n