Come sappiamo iPad ha lo stesso sistema operativo di iPhone e iPod Touch.
La cosa è ancora piu ‘evidente è quella di sviluppare un’applicazione su un unico ambiente di sviluppo (SDK: Xcode, Interface Builder, iPhone Simulator, Instruments, …), un linguaggio di programmazione (Objective-C, in primo luogo, ma anche C, C + +, ..), il paradigma di programmazione stessa (MVC – Model View Controller, Object Programming), e il framework Cocoa Touch con piccole differenze dovute alle diverse caratteristiche tra i diversi dispositivi hardware;

Per “naturalizzare” le nostre applicazioni per iPhone iPad abbiamo due possibilità:

1) Creare una nuova versione del nostro programma, specificamente progettata per e in nome iPad.
2) Creare un’applicazione universale (Universal Access) in grado di operare correttamente e di “adattare”, come dispositivo su cui è iniziato. In questo caso, (vedi articolo), è necessario creare un unico programma è progettato per iPhone e iPad.

Per entrambi i casi, tuttavia, è necessario considerare alcuni aspetti, ad esempio.

Di orientamento
Come per l’iPhone (e iPod), le app hanno un orientamento predefinito, portrait (verticale).  l’iPhone essendo un telefono cellulare, anche se siamo in grado di prevedere il funzionamento della nostra applicazione in modalità landscape (orizzontale).
L’ iPad è un  dispositivo concepito per non avere un orientamento predefinito. L’ampio display è di facile utilizzo in verticale o orizzontale, ma non solo, mettiamo a disposizione 360 gradi per le nostre applicazioni, o tutti e 4 i modi in cui l’utente può mantenere il suo iPad. Per garantire la massima esperienza utente per le nostre applicazioni dovranno essere prese per garantire che la nostra forma visiva e quindi perfezionare l’esperienza, cercando di rendere al meglio lo spazio disponibile che abbiamo di volta in volta.

Dimensioni dello schermo
Nello sviluppo di applicazioni per iPad fondamentale è la dimensione del display.
Per il passaggio dal vostro iPhone, e soprattutto durante lo sviluppo di una applicazione universale, dato che le proporzioni dei vari dispositivi di visualizzazione sono diverse:

* IPhone 3GS e iPod Touch: 480 × 320 pixel per 163 ppi (pixel per pollice)
IPhone 4 *: 960 × 640 pixel per 326 ppi (pixel per pollice)
* IPad: 1024 × 768 pixel per 132 ppi (pixel per pollice)

L’iPhone ha le stesse proporzioni ma diverse risoluzioni, con iPad, tuttavia, differiscono anche in scala. Questo fattore è molto importante ed è necessario pianificare al meglio la vostra interfaccia grafica, se non si ottiene effetti collaterali.

Dividi la vista – Split View
Attraverso l’uso di SplitView, un nuovo tipo di vista, compatibile solo iPad. In modalità landscape (orizzontale) vedremo la nostra tabella di sinistra che ci permetterà di navigare e fare le nostre scelte, mentre la destra è la vista del dettaglio. In modalità ritratto, invece, vediamo il dettaglio (Detail View) in navigazione a schermo intero e la tabella all’interno di una popover che apparirà al tocco di un pulsante.

L’ampio display dell’iPad ha permesso non solo l’introduzione di SplitView, ma anche altri interessanti e disponibilisolo per iPad, per esempio, Popover View.

Popover view
poichè è solo compatibile con il iPad. Un popover non è altro che una visione particolare che appare sullo schermo premendo un pulsante e scompare su un punto qualsiasi del display al di fuori di essa. Questo tipo di oggetto è lo stesso che viene utilizzato in SplitView visualizzato in modalità portrait (verticale) per visualizzare la tabella di navigazione. Si potrebbe sfruttare il suo potenziale per mostrare, ad esempio, menu contestuali, collezioni di strumenti e così via.Nota: durante la loro progettazione sta nel prevedere uno spazio esterno per il tap che permetterà la sua chiusura.

GPS, bluetooth, Video
Infine ecco alcune altre caratteristiche minori, ma non meno importante che prendiamo in considerazione durante la transizione dalla programmazione iPhone iPad. A differenza di quanto accade per l’iPhone, la versione della vostra applicazione iPad dedicherà una piccola porzione del display video (invece del solo schermo intero), questo permetterà di consegna delle funzioni multimediali (vedere YouTube). È inoltre possibile godere l’uso di cavo video-out o addirittura un auricolare wireless, ed il microfono. Grazie al bluetooth, ma è possibile utilizzare la connessione di tastiere esterne. La condivisione di informazioni tra dispositivi (IPAD, Mac, PC, ..) è stata migliorata ed è possibile spostare l’oro, condividere e sincronizzare file nel modo migliore. Per quanto riguarda il GPS, si sa che non tutti i dispositivi lo hanno.

Leggiamo il rapporto di ChangeWave Research e sfogliamo il sito InvestorPlace (http://www.investorplace.com/25527/explosion-in-corporate-tablet-demand) che ci relaziona sui risultati di un nuovo sondaggio condotto lo scorso mese in materia di utilizzo aziendale di dispositivi tablet, come iPad di Apple.

Con le offerte di nuovi tablet come l’ardesia HP 500 e il Dell Streak, la ricerca rileva che le imprese ancora preferiscono l’ iPad.

In termini di uso corrente, il 7% degli intervistati aziendali  dicono che la loro azienda fornisce agli impiegati dispositivi Tablet.

iPad di Apple (82%) resta di gran lunga il Tablet più popolare per fini commerciali. HP (Slate, 11%) e Dell (Streak, 7%) mostrano un interesse tra gli utenti aziendali – ma entrambi rimangono molto indietro la quota preponderante di Apple sul mercato.
L’uso del tablet in azienda dovrebbe aumentare a picco, si prevede un utiulizzo di tablet nel primo trimestre del 2011co una penetrazione del 14%, il doppio del numero attuale. Tali società prevedono di iniziare ad utilizzare tablet all’inizio del prossimo anno e hanno in programma di adottare per il 78% il dispositivo tablet iPad di Apple.

Quando disegno un’applicazione per iPhone e  iPad, uno degli aspetti piu’ importanti per un App graphic designer è quello di disegnare icone, loghi, immagini di sfondo e di lancio (splash).
Rilevo, sopratutto confrontandomi con sviluppatori e creativi che c’e’ una grande confusione tra iPhone 3G, iPhone 3GS, iPod Touch 3, iPod Touch 4, iPhone 4 e iPad.
Esistono quindi delle differenze tra le dimensioni e il tipo di immagini che devo creare per un’applicazione o un progetto che possa essere ottimizzato per tutti i dispositivi sopra citati.

Cercando in rete ho trovato quindi una utile tabella per il nostri progetti iPhone /  iPad il cui “OS target” sia 3.2 o superiore:

Normalmente le icone  sono file in formato PNG con angoli a 90 gradi,  senza la trasparenza, senza livelli, e impostati a 72 PPI. iPhone OS arrotonda atomaticamente gli angoli, aggiunge un facoltativo effetto glossy e altri effetti.  Se non si vuole lasciare che l’iPhone / iPad OS applichi l’effetto gloss per le icone, gli sviluppatori dovranno aggiungere una chiave al info.plist chiamata UIPrerenderedIcon ed effettuare un controllo. La profondità di bit standard è di 24 bit + 8 bit alpha channel.

I progettisti e programmatori comprendono che le dimensioni degli elementi su schermi iPhone e  iPad non sono costanti. La differenza nelle dimensioni dello schermo e la funzionalità dello zoom sono un luogo comune, ma il formato PNG e 72 PPI è ancora il default.
Si noti che il formato PNG rigetta la Densità di pixel. La maggior parte degli editor di immagini, tra cui Adobe Photoshop, assumono che la densità dei pixel di un’immagine è di 72 se tale informazione non viene modificata.)

Disegnare icone per iPad può essere piu’ difficile. Alcuni progettisti rilasciano solo le icone standard per iPad poichè non riescono a comprendere che è meglio inserire anche alcune icone  di piccola dimensione, che sono comunque opzionali. Quindi è sempre meglio aggiungere delle piccole icone al progetto iPad,  nei formati di 64 × 64, 32x32px, e 24x24px 16x16px. I programmatori sapranno poi come includere questi file.

Si deve sapere che quando l’utente seleziona l’icona dell’applicazione principale l’applicazione inizia subito a caricarsi. E ‘importante rendere il tempo di lancio più breve possibile. Ogni app  iPhone e iPad puo’ avere una propria immagine di lancio (splash), che imita l’interfaccia utilizzando un’immagine statica. La splash page dovrebbe essere la più piccola possibile in modo da garantire un rapido caricamento del file. E’ quindi sempre sconsigliabile creare file di dimensioni vicine al megabyte.

Impostazione file Info.plist

Nel file Info.plist gli sviluppatori precisano gli orientamenti dell’applicazione assieme alle immagini di lancio correlate. Se manca, devono aggiungere queste righe:

Gli sviluppatori possono modificare precedenti convenzioni di naming , come spesso facciamo e possono usare il loro nome personalizzato per  icone e per lanciare i file di immagine.
Noi di norma siamo abituati a configurare le nostre applicazioni iPad in maniera diversa rispetto alle versioni iPhone, in modo da specificare i valori specifici del dispositivo per le chiavi Info.plist.
Ad esempio:

Esempio di icona e le impostazioni di immagine lancio in Info.plist per applicazioni universali. Piattaforma: iPhone OS 3.2 +

Note per gli sviluppatori:

Se l’applicazione supporta l’esecuzione di iPhone in iPhone OS 3.1.x o versioni precedenti, non è possibile utilizzare la chiave CFBundleIconFiles per specificare i file icona. È necessario creare le icone delle stesse dimensioni come indicato nella nostra tabella, ma ogni immagine deve essere chiamate come segue:

Icon.png – Icona per applicazioni per iPhone or iPod touch
Icon-72.png – Icona per applicazioni per iPad in un’applicazione Universale
Icon-Small.png - Risultati della ricerca e l’icona delle impostazioni su iPhone e iPod touch
Icon-Small-50.png – Risultati della ricerca in applicazioni iPad

Dalla versione 3.2 se si specifica un-Icon small.png o file Icon-Small-50.png nel bundle, il sistema preferisce quei file icona rispetto a quelle nella chiave CFBundleIconFiles e il sistema operativo preferisce il defination icon dell’applicazione nella chiave CFBundleIconFiles più di qualunque altra.

Artwork Guitar Tuner i3F HD per iPad

Su Apple Store la nuova applicazione i3Factory nativa per iPad:  Guitar Tuner i3F HD per iPad

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=402070824&mt=8

Welcome to i3Factory.com Music World.
Guitar Tuner i3F in Version HD for Ipad.

Based on Fourier Algoritm is one of the best Tuner in the market, probably the most simple to use.

This Tuner have an oscilloscope and you can see the wave sound on the iPad.

With this very easy to use guitar tuner you can tune your personal guitar and bass.

The device listen the strings of your guitar helping your finger to tune the six guitar strings.

A very sofisticaded algorithm is in the core of owr usefull tool.
Have Fun!

Artwork Metronome i3f HD for iPad

Pubblicato in Apple Store la nuova applicazione i3Factory nativa per iPad: Il metronomo i3F HD

http://itunes.apple.com/us/app/metronome-i3f-hd/id402357583?mt=8

Welcome to the i3Factory Music World!
The HD Metronome has all standard and extended metronome tempos from 5 to 251 BPM! Just press Start!

The fist one with Tap Tempo option and Classic, Bongos and Bell sounds.
A setup is included for 1/2 , 2/3, 1/4, 3/4, 4/4, 2/6, 4/6

Info:
A metronome is a tool that produces a steady pulse (or beat) to help musicians play rhythms accurately. The pulses are measured in beats-per-minute (BPM). Most metronomes are capable of playing beats from 35 to 250 BPM. Common uses of the metronome are helping you to maintain an established tempo while practicing, and learning difficult passages.

The first step in metronome use is to understand time signatures. Time signatures are found at the beginning of a musical piece, after the clef and the key signature. Time signatures (also called meter signatures) consist of two numbers. The top number indicates the number of beats in a measure, while the bottom number corresponds to the value of the beat. Most often, you will see 2, 3, 4 or 6 beats per measure. Beats are commonly half notes (the bottom number of the meter signature is “2”) or quarter notes (“4”) (the bottom number of the meter signature is “4”).

Con l’introduzione dell’iPad gli sviluppatori si son trovati di fronte al dilemma se sviluppare applicazioni separate per iPhone e iPad oppure rilasciare un’unica app “universale” valida per entrambi i dispositivi.

Indipendentemente da eventuali scelte di marketing, che potrebbero far propendere verso applicazioni separata col vantaggio di poterne vendere due al posto di una, in questo articolo spiegheremo quali sono i vantaggi che si possono ottenere dallo sviluppo di una singola applicazione e alcuni utili suggerimenti su come impostare il lavoro.

Prima di addentrarci nelle caratteristiche di un’applicazione universale, e’ bene rammentare come avviene il caricamento e il lancio di un’applicazione in iOS.

CARICAMENTO E LANCIO DELL’APPLICAZIONE

La figura in basso, tratta come sempre dall’eccellente documentazione Apple fornita col gratuitamente col pacchetto XCode dal sito http://developer.apple.com, mostra qual e’ la sequenza degli eventi che si scatena dal momento in cui l’utente tocca sull’icona dell’applicazione che intende lanciare.

Essendo Objective-C nient’altro che un’estensione del C, un’applicazione parte con l’esecuzione della funzione main(). Utilizzando i template forniti con XCode, la funzione main() contiene il seguente codice, che e’ bene non modificare mai a meno di esigenze molto particolari:

Quel che fa questo codice e’ essenzialmente lanciare la funzione UIApplicationMain() il cui compito consiste innanzitutto nell’instanziare l’oggetto UIApplication, il cui scopo e’ quello di creare e eseguire il motore delle applicazioni iOS, il cosiddetto Event Loop. Non entreremo in quest’articolo nella descrizione dell’Event Loop (lo faremo prossimamente) ma per ora basti sapere che ogni qualvolta l’utente tocca lo schermo del suo dispositivo, il tocco viene catturato dall’Event Loop e smistato alla porzione di codice che si occupera’ di gestirlo.

Dato che l’oggetto UIApplication e’ unico e gestito dal sistema operativo, come facciamo a inserire il nostro codice all’interno di questo meccanismo di start-up dell’applicazione? La risposta e’: tramite l’”application delegate”. Uno dei compiti della funzione UIApplicationMain e’ infatti quello di instanziare il nostro Application Delegate e, durante la fase di lancio, fornirgli il controllo tramite la ben nota chiamata al metodo “application:didFinishLaunchingWithOptions:”. In questo metodo noi inseriremo la nostra logica iniziale, creeremo i nostri view controller e comunque ci consentira’ di far partire la nostra app.

Riassumendo: l’utente tocca l’icona dell’applicazione, il sistema operativo carica l’app e chiama la funzione “main()”, la funzione main chiama la funzione UIApplicationMain, quest’ultima instanzia l’oggetto (unico) UIApplication, il quale avvia l’Event Loop e chiama il suo “delegate” affinche’ quest’ultimo esegua il codice di inizializzazione proprio dell’applicazione.

Quel che resta da definire a questo punto e’: come fa UIApplication a conoscere il suo “delegate”? la risposta e’: questa informazione viene fornita tramite il file Info.plist con la chiave “NSMainNibFile” (indicata in XCode come “Main nib file base name”). Questo nib file, che in genere nei template di XCode si chiama MainWindow.xib, conterra’ un oggetto AppDelegate che sara’ collegato all’outlet “delegate” del File’s Owner, che non e’ nient’altro che il nostro oggetto UIApplication.

Quindi UIApplicationMain svolgera’ oltre al compito sostanziale di instanziare UIApplication anche quello di caricare l’NSMainNibFile e collegare l’instanza di UIApplication (nota come “sharedApplication”) all’AppDelegate.

Questa lunga spiegazione e’ necessaria per capire come far partire un’app universale. In genere i template di XCode per le applicazioni univesali forniscono due diversi NSMainNibFile, uno denominato NSMainNibFile – e usato di default – un altro denominato NSMainNibFile~ipad che, se definito, verra’ caricato nel caso l’app venisse lanciata da un’iPad.

In genere le due chiavi devono puntare a due finestre differenti, dato che sono differenti le dimensioni degli schermi, e il programmatore potrebbe scegliere di instanziare i due UIViewController iniziali, che potrebbero essere profondamente diversi, gia’ nel nib file iniziale. Quel che pero’ fa il template di XCode e’ collegare all’UIApplication delegate outlet due diverse istanze di AppDelegate, denominate rispettivamente AppDelegate_iPhone e AppDelegate_iPad.

Da questo momento in poi le due app prenderanno strade sostanzialmente differenti e sara’ compito del programmatore gestire i due “rami” di codice e cercare di accomunare tra loro quelle porzioni di codice che sono indipendenti dall’interfaccia grafica.

Compito di questo articolo e’ indicare alcune regole pratiche che faciliteranno il compito del programmatore cercando di accomunare il piu’ possibile le porzioni di codice.

APPLICATION DELEGATE UNIFICATO

Il primo approccio rivolto all’unificazione del codice e’ quello di definire un unico application delegate. Come detto in precedenza il template “Universal app” di XCode tende a creare due app delegate praticamente identici, uno per iPad e l’altro per iPhone, e referenziarli in due MainWindow.xib differenti, che e’ bene rimangano tali dato che in questa sede si potrebbero gia’ cominciare a definire le peculiarita’ grafice delle due app (se non altro, le due Window hanno gia’ dimensioni differenti!).

Pertanto il nostro approccio sara’ cancellare uno dei due delegate dal nostro codice (ad esempio AppDelegate_iPad) e sostituire nel MainWindow ad esso associato (nell’esempio: MainWindow_iPad) l’oggetto corrispondente.
In questa maniera l’eventuale caricamento di dati essenziali all’applicazione e il codice richiesto dal protocollo di UIApplicationDelegate sara’ comune nei due casi.

ORGANIZZAZIONE DEL PROGETTO

Per mantenere un certo ordine nell’organizzazione del progetto, e’ buona norma definire tre gruppi all’interno di XCode, denominati Shared, iPhone  e iPad, rispettivamente utilizzati per i file comuni, specifici all’iPhone e specifici all’iPad. Nel nostro caso inseriremo l’AppDelegate comune nel gruppo Shared.

FORCHETTE NEL CODICE

E’ ovvio che tanto piu’ si condivideranno delle porzioni di codice, tanto piu’ sara’ necessario discriminare all’interno di tale codice se si sta eseguendo l’app in un iPad o in un iPhone/iPod Touch, dato che sarebbe presuntuoso pensare di poter scrivere del codice sempre indipendente dal device, specialmente nei View Controller e nelle View.

A tal fine e’ bene aggiungere nel proprio file “Prefix.pch” la definizione seguente:

La funzione isPad(), una volta chiamata, restituira’ YES se l’app viene lanciata in un iPad, NO altrimenti. Questo codice si basa sulla funzione “userInterfaceIdiom” definita nella classe UIDevice. Se questo metodo fornisce in risposta la costante UIUserInterfaceIdiomPad allora siamo in un iPad, altrimenti no. Pero’, dato che questa funzione e’ stata introdotta solamente con la versione 3.2 di iOS, ossia quella che ha introdotto l’iPad (in questo possiamo dire che in Apple non sono stati molto lungimiranti!), per poter garantire la compatibilita’ con versioni precedenti di iOS dobbiamo controllare che questa funzione esista e possa essere chiamata (se non lo facessimo, la nostra app andrebbe miseramente in crash). E’ ovvio che una risposta negativa a questo check implicherebbe una versione di iOS precedente alla 3.2 e quindi il dispositivo non puo’ essere un iPad.

Quindi, tutte le volte che dovremo gestire una qualche eccezione tra i due dispositivi, ci sara’ sufficiente creare una condizione if…else… su isPad() e gestire il comportamento dell’app nei due casi.

IL PATTERN MVC

La programmazione in iOS si basa profondamente sul paradigma Model-View-Controller (MVC).
Questo pattern architetturale prevede che un software sia articolato nelle tre unita’ fondamentali: Modello, Vista e Controllore. Il modello si occupa della gestione dei dati di un’applicazione, le viste gestiscono l’interfaccia utente e la rappresentazione grafica mentre il controller si occupa della logica dell’applicazione mettendo in comunicazione il modello con la vista.

E’ evidente che il Modello prescindera’ sempre dalla natura del dispositivo, in particolare nel nostro caso saremo facilitati dal fatto che sia l’iPhone che l’iPad condividono esattamente le stesse classi e le stesse funzioni per tutto cio’ che riguarda la gestione dei dati (le cosiddette “foundation classes”, ma anche il file system e i vari media framework o l’accesso ai sensori). Pertanto massima cura dovra’ essere data al progetto dell’app affinche’ i moduli comuni non direttamente legati alla rappresentazione grafica siano spostati all’interno del modello.

Talvolta si tende a integrare alcune funzionalita’ all’interno dei View Controller, questo per semplicita’ nella scrittura del codice: dato che il View Controller gestiste il flusso dell’applicazione perche’ non inserire certe funzionalita’, quali ad esempio quelle di networking, all’interno del View Controller? sebbene questo approccio continui ad essere sempre valido, occorre considerare il fatto che in taluni casi non e’ conveniente condividere tra i due dispositivi lo stesso View Controller, e in tal caso tali funzionalita’ andrebbero replicate con evidenti problemi di manutenzione del codice. Per cui si consiglia di spostare quanto piu’ possibile queste operazioni all’interno dei modelli, e sfruttare i meccanismi di comunicazione di Objective-C (protocolli, KVO, notifiche) per far colloquiare i modelli coi controller.

VISTE CONDIVISE

Condividere le viste, ossia le varie UIView e tutte le loro sottoclassi, e’ compito in genere abbastanza arduo. In genere si sconsiglia di costruire una vista per iPad partendo da quella per iPhone e “ingigantendola” di conseguenza: l’effetto e’ abbastanza sgradevole e comunque non renderebbe merito del magnifico display dell’iPad.

Quindi il consiglio che ci sentiamo di dare e’ quello di cercare di studiare l’interfaccia grafica tenendo conto delle caratteristiche dei due dispositivi e solamente in seguito pensare se e come unificare parti di essa. Vi saranno sicuramente dei casi in cui le viste possono essere condivise: si pensi ad esempio alle piccole miniature che si vedono in fondo al lettore di PDF integrato nell’app iBooks. Esse possono essere costruite (diciamo “possono” poiche’ non sappiamo se i progettisti di Apple abbiano seguito lo stesso approccio) usando un’unica vista che calcolando le dimensioni dello schermo sara’ in grado di conoscere il numero di miniature che potranno essere posizionate. Inoltre le stesse dimensioni delle miniature, dato che saranno diverse fra i due schermi, potranno essere discriminate grazie all’uso della nostra funzione isPad(). Quindi senza ombra di dubbio un’eventuale classe “ThumbnailsView” potra’ essere inserita nel gruppo Shared del nostro progetto.

VIEW CONTROLLER

Non c’e’ ombra di dubbio che i View Controller, rappresentando la logica dell’applicazione e quindi la parte piu’ complessa, richiedono un’attenta valutazione prima di effettuare la scelta della condivisione o no. Infatti tenere separati i View Controller tra i due rami del progetto (iPhone e iPad) puo’ implicare una quantita’ eccessiva di codice ridondante. Ma allo stesso tempo un’eccessiva unificazione, soprattutto per quei View Controller che piloteranno viste molto differenti per i due schermi, potrebbe comportare a una tale ramificazione intra-codice e un numero cosi’ grande di biforcazioni da rendere il codice difficilmente leggibile.

Si tenga conto inoltre che certi elementi molto comuni nell’iPhone, come gli UITabController, sono raramente utilizzati nell’iPad, e quindi questo gia’ in partenza implica una netta separazione delle due porzioni di codice. Chiaramente gli UITabController istanziano a loro volta dei UIViewController che potrebbero essere unificati tra loro. Si pensi per esempio al caso di una mappa: i percorsi per arrivare alla mappa possono essere molto diversi fra due dispositivi, ma alla fine la vista, a parte alcune differenze, sara’ sostanzialmente la stessa: una mappa a tutto schermo con una toolbar o navigation bar per accedere ad altre funzioni.

Il prossimo paragrafo, sui Popover, fornira’ una soluzione molto comoda per unificare il maggior numero di View Controller possibile.

I POPOVER

L’iPad e’ dotato di un insieme di view controller unici, quali gli UISplitViewController e gli UIPopoverController.

Questi ultimi sono quei “fumetti” che appaiono di tanto in tanto nell’interfaccia delle app per iPad e che consentono di accedere ad alcune funzionalita’ extra dell’applicazione. Apple suggerisce nelle sue Human Interface Guidelines (HIG) di utilizzare questo controller tutte le volte che si vuole accedere ad alcuni sezioni dell’app senza distogliere l’utente dalla pagina principale. Questo approccio e’ molto diverso dall’iPhone, in cui il progresso all’interno di un’applicazione avviene tipicamente tramite le “sliding windows”, ossia le finestre scorrevoli da destra verso sinistra e gestite da un UINavigationController. A ragione, i redattori dell’HIG ritengono che far scorrere tali finestre in un’app per iPad non sarebbe il massimo, poiche’ date le loro dimensioni il tutto  risulterebbe essere oneroso per il processore (rendering grafico) e visivamente pesante. In questo la soluzione suggerita e’: aprire un popover all’interno della finestra e inserire il view controller al suo interno. E’ vero che nel tempo gli sviluppatori si sono sbizzarriti nell’ottenere soluzioni alternative a questo approccio, ad esempio con viste scorrevoli parzialmente, ma l’approccio dei popover risulta essere il piu’ immediato, abbastanza elegante e comunque perfettamente in linea con le HIG.

I popover possono essere sfruttati per unificare i view controller. Si consideri ad esempio il caso di una funzione “Impostazioni” che si vuole introdurre nell’app. Ovviamente date le differenti dimensioni dello schermo, per l’iPhone si potrebbe impostare una classica vista 320×480 contenente una tabella e mostrata per scorrimento. Nell’iPad occorrerebbe costruire una macro vista 768×1024 da mostrare in qualche maniera e magari difficile da riempire (e quindi da rendere esteticamente gradevole) soprattutto se il numero di impostazioni risultasse ridotto. In questo caso la soluzione migliore sarebbe creare un popover e inserire al suo interno una finestra di dimensioni, guarda caso, 320×480.

Pertanto avremmo lo stesso ImpostazioniViewController, studiato per un iPhone, e le differenze fra i due device sarebbero:

1. chiamata via NavigationController (“push”) per iPhone, via PopoverController per iPad
2. presenza della navigation bar con “Back” button per iPhone, presenza opzionale della navigation bar ma senza “Back” button

LE MODAL VIEW

Le modal view sono tradizionalmente utilizzate nell’iPhone per interrompere il flusso dell’applicazione e porre l’utente di fronte ad un’attivita’ che richiede la sua immediata e unica attenzione. Con l’iPad tali viste sono state estese per consentire un approccio diverso all’interazione con l’utente, ed e’ grazie a tale scelta che possiamo pensare ad un’ulteriore forma di condivisione del codice.

La differenza sostanziale e’ che mentre nell’iPhone la modal view appare sempre e soltanto dal basso verso l’alto a riempire tutto lo schermo, nell’iPad e’ possibile scegliere tra diversi approcci. Nel nostro caso l’approccio piu’ confacente alla condivisione e’ quello di mostrare la vista modale in modalita’ “Form Sheet”, con la quale la modal view appare al centro dello schermo, con dimensioni ridotte, con un effetto di “dimming” nelle aree lasciate scoperte.

In questo caso la nostra vista comune non avra’ le stesse dimensioni (nell’iPad e’ comunque piu’ grande) per cui dovremo gestirla affinche’ il ridimensionamento risulti adeguato. Ad ogni modo queste eccezioni possono essere facilmente gestite nel nostro codice tramite l’uso della funzione isPad() senza dover necessariamente ricorrere all’uso di View Controller separati.

CONCLUSIONI

Senza dubbio scrivere una buona app universale rapprsenta sempre una sfida. Ma se non altro i vantaggi che si ottengono in riutilizzabilita’ e manutenzione valgono lo sforzo. Inoltre l’impegno in piu’ richiesto per la definizione di un’architettura che favorisca la condivisione del codice verra’ premiato da un software che risultera’ essere piu’ ordinato, leggibile e estendibile.

Chiaramente questo obiettivo puo’ non essere facilmente raggiungibile, e invitiamo gli sviluppatori a non cimentarsi in imprese disperate per rendere universali tutte le app, soprattutto in quei casi in cui le due interfacce sono profondamente diverse, oppure il contributo dovuto ai modelli e’ insignificante oppure si proviene da un’app iPhone gia’ esistente e progettata con tutt’altri criteri.

Prototipo interattivo creato con keynotopia

Vi segnalo un’interessante pacchetto che vi permetterà di creare Prototipi Interattivi per iPhone, iPad, Android e Web. Un vero e proprio prototipo puo’ essere creato in meno di 30 minuti, il tutto utilizzando  Apple Keynote unitamente ai templates Keynotopia per l’user interface.

I Pacchetti contengono  piu’ di  250 componenti per l’user interface (interfaccia utente), fatti a mano in  Apple Keynote. Con Keynote e Keynotopia potete facilmente creare dei files Pdf interattivi che poi istallati sul device vi permetteranno di fare presentazioni di funzionali direttamente dal device.

Clicca qui per visitare Keynotopia.

Nota:

Keynote e’ un un’applicazione Apple economica e facilmente utilizzabile cheap e che non richiede speciali esperienze o abilità per disegnare un’interfaccia utente e creare link interattivi.

Il Video tutorial:

Prototyping an interactive iPhone app in 10 minutes

iOS Dev Center

Apple, con lo scopo di chiarire le idee ai developers e ascoltarne le richieste, ha pubblicato delle linee guida. (Engadget ha pubblicato in PDF tutte le linee guida, che trovate seguendo questo link).
Cupertino ha chiarito il procedimento di verifica delle applicazioni per App Store attraverso un breve comunicato stampa che annuncia i cambiamenti alla licenza iOS Developer Program.

App Store è ad oggi il più grande negozio online di applicazioni per piattaforme mobili (iPhone, iPad, iPod Touch), e conta piu’ di 250.000 titoli in catalogo e 6 miliardi e mezzo di download dichiarati dall’azienda

Le modifiche sostanziali alla licenza d’uso dell’SDK riguardano alcuni punti che al momento sono protetti dall’accordo di riservatezza NDA, e ammorbidiscono alcune limitazioni che riguardano gli strumenti di sviluppo di terze parti che permettevano di costruire applicazioni native per iPhone con tecnologie Flash, Silverlight, Java, e simili.

Fino alla pubblicazione di questo documento, gli sviluppatori iOS potevano lavorare esclusivamente sugli strumenti di programmazione approvati da Apple. Non esisteva alcuna possibilità di scrivere codice con il proprio ambiente preferito e poi renderlo compatibile con iPhone e iPad.
Da oggi gli sviluppatori potranno usare anche altri gli strumenti.

Molto interessante l’introduzione del Documento :

Pochè iPad non supporta la tecnologia Flash non abbiamo pieno accesso al contenuto video di alcuni siti come ad esempio il  gettonatisiimo Megavideo.

Esiste comunque la possibilità di visionare sull’iPad , come sull’iPhone e iPod Touch,  numerosi Video, Film e serie Tv . La visione è possibile acquisendo alcune App molto valide direttamente su App Store:

1) Air Video

Air Video è una notevole applicazione presente su App Store in versione gratuita (Air Video Free) o a pagamento.

Questa app permette leggere i file presenti sul  Mac o PC (anche Dvix o Xvid) di vedere filmati in streaming  senza doverli trasferire sull’iPad . Utilizza le connessioni in rete wifi o internet.La codifica puo’ essere effettuata in tempo reale.
La qualità di riproduzione è ottima.

2) yxPlayer

Yxplayer è un interessante applicazione che permette lo streaming di contenuti sul nostro iPad senza dover per forza convertire i DviX in mp4.

3) Justin.tv

Questa applicazione permette di vedere la televisione in streaming. L’app e’ gratuita ed è disponibile su App Store.
Permette di vedere più di 1800 canali!

Qwiboo, la società che ha sviluppato il gioco Aqua Globs HD, denuncia di aver verificato che la sua applicazione è stata piratata da almeno il 50% degli utenti che inviano i loro punteggi.

Forse a causa della semplicità degli strumenti che permettono il cosidetto ” jailbreak” o “sbloccaggio dell’Ipad” che hanno avuto un ruolo fondamentale nell’aumento della pirateria,  alcuni sviluppatori sono  preoccupati.

Secondo lo sviluppatore Vladimir Roth, nonostante uno scenario non proprio rassicurante, non c’è da preoccuparsi della pirateria per il momento. Coloro che scaricano le .ipa dal Web, afferma, non le acquisterebbero comunque attraverso i canali ufficiali. Resta comunque un fenomeno sconcertante, anche e soprattutto se consideriamo che Aqua Globs HD costa appena 1,59€ e viene anche distribuito in una variante gratuita.

Ben diverso il discorso per il creatore di Rally Master Pro 3D il quale meno di un anno fa, sui forum di Touch Arcade, aveva dichiarato su iPhone un  tasso di pirateria del 95%. Al tempo sembra che il fenomeno era causato da 2 motivi principali, il costo  di 7 Dollari evidentemente alto, e l’assenza di una versione gratuita di prova.