Come sicuramente saprete, è relativamente semplice in Xcode visualizzare un’immagine prendendo il link direttamente via HTTP, ma il caricamente delle righe delle table richiede che vengano scaricate le immagini che visualizziamo PRIMA di visualizzare la riga stessa. L’obiettivo che volevo raggiungere era lo stesso che potete vedere sfogliando l’applicazione ‘App Store’ nella sezione categoria su iPhone/iPod/iPad… in cui se ci fate caso, vedrete apparire immediatamente i testi e poco dopo le 5 icone che vengono scaricate in background asincronicamente (gran parola!).

Innanzitutto creaiamo la classe “AsyncImageView” che richiameremo dal nosto metodo “cellForRowAtIndexPath”.

Di seguito il file AsyncImageView.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

#import "AsyncImageView.h"
 
@implementation AsyncImageView
 
- (void)dealloc {
	[connection cancel]; //in case the URL is still downloading
	[connection release];
	[data release]; 
    [super dealloc];
}
 
 
- (void)loadImageFromURL:(NSURL*)url {
	if (connection!=nil) { [connection release]; } //in case we are downloading a 2nd image
	if (data!=nil) { [data release]; }
 
	NSURLRequest* request = [NSURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0];
	connection = [[NSURLConnection alloc] initWithRequest:request delegate:self]; //notice how delegate set to self object
}
 
 
//the URL connection calls this repeatedly as data arrives
- (void)connection:(NSURLConnection *)theConnection didReceiveData:(NSData *)incrementalData {
	if (data==nil) { data = [[NSMutableData alloc] initWithCapacity:2048]; } 
	[data appendData:incrementalData];
}
 
//the URL connection calls this once all the data has downloaded
- (void)connectionDidFinishLoading:(NSURLConnection*)theConnection {
	//so self data now has the complete image 
	[connection release];
	connection=nil;
	if ([[self subviews] count]>0) {
		[[[self subviews] objectAtIndex:0] removeFromSuperview]; //so remove it (releases it also)
	}
 
	//make an image view for the image
	UIImageView* imageView = [[[UIImageView alloc] initWithImage:[UIImage imageWithData:data]] autorelease];
 
	imageView.contentMode = UIViewContentModeScaleAspectFit;
	imageView.autoresizingMask = ( UIViewAutoresizingFlexibleWidth || UIViewAutoresizingFlexibleHeight );
	[self addSubview:imageView];
	imageView.frame = self.bounds;
	[imageView setNeedsLayout];
	[self setNeedsLayout];
 
	[data release]; //don't need this any more, its in the UIImageView now
	data=nil;
}
 
//just in case you want to get the image directly, here it is in subviews
- (UIImage*) image {
	UIImageView* iv = [[self subviews] objectAtIndex:0];
	return [iv image];
}
 
@end

Ed il relativo file di implementazione:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

#import "AsyncImageView.h"
 
 
@implementation AsyncImageView
 
- (void)dealloc {
	[connection cancel]; //in case the URL is still downloading
	[connection release];
	[data release]; 
    [super dealloc];
}
 
 
- (void)loadImageFromURL:(NSURL*)url {
	if (connection!=nil) { [connection release]; } //in case we are downloading a 2nd image
	if (data!=nil) { [data release]; }
 
	NSURLRequest* request = [NSURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0];
	connection = [[NSURLConnection alloc] initWithRequest:request delegate:self]; //notice how delegate set to self object
}
 
 
//the URL connection calls this repeatedly as data arrives
- (void)connection:(NSURLConnection *)theConnection didReceiveData:(NSData *)incrementalData {
	if (data==nil) { data = [[NSMutableData alloc] initWithCapacity:2048]; } 
	[data appendData:incrementalData];
}
 
//the URL connection calls this once all the data has downloaded
- (void)connectionDidFinishLoading:(NSURLConnection*)theConnection {
	//so self data now has the complete image 
	[connection release];
	connection=nil;
	if ([[self subviews] count]>0) {
		//then this must be another image, the old one is still in subviews
		[[[self subviews] objectAtIndex:0] removeFromSuperview]; //so remove it (releases it also)
	}
 
	//make an image view for the image
	UIImageView* imageView = [[[UIImageView alloc] initWithImage:[UIImage imageWithData:data]] autorelease];
	//make sizing choices based on your needs, experiment with these. maybe not all the calls below are needed.
	imageView.contentMode = UIViewContentModeScaleAspectFit;
	imageView.autoresizingMask = ( UIViewAutoresizingFlexibleWidth || UIViewAutoresizingFlexibleHeight );
	[self addSubview:imageView];
	imageView.frame = self.bounds;
	[imageView setNeedsLayout];
	[self setNeedsLayout];
 
	[data release]; //don't need this any more, its in the UIImageView now
	data=nil;
}
 
- (UIImage*) image {
	UIImageView* iv = [[self subviews] objectAtIndex:0];
	return [iv image];
}
 
@end

Una volta che abbiamo la classe pronta, basterà copiarla dentro a qualsiasi progetto per poterla utilizzare, vediamo come.

Vi riporto per completezza tutto il metodo “cellForRowAtIndexPath”, che come saprete si occupa di valorizzare la riga che stiamo caricando in quel momento.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

- (UITableViewCell *)tableView:(UITableView *)tableView
		 cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"ImageCell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
 
    if (cell == nil) {
		[[NSBundle mainBundle] loadNibNamed:@"CellaRiepilogo"  owner:self options:NULL];
		cell = nibLoadedCell;
 
    } else {
		AsyncImageView* oldImage = (AsyncImageView*)
		[cell.contentView viewWithTag:999];
		[oldImage removeFromSuperview];
    }
 
	CGRect frame;
	frame.size.width=47; frame.size.height=47;
	frame.origin.x=8; frame.origin.y=8;
	AsyncImageView* asyncImage = [[[AsyncImageView alloc]
								   initWithFrame:frame] autorelease];
	UIImage *myImage = [UIImage imageNamed:@"blackaccessorybutton.png"];
	UIImageView *imageView = [[UIImageView alloc] initWithImage:myImage];
	[cell setAccessoryView:imageView];
 
 
	Sciopero *sciopero = [dati objectAtIndex:indexPath.row];
 
	UILabel		*dataLabel	= (UILabel *)[cell viewWithTag:1];
	UILabel		*settoreLabel= (UILabel *)[cell viewWithTag:2];
	UILabel		*modalitaLabel= (UILabel *)[cell viewWithTag:3];
	UILabel		*descrizioneLabel= (UILabel *)[cell viewWithTag:4];
 
 
	dataLabel.text = [NSString stringWithFormat:@"%@", [sciopero.data uppercaseString]];
	settoreLabel.text = [NSString stringWithFormat:@"%@", sciopero.settore];
	modalitaLabel.text = [NSString stringWithFormat:@"%@", [sciopero.modalita lowercaseString]];
	descrizioneLabel.text = [NSString stringWithFormat:@"%@", [sciopero.descrizione lowercaseString]];
 
 
	asyncImage.tag = 999;
	NSURL *url = [NSURL URLWithString: sciopero.icona];	
	//UIImage *img = [UIImage imageWithData:[NSData dataWithContentsOfURL:url]];
	//categoria.immagine  = img;
 
	[asyncImage loadImageFromURL:url];
 
	[cell.contentView addSubview:asyncImage];
 
    return cell;
}

Nel mio caso utilizzo una cella personalizzata con uno XIB associato di nome “CellaRiepilogo.xib”.

La parte da personalizzare a seconda dei casi è la seguente:

1
2
3
4
5

CGRect frame;
	frame.size.width=47; frame.size.height=47;
	frame.origin.x=8; frame.origin.y=8;
	AsyncImageView* asyncImage = [[[AsyncImageView alloc]
					initWithFrame:frame] autorelease];

Ossia, creiamo il frame delle dimensioni che ci interessano (nel mio caso 47×47) e decidiamo dove farlo apparire (in questo caso coordinate x=8 e y=8).

Successivamente:

1
2
3
4

asyncImage.tag = 999;
	NSURL *url = [NSURL URLWithString: sciopero.icona];	
	[asyncImage loadImageFromURL:url];
	[cell.contentView addSubview:asyncImage];

E il gioco é fatto!

Ricordatevi di mettere l’import:

1

#import "AsyncImageView.h"

Non ho scritto io quella classe, e purtroppo non ricordo dove l’ho pescata, peró ne ho trovate diverse , e questa l’ho personalizzata in diverse parti.

Questo stesso codice l’ho usato giá in parecchie applicazioni:

iQuimall, mi serviva per caricare le cover/skin degli iphone via web
iScioperi Trasporti – dovevo caricare tutti i dati comprensive di immagini da un mio XML su web
(questo spezzone di codice viene proprio da lí!)
Tutte le altre mie app, che hanno nel tab bar l’opzione “Altre App” appare la lista completa delle
applicazioni da me realizzate, e cliccando sulla riga si va direttamente sull’AppStore per l’acquisto!

Spero vi sia utile!

Possiamo impostare le local notification per visualizzare un messaggio, riprodurre un suono o impostare un badge all’icona dell’applicazione.

Nella mia applicazione, ad esempio, ho la necessità di “avvisare” l’utente di determinate scadenze (note a priori) e le Local Notification costituiscono lo strumento adatto per facilità d’uso sia del programmatore sia dell’utilizzatore.

Il nostro progetto

Per fare un semplice test, creeremo un’applicazione che all’avvio verifica se è stata “aperta” da una local notification ed in uscita crea una local notification.

Creiamo una “Window-based application” che chiameremo TestNotificheLocali.

Nel file “TestNotificheLocaliAppDelegate.h” aggiungiamo questi 2 metodi che utilizzeremo successivamente:

1
2
3
4

//Metodo per impostare le notifiche locali
- (void)impostaLocalNotification:(NSDate *)dataNotifica ConNome:(NSString *)nome;
//metodo per visualizzare un’ alertView
- (void) visualizzaMessaggio:(NSString*)message titolo:(NSString*)titoloFinestra;

Nel file “TestNotificheLocaliAppDelegate.m” aggiungiamo una costante che utilizzeremo per recuperare informazioni dalla local notification.

1
2
3
4
5
6

@implementation TestNotificheLocaliAppDelegate
 
@synthesize window;
@synthesize viewController;
 
#define chiaveNome @"chiaveNomeDictionary"

Impostiamo all’avvio dell’applicazione un controllo per intercettare un’eventuale apertura dell’applicazione da parte di una notifica locale.

1
2
3
4
5
6
7
8
9
10
11
12

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
 
	//Richiediamo una istanza di UILocalNotification dal dictionary delle opzioni di avvio (se ci sono). Il contenuto sarà vuoto se richiamiamo direttamente l'applicazione
	UILocalNotification *notifica = [launchOptions objectForKey: UIApplicationLaunchOptionsLocalNotificationKey]; 
 
	//Verifichiamo se l'istanza è vuota (ad esempio abbiamo richiamato direttamente l'applicazione)
	if (notifica) {
		//Questo significa che l'applicazione si è avviata da un messaggio di notifica locale!
 
		//Visualizzo il messaggio recuperando l'informazione tramite la costante utilizzata per il dictionary
		[self visualizzaMessaggio:@"Programma avviato da una local notification" titolo:[notifica.userInfo objectForKey:chiaveNome]];
	}

Sempre nello stesso metodo, aggiungiamo la cancellazione di tutte le notifiche locali e il richiamo del metodo per la creazione di una notifica.

1
2
3
4
5
6

	//Cancelliamo tutte le notifiche locali della nostra applicazione
	[[UIApplication sharedApplication] cancelAllLocalNotifications];
 
	//Richiamiamo il metodo per la creazione della notifica
	//come parametro gli passo la data attuale
	[self impostaLocalNotification:[NSDate date] ConNome:@"NotificaTest"];

Il metodo accetta in ingresso la data di notifica ed il nome che visualizzeremo nell’alertView.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

	UILocalNotification *notifica=nil;
 
	//Verifico che il firmware sia il 4.0
	float version = [[[UIDevice currentDevice] systemVersion] floatValue];
	if (version >= 4.0){
 
		//Istanzio la variabile che mi servirà per impostare la local notification
		UILocalNotification *notifica = [[UILocalNotification alloc] init];
 
 
		//Imposto il fireDate che è la data ed ora di visualizzazione del messaggio
		//imposto come visualizzazione 1 minuti dopo la data specificata
		notifica.fireDate = [dataNotifica dateByAddingTimeInterval:(1*60)];
 
		/*Imposto il timezone per esser certo che la data e l'ora impostate siano sempre corrette,
		 assegnando infatti l'oggetto timeZone, il fireDate viene regolato automaticamente
		 quando ci sono cambiamenti di fuso orario, di default il timeZone è "nil".
		 */
		notifica.timeZone = [NSTimeZone defaultTimeZone];
 
		//Messaggio che verrà visualizzato dall'iOS se la nostra applicazione è spenta
		notifica.alertBody = [NSString stringWithFormat:@"%@ - notifica locale",nome];
		//Nome del pulsante per avviare la nostra applicazione
		notifica.alertAction = @"Dettagli";
 
		//Qui possiamo impostare un suono, per semplicità impostiamo il suono di default
		notifica.soundName = UILocalNotificationDefaultSoundName;
 
		//Aggiorniamo il badge dell'applicazione
		notifica.applicationIconBadgeNumber = 1;
 
		//aggiungiamo un dictionary con informazioni a piacere, in questo caso ho inserito il nome dell'evento
		// per utilizzarlo successivamente richiamandolo in base alla costante
		NSDictionary *infoDict = [NSDictionary dictionaryWithObjectsAndKeys:nome,chiaveNome, nil];
		notifica.userInfo = infoDict;
 
		//Impostiamo la nostra local notification 
		[[UIApplication sharedApplication] scheduleLocalNotification:notifica];
 
		//Distruggiamo l'oggetto solo se istanziato
		if (notifica){
			[notifica release];
		}
 
	}
}

Intercettare una notifica locale quando l’applicazione è in esecuzione è semplicissimo.

1
2
3
4

//Metodo per intercettare le notifiche durante l'esecuzione dell'app
- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notif {
	[self visualizzaMessaggio:[notif.userInfo objectForKey:chiaveNome] titolo:@"Notifica intercettata"];
}

Questo è il metodo per visualizzare i messaggi.

1
2
3
4
5
6
7

- (void) visualizzaMessaggio:(NSString*)message titolo:(NSString*)titoloFinestra {
	UIAlertView* alertView = [[UIAlertView alloc] initWithTitle:titoloFinestra message:message delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil];
	[alertView show];
	if (alertView) { 
		[alertView release]; 
	}
}

Ci sono altre proprietà che si possono impostare, ad esempio è possibile gestire la “ripetizione” del messaggio, oppure cambiare l’immagine di avvio dell’applicazione quando questa viene richiamata da una local notification.

Tutto è come sempre dettagliato nella documentazione ufficiale:

http://developer.apple.com/iphone/library/documentation/iPhone/Reference/UILocalNotification_Class/Reference/Reference.html

Qui c’è un ottimo esempio scritto dalla Apple:

http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html

Considerazioni finali

Come potete vedere grazie all’SDK è tutto molto semplice, la classe UILocalNotification è comunque migliorabile.

Ad esempio si potrebbe migliorare la gestione della “cancellazione” di una local notification; attualmente infatti è possibile cancellarla solo “passando” la local notification che vogliamo eliminare, richiamando il seguente metodo:

1

- (void)cancelLocalNotification:(UILocalNotification *)notification

Richiamando questo metodo invece cancelleremo tutte le local notification impostate dalla nostra applicazione:

1

- (void)cancelAllLocalNotifications

Nella mia applicazione ho la necessità di visualizzare le notifiche in base ai dati inseriti dall’utente.
Il metodo di cancellazione di una notifica locale non mi aiuta molto nelle eventuali modifiche/cancellazioni dei dati dell’utente, dal momento che, per tenerne traccia, dovrei salvarmi l’istanza creata e “legarla” al record sul database.

Inoltre sarebbe molto dispendioso in termini di sviluppo tracciare tutte le modifiche dell’utente con la possibilità di bug.
Ho scelto una strada semplice che racchiude tutta la gestione in un unico punto.
All’uscita dell’applicazione cancello le local notifications e le riscrivo in base ai dati salvati dall’utente; in tal modo sono sicuro di ricreare sempre le local notifications corrette.

Fatemi sapere cosa ne pensate di questa nuova funzionalità!

Se avete problemi con il tutorial, questo è il nostro file di progetto.

Il vecchio forum

La scelta iniziale, di basare il nostro forum sul plugin “Simple:Press Forum” per wordpress è stata fatta più che altro per questioni estetiche. Un forum strutturato come plugin, di fatto, si integra perfettamente nel sito stesso, basato appunto su wordpress. La nostra poca esperienza nella scelta delle piattaforme, però, non ci ha fatto considerare più di tanto l’importanza reale che riveste questo importante e fondamentale strumento. Altro motivo di tale scelta è stata per via di un’unica registrazione per i nostri utenti, valida sia per il blog che per il forum. A conti fatti, però, l’iscrizione al blog (autori esclusi) è del tutto superflua, anzi, ad oggi serve esclusivamente per postare proprio sul forum.

Un po’ in ritardo, (ma meglio tardi che mai ), abbiamo deciso di cambiare e di passare a una piattaforma più professionale. Ci abbiamo ragionato su parecchio per scegliere la versione più adatta, abbiamo testato sia phpbb che altre piattaforme free e alla fine abbiamo deciso di appoggiarci ad una versione commerciale: vBulletin (ad oggi alla versione 4.0.5).

Il nostro nuovo forum

vBulletin è sicuramente un’ottima piattaforma per il forum e spero che sarà di vostro gradimento. (In effetti il pannello amministrativo è pressochè infinito ). Avremmo potuto cambiare anche la parte relativa al blog e passare completamente a vBulletin (l’ultima versione integra cms e blog), ma dopo un’accurata analisi la mia personale conclusione è che non sia ancora pronto, non come serve a noi almeno, wordpress è più che perfetto. Inoltre abbiamo da poco rinnovato la grafica e un altro cambio estetico potrebbe creare più confusione che altro.

In conclusione l’attuale configurazione, e credo la definitiva (temi grafici a parte) è questa:

• Sito (blog): basato su wordpress
• Forum: basato su vBulletin

Cosa comporta questo cambiamento?

Una cosa un po’ scomoda forse, ma non impossibile: occorrerà una nuova registrazione al forum per poter sfruttare questa nuova versione. Non è necessario utilizzare nick o mail diverse, anzi, è consigliabile fare la nuova iscrizione mantenendo gli stessi dati, in modo tale da poterci riconoscere ancora.

ATTENZIONE: Se volete accedere al forum dovrete registrarvi tramite il seguente indirizzo

I lavori sono ancora in corso, quindi potreste riscontrare alcune anomalie nei prossimi giorni, ma abbiate fiducia, pian piano vedrete tornare tutto alla normalità

Per quanto riguarda la migrazione del vecchio forum, infine, ci sono ancora alcuni problemi che vedremo di risolvere al più presto. Questo perchè probabilmente siamo riusciti a scegliere (inizialmente) il forum peggiore per quanto riguarda la migrazione ad altre piattaforme.

Vorrei precisare che Simple:Press rimane comunque un ottimo plugin per wordpress che tutto sommato non ci ha dato grossi problemi di gestione. Forse, però, è più adatto a chi ha esigenze minori rispetto alle nostre, dove, anche solo un buon editor per postare codice o screenshot, può rivelarsi di vitale importanza.

Iscrizione Newsletter devAPP

Ultima cosa, se volete iscrivervi alla nostra newsletter (chi è iscritto sa che non siamo poi così invadenti), potrete farlo semplicemente inserendo la vostra mail nel box “Newsletter” sulla sidebar (la barra laterale) sinistra. Dopodichè dovrete solo più cliccare sul pulsante “Subscribe”, come mostrato in fugura:

Ovviamente potrete cancellare la vostra iscrizione in ogni momento con qualche semplice click!!

Per ora è tutto, speriamo che la novità, nonostante qualche piccolo imprevisto, sia di vostro gradimento.

Mi raccomando, continuate a consigliare, criticare, scrivere (la nostra mail se ancora non la conoscete è info@devapp.it)

A presto

PS: la sorpresa in arrivo segnalata su twitter e facebook non è questa, dovrete pazientare ancora un pochino per conoscerla.. ^^

Come ben saprete molti programmi hanno la necessità di salvare file, che siano questi foto, video, piuttosto che documenti di testo o ancora impostazioni varie dell’applicazione. Insomma, l’uso dei file in un programma è praticamente d’obbligo per la quasi totalità delle applicazioni esistenti. Ma dove dobbiamo salvare i nostri file? Come sono organizzate le cartelle all’interno dei nostri programmi iPhone? Di cosa dovremo tenere conto durante la scelta della corretta posizione?

La tabella seguente e le informazioni a seguire, prelevate direttamente dalla documentazione ufficiale Apple, ci chiariranno senz’altro le idee:

Come vedete ogni cartella è stata creata per uno scopo specifico. Programmare le nostre applicazioni iPhone, tenendo conto di questi fattori, eviterà eventuali imprevisti o problemi legati al programma stesso.

Case Sensitivity

Il file system dei dispositivi basati su iOS è CASE SENSITIVE. Quando lavorerete con i nomi dei file (e tutto il percorso in genere), dovrete essere certi di utilizzare correttamente maiuscole e minuscole, esattamente come li avevate salvati, o non sarete in grado di aprire o accedere ai file.

Condividere File con computer desktop

Se volete offrire agli utenti la possibilità di accerere ai file del vostro programma tramite computer desktop, potrete farlo tramite il file sharing. Tramite il file sharing abiliterete la condivisione dei file esclusivamente dall’applicazione al computer desktop dell’utente. Non permette quindi la condivisione con altre applicazioni sullo stesso device. Per condividere dati e file tra applicazioni diverse dovrete ovviare usando la “pasteboard“, o sfruttare un controller apposito.

Backup e Restore

iTunes si preoccupa automaticamente di effettuare backup e ripristino dei dati degli utenti in particolari condizioni. Dovrete però sapere dove mettere i vile per essere certi che questi vengano correttamente “backuppati” e all’occorrenza ripristinati, in base alle vostre necessità.

Cosa viene backuppato?

Innanzitutto non dovrete preparare le vostre applicazioni in alcun modo per quanto riguarda le operazioni di backup e ripristino. Da iOS 2.2 in poi, infatti, quando un dispositivo viene connesso a un computer e sincronizzato, iTunes avvia un backup incrementale di tutti i file, eccetto quelli presenti nelle seguenti directory:

• Application_Home/AppName.app
• Application_Home/Library/Caches
• Application_Home/tmp

Anche se iTunes fa il backup del bundle dell’applicazione stessa, non lo fa durante ogni operazione di sincronizzazione. Le applicazioni acquistate dall’App Store direttamente dal device, ad esempio, sono backuppate alla successiva sincronizzazione con iTunes. Le applicazioni, però, non verranno backuppate più durante le successive operazioni di sincronizzazione, a meno che l’applicazione stessa sia cambiata (ad esempio a causa di un aggiornamento).

Per far in modo che il processo di sincronizzazione non duri per un periodo troppo lungo, dovrete essere selettivi sulla posizione scelta durante il salvataggio dei file nelle directory della vostra applicazione. La directory Application_Home/Documents dovrebbe essere usata per salvare i documenti degli utenti e i file dati dell’applicazione. I file temporanei delle vostre applicazioni dovrebbero quini essere posti all’interno della cartella Application_Home/tmp ed essere cancellati dall’applicazione stessa quando non servono più. Se la vostra applicazione avesse la necessità di creare file che devono essere presenti durante gli avvii successivi, ma non necessitano di backup, dovrete porli all’interno della cartella Application_Home/Library/Caches.

NOTA:
Se la vostra applicazione crea file di grandi dimensioni, o file che vengono modificati frequentemente, dovreste considerare di inserirli nella cartella Application_Home/Library/Caches (che non viene “backuppata”) e non all’interno di Application_Home/Documents. Il Backup (o il restore) di grandi file possono infatti rallentare l’intero processo in modo sisgnificativo. Stesse regole per quanto riguarda i file che vengono modificati frequentemente (e di conseguenza che devono essere “backuppati” frequentemente). Posizionare questi file nella cartella “Caches” fa si che non vengano “backuppati” (da iOS 2.2 in poi) durante ogni operazione di sincronizzazione.

File salvati durante gli aggiornamenti dell’applicazione

Quando un utente scarica un aggiornamento per un’applicazione, iTunes installa l’aggiornamento in una nuova directory. Successivamente sposta i file utente dalla vecchia installazione alla nuova ed infine cancella la vecchia installazione. I file nelle seguenti directory saranno presenti anche nella nuova versione dopo il processo di aggiornamento:

• Application_Home/Documents
• Application_Home/Library/Preferences

Sebbene anche i file di altre directory potrebbero essere spostati, non dovrete fare affidamento su questo per i vostri aggiornamenti.

Per prima cosa creiamo una “Window-based application” e diamole un nome (io l’ho chiamata “PDFFromSafari”).

A questo punto modifichiamo il file info.plist per registrare le estensioni che la nostra applicazione sarà in grado di manipolare. Per farlo impostiamo la visualizzazione del file come “Source Code File” in modo da vedere la sua struttura come file xml.

Il file aperto si presenta più o meno così:

Andiamo ad aggiungere le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

	<key>UIApplicationExitsOnSuspend</key>
	<true/>
 
	<key>CFBundleDocumentTypes</key>
	<array>
		<dict>
			<key>CFBundleTypeIconFiles</key>
			<array>
				<string></string>
			</array>
			<key>CFBundleTypeName</key>
			<string>NSPasteboardTypePDF</string>
			<key>CFBundleTypeRole</key>
			<string>Viewer</string>
			<key>LSHandlerRank</key>
			<string>Alternate</string>
			<key>LSItemContentTypes</key>
			<array>
				<string>com.adobe.pdf</string>
			</array>
		</dict>
	</array>

Analizziamo quello che abbiamo scritto:

1
2

<key>UIApplicationExitsOnSuspend</key>
<true/>

Questa opzione impone all’applicazione di chiudersi quando si preme il pulsante dell’iPhone anziché entrare in Background. Ovviamente questo si applica solo se il dispositivo su cui lavoriamo è al iOS 4, altrimenti questo è il comportamento standard.

Le righe successive invece riguardano proprio la registrazione delle estensioni gestite dall’applicazione.

In particolare:

1

<key>CFBundleTypeIconFiles</key>

Contiene un array di stringhe contenenti il percorso all’icona che viene associata al file nel menù contestuale dei programmi che lo possono aprire.

1

<key>CFBundleTypeName</key>

Ha una stringa con il nome del tipo di documento che apre (nel nostro esempio “NSPasteboardTypePDF”).

1

<key>LSHandlerRank</key>

Raprresenta il ruolo che ha l’applicazione. Nel nostro caso con Alternate specifichiamo che si tratta di un modo alternativo per aprire il file

Infine:

1

<key>LSItemContentTypes</key>

contiene un Array di Uniform Type Identifiers (UTIs) che l’applicazione è in grado d’aprire. Nel nostro esempio i PDF: com.adobe.pdf

Ora che abbiamo modificato il file info.plist salviamolo e andiamo a scrivere il codice dell’ applicazione. In particolar modo quello che facciamo è cambiare il metodo

1

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

Dell’Application Delegate.

Ecco le modifiche da fare:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
 
	NSURL *urlFileEsterno = (NSURL *)[launchOptions valueForKey:UIApplicationLaunchOptionsURLKey];
 
	if(urlFileEsterno != NULL){
		//carico il pdf in un oggetto NSData
		NSData *pdf = [[NSData alloc] initWithContentsOfURL:urlFileEsterno];
 
		UIWebView *webview = [[UIWebView alloc] initWithFrame:[[UIScreen mainScreen]bounds]]; 
		[webview loadData:pdf MIMEType:@"application/pdf" textEncodingName:nil baseURL:nil];
		[pdf release];
 
		webview.scalesPageToFit = YES;
		[window addSubview:webview]; 
		[webview release]; 	
 
		//elimino il file copiato sul dispositivo
		NSFileManager *filemanager = [NSFileManager defaultManager];
		[filemanager removeItemAtURL:urlFileEsterno error:NULL];
		[filemanager release];
 
	}else {
		//mostro un alert
		UIAlertView *popUp = [[UIAlertView alloc] initWithTitle:@"Aprimi da Safari"
														message:@"Prova ad aprirmi da Safari o dal programma Mail" 
													   delegate:self 
											  cancelButtonTitle:@"OK" 
											  otherButtonTitles:nil];
		[popUp show];
		[popUp release];
	}
 
 
    [window makeKeyAndVisible];
 
	return YES;
}

Vediamo di capire cosa fa:

1

NSURL *urlFileEsterno = (NSURL *)[launchOptions valueForKey:UIApplicationLaunchOptionsURLKey];

Questo è l’URL del file esterno. Ogni volta che un file viene aperto questi viene memorizzato all’interno della sottocartella inbox dei Documents dell’applicazione.

1

if(urlFileEsterno != NULL){

Controllo l’esistenza del file. Se il file esiste allora lo salvo all’interno di un oggetto NSData grazie al metodo:

1

NSData *pdf = [[NSData alloc] initWithContentsOfURL:urlFileEsterno];

Questo permette di aprire il file in una UIWebView con il metodo

1

[webview loadData:pdf MIMEType:@"application/pdf" textEncodingName:nil baseURL:nil];

Per finire istanziamo un oggetto NSFileManager che si occupa di eliminare il file creato (Ovviamente nulla ci vieta di tenerlo):

1
2
3

	NSFileManager *filemanager = [NSFileManager defaultManager];
	[filemanager removeItemAtURL:urlFileEsterno error:NULL];
	[filemanager release];

(NB. Il metodo removeItemAtURL è stato introdotto dalla SDK 4, per cui se state usando versioni precedenti dovrete usare qualche accorgimento e cambiare il metodo con removeItemAtPath).

Quello che fa il blocco dell’else è semplicemente visualizzare un alert quando si apre l’applicazione in maniera “normale”, senza passare da Safari (o chi per esso).

Salviamo ed eseguiamo… dal momento che il simulatore non ha Mail, ho testato il funzionamento dell’app aprendo Gmail da Safari ed andando ad aprire una mail con allegato un pdf.

Vediamo il risultato:

se avvio l’applicazione:

Quando apro il pdf in Safari compare il menu Apri in:

Lo stesso pdf aperto nella nostra applicazione:

Considerazioni Finali

Ciò che rende molto potente il meccanismo delle UTI è che permette di definire anche tipi di file proprietari. Se siete interessati ad un esempio che include la definizione di UTI personali vi rimando a questa discussione su StackOverflow (in Inglese) al seguente indirizzo.

Per avere invece maggiori informazioni, invece, sulla definizione dei CFBundleDocumentTypes questi sono alcuni link alla documentazione Apple:

http://developer.apple.com/iphone/library/documentation/General/Conceptual/iPadProgrammingGuide/CoreApplication/CoreApplication.html#//apple_ref/doc/uid/TP40009370-CH6-SW11

http://developer.apple.com/iphone/library/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-101685-TPXREF107

http://developer.apple.com/iphone/library/documentation/uikit/reference/UIDocumentInteractionController_class/Reference/Reference.html

Se avete problemi con il tutorial, questo è il nostro file di progetto.

Il secondo articolo, a cura del nostro autore Gino Sarnieri, propone invece un tutorial sulla realizzazione della nostra prima applicazione per il nuovo OS di Samsung: Bada, ricordiamo, il nuovo antagonista di iPhone OS che promette davvero molto bene.

Ecco cosa troverete di nostro in questo nuovo numero:

ARTICOLO 1
TITOLO: Apple programming, sviluppare per Mac
ARGOMENTO:“Dai un morso alla Mela! Scopri come entrare nel mondo dello sviluppo MAC”
AUTORI: Rino Picardi e Andrea Busi
PAGINE ARTICOLO: 6 (da pag. 14 a pag. 19)
COSTO RIVISTA + CD: € 6,99
COSTO RIVISTA + CARTE + CD: € 9,99
COVER STORY a cura di devAPP

ARTICOLO 2
TITOLO: Samsung BADA: La prima applicazione
ARGOMENTO: Tutorial sulla realizzazione della prima applicazione BADA
AUTORE: Gino Sarnieri
PAGINE ARTICOLO: 5 (da pag. 57 a pag. 61)
COSTO RIVISTA + CD: € 6,99
COSTO RIVISTA + CARTE + CD: € 9,99

E ora.. tutti in edicola

Attenzione: Ricordiamo che gli articoli che pubblichiamo sulla rivista sono in esclusiva per loro, quindi non li vedrete sulle nostre pagine.

Ok, è sicuramente lavoro in più per noi programmatori, ma se non vogliamo perdere clienti e/o ottenere feedback negativi, dovremmo farcene una ragione e studiare bene tutto con calma.

Oggi vedremo come sfruttare UIDevice per ottenere modello del device, nome, sistema operativo installato e versione. Partiamo subito con questo semplice tutorial.

Apriamo Xcode e creiamo un nuovo progetto. Dall’elenco dei template disponibili selezioniamo “View-based Application” e proseguiamo. Diamo un nome al nostro progetto, ad esempio “myDevice”, scegliamo una posizione in cui salvare (sulla scrivania andrà benissimo) e proseguiamo. Apriamo il file “myDeviceViewController.h” e dichiariamo 4 UILabel che useremo per mostrare i dati rilevati:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#import <UIKit/UIKit.h>
 
@interface myDeviceViewController : UIViewController {
	IBOutlet UILabel *lblModel;
	IBOutlet UILabel *lblName;
	IBOutlet UILabel *lblSystemName;
	IBOutlet UILabel *lblSystemVersion;
}
 
@property (nonatomic, retain) IBOutlet UILabel *lblModel;
@property (nonatomic, retain) IBOutlet UILabel *lblName;
@property (nonatomic, retain) IBOutlet UILabel *lblSystemName;
@property (nonatomic, retain) IBOutlet UILabel *lblSystemVersion;
 
@end

Niente di complicato insomma, 4 semplici UILabel che grazie a IBOutlet troveremo pronte in Interface Builder per essere collegate ai rispettivi oggetti disegnati graficamente.

Salviamo e facciamo doppio-click sul file “myDeviceViewController.xib”, si aprirà quindi Interface Builder che useremo per disegnare la nostra semplicissima interfaccia grafica. Ci occorreranno semplicemente 8 UILabel. Cercate quindi UILabel in Library -> Objects e trascinatene 8 nella View. Quattro le useremo come etichette per indicare cosa verrà visualizzato in quella adiacente. Dovreste ottenere un risultato simile a quello mostrato in figura:

Non ci resta che collegare questi oggetti ai rispettivi dichiarati poco fa nel file di interfaccia .h. Per farlo clicchiamo su “File’s Owner” e spostiamoci sul “Connections Inspector”, colleghiamo quindi i 4 “lbl” con le UILabel appena trascinate. Finiti i collegamenti salviamo e chiudiamo Interface Builder.

A questo punto ci tocca implementare il codice vero e proprio che ci permetterà di mostrare a video (nelle UILabel) i dati del dispositivo che sta eseguendo la nostra applicazione iPhone. Aprite il file “myDeviceViewController.m”, aggiungete i rispettivi @synthesize subito dopo l’istruzione “@implementation myDeviceViewController”

1

@synthesize lblModel, lblName, lblSystemName, lblSystemVersion;

Scommentate quindi il metodo “viewDidLoad” e modificatelo come segue:

1
2
3
4
5
6
7
8

- (void)viewDidLoad {
        [super viewDidLoad];
 
	lblModel.text = [[UIDevice currentDevice] model];
	lblName.text = [[UIDevice currentDevice] name];
	lblSystemName.text = [[UIDevice currentDevice] systemName];
	lblSystemVersion.text = [[UIDevice currentDevice] systemVersion];
}

Come vedete è tutto molto semplice e non facciamo altro che andare a settare la proprietà “text” delle UILabel con il rispettivo valore prelevato tramite [[UIDevice currentDevice] nomeValoreCheCiInteressa];

Questo semplice tutorial si conclude qui, a questo punto sapete come intercettare informazioni sul device in uso, non vi resta che perfezionare le vostre applicazioni e renderle compatibili per tutte le combinazioni di device/sistema esistenti.

Iniziamo naturalmente con un nuovo progetto di tipo view-based e chiamiamolo “KeyTab”. Bene, apriamo il KeyTabViewController.xib e inseriamo un campo di testo.

Passiamo quindi al file di interfaccia KeyTabViewController.h e inseriamo un IBOutlet UITextField :

1
2
3
4

@interface keyTab2ViewController : UIViewController <UITextFieldDelegate> {
    IBOutlet UITextField * txt;
}
@end

Aggiungiamo anche il delegato del textField. Torniamo al nostro file .xib e colleghiamo il File’s Owner con il campo di testo, e il delegato con il campo di testo. (clicchiamo sul file’s owner tenendo premuto control e colleghiamo le parti).

Passiamo ora all’implementazione dei metodi. Nel viewDidLoad inseriamo la notifica di quando compare la tastiera:

1
2
3
4
5
6
7
8

- (void)viewDidLoad
{
    [super viewDidLoad];
 
	[[NSNotificationCenter defaultCenter] addObserver:self
		selector:@selector(keyboardWasShown:)
		name:UIKeyboardDidShowNotification object:nil];
}

Notate che questa volta non abbiamo fatto alcuna differenza per iOS 4 o precedenti, in quanto il procedimento è lo stesso del precedente tutorial.

Bene, ora aggiungiamo il metodo per far tornare la tastiera:

1
2
3
4
5
6

-(BOOL)textFieldShouldReturn:(UITextField *)textField
{
	[textField resignFirstResponder];
 
	return YES;
}

Passiamo ora al vero e proprio pezzo fondamentale, l’inserimento della barra:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

- (void)keyboardWasShown:(NSNotification*)aNotification
{
	NSDictionary *info = [aNotification userInfo];
    NSValue *keyBounds = [info objectForKey:UIKeyboardBoundsUserInfoKey];
 
    CGRect bndKey;
    [keyBounds getValue:&bndKey];
 
	UIToolbar *toolbar = [[UIToolbar alloc] initWithFrame:CGRectMake(0, -40, bndKey.size.width, 40)];
	//[toolbar setTranslucent:YES];
	UIColor * black = [[UIColor alloc] initWithRed:0 green:0 blue:0 alpha:1.0];
	[toolbar setTintColor:black];
	UIBarButtonItem *barButtonItem = [[UIBarButtonItem alloc] initWithTitle:@"Bottone 1" style:UIBarButtonItemStyleBordered target:self action:@selector(buttonClicked:)];
	NSArray *items = [[NSArray alloc] initWithObjects:barButtonItem, nil];
	[toolbar setItems:items];
	[items release];
 
	UIWindow* tempWindow = [[[UIApplication sharedApplication] windows] objectAtIndex:1];
	UIView* keyboard;
	for(int i = 0; i < [tempWindow.subviews count]; i++)
	{
		//Get a reference of the current view
		keyboard = [tempWindow.subviews objectAtIndex:i];
 
		//Check to see if the description of the view we have referenced is "UIKeyboard" if so then we found
		//the keyboard view that we were looking for
		if([[keyboard description] hasPrefix:@"<UIPeripheralHost"] == YES)
		{
			[keyboard addSubview:toolbar];
		}
	}
 
}

Alla riga 7 creiamo la nostra UIToolBar, le dimensioni sono state calcolate perfettamente, gli diamo un colore (in questo caso nero). Creiamo poi un bottone, ne possiamo inserire quanti ne vogliamo, e gli diamo come azione il metodo buttonClicked. Nelle prossime due righe non facciamo altro che creare un array, inserirci dentro il bottone e aggiungere il contenuto dell’array nella barra. In questo caso i bottoni (se ne create più di uno) vi verranno messi tutti in fila, partendo da sinistra. altrimenti potete creare dei bottoni tramite delle viste personalizzate e allora li potete posizionare ovunque.

La parte che segue poi è sempre la stessa, andiamo alla ricerca della vista della tastiera, una volta trovata gli aggiungiamo la barra.

L’ultima cosa che ci resta da fare è quella di creare il metodo che viene chiamato quando clicchiamo sul bottone:

1
2
3
4
5
6

- (void)buttonClicked:(NSNotification *)note
{
	UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"CLICK!!!" message:@"Hai cliccato il bottone sulla tastiera!!" delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil];
	[alert show];
	[alert release];
}

Ecco qui, quando si clicca su bottone compare un alertView. Spero che i miei brevi tutorial vi siano utili, se volete potete scaricare il progetto da qui:

Eccovi uno screenshot del tutorial in esecuzione:

Perchè è così importante la gestione della memoria?

Gestire la memoria significa prima di tutto evitare di sprecare inutilmente risorse (in questo caso di memoria), che, soprattutto nel caso dei dispositivi mobili, ritroviamo in quantità limitata e non espandibile. Ovviamente gestire la memoria non è solo importante per questo tipo di device, ma anche per le applicazioni desktop, le cui funzionalità potrebbero portare ad occupare enormi quantità di memoria (pensate ad esempio ad applicazioni di tipo scientifico). Quanto mostreremo in questo articolo sarà utile quindi non solo per lo sviluppo di applicazioni iPhone e iPad, ma anche per quello di applicazioni MacOS.

Come saprete (o comunque intuirete) ogni variabile, puntatore, oggetto o altro elemento del nostro programma occupa memoria e anche se potrebbero sembrarvi quantità minime, sappiate che l’apparenza, spesso, inganna. Perchè dico questo? Objective-C (il linguaggio principale con cui lavoriamo) è un linguaggio orientato agli oggetti, e questa potente tecnica di programmazione, come sapete, ci offre funzionalità potentissime, ma allo stesso tempo molto pericolose se non capiamo a fondo il loro principio di funzionamento. Una di queste potenti (e pericolose) caratteristiche è l’ereditarietà, ovvero la caratteristica che ci permette di creare nuovi oggetti personalizzati, partendo da altri esistenti mantenendo tutte le carattaristiche (proprietà e metodi) dell’oggetto di partenza.

Ora, come ben saprete la maggior parte del nostro lavoro su iPhone e iPad si basa sul framework Cocoa Touche in particolare dall’UIKit, offerto da Apple, (maggiori informazioni qui) e come potete vedere dal seguente schema esiste una gerarchia specifica per gli oggetti di questo utile kit, in particolare notate come tutti gli oggetti siano derivati di un unico “super” oggetto: NSObject.

Ora immaginiamo un semplice caso, dobbiamo creare una nuova classe con metodi ed eventi personalizzati, che eredita direttamente da NSObject. Analizzando il file di interfaccia della nostra nuova classe, potremmo trovarci di fronte a qualcosa di simile:

1
2
3
4
5

@interface MyClass: NSObject {
    IBOutlet UITextField *myTextField;
}
// Eventuali metodi
@end

Istanziato un oggetto di questa classe, come minimo dovremo aver sufficiente spazio in memoria da allocare per contenere un oggetto UITextField, ma non solo. Dato che questa classe eredita da NSObject, dobbiamo aver spazio sufficiente per contenere anche tutti gli elementi di questo oggetto!

Immaginate ora di creare un nuovo oggetto partendo invece da UITextField, in questo caso dovrete prevedere di aver spazio in memoria per i nuovi elementi e, secondo lo schema sopra, anche per gli elementi di UITextField (da cui ereditate direttamente), ma anche quelli di UIControl (da cui eredita UITextField), UIView (da cui eredita UIControl), UIResponder (da cui eredita UIView) e infine NSObject. Insomma, come potrete intuire le cose si complicano un pochino e di fatto, se pensavate di cavarvela con poca memoria, in realtà ci rendiamo conto che ne serve più del previsto e dovremo allocare la quantità di memoria necessaria a contenere sia i nuovi elemente da noi creati che tutti quelli ereditati. Oltre ad allocare la quantità corretta di memoria, capirete quindi che sarà il caso, inoltre, di liberare appena possibile la memoria utilizzata, ovvero quando l’oggetto residente in memoria non serve più.

Insomma, un attenta pianificazione e gestione della memoria può essere decisiva per il successo della vostra applicazione iPhone!

Allocare la giusta quantità di memoria per un oggetto in Objective-C (alloc, init)

Allocare la corretta quantità di memoria (ricordate ne che abbiamo una quantità limitata da usare), sembrerebbe quindi un processo lungo e complesso, ma non è così. Il framework, e in particolare proprio il “super” oggetto NSObject, ci offre infatti un metodo di classe molto utile: Alloc!

Grazie a questo metodo (che potremo usare nei nostri oggetti che ereditano direttamente o indirettamente da NSObject) saremo in grado di allocare la giusta quantità di memoria sia per tutti i nostri nuovi elementi. che per quelli ereditati. A livello di codice è molto semplice, se dovessimo creare nel nostro programma un’istanza di MyClass, questo potrebbe essere il codice da scrivere:

1

    MyClass *myNewClass = [MyClass alloc];

L’istruzione è ancora incompleta, infatti dobbiamo ancora inizializzare il nostro oggetto perchè sia pronto per essere utilizzato all’interno del nostro programma. Per farlo possiamo sfruttare un altro metodo offerto da NSObject: init!
Grazie ad “init” potremo appunto inizializzare i nostri oggetti, ovvero dotarlo della configurazione di default che servirà all’avvio dell’applicazione (o meglio al momento della creazione dell’oggeto). Anche qui il codice è molto semplice:

1

    MyClass *myNewClass = [[MyClass alloc] init];

Unica cosa che dobbiamo ricordare è che come lo spazio da allocare deve essere calcolato anche per gli elementi degli oggetti da cui si eredita, anche l’inizializzazione deve essere fatta per questi stessi elementi. Niente paura, anche per questo ci basterà un’unica riga di codice all’interno del metodo init nell’implementazione della nostra classe:

1
2
3
4
5

- (id)init {
    [super init];
    // Codice per inizializzazione
   return self;
}

Grazie all’istruzione [super init] non ci dovremo preoccupare di inizializzate tutto manualmente.
A questo punto il nostro oggetto “myNewClass ” è pronto per essere utilizzato.

Liberare la memoria al momento giusto (retain, release, dealloc)

Per la creazione del nostro oggetto nel programma è tutto, è infatti stata creata un’istanza della nostra classe, la abbiamo allocata in memoria (considerando lo spazio necessario) e infine la abbiamo inizializzata a dovere per poterla utilizzare come meglio crediamo. Ovviamente la gestione della memoria non si limita a questo, dovremo infatti prevedere, ad un certo punto, di liberare lo spazio di memoria occupato dalla stessa. NSObject offre un metodo che compie questo lavoro: dealloc, questo, però, non dovrà mai essere chiamato esplicitamente, ma dovrà essere chiamato indirettamente dal metodo di protocollo release. Non preoccupatevi se non capite a fondo cosa sto dicendo, ora vedrò di spiegarvi il meccanismo che sta dietro questa frase.

Perchè non possiamo invocare direttamente dealloc? Semplicemente perchè deallocando l’oggetto sparirebbe dall’intero programma e potrebbe capitare che in realtà, questo, serva ancora da qualche parte. Infatti oltre a servire nel metodo in cui è chiamato, un oggetto potrebbe essere passato come argomento ad altro oggetto e avere ancora uno scopo che necessiti la sua esistenza. Deallocandolo in un caso come questo il programma restituirebbe un errore o comunque si comporterebbe in modo anomalo e imprevisto.

Da qui nasce l’esigenza avere un contatore che indichi al nostro programma se esiste ancora qualcuno interessato ad sfruttare il nostro oggetto. Questo contatore dovrà avere valore 1 non appena l’oggetto verrà allocato in memoria, dovrà quindi essere incrementato di 1 ogni volta che un altro oggetto ha interesse a mantenerlo in memoria, e diminuito di 1 quando un oggetto decide che non gli serve più.

Anche in questo caso non dovremmo inventarci nulla in quanto in nostro aiuto arriva il nostro caro NSObject, che offre ad ogni oggetto da esso ereditato una proprietà chiamata retainCount. Quando retainCount varrà 0, dealloc verrà richiamato in automatico e la memoria sarà liberata.

Come detto allocando un oggetto in memoria verrà impostato il suo retainCount a 1, noi dovremo semplicemente dire al programma di sottrargli un 1 quando non ci servirà più, per farlo useremo il metodo release:

1
2
3
4
5

MyClass *myNewClass = [[MyClass alloc] init];
 
// Facciamo qualcosa con la nostra myNewClass
 
[myNewClass release];

In particolare riportiamo i momenti in cui retainCount può variare (tratti dal nostro precedente articolo su questo tema a cura di Ignazio Calò):

• Quando una variabile viene inizializzata il suo retainCount viene incrementato di 1.
• I metodi alloc, copy, allocWithZone incrementano retainCount di 1.
• I metodi release, autorelease decrementano retainCount di 1. (autorelease lo fa in un momento non deterministico)
• Se non diversamente specificato il metodo autorelease viene invocato di default.

Casi particolari

Ora, senza entrare troppo nel dettaglio, sappiate che esistono alcuni casi in cui possiamo usare un oggetto senza allocarlo o deallocarlo, semplicemente il tutto viene gestito in automatico e gli oggetti vengono rilasciati quando non servono più.

Vediamo un esempio:

1

NSString *myNewString = [NSString stringWithFormat:@"Nuova stringa"];

In questo caso stiamo utilizzando il metodo di classe “stringWithFormat” (quelli che iniziano con + per intenderci), per questo tipo di metodi non dovremo preoccuparci di nulla e potremo utilizzare questi oggetti senza troppi pensieri.

Errori nella gestione della memoria

Per concludere vediamo cosa comporta non gestire correttamente la memoria durante lo sviluppo di un’applicazione iPhone, iPad e anche Mac. Se allochiamo un oggetto, dedichiamo quindi ad esso uno spazio in memoria, ma ci dimentichiamo per qualche ragione di rilasciarlo, questo occuperà per tutta la durata dell’esecuzione del programma quello spazio in memoria, e ogni volta che richiameremo una nuova istanza dell’oggetto, un altro pezzettino di memoria andrà occupato inutilmente. Capirete che pian piano, la memoria disponibile (ricordiamo che sui dispositivi mobili è limitata in modo considerevole rispetto agli ambienti desktop), andrà ad esaurirsi fino al blocco del programma stesso o al verificarsi di comportamenti anomale e imprevisti. Questo tipo di errore nella gestione della memoria è chiamato Memory Leak.

Per farvi comprendere meglio cosa significa incappare in questo errore vi riportiamo, per semplicità e comodità, e vista inoltre l’immediatezza e la chiarezza di quanto illustrato, un breve esempio tratto da wikipedia:

Questo esempio vuole dimostrare come un leak può nascere, ed i suoi effetti, senza dover conoscere le basi della programmazione. Questo è solo un esempio fittizio.

Il programma in questione fa parte di un software molto semplice dedicato al controllo di un ascensore. Questa porzione di algoritmo viene eseguita ogni volta che qualcuno all’interno preme un bottone.

Quando il bottone viene premuto:

• recupera un po’ di memoria per ricordare il piano richiesto
• metti il numero richiesto in memoria
• siamo già al piano giusto?
• se sì, non dobbiamo fare niente: finito
• altrimenti, aspetta finché l’ascensore è disponibile
• vai al piano richiesto
• rilascia la memoria usata per ricordare il numero del piano

Questo programma potrebbe sembrare corretto, ma contiene un leak. Consideriamo il caso in cui l’ascensore si trova al piano 3 e premiamo il bottone 3. Otteniamo un po’ di memoria che non restituiremo mai. Ogni volta che succede perdiamo un po’ di memoria.

Questo problema non avrà un effetto immediato. Le persone non premono il bottone di un piano su cui stanno, ed in ogni caso ci può essere abbastanza memoria da gestire questa situazione centinaia o migliaia di volte. Ma alla fine la memoria finirà. Potrebbe richiedere mesi o anni, o potrebbe non essere mai scoperto.

Le conseguenze potrebbero essere sgradevoli; alla fine l’ascensore smetterebbe di funzionare. Se il programma avesse bisogno di memoria per aprire le porte, qualcuno potrebbe restare intrappolato all’interno, visto che non abbiamo risorse per aprirle.

Bisogna notare che il memory leak aumenta finché il programma è in esecuzione. Ad esempio, se un calo di elettricità blocca l’ascensore, al ritorno dell’alimentazione la memoria sarà completamente disponibile ed il lento processo di perdita di memoria deve ricominciare da zero.

Questo articolo non può certo considerarsi esaustivo sull’argomento, ma speriamo di aver tolto qualche dubbio in più e di invogliarvi, vista l’importanza, ad approfondire questo “apparentemente noioso” argomento.

A causa delle restrizioni imposte per motivi di sicurezza sull’ iPhoneOS non è possibile vedere l’intero filesystem ma solo ciò che è all’interno del filesystem riservato alla vostra applicazione (sandbox), ciò porta all’impossibilità di usufruire direttamente dei dati utente (musica, video) o delle altre applicazioni.

Innanzitutto è importante conoscere il contenuto della home-directory comune a tutte le applicazioni in modo da tenere “in ordine” i file della nostra app…

L’home-directory è composta generalmente da quattro principali directory:

• NomeApplicazione: ha il nome dell’applicazione e contiene eseguibile, NIB, localizzazioni, ecc… (non potete effettuare operazioni di I/O)
• “Library”: è la cartella genitore di “Preferences” e la lettura/scrittura avviene attraverso l’uso delle API
• “Documents”: di default è vuota ed è gestibile a proprio piacimento
• “tmp”: come suggerisce il nome è la cartella dei file temporanei, potrete utilizzarla a vostro piacimento ma è importante ricordare che non viene presa in considerazione da iTunes e che bisogna ricordarsi di svuotarne il contenuto (buona norma è svutarlo alla chiusura dell’app)

Un consiglio di particolare importanza è quello di lasciar perdere le prime due directory e utilizzare solo le altre…

Ora passiamo a parlare un po più nella pratica di come potrà avvenire l’accesso al filesystem; per lo scopo utilizzeremo la classe NSFileManager (per maggiori info vi rimando alla documentazione ufficiale).

Visualizzare il contenuto di una directory

Per lo scopo useremo la classe NSFileManager e il suo metodo directoryContentsAtPath:
Questo ha come ritorno la lista dei nomi di file e directory nel percorso dato, questi sono restituiti all’interno di un NSArray di NSString.
Il consiglio è di utilizzare una UITableView che avrà come lunghezza la dimensione dell’array e come contenuto l’array stesso (i-esima cella => i-esimo elemento dell’NSArray).

Attributi di un file

Precedentemente abbiamo visto come ottenere il contenuto di una precisa directory ma, come avrete sicuramente notato, file e cartelle non sono distinguibili in quanto rappresentate entrambe una una NSString contenente il loro nome. Appunto per questo ricorreremo al metodo fileExistsAtPath:isDirectory: (sempre di NSFileManager), isDirectory è un puntatore a un boolean (BOOL) che avrà i valori YES se il percorso è una directory.

Lettura di un file

Per la lettura di un file ci rifaremo al concetto di flusso che considera i byte del file all’interno di uno stream che viene sequenzialmente letto (in questo modo non dovremmo necessariamente caricare tutto il file in memoria e perciò avremo evitato di dover leggere solo file di piccole dimensioni).

La classe che andremo ad utilizzare sarà una sottoclasse di NSStream denominata NSInputStream.

Possiamo riassumere le operazioni da eseguire in:

• creare un buffer di memoria contenente i byte letti dal flusso (stream);
• leggere ciclicamente (es. con un ciclio while) i blocchi di byte (con dimensione inferiore alla dimensione del flusso);
• operare sui byte (per esempio scriverli di seguito in un UITextView dopo averli opportunamente convertiti in stringhe);
• chiudere il flusso quando i byte sono terminati.

L’esempio del terzo punto è proprio quello che andremo ad affrontare…

Come riportiamo i byte nel UITextView ?

Penso che un codice esprima molto più di 1000 parole:

1
2
3

-(void) appendText: (NSString*) text {
textView.text = [NSString stringWithFormat: @"%@%@", textView.text, text];
}

La stringa in rosso rappresenta ciò che dobbiamo aggiungere mentre textView.text è il testo dell’UITextView.

Naturalmente non possiamo dare in input al metodo direttamente il blocco di byte letto ma dobbiamo prima convertirlo, anche in questo caso riporteremo la parte di codice necessria all’operazione:

1
2

NSString *bufferString = [[NSString alloc] initWithBytesNoCopy:buffer length:bufferLength encoding:NSUTF8StringEncoding freeWhenDone: NO];
[self appendText:bufferString];

“bufferString” sarà il testo in input ad appendText (che nel metodo in questione chiamiamo semplicemente text) mentre buffer sarà il gruppo di byte letti.

NSUTF8StringEncoding è utilizzabile solo per file di testo semplici.

Creazione e Scrittura di un file

Per la creazione del file useremo createFileAtPath: di NSFileManager.

Per la scrittura di questo useremo il concetto di flusso ma invece che considerarlo in input sarà in output (cioè verso il file creato); per questo scopo useremo il metodo write:maxLength: di NSOutputStream (sottoclasse di NSStream).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

-(void) createAndSave {
 
[asyncOutputStream release];
[outData release];
 
outData = [[textView.text dataUsingEncoding: NSUTF8StringEncoding] retain];
 
outRange.location = 0;
 
NSString *newFile [parentDirectoryPath
stringByAppendingPathComponent: fileName.text];
 
[[NSFileManager defaultManager] <strong>createFileAtPath</strong>:newFile contents:nil attributes:nil];
 
asyncOutputStream = [[NSOutputStream alloc] initToFileAtPath: newFIle append: NO];
 
[asyncOutpuntStream setDelegate: self];
[asyncOutpuntStream scheduleInRunLoop:[NSRunLoop runLoop] forMode: NSDefaultRunLoopMode];
[asyncOutpuntStream open];
}

textView sarà UITextView che conterrà il testo del file

fileName sarà UITextField che conterrà il nome del file

asyncOutputStream indica che il flusso dei dati avviene in maniera asincrona (ciò può avvenire anche nel caso della lettura); in questo modo l’app non resta in blocco per tutta la durata del flusso ma opera solo quando il flusso ha dei byte disponibili.

outData conterrà il testo dell’UITextView convertito in NSData in modo da essere compatibile con il flusso
Nel file header (.h) saranno necessarie le variabili d’istanza:

1
2
3

NSData *outData;
NSRange *outRange;
NSOutputStream *asyncOutputStream;

Queste servono per coordinare il metodo e il callback…

E’ importante ricordare che la scrittura nel flusso genererà degli eventi, i più importanti sono:

• NSStreamEventHasSpaceAvaible: indica che il flusso è pronto
• NSStreamEventErrorOccurred: indica che si è verificato un errore (potete ad esempio visualizzare un UIAlertView)

Quando il primo caso si verificherà siamo pronti a impostare il buffer da passare a write:maxLength di NSOutputStream

1

[outputStream write: buffer maxLength: 1]

in questo caso la lunghezza è pari a 1 ma può essere modificata.

outputStream è il nostro NSOuputStream:

1

NSOutputStream *outputStream = (NSOutputStream*) stream;

Mentre stream è un NSStream* in input:

1

-(void)stream:(NSStream*)stream handelEvent:(NSStreamEvent)event { ... }

Buona programmazione a tutti e arrivederci al prossimo articolo…

Cinaglia Pietro