Oggi parliamo di un argomento molto importante, spesso sottovalutato e che dovrebbe toccare ogni sviluppatore iPhone (e non): il design delle applicazioni. Molte volte, infatti, vuoi per questioni di tempo, vuoi per pigrizia, si fa l’errore di saltare tutti i passaggi che si pensa siano più inutili, uno di questi è appunto il design dell’applicazione, che andrebbe ragionato nelle prime fasi di sviluppo, ovvero nella parte di progettazione delle proprie applicazioni. Ogni studente di ingegneria informatica (o scienze informatiche) sa molto bene che questa parte è davvero importante, anche se nella realtà capita anche a loro, a lungo andare, di perdere la buona abitudine di fermarsi quei “5 minuti” in più che potrebbero far invece risparmiare ore se non giorni di correzione dell’applicazione per via di un cattivo design iniziale.
Dopo 3 anni di esperienza, malgrado la mia giovane età, ho capito che questo può essere un errore fatale. Il rischio di finire in un vicolo cieco è altissimo, anche perché spesso ci si trova davanti clienti che iniziano a richiedere questa o quell’altra “piccola modifica”, convinti che una qualsiasi banalità, sia una modifica da pochi minuti (tanto cosa ci vuole ad aggiungere “un flag” qua e la :P). Ecco perchè ragionare per bene fin da subito (anche e soprattutto con i nostri clienti) soprattutto prima di iniziare a scrivere codice e insieme allo sviluppo di un bel diagramma delle classi che ci serviranno, non guasta mai!
Cosa costruiremo nella nostra applicazione?
Passiamo al nostro progetto e proviamo ad immaginare di quanti controller necessitiamo per la nostra applicazione. Ad occhio e croce potrebbero servircene almeno 4 per:
- Quick Converter (Convertitore Rapido)
- Multi Converter (Convertitore con una valuta “madre” e le altre in cascata, a scelta)
- Rates (Possibilità di vedere i singoli cambi)
- Settings (Da non trascurare!)
Ognuno di questi avrà una classe. Personalmente non includo mai i View Controller nel diagramma delle classi ed il perchè è molto semplice: i View Controller, durante lo sviluppo, possono scomparire come nascere.
Quello di cui necessitiamo veramente è capire se le nostre valute necessitano o meno di una classe apposita, o se semplicemente potremmo limitarci ad utilizzare una struttura dati più basica come, ad esempio, un NSDictionary. Nel progetto che costruiremo un semplice NSDictionary, con le giuste chiavi, potrebbe essere più che sufficiente, ma essendo questo un tutorial completo proposto come studio, sono convinto che creando una classe apposita avremo l’occasione di poter toccare molti più aspetti della programmazione su iPhone.
Decisa quella che è la nostra struttura dati più semplice, la valuta, dobbiamo ragionare sul cambio. Il tasso di cambio, con valuta annessa, può essere considerata una classe? Possiamo creare una classe con le due valute e poi inserire una variabile che ne identifica il tasso di cambio? Certo, ma questa soluzione la ritengo, personalmente, pessima. Creare una classe con 3 variabili, dove due di esse sono di una classe creata da noi, a meno che il nostro storage dati non sia in Core Data (e più avanti vedremo il perchè), è uno spreco di risorse. Quello che faremo sarà semplicemente salvare il nostro tasso di cambio in un NSMutableDictionary con chiave del tipo “valuta1-valuta2”. Questo ci permetterà di salvare risorse e di avere un numero limitato di oggetti in memoria. In questo caso, la scelta migliore, è tenere tutto quanto in memoria, rendendo il tempo di conversione molto inferiore.
Come facciamo ad avere un oggetto che resti in vita per tutta la durata del nostro programma? Le soluzioni sono molteplici, si può iniziare con un semplice oggetto nel nostro delegate, fino ad un oggetto dichiarato in un file header globale passando per un singleton. Quest’ultimo caso citato è proprio quello che useremo.
Vedremo in uno dei prossimi articoli cos’è in dettaglio un oggetto “singleton” e mostreremo i suoi vantaggi e svantaggi, per ora vi saluto, ci si vede nel prossimo articolo che tratterà le icone per la nostra applicazione.
NOTA: Potete seguire tutto il progetto completo navigando nella categoria “Progetti Completi” del sito.










One Response to “Creiamo un’applicazione completa | Il Design di un’app”
21 Febbraio 2011
Tweets that mention Creiamo un'applicazione completa | Design di un'applicazione iPhone | devAPP -- Topsy.com[…] This post was mentioned on Twitter by thinkdiff ch, Rynox, iPadWorld.it, devAPP, Bubi Devs and others. Bubi Devs said: Creiamo un’applicazione completa | Il Design di un’app: Oggi parliamo di un argomento molto importante, spesso s… http://bit.ly/fgQKlN […]