Chords Archiver è una applicazione gratuita, sviluppata da un giovane programmatore italiano, Davide Troise.

Chords Archiver è sostanzialmente un archiviatore di accordi e testi di canzoni, con alcune ottimizzazioni per l’utilizzo durante le performance live.

L’autore ha approntato anche un pagina di supporto che ne spiega il funzionamento e le caratteristiche principali.

Chord Archiver permette archiviare le tue canzoni (con testo, accordi e tablature) a mano o cercandole su internet con Safari, per poi salvarle nell’applicazione.

Le canzoni sono ordinate per autore, in sezioni alfabetiche ed è implementata una ricerca su tutto il testo per aiutarti a trovare facilmente una canzone.

I preferiti. Puoi segnare le tue canzoni preferite con una stella. Queste canzoni sono visualizzate in un menu dedicato a destra in cui puoi decidere l’ordine di tali canzoni creando una vera e propria scaletta per le tue esibizioni dal vivo!
Per sfogliare i preferiti avanti e indietro in maniera immediata, hai bisogno di un solo dito: scorri a destra o a sinistra sul display per cambiare canzone a seconda della lista dei preferiti.

Autoscroll e grandezza del carattere. Le canzoni lunghe hanno testo e accordi lunghi: con lo scroll automatico puoi scorrerli senza toccare il display. Puoi anche cambiare la grandezza del font e la velocità di scorrimento del testo: Chord Archiver si ricorda questi parametri per ogni canzone.

L’applicazione è localizzata in italiano e inglese.

L’autore, che fa anche parte della nostra Redazione, ci tiene a incoraggiare commenti, suggerimenti e critiche al fine di migliorare questa che è la sua prima applicazione per iPad.

-(id)initWithFloat:(float)newFloat
{
	[super init];
	storedFloat = newFloat;
	return self;
}

seguendo l’utile convenzione sui nomi che prevedere, in questo caso, di iniziare il nome del metodo con init, poi segnalare la presenza di uno o più argomenti con la parola With, ed infine scrivendo il nome del primo argomento. Dal secondo il poi si aggiungerebbe la congiunzione and.

Dal punto di vista progettuale, in questo modo l’oggetto della classe che contiene questo nuovo metodo è inzializzato con la variabile di istanza storedFloat impostata al valore dell’argomento. E possiamo allocare un’istanza della classe e inizializzarla con tanto di argomento, tutto in una sola riga di codice:

myNumber *aNumber = [[myNumber alloc] initWithFloat:4.92131];

Un problema nasce quando qualcun altro potrebbe usare ancora il metodo init che, essendo ereditato quantomeno da NSObject, non è eliminabile ma non inizializza l’oggetto come vorremmo.

La soluzione è aggiungere il metodo init nell’implementazione della nostra classe, in modo che vada a sovrascrivere il metodo ereditato, e scrivere

-(id)init
{
	return [self initWithFloat:4.92131];
}

senza la necessità di richiamare [super init] dal momento che lo fa già initWithFloat.

Abbiamo iniziato a parlare di oggetti e memoria in un primo articolo sui metodi alloc e init, proseguendo con una breve discussione dei problemi dovuti al memory leak. Oggi andiamo avanti su questo tema e partiamo subito ricordando che gli oggetti non vengono mai deallocati dall’utente ma viene utilizzato il contatore di retain.

Quando un oggetto viene allocato il suo contatore di retain è impostato automaticamente a 1, e viene incrementato ogni volta che in una parte di codice si dichiara l’interesse a quell’oggetto. Viceversa, quando l’oggetto non serve più, viene chiamato il metodo release, che decrementa il contatore di 1 finché, arrivato a zero, l’oggetto viene deallocato automaticamente dal sistema.

È più facile di quel che sembra e, una volta iniziato in concreto ad usare questo sistema, sarà ancora più facile. Ma esistono dei casi in cui tutta questa responsabilità per un oggetto non è così comoda da avere. Ecco un esempio.

Data una classe che potremmo chiamare MyNumber, consideriamo un metodo che restituisca il numero registrato (theNumber, che supponiamo sia un float) come oggetto NSString. Nel file .h scriveremo quindi

-(NSString *)theNumberAsString;

Nell’implementazione (ovvero il file .m) dovremo allocare un nuovo oggetto NSString, dal momento che deve essere restituito, basato sul valore della variabile theNumber che è di tipo float. Per fare questo usiamo il metodo initiWithFormat.

Se però scrivessimo tale implementazione come

-(NSString *)theNumberAsString
{
NSString *theString = [[NSString alloc] initWithFormat:@"%f", theNumber];

return theString;
}

potremmo pensare di dover rilasciare la variabile theString, scrivendo il comando [theString release] prima della riga return. Ma a questo punto restituiremmo un oggetto non più allocato, generando un ovvio errore.

Il problema è però che non vogliamo dover rilasciare un oggetto in un metodo in cui non lo abbiamo allocato, quindi, ad esempio, non vogliamo rilasciare la NSString theString nel metodo che richiama theNumberAsString, in qualunque parte del codice si trovi.

Se infatti dovessimo scrivere un metodo così

{
MyNumber *aNumber = [[MyNumber alloc] init];

[aNumber setTheNumber:3];

NSString *aNumberString = [aNumber theNumberAsString];

/* ... codice che usa aNumberString ... */

[anumberString release];
}

allora saremmo costretti ad avvisare tutti coloro volessero usare l’istanza *aNumber di rilasciare qualunque stringa theString a cui abbia avuto accesso tramite il metodo theNumberAsString.

Fortunatamente il framework Cocoa, che ha preparato per noi Apple, risolve questa complicazione con il meccanismo dell’autorilascio: ovvero il comando autorelease.

Autorelease, infatti, rilascia automaticamente tutti gli oggetti non utilizzati quando il programma resta in attesa che l’utente faccia qualcosa, ovvero alla successiva esecuzione del ciclo degli eventi. Se a quel punto l’oggetto ha un conteggio dei riferimenti uguale a zero, sarà deallocato automaticamente, come prevedibile.

Quindi il codice da modificare è quello nell’implementazione di theNumberAsString:

-(NSString *)theNumberAsString
{
NSString *theString = [[NSString alloc] initWithFormat:@"%f", theNumber];

return [theString autorelease];
}

In questo modo la stringa theString viene rilasciata solo alla fine del codice corrente. La conseguenza è che se generiamo stringhe in un metodo che usa theNumberAsString non dobbiamo più preoccuparci di rilasciarle, perché sono allocate in theNumberAsString e verrà utilizzato per loro l’autorilascio. Nel file di implementazione dell’ipotetica classe che usa il metodo theNumberAsString, che potrebbe ad esempio essere una azione che visualizza un numero in una casella di testo in conseguenza al clic di un utente, scriviamo quindi:

-(IBAction)showANumber:(id)sender
{
MyNumber *aNumber = [[myNumber alloc] init];

[aNumber setTheNumber:pi];

NSString *aNumberString = [aNumber theNumberAsString];

[textView insertText:aNumberString];

[aNumber release];
}

Facciamo quindi una cronistoria di ciò accade: dopo la creazione dell’oggetto di classe MyNumber, abbiamo creato un puntatore all’oggetto stringa aNumberString (che però è allocato nel metodo theNumberAsString, non in showANumber), gli assegnamo la stringa theNumber che proviene dalla classe MyNumber (è il compito che svolge proprio theNumberAsString) e poi inseriamo tale stringa nel TextField chiamato textView.

L’unico messaggio di release è quello inviato all’istanza aNumber, che è appunto l’unica allocata nel metodo showANumber. Una volta terminato tale metodo, il puntatore aNumberString va fuori ambito (scope) e, poiché nel nostro particolare meccanismo, subito dopo il programma resta in attesa di un’altra azione dell’utente (presumibilmente un altro clic), l’oggetto stringa restituito da theNumberAsString viene rilasciato (grazie all’autorilascio) e quindi deallocato.

Abbiamo così messo in opera un ottimo meccanismo per negare la resposabilità su un oggetto, che altrimenti non avremmo saputo dove rilasciare.

La scorsa settimana abbiamo parlato dei metodi alloc e init nella creazione di oggetti in Objective-C. Sappiamo però che tenere in vita un oggetto significa consumare memoria ma, finquando questo oggetto ci serve, è un costo che paghiamo volentieri.

Il memory leak (ovvero perdita o falla di memoria) è, infatti, un problema di carenza di memoria causato spesso proprio da oggetti allocati e inizializzati che non vengono mai deallocati. Si tratta di un comune errore di programmazione poiché tali oggeti sono creati nell’ambito di un metodo (quindi in un blocco di codice chiuso fra parentesi graffe, un cosiddetto scope), si potrebbe pensare che vengano distrutti automaticamente appena usciti dall’ambito in cui sono stati creati, un po’ come accade per le variabili scalari.

In realtà, chiusa la parentesi graffa del metodo, ciò che cessa di esistere non è l’oggetto ma il puntatore all’oggetto. L’oggetto, pur senza alcun riferimento, continua ad esistere e ad occupare memoria. Bisogna quindi saper gestire in maniera opportuna il rilascio di questi oggetti, tramite una funzionalità di Objective-C chiamata negazione della responsabilità.

Va ricordato infatti che gli oggetti non devono mai essere deallocati direttamente dall’utente (dal momento che non si può prevedere che un oggetto creato da un metodo non serva ad un altro metodo), ma bisogna utilizzare il cosiddetto contatore di retain. Quando un oggetto viene allocato il suo contatore di retain è impostato automaticamente a 1, e viene incrementato ogni volta che in una parte di codice si dichiara l’interesse a quell’oggetto. Viceversa, quando l’oggetto non serve più, viene chiamato il metodo release, che decrementa il contatore di 1 finché, arrivato a zero, l’oggetto viene deallocato automaticamente dal sistema.

Quando una classe eredita da un’altra classe, eredita sia le funzionalità (cioè i metodi) che tutte le variabili di istanza dalla classe genitore.

Per allocare la memoria necessaria per un oggetto, NSObject (di cui ogni oggetto è almeno figlio) fornisce un metodo di classe chiamato alloc che alloca sempre la memoria sufficiente per qualsiasi oggetto specifico:

NSObject *someNewObject = [NSObject alloc];

Il metodo alloc provvede anche a impostare tutte le variabili di istanza a zero e i puntatori a nil.

A questo punto bisogna solo inizializzare l’istanza della classe appena creata con il metodo di classe init, che può essere ridefinito a patto che vengano inizializzate tutte le variabili di istanza del genitore (che, ricordiamo, sono state tutte ereditate) e che venga restituita l’istanza stessa su cui il metodo è chiamato:

-(id)init
{
	[super init];

	//altro codice

	return self;
}

Richiamare [super init] tutte le volte che si eredita una classe è garanzia che, a cascata, tutte le variabili di istanza di tutta la genealogia della classe vengano correttamente inizializzate.

La programmazione con  Objective-C, ma non solo, mette spesso di fronte al problema di rendere il codice più leggibile possibile. Nei decenni si sono sviluppate notevoli quantità di convenzioni per ottenere questo risultato. In Xcode ce ne sono due particolarmente importanti. Vediamole insieme.

C’è camelCase e CamelCase

Se il nome di metodo o di una variabile è composto da più parole,  va seguita la convenzione camelCase: le parole devono essere concatenate l’una all’altra e devono essere scritte con l’iniziale maiuscola, tranne l’iniziale della prima parola.

Le classi si scrivono seguendo la stessa convenzione dei nomi, con la differenza che anche la prima parola va scritta con l’iniziale maiuscola. In questo modo quando si richiama un metodo di classe lo si riconosce subito:

[LengthConversion centimetersFromInches:inches];

Indicare l’argomento del nome del metodo

I metodi che accettano argomenti vanno scritti con il nome del primo argomento nel nome stesso del metodo, come ad esempio

-(float)centimetersFromInches:(float)inches;

Un’eccezione è nei nomi dei metodi target-azione, in cui l’argomento è sempre sender.

Se conoscete altre convenzioni utili, segnalatele pure nei commenti.

Davide Casali, Marco Colombo e Alessandro Morandi sono gli sviluppatori che si stanno occupando del progetto Baker, un framework Open Source per Xcode che permette, in maniera molto semplice, di realizzare un eBook per iPad in poco tempo. L’eBook, in forma di applicazione, e non di ePub, è subito inviabile ad Apple per l’approvazione e la vendita su App Store.

Il progetto è sviluppato su GitHub, la piattaforma di condivisione e collaborazione di cui abbiamo parlato la settimana scorsa e che permette di realizzare un fork, una diramazione, partendo proprio da un progetto come Baker, per realizzarne la propria personale versione, oppure proprio di collaborare con gli sviluppatori per contribuire a sviluppare il progetto originale.

Per sfruttare al meglio Baker sono necessari tre passaggi principali:

Il primo passaggio è la progettazione di pagine HTML che abbiano una larghezza fissa di 768 pixel (quella dell’iPad) usando tutte le tecnologie a disposizione di WebKit, ovverosia HTML 5, CSS e Javascript. Per testare la grafica e il funzionamento di queste pagine, ognuna delle quali deve rappresentare un capitolo del libro, è sufficiente caricarle su Safari. Per questo scopo è utile usare il codice CSS a larghezza fissa di 768 pixel messo a disposizione dal team di Baker.

Il secondo passaggio e la realizzazione del pacchetto che verrà usato dal framework. Si tratta semplicemente di una cartella chiamata book che dovrà contenere, come già accennato, i file HTML, uno per ogni capitolo. In particolare si dovranno chiamare 1.html, 2.html, eccetera, con 1.html che presumibilmente sarà la copertina dell’eBook. Nella stessa cartella dovranno essere incluse anche tutte le immagini e gli altri file necessari ai documenti HTML, anche inseriti in sottocartelle. Gli autori del progetto Baker hanno messo a disposizione un file zip contente un eBook d’esempio in formato HTML, creato secondo le linee guida qui sopra illustrate.

Il terzo ed ultimo passaggio consiste nel download del framework, sotto forma di progetto Xcode (e licenza BSD, nella versione a tre clausole). Basta scompattare lo zip, sostituire la cartella book con quella preparata in precedenza (o quella d’esempio) e fare doppio clic sul file Baker.xcodeproj per aprirlo in Xcode. A questo punto ci sono delle modifiche da fare per poter pubblicare l’applicazione eBook, ma possiamo già cliccare sul pulsante Build&Run per vedere, con il Simulatore, come apparirebbe l’esempio di libro digitale su iPad:

fai clic per ingrandire

Ovviamente prima della pubblicazione dobbiamo rinominare il progetto Xcode (dal menu Project>Rename…) e inserire l’icona che vogliamo appaia su App Store e su iPad, una volta installato l’eBook. Per qualsiasi dubbio, il progetto include un file Readme che spiega tutti i passaggi necessari in maggior dettaglio.

Grazie a Francesco per la segnalazione.

GitHub è un sito per archiviare e condividere codice con altri programmatori, sviluppando insieme progetti soprattutto Open Source. Non è la prima piattaforma che permette alle comunità spontaneamente nate in rete di sviluppare un progetto comune, ma certamente si tratta di un sito ottimamente realizzato.

Si può scegliere di creare un account gratuito senza limiti di numero di repository (deposito di codice) e senza limiti di collaboratori. Esistono poi ben 7 profili di account a pagamento, dal Micro a 7.00 $/mese per 5 repository privati e 1 collaboratore privato, fino al Platinium a 200 $/mese per 125 repository privati e un numero qualunque di team di sviluppo.

Innanzitutto, all’accesso si può cliccare in alto, dove si trova la scritta

Would you rather see this site in Italian? (Vorresti visualizzare questo sito in Italiano?)

La traduzione non è ancora completa, ma può aiutare a muoversi più velocemente nel sito.

Moltissimi sono i linguaggi supportati, con colorazione della sintassi. Ecco l’elenco completo:

ActionScript, Arc, ASP, Assembly, Boo, C, C#, C++, Clojure, CoffeeScript, ColdFusion, Common Lisp, D, Delphi, Duby, Eiffel, Emacs Lisp, Erlang, F#, FORTRAN, Go, Groovy, Haskell, HaXe, Io, Java, JavaScript, Lua, Max/MSP, Nu, Objective-C, Objective-J, OCaml, ooc, Perl, PHP, Pure Data, Python, R, Racket, Ruby, Scala, Scheme, sclang, Self, Shell, Smalltalk, SuperCollider, Tcl, Vala, Verilog, VHDL, VimL e Visual Basic.

In Objective-C, linguaggio principe per la programmazione per Mac OS X e iOS, esistono molti progetti aperti, come ad esempio il FaceBook iOS SDK, la libreria open source per integrare Facebook nella propria applicazione. Tale progetto è quello che ha subito, recentemente, il maggior numero di fork, ovvero diramazioni: molti sono stati i programmatori che, usando GitHub, hanno preso questo SDK per adattarlo alle proprie esigenze di sviluppo.

Dopo aver letto l”articolo in tre parti “Xcode: imparare a usare la Documentazione”, siamo pronti per tradurre le conoscenze acquistite con lo studio delle referenze di NSTableView, NSMutableArray e NSDocument in una applicazione funzionante.

Se ne senti il bisogno, rileggi prima le tre parti

• Xcode: imparare a usare la Documentazione /1
• Xcode: imparare a usare la Documentazione /2
• Xcode: imparare a usare la Documentazione /3

Progetto dell’applicazione

Come forse hai già immaginato, se durante lo studio della Documentazione siamo partiti dalla Table View, per poi scoprire che dovevamo usare un NSMutableArray come sorgente dati, ed infine scoprire che per salvare tutto in un file ci serviva NSDocument, ora progetteremo l’applicazione e scriveremo il codice in senso inverso: prima creando un progetto Xcode Document-Based, poi creando l’array e infine collegandolo con la Table View, creando anche tutti i metodi per far interagire la Table View con l’array.

Guida video di supporto

A corredo di questo articolo abbiamo pubblicato una Guida video che ripercorre tutti i passaggi qui di seguito presentati. La Guida video non si dilunga in spiegazioni ma è solamente un supporto visivo per chi non ha ancora maturato dimestichezza con l’ambiente di sviluppo di Xcode e Interface Builder.

Creare il progetto

Si comincia creando un nuovo progetto andando su File > New Project… e scegliendo una Cocoa Application. Xcode ci permette di usare immediatamente la classe NSDocument mettendo il segno di spunta su Create document-based application.

Se la nostra tabella vogliamo che serva ad elencare delle squadre di calcio, giusto per fare un esempio, allora potremmo chiamare l’applicazione TeamList.

Vengono creati tutti i file necessari, compresi due file xib, MainMenu.xib e MyDocument.xib. Quest’ultimo file è la finestra in cui metteremo la Table View.

Creare l’interfaccia grafica

Se apriamo MyDocument.xib in Interface Builder possiamo costruire l’interfaccia grafica del nostro documento, che poi altro non sarà che una tabella, qualche pulsante, una label e un campo di testo. Potremmo creare l’interfaccia anche dopo aver scritto tutto il codice, ma progettarla adesso ci aiuta a fissare meglio le idee su come vogliamo che funzioni l’applicazione.

Prima di tutto eliminiamo la Label al centro finestra e prendiamo quindi un oggetto Table View dalla Library, trascinandola nella finestra stessa. Dopo averla ridimensionata, eliminiamo una colonna. Il modo più semplice è cliccare sulla Table View, andare sull’Inspector, nella sezione Attributes (premendo ⌘1), e impostando  il numero di colonne a 1.

Possiamo anche digitare una intestazione per la colonna facendo doppio click sull’Header e scrivendo, nel nostro esempio, Lista delle squadre. Poi aggiungiamo un Push Button, un Text Field e una Label in basso a sinistra. In basso a destra mettiamo invece uno Square Button il cui attributo Image dovrà essere NSRemoveTemplate: verrà aggiunto automaticamente un segno meno in formato standard.

Per il resto regolate dimensioni e posizioni in base al vostro gusto e alle linee guida blu che Interface Builder mostra quando si fanno queste regolazioni: sono linee che aiutano a seguire le Human Interface Guidelines di Apple.

Il risultato finale dovrà assomigliare a qualcosa del genere:

Stesura del codice

Dal momento che ormai abbiamo chiaro in testa cosa deve fare l’applicazione e sappiamo anche come farlo perché abbiamo studiato le pagine necessarie della Documentazione (non hai studiato? Torna indietro!), possiamo scrivere tutto il codice necessario. Potrebbe essere una buona idea quella di aprire le tre parti dell’articolo “Xcode: imparare a usare la Documentazione” (1, 2 e 3) in tre pannelli del browser per seguire meglio la stesura del codice.

I file di codice che dobbiamo modificare sono solamente 2: MyDocument.h e MyDocument.m. Questi rappresentano la classe MyDocument, di cui MyDocument.xib è il corrispettivo grafico. Non servirà quindi creare una istanza della classe MyDocument nel file xib, poiché quest’ultimo è già il proprietario della classe.

Nel file MyDocument.h dobbiamo dichiarare

• gli Outlet per permettere l’accesso ai dati della TableView e del TextField
• le Action per poter far eseguire un codice quando si preme sui due pulsanti
• l’array che sarà la nostra sorgente dati e dovrà essere persistente finquando la finestra MyDocument non verrà chiusa.

Il codice del file MyDocument.h è quindi il seguente:

@interface MyDocument : NSDocument
{

IBOutlet NSTableView *teamListTableView;
IBOutlet NSTextField *newTeamTextField;

NSMutableArray *teamListArray;

}

- (IBAction)addToTeamList:(id)sender;
- (IBAction)deleteFromTeamList:(id)sender;

@end

Il significato dovrebbe essere chiaro, per domande usate i commenti.

Molto più complessa sarà la stesura del codice di implementazione nel file MyDocument.m. Vediamo uno ad uno tutti i metodi che devono essere aggiunti ed implementati.

Personalizziamo il metodo di inizializzazione, creando l’array che dovrà essere trattenuto per tutta la vita del documento:

- (id)init
{
    self = [super init];
    if (self) {
		teamListArray = [[NSMutableArray alloc] initWithObjects:@"Juventus", @"Milan", @"Inter", nil];
    }
    return self;
}

Quindi, specularmente, scriviamo il metodo di deallocazione

-(void)dealloc
{
	[teamListArray release];

	[super dealloc];
}

I prossimi due metodi servono per costruire la tabella. Dapprima si determina il numero di righe da creare:

- (NSInteger)numberOfRowsInTableView:(NSTableView *)aTableView
{
return [teamListArray count];
}

E poi si popolano con ciò che è contenuto nell’array, riga per riga:

- (id)tableView:(NSTableView *)aTableView
		objectValueForTableColumn:(NSTableColumn *)aTableColumn
			row:(NSInteger)rowIndex
{
	return [teamListArray objectAtIndex:rowIndex];
}

Ora scriviamo il metodo dell'azione scaturita dal clic sul pulsante <em>Aggiungi</em>

[obj-c]
- (IBAction)addToTeamList:(id)sender
{
	[teamListArray addObject:[newTeamTextField stringValue]];

	[newTeamTextField setStringValue:@""];

	[teamListTableView reloadData];

	[self updateChangeCount:NSChangeDone];

}

Questo è invece il metodo che viene lanciato quando si clicca sul tasto per rimuovere una squadra. Se nessuna riga è selezionata esce dal metodo senza fare nulla.

- (IBAction)deleteFromTeamList:(id)sender
{
	int selectedItemIndex = [teamListTableView selectedRow];

	if (selectedItemIndex != -1 ) {

		[teamListArray removeObjectAtIndex:selectedItemIndex];

		[teamListTableView reloadData];

		[self updateChangeCount:NSChangeDone];
	}
}

Questo metodo fa parte del protocollo TableViewDataSource e viene richiamato quando si vuol modificare una riga e si fa quindi doppio clic, si scrive il nuovo nome e poi si fa invio:

- (void)tableView:(NSTableView *)aTableView
	setObjectValue:(id)anObject
		forTableColumn:(NSTableColumn *)aTableColumn
			row:(NSInteger)rowIndex
{
	[teamListArray replaceObjectAtIndex:rowIndex withObject:anObject];

	[self updateChangeCount:NSChangeDone];
}

Gli ultimi due metodi servono per salvare e riaprire il documento che contiene i dati dell’array. Il primo semplicemente scrive un file temporaneo (grazie all’argomento atomically:YES) e poi lo sposta nella posizione scelta dal pannello di salvataggio.

- (BOOL)writeToURL:(NSURL *)absoluteURL
			ofType:(NSString *)typeName
			 error:(NSError **)outError
{
	return [teamListArray writeToURL:absoluteURL atomically:YES];
}

Quest’altro apre un documento precedentemente salvato. In questo modo viene aperta anche un’altra finestra del programma, per cui è necessario rilasciare l’array allocato e inizializzato nel metodo init, riallocarlo e reinizializzarlo, questa colta con il contenuto del file aperto. Poi si ricarica la tabella che, avendo l’array come sorgente dati, rifletterà il contenuto del file aperto.

- (BOOL)readFromURL:(NSURL *)absoluteURL
			 ofType:(NSString *)typeName
			  error:(NSError **)outError
{
	[teamListArray release];

	teamListArray = [[NSMutableArray alloc] initWithContentsOfURL:absoluteURL];

	[teamListTableView reloadData];

	return YES;
}

Collegare i metodi all’interfaccia

Se si ha dimestichezza con Interface Builder, collegare le azioni e gli outlet all’interfaccia non sarà particolarmente difficile. Basterà infatti fare clic col tasto destro del mouse (clic secondario) sul cubo del File’s Owner, per aprire l’hud nero che elenca gli Outlet, le Received Action e i Referencing Outlet.

Dobbiamo quindi solo collegare le seguenti coppie:

• newTeamTextField con il Text Field
• teamListTableView con la Table View
• addToTeamList con il Pulsante “Aggiungi”
• deleteFromTeamList con il Pulsante quadrato “-”

Infine va creato un riferimento fra il documento NSDocument e la Table View di modo che la NSDocument sappia cosa deve salvare su file (ovviamente via codice abbiamo fatto l’uteriore collegamento Table View-array). Quindi colleghiamo

• dataSource con la Table View

Il risultato dovrebbe essere il seguente

Salvate, tornate in Xcode, compilate, eseguite e testate ogni funzionalità.

Per una dimostrazione della creazione di questo progetto vi rimando alla Guida video “Xcode: creare una lista di squadre di calcio”.

Il cuore della nostra Table View e della relativa sorgente dati è stato ormai studiato. Sembra tutto pronto per cominciare a scrivere del codice, ma in realtà rimane da studiare un modo per salvare e aprire un file che contenga le informazioni memorizzate nell’NSMutableArray.

Le parti precedenti dell’articolo sono

• Xcode: imparare a usare la Documentazione /1
• Xcode: imparare a usare la Documentazione /2

NSDocument

In realtà è sufficiente dare un’occhiata ai vari tipi di template disponibili quando creiamo un nuovo proggetto in Xcode per accorgerci che esiste un opzione Document-Based. Ma questo presuppone aver già letto qualcosa sul salvataggio dei file. Per questo facciamo finta che il nostro neo-programmatore non abbia mai sentito nominare questo tipo di applicazioni e che vada a cercare “save file” nella Documentazione.

I primi due risultati nella categoria Reference sono:

• NSSavePanel Class Reference
• NSDocument Class Reference

Il primo serve per gestire il pannello di salvataggio ed è, a quanto pare, troppo in profondità: noi vogliamo sapere come si salva, non siamo ancora interessati a modificare il comportamento del pannello di salvataggio.

Il secondo risultato ci porta alla classe NSDocument, il cui paragrafo introduttivo, Class at a Glance, ci dice che:

NSDocument is an abstract class that defines the interface for documents, objects that can internally represent data displayed in windows and that can read data from and write data to files. Documents create and manage one or more window controllers and are in turn managed by a document controller. Documents respond to first-responder action messages to save, revert, and print their data.

La cosa più importante che ci viene detta in questo paragrafo è che i documenti sono oggetti che possono rappresentare internamente dei dati visualizzati in finestre e che possono leggere dati da file e scriverli su file. Ottimo, è esattamente quello che ci serve.

Nel paragrafo Commonly Used Method troviamo due metodi gemelli:

writeToURL:ofType:error:

Writes the document’s data to a URL.

readFromURL:ofType:error:

Reads the document’s data from a file.

Utilizzeremo il primo per scrivere il file e il secondo per leggerlo. Da notare come la posizione sul disco possa essere indicata anche come URL, similmente ad una posizione sul web.

A questo punto dobbiamo solo trovare i metodi corrispondenti della classe NSArray per scrivere il contenuto dell’array sul file e per creare un array con i contenuto del file.

Tornando alla documentazione di NS Array troviamo writeToURL:atomically: che ci sembra ottimo per essere usato in writeToURL:ofType:error: di NSDocument. E troviamo anche initWithContentsOfURL: che permette di inizializzare un array con il contenuto di un file.

Un ultimo aspetto interessante, che potremmo voler implementare per far assomigliare la nostra applicazione ad una vera applicazione, è la possibilità di monitorare i cambiamenti effettuati dall’utente alla tabella. Lo scopo è quello di avvisare l’utente, mentre sta chiudendo il documento, che ci sono dei dati non salvati, ed eventualmente permettergli di salvarli.

Per fare questo dobbiamo solamente sfruttare il metodo di NSDocument chiamato updateChangeCount:. Il paragrafo Discussion spiega:

The change count indicates the document’s edited status; if the change count is 0, the document has no changes to save, and if the change count is greater than 0, the document has been edited and is unsaved. The changeType is described in “Constants.” If you are implementing undo and redo in an application, you should increment the change count every time you create an undo group and decrement the change count when an undo or redo operation is performed.

Se andiamo nella pagina Constants e scendiamo fino a NSDocumentChangeType, possiamo leggere con quale costante possiamo incrementare il contatore ChangeCount:

NSChangeDone

Increment change count. The value to pass to updateChangeCount: to indicate that a single change has been done.

Se chiamiamo questo metodo ogni volta che effettuiamo una modifica alla tabella (e quindi all’array), avremo la certezza di non perdere accidentalmente tali modifiche.

Le parti precedenti dell’articolo sono

• Xcode: imparare a usare la Documentazione /1
• Xcode: imparare a usare la Documentazione /2