• English

1.0 La visualizzazione di una pagina web con l’iphone (viewport):
Quando, utilizzando safari, l’iPhone carica una pagina Web esegue uno scaling, viene ridotta la risoluzione della pagina per farla visualizzare sul display.
Il funzionamento dello scaling avviene poiche’ l’iPhone controlla la larghezza della pagina ad una risoluzione, considerata la piu’ comune, di 980 pixel per poi scalarla, in un secondo passaggio, alla risoluzione di 320 pixel (se il telefono e’ in posizione verticale) o 480 pixel (se e’ in orizzontale).Pertanto per quei siti la cui risoluzione e’ meno di 980 pixel (in larghezza) verra’ mostrato uno spazio bianco ai lati che rendera’ meno leggibile il testo pubblicato.

Per evitare problemi di visualizzazione e’ necessario aggiungere un “meta tag” che imposti la viewport dell’iPhone alla larghezza della pagina.
Nel caso di una pagina web con una larghezza di 700 pixel quindi il nostro viewport dovra’ essere di 700 pixel:

< meta name=”viewport” content=”width=700″ />

Sara’ anche possibile bloccare il minimo (minimum-scale), il massimo (maximum-scale) zoom possibile sulla pagina e settare uno zoom¬† predefinito iniziale (initial-scale).

< meta name=”viewport” content=”initial-scale=0.6, minimum-scale=0.4, maximum-scale=0.8″ />

I valori che impostano lo scaling vanno calcolati in relazione alla dimensione in pixel della pagina che altrimenti e’ preimpostata a 980 pixel: 0.6 corrisponde cosi’ a 588 (588 = 980 x 0.6).

2.0 Il doppio Tap , come funziona l’auto zoom (gesture)
Come e’ noto, si puo’ eseguire uno zoom toccando velocemente due volte sull’elemento che si vuole ingrandire (doppio-tap).

Il disegnatore del sito deve progettare un design che renda questa azione piu’ efficace possibile. Quando si esegue un doppio-tap su un oggetto, l’iPhone puo’ eseguire due azioni: se l’elemento in questione e’ un’immagine questa verra’ automaticamente ingrandita e centrata nello schermo; se invece si fa il doppio Tap su una porzione di testo l’iphone verifichera’ in quale blocco e’ inclusa, quindi espandera’ e centrera’ il blocco a tutto schermo.

Tre regole importanti:
1) Strutturare sempre la pagina in diversi blocchi di contenuto in modo da consentire un piu’ facile ingrandimento della porzione che interessa al’utente.
2) Evitare di disegnare un layout con delle colonne troppo larghe.
3) Assolutamente da evitare un layout senza colonne.

In questi ultimi casi se si esegue uno doppio-tap sulla pagina web l’iPhone non riuscira’ ad impostare la grandezza del blocco, non eseguira’ lo zoom e lascera’ il contenuto non del tutto leggibile poiche’ un layout ad una colonna rende impossibile eseguire uno zoom sui contenuti della pagina.

Android SDK

Jeff LaMarche e’ un programmatore e autore attualmente impegnato nello sviluppo di applicazioni per iPhone e Mac, nonche’ autore di un seguitissimo (e autorevole) blog e del libro “Beginning iPhone Development”.
Riportiamo in questa pagina la traduzione dell’articolo Android SDK from an iPhone Developer’s Perspective. Ringraziamo Jeff per averci concesso l’autorizzazione a riportare la traduzione del testo integrale.
Riconosciamo l’onesta’ intellettuale di Jeff nel sostenere che le sue opinioni sono polarizzate da un amore sviscerato per l’ambiente di sviluppo per iPhone. Nonostante cio’ condividiamo in gran parte le sue affermazioni e siamo perfettamente d’accordo con lui nel ritenere l’SDK per Android meritevole di attenzione se non altro per le sue enormi potenzialita’ di sviluppo.
Vi lascio adesso alla lettura del testo, davvero istruttivo.

Ho gia’ riportato la mia opinione sul dispositivo Nexus One (leggi l’articolo originale oppure la nostra traduzione delle parti salienti). E’ arrivato il momento di veder le cose dal punto di vista della programmazione. E’ arrivata quindi l’ora per una mia opinione sull’ambiente di sviluppo (SDK) di Android.

Permettemi di cominciare dicendo un’ovvieta’, dato che conosco alcune persone che dimenticheranno quanto segue: sto per formulare la mia opinione personale e assolutamente soggettiva riguardo l’SDK di Android. Questa opinione puo’ differire dalla vostra, e questo va bene. Veramente. E’ proprio cosi’. La terra continuera’ a girare anche se voi pensate che io mi stia sbagliando al 100%.

Permettetemi anche di porre in evidenza i miei punti di vista: io non amo Java. Ho usato Java per molto piu’ tempo di Objective-C e ho tutto sommato fatturato molte piu’ ore e guadagnato molto piu’ denaro usando Java piuttosto che Objective-C, ma dal momento in cui ho letto i volumi sul linguaggio e la programmazione in Objective-C, negli anni 1997 e 1998, ho avuto l’impressione che Java stesse intraprendendo la direzione sbagliata. Ogni passo nell’evoluzione di Java ha rinforzato questa sensazione. L’approccio usato in NextSTEP (il quale si e’ evoluto in Cocoa e quindi Cocoa Touch) avvalora il mio pensiero. Io credo in questo approccio. Sia la metodologia che il linguaggio mi piacciono cosi’ tanto, infatti, che ho preferito tagliare i miei guadagni in maniera sostanziosa pur di poter lavorarci sopra a tempo pieno. Cosicche’, basandovi su questo, dovreste capire che Android parte gia’ svantaggiato dal mio punto di vista.

Ho cercato di rimandare il piu’ possibile la pubblicazione di questo articolo per evitare di cadere nell’errore commesso da molte persone con l’SDK di iPhone e Xcode, che e’ quello di scrivere un articolo relativamente al fatto che non funziona nella maniera che desidero io e che quindi non va bene. Dato che ho una notevole esperienza con il linguaggio e l’ambiente di sviluppo (IDE) e dato che ho gia’ alcune settimane alle spalle con l’SDK di Android, posso tranquillamente fornire un’opinione che non e’ esclusivamente una mia protesta per il fatto che non e’ quello che io so fare e che mi piace fare, anche se ovviamente il fatto che faccia molte cose in una maniera che a me non piace certamente influisce sulla mia opinione.

Quindi, dopo aver speso diverse settimane con Android, cosa ne penso?

Sicuramente non e’ male. E’ decisamente un SDK potente. Ha quasi tutto quel che ti serve e, essendo basato su Java, esiste una quantita’ notevole di codice e di librerie su cui fare affidamento. Il progetto dell’SDK e’ un tantino inconsistente (tutto sommato come l’esperienza del sistema operativo). Vi sono alcune parti che ricordano l’iPhone SDK molto da vicino, per quanto possibile date le differenze tra i linguaggi, e vi sono altre parti del tutto aliene.

Vi e’ sicuramente una mancanza di consistenza nella progettazione dell’SDK se confrontata con quella di iPhone. Molte parti dell’SDK sembrano scritte da gruppi completamente differenti che non necessariamente hanno comunicato o si son messi d’accordo sul modo migliore di far le cose. Vi sono alcune inconsistenze anche nell’SDK di iPhone, ma ci sono comunque dei principi guida e dei design pattern cosi’ dominanti nell’iPhone SDK che non hanno una controparte in Android. L’effetto finale e’ un Android un po’ caotico e disunito, ma comunque ancora valido.

Android ha anche un compito difficile da assolvere: esso e’ stato progettato per girare su una vasta gamma di dispositivi e si puo’ sviluppare su molti sistemi operativi e molte macchine. Google ha fatto un lavoro davvero ammirevole date le difficolta’ che occorre affrontare quando non hai opzioni hardware limitate e sulle quali hai il pieno controllo.

Uno dei modi in cui e’ stato affrontato il problema e’ stato nella realizzazione dell’emulatore. E’ possibile configurare l’emulatore per simulare differenti dispositivi con differenti caratteristiche e dimensioni dello schermo, permettendo quindi di impostare diversi dispositivi virtuali. Cio’ significa che puoi testare la tua applicazione su un “Nexus One virtuale”, quindi passare a un nuovo dispositivo virtuale a testarla su un “Motorola Droid virtuale”. Lavorare con l’emulatore e’ facile, ma non tanto quanto come il simulatore di iPhone. Ad esempio, quando lanci un’applicazione sull’emulatore, esso non diventa l’applicazione corrente e l’emulatore non si sblocca automaticamente. Ad ogni modo l’esperienza e’ accettabile, specialmente se si tengono conto delle sfide aggiuntive dovute al fatto che si tratta di una piattaforma aperta.

La stessa applicazione eseguita sul dispositivo ha girato molto bene. Sorprendentemente bene, in effetti. Ancora, l’esperienza non e’ agevole come quella di lanciare un’app sull’iPhone. Ci si imbatte in piccoli inconvenienti, ad esempio quando esegui un programma sul dispositivo il telefono non si sveglia o si sblocca cosi’ come fa l’iPhone. Ma alla fin fine esso lavora piuttosto bene e senza il peso di dover fornire profili di distribuzione o certificati di sviluppo.

Ho scoperto che il debugging su Android non e’ affatto agevole, ma questo magari e’ dovuto al fatto che conosco GDB molto meglio di JDB/ADB (Android Debugging Bridge) e che conosco le potenzialita’ di debugging di Xcode molto meglio di quelle di Eclipse.

Anche se non e’ necessario usare Eclipse per programmare per Android, di fatto esso e’ la scelta di default. O almeno e’ la scelta che presentera’ meno ostacoli al momento di effettuare il setup dell’ambiente. Eclipse e’ molto bene integrato con Android e i suoi tool. L’esecuzione e il debugging sul device o sull’emulatore sono un bijoux e vi sono addirittura dei tool per forzare dei dati all’interno del dispositivo virtuale in esecuzione, come la posizione geografica.

Ma odio Eclipse con tutto il cuore. Esso non si sposa minimamente col mio modo di lavorare. Considero la sua interfaccia utente imperscrutabile e le sue prestazioni sul Mac non proprio eccellenti. Se dovessi sviluppare molto su Android investirei molto probabilmente su qualche IDE alternativo con una buona integrazione di Android, o al limite lavorerei con TextMate e linea di comando.

Mi sento come se potessi scrivere ogni applicazione di cui ho bisogno con Android. Renderla bella e’ una sfida e ho speso piu’ tempo leggendo la documentazione di quanto abbia mai fatto per l’iPhone. Conoscere ogni dettaglio dell’SDK di Android non necessariamente fornisce dei suggerimenti su come puo’ lavorare un’altra parte e anche se si e’ degli esperti sviluppatori Java non si ottiene un vantaggio aggiuntivo a tal fine.

Disegnare le viste con Android e’ una delle aree su cui inequivocabilmente affermare trattarsi di un’esperienza peggiore che nell’iPhone, su ogni singolo aspetto. L’approccio utilizzato da Android per creare le viste non ha un qualsiasi valore che possa riscattarlo. Disegnare l’interfaccia per iPhone e’ facile, divertente e intuitivo. Su Android, e’ un casino. Sembra di lavorare con la stirpe maledetta di GridBagLayout e XML. E’ assolutamente orribile. Ma dopotutto Java non ha mai lavorato bene con le UI e la cosa non e’ mai stata particolarmente divertente, cosicche’ posso dire di non essere sopreso, anche se attualmente esso ha superato le mie aspettative nell’essere anche peggiore di quanto pensassi fosse umanamente possibile. L’intero processo e’ contro-intuitivo e richiede un sacco di tempo, e tutto questo per avere qualcosa che funzioni e basta. Il tutto e’ ancora piu’ dispendioso e penoso per ottenere qualcosa che non faccia schifo.

Ma questa e’ l’unica area finora che ho trovato orribile in Android. Complessivamente e’ un SDK abbastanza buono. Sicuramente non e’ divertente (almeno per me). Manca totalmente di ogni aspetto divertente. L’SDK non si toglie mai di mezzo quando voglio creare. E’ un continuo ostacolo. Non grande o insormontabile, ma sempre presente. L’SDK per iPhone, d’altro canto, e’ davvero divertente. Una volta capito l’aspetto generale di come fare le cose, e’ diventato facile per me dimenticare l’SDK e occuparmi semplicemente di creare le mie app.

Ho cercato di capire esattamente dov’e’ la differenza; che cos’e’ che rende una cosa divertente e l’altra no, e penso di averlo capito. L’SDK di Android in genere fallisce nel seguire un principio che Apple segue dannatamente bene, e cioe’:
Rendi sempre facili le cose che fai.
Come risultato, su Android le cose che tu non fai quasi mai sembrano essere ugualmente difficili e dispendiose quanto quelle che fai di continuo.

Un esempio: data la dimensione dello schermo relativamente piccola, una delle cose che fai continuamente nelle applicazioni per telefonini e’ muoverti tra le varie schermate. Nell’iPhone effettuiamo questo nella seguente maniera:

1. Creare un’istanza della classe view controller per la vista che vogliamo mostrare
2. Impostarne le proprieta’ per fornire i dati di cui ha bisogno per funzionare
3. Mostrare la vista aggiungendo il view controller alla gerarchia delle viste, inserendola in una pila di navigation controller o presentandola in maniera modale, il tutto di solito in una sola linea di codice

Invece in Android questo non e’ cosi’ immediato:

1. Aggiungere un riferimento all’Activity (l’analogo di UIViewController, anche se non esattamente la stessa cosa) nell’Android Manifest della tua applicazione per consentire ad Android di sapere quale classe puo’ essere lanciata
2. Creare un Intent basato sulla classe dell’Activity
3. Assicurarsi che ogni dato che si vuol passare all’altra Activity sia serializzabile oppure sia un tipo di dato di base
4. Iniettare l’informazione che si vuol passare all’Activity come un “extra” all’Intent, serializzando gli oggetti
5. Far partire l’Activity
6. Nella classe dell’Activity riscrivere onActivityResult e recuperare gli extra di cui si ha bisogno, de-serializzando quelli che non sono tipi di dati nativi.
7. Nell’Activity scavalcare il metodo onCreate() per specificare la vista che deve essere usata

In realta’ le due liste precedenti non rendono giustizia alla differenza di lavoro effettivamente impiegato. Questo compito diventa una seconda natura per lo sviluppatore iPhone poiche’ e’ intuitivo, fortunatamente. Queste sono le classiche tre o quattro linee di codice che inizi a scrivere senza neanche pensarci su. Su Android la quantita’ di cose che devi fare per ottenere lo stesso risultato e’ sparpagliata attraverso i tuoi file di progetto e il compito difficilmente puo’ diventare una seconda natura o quantomeno facile.

Ora, le persone che amano Android diranno che gli Intent sono potenti – molto piu’ che nell’approccio di iPhone – dato che gli Intent possono essere utlizzati per consentire ad altri programmi e al sistema operativo di avvantaggiarsi delle funzionalita’ del tuo programma.

In effetti gli Intent sono potenti. Il problema e’ che essi forniscono un potere di cui non hai bisogno nella maggior parte dei casi e delle applicazioni. E fanno tutto questo al costo di rendere qualcosa di cui hai bisogno tutto il tempo piu’ complicata e complessa di quel che dovrebbe essere (e quindi piu’ probabilmente fonte di bug). E’ una complessita’ indiscriminata, che non e’ una virtu’. Come OpenDoc e CyberDog possono confermare, dei concetti apparentemente buoni non sempre si manifestano in buone implementazioni o esperienze utente, e l’iPhone non ha mai sofferto molto per la sua mancanza di una funzionalita’ di condivisione tra le applicazioni.

A mio avviso, gran parte dell’SDK di Android (soprattutto le parti che non sono state pesantemente influenzate dall’SDK per iPhone) sembrano essere sovra-ingegnerizzate. Molta della complessita’ delle caratteristiche di Android sembra sia dovuta a un intento di complessita’. Quindici anni fa avrei amato tutto cio’ dato che ero nella mia fase di programmatore macho super ingegnerizzato¹ e tutta quella complessita’ e la potenza teorica ad essa associata mi avrebbero fatto sentire davvero bene.

Oggi mi fa solo scuotere la testa e pensare che gli ingegneri di Google dovrebbero smetterla di mostrare quanto sono bravi e cominciare a scrivere codice elegante e complesso alla giusta maniera. Essi dovrebbero disegnare l’architettura del loro SDK con la consapevolezza del fatto che non tutti i compiti sono creati alla stessa maniera e che la semplicita’ e’, a volte, la scelta migliore in assoluto.

Ma, nonostanze la sensazione riguardo l’eleganza di Android, esso e’ senza dubbio un SDK per applicazioni mobili accettabile. Vi sono un sacco di funzionalita’ e un numero incredibile di librerie e codici di esempio su cui ti puoi basare senza dover re-inventare la ruota.

Non mi ci vedo a lavorare a tempo pieno su Android. Non mi ci vedo neanche nella ricerca attiva di lavoro basato su Android che non sia parte di un progetto piu’ grande che coinvolga un’applicazione iPhone. Ma, detto tra noi, non e’ male. A volte e’ poco elegante, inutilmente complesso e convoluto, ma e’ giovane e tutte le potenzialita’ per diventare un gran SDK.

Android decollera’? Probabilmente si’. Vi sono un sacco di telefoni Android pronti a entrare sul mercato. Le compagnie telefoniche e di telecomunicazioni amano i sistemi operativi gratuiti dato che incrementano i loro margini di profitto. E, non appena abbastanza persone disporranno di telefoni Android, allora le persone cominceranno veramente a scrivere applicazioni per tali telefoni. Non credo che si assistera’ mai allo stesso fenomeno dell’iPhone, in cui persone di tutti i generi e senza esperienza di programmazione hanno sviluppato un desiderio di imparare a scrivere software, ma credo che vi sara’ comunque un buon mercato per le applicazioni per Android e, parimenti, per gli sviluppatori Android.

Son contento di lasciare questo mercato agli altri.

¹Ogni programmatore e’ passato per questa fase se ha lavorato con la programmazione abbastanza a lungo. Se tu stai programmando da un bel po’ di tempo e pensi di non essere passato per questa fase, allora vi sono ottime probabilita’ che tu ci stia proprio dentro.

Another Brick in the Wall

We are proud in i3factory to introduce a new term related to the way we make our apps: this is the “iphone brick”. Unfortunately this term is mainly used (try to make a search on google) to identify those bricked iPhone, that is devices that stop to work properly.
In our case we think at the brick as a major block that can be easily integrated in each application thus providing standardization and ease of use and testing.

So what is a “brick”? it’s a basic component that provides a full functionality with minimum programming level customization and some UI degree of flexibility. We already used bricks in our music applications, we have one for detecting notes (listener), we have one for playing basic sounds, we have another one to present simple e-books.

The theory behind bricks can be easily proven by one of the basic design patterns in iPhone CocoaTouch programming: the MVC – Model View Controller.

Summarizing, this pattern separates the role of a View, that is the part of code dedicated to user interface, to data presentation and user interaction, of the Model, that is the part of code hidden to the user and that represents the data model behind the app, and finally the Controller, that is the glue between the View and the Model and which is the part of code that knows the application logic and orchestrates the View and Model interactions.
Of course you’re not strictly required to keep these entities well separated in your code, especially in the iPhone where the UIViewController class is basically a Controller containing one or more views.

Now a standard iPhone app is based on a sequence of pages that are displayed to the user according to the application logic. This may happen in several ways, that is by navigating into a model hierarchy (typical left to right view panning), or flipping views, or showing modal views (typically bottom to top view panning) or finally switching between them using a tab bar.
Each one of these pages knows the portion of application logic that it represents: e.g. a page whose purpose is to show the user a database query knows where to fatch data from or, at least, is getting this data from the view that’s calling it; and the same page knows how to react once the user select one of the database entries it’s showing.
Typically a page is both a controller, because it contains a slice of the application flow, it’s obviously a view, because it shows something and interact with the user, and finally it may contain a portion of the model.
Whatever are the capabilities assigned to this controller, its role in the app flow and its interface towards the rest of the code is so well defined that we are able, in many cases, to give it the shape of a brick and place wherever we want in our app.

One of the simplest brick examples is the “SplashScreen” brick. A splash screen can be implemented in many ways inside an app, so we have no real need to provide it as a view controller object, but we recognize in it the characteristics required by a brick:
- well defined functionality
- restricted interaction with the app flow
- some degree of UI customization.
The functionality is quite simple: fill the iPhone screen with a fixed image for a given time, w/o any user interaction. The customization is limited to these two parameters: image and duration. Finally the interaction with the app is quite simple: inform it when the time interval specified as duration has elapsed.

Usually a splash screen appears when the app starts-up, so the easier place where to put it is inside the application delegate. A code example is the following:

Where the splash instance is an IBOutlet of a custom ViewController defined in the MainWindow.xib NIB file. So when the main NIB file is loaded we get the splash loaded too.
The image parameter is customized directly in the SplashBrick.xib file (we don’t want to do all programmatically; we are strong supporters of NIB files so we try to represent graphical information as much as possible using Interface Builder), while the duration is set using the setDuration: method. Finally we provide an extra parameter, that we call here delegate but it’s not a real delegate because it doesn’t provide as all delegates an extra functionality to the class, but it’s more an observer. Anyway we decided to use the delegate term in order to provide some common behaviour to all bricks.
The role of this delegate/observer is essential: it will be informed by the splash controller of the expiration of the duration time. This is what the splash can do only, as it has no control at all of the application loop. At this point the observer, once notified of the splash termination, knows how to react to this event and can decide what to do. In our example we simply decided to remove the splash and setup a new tab bar controller. This is the real starting point of the app: from now on the splash will be disposed of (and in fact its instance can be released thus freeing the space allocated to store the NIB and the image).

Of course we can add a more complicated logic by letting the app delegate to run some initial setup in a background thread and then remove the splash screen only when this setup is over. So the splash duration takes the meaning of a “minimum duration”.

The main splash methods are here:

When the splash appears the timer is started. When it fires the observer will be called using the splashDidEnd method.
Of course we could have improved the robustness by checking for the app to be able to run the selector and providing an “exit strategy” (probably a basic exit(1); statement!). Or we could have provided a loadView method to setup the splash fully programmatically. Or else… this depends on your needs.

Next posts we’ll present some more complicated examples: how to make a “Credits page” brick and how to make a “Cached URL” brick (this one is a pure modeling brick).

Icone per iphone e ipod touch

Navigando con un qualsiasi browser per Computer, sulla barra degli indirizzi spesso apparir√† un’icona.
Poiche’ basta inserire il file con l’icona favicon.ico sulla cartella principale del sito (generalmente: httpdocroot o httpdoc) e se necessario richiamare l’icona dall’html, ci chiediamo come sia possibile aggiungere un icona specifica se aggiungiamo un sito web , come preferito, nella home page dell’iphone o dell’ipod.

Innanzi tutto cerchera’ di ricordare una serie di informazioni oramai conosciute da tutti gli sviluppatori web, che comunque possono fornire nuovo interesse a chi invece e’ legato ad una cultura di programmazione piu’ tradizionale e meno orientata per il la costruzioni di siti.

Ritengo infatti necessario conoscere la “sintassi” per il web prima di cimentarci nelle semplici operazioni di inserimento di un’icona rappresentativa del sito che vogliamo adattare per iphone.

1.0 Favicon

Iniziamo a fornire informazioni per la creazione delle favicon da inserire nei vari siti web.
Ogni immagine delle giuste dimensioni (16 x 16 o 32 x 32 pixel se .ico) puo’ essere usata come favicon.

Per Generare le Favicon e’ possibile utilizzare differenti servizi online.

Di seguito ho inserito alcuni link a servizi online che vi aiutano a creare l’icona chiamata favicon.ico, ossia la piccola icona che compare a fianco del link di un sito nella barra degli indirizzi.

1.1 Come creare una favicon per il tuo sito web:

1.a) Favicom from Pics (http://www.chami.com/html-kit/services/favicon/) e’ un sito con generatore di favicon , anche animate, che vi permetter√† di creare l’icona da visualizzare alla sinistra dell’URL nella barra degli indirizzi.
Funzionamento: Create un’immagine quadrata con nome favicon in formato GIF o JPG e caricarla nel campo Source Image. Cliccate sul bottone Generate Favicon.icon e’ il sito vi creera’ in automatico l’icona in formato .ico con le dimensioni corrette. A questo punto non vi rimarra che aggiungere il file favicon.ico nella “document root” del vostro sito web e posizionare il seguente tag nell’html all’interno dell’ header (<head>..</head>):
<link rel=”shortcut icon” href=”favicon.ico” />

1.b) Favicon.cc (http://www.favicon.cc/) e vi permette di caricare una vostra immagine per poi editarla nel comodo editor online.
Funzionamento: Preparate un’immagine sul vostro computer e cliccate su import image per fare l‚’upload sull’editor di Favicon.cc a questo punto potete cambiare i colori pixel per pixel e vedere l’anteprima sia nella barra degli indirizzi sia sotto.

1.c) Favicon from Pics (http://www.html-kit.com/favicon/) e’un’ottimo sito, tra i migliori che abbiamo provato.
Funzionamento:Una volta che avete generato le vostre immagini favicon.ico (ve ne genera a diverse grandezze e anche animate, per i browser che le supportano), cliccate sul link Download Favicon Package e scaricatele tutte in un file.

1.d) il sito WebScriptlab mette a disposizione un generatore di favicon.
Funzionamento: bastera’ inserire l’immagine desiderata, e in pochi istanti creera’ per noi una favicon da inserire nella nostra pagina web. Ogni immagine delle giuste dimensioni (16 x 16 o 32 x 32 pixel se .ico) puo’ essere usata come favicon. Alternativamente al formato .ico, possono essere usati anche i formati .gif e .png di qualsiasi dimensione.

NOTA: Numerosissimi altri siti forniscono strumenti sia online che offline per generare le favicon e sono tutti molto semplici da usare.

Ovviamente i servizi che abbiamo segnalato sono tutti gratuiti!

2.0 Inserire un’ icona sulla home (Desktop) dell’Iphone e Ipod touch

Utilizzando iphone o ipod touch di nuova generazione possiamo inserire nel segnalibri (bookmark) un icona direttamente nella home (desktop) dell iphone o ipod.

Seguendo le indicazioni dell’utile sito  www.mambro.it , l’icona dovra’ essere salvata in formato PNG e deve avere dimensioni (canvas image size) pari a 57 x 57 pixel
E’ possibile costruire icone anche di dimensioni maggiori ma l’iphone/ipod le adattera’ sempre alla dimensione 57 x 57 px.
Create la vostra icona (usando il template fornito mambro: TEMPLATE PSD) e mettete il file PNG nella root del vostro sito
Inserite ora prima del tag <HEAD> il seguente codice:

<HEAD>
<link rel="apple-touch-icon" href="/icona.png">
</HEAD>

Note sull’uso template linkato da mambro.it :
Aprite il file PSD e inserire il vostro logo negli appositi spazi e salvare il tutto in PNG facendo attenzione a DISABILITARE i livelli ‚overlay e griglia, che servono solo a farvi capire come verra’ visualizzata l’icona e come posizionarla.
Sara’ infatti compito dell’iphone/ipod aggiungere l’effetto stondato e glossy sulla vostra icona

:: SCARICA IL TEMPLATE PSD ::

APPENDICE: Favicon
Da Wikipedia, l’enciclopedia libera.

Favicon e’ un termine inglese, contrazione di favorites icon. In informatica indica un’icona associata ad una particolare pagina web. Solitamente la favicon e’ una piccola immagine, spesso un logo, pertinente ai contenuti del sito web correlato. La favicon viene visualizzata alla sinistra dell’URL nella barra degli indirizzi di un browser, nel momento in cui si naviga un sito che ne e’ provvisto. L’icona e’ inoltre visualizzata nel menu dei preferiti di un browser. Nata come funzionalita’ di Microsoft Internet Explorer versione 5, in seguito e’ stata integrata su molti altri browser tra cui: Firefox, Mozilla, Opera, Safari, e Konqueror.

In origine la favicon era semplicemente posta nella directory radice del webserver con il nome favicon.ico e usata direttamente da Internet Explorer. Piu’ tardi e’ stato introdotto un apposito tag HTML per specificare la posizione del file. Il tag viene posto nella sezione head di un file HTML con sintassi:

<link rel=”shortcut icon” href=”favicon.ico” />
o, in conformità agli standard imposti dal World Wide Web Consortium:
<link rel=”icon” href=”http:/favicon.ico” />

In questo modo ogni immagine delle giuste dimensioni (16×16 o 32×32 pixel se .ico) puo’ essere usata come favicon. Alternativamente al formato .ico, possono essere usati anche i formati .gif e .png di qualsiasi dimensione.

Sfruttando le potenzialita’ del formato .gif e’ possibile creare delle favicon animate, anche se esse sono supportate solo da alcuni browser. Per usare i formati GIF o PNG i tag rispettivamente necessari sono:

<link rel=”icon” href=”http:/favicon.gif” type=”image/gif” />
o
<link rel=”icon” href=”http:/favicon.png” type=”image/png” />

FAVICON.ICO
Le favicon sono quelle minuscole icone (16√ó16 pixel) che compaiono alla sinistra della URL nella barra degli indirizzi del browser. Far comparire la favicon e’ un gioco da ragazzi, come potete leggere in questo articolo. Il problema e’ creare l’immagine. Il formato, obbligatoriamente .ico, non e’ facilmente editabile e richiede spesso l’uso di programmi di grafica specifici, raramente freeware. Ma come riportato su DesMM.com, e’ possibile aggirare l’ostacolo con un plug-in gratuito per Photoshop.

Un aspetto da non tralasciare e’ quello di avere una bella icona preferiti,  Firefox la inserisce sempre nella Navigation bar.
E’ semplice la realizzazione di questa decorazione :
1) Apriamo dal vostro programma di Photo-editing preferito e realizziamo una icona 16×16 che identifica il vostro sito e la salveremo in formato .gif.

2) Il formato corretto per la visualizzazione delle favicon e’ il .ico, ma non tutti i programmi permettono di salvare in questo formato. Un programmino freeware che puo’ essere utile e’ Irfanview che ha all’interno del salva con nome la scelta di registrare nel formato .ico.

3) Per comprenere  meglio il processo di conversione .ico, soggeriamo di leggere questo sito http://www.html-kit.com/e/favicon.cgi nel quale, con un  form, potrete convertire il vostro file .gif seguendo delle semplici istruzioni.

4) Inserite il file creato nella Docroot del vostro server(Document root: generalmente la cartella nominata httpdocs o www) . E’ necessario  che il file sia nominato favicon.ico altrimenti i browser non lo troveranno.

5) Agggiungiamo nelle pagine html tra i tag<HEAD> e</HEAD>, un codice. Ovviamente dovrete sostituire il nome corretto del vostro dominio al posto di www.nomesito.com:

Il sito di i3factory visto dall'iphone

Con questo articolo abbiamo raccolto numerose referenze sul web e spiegheremo come inserire un codice che permetta di riconoscere automaticamente se sta autilizzando un iphone, un ipod touch o un’ipad .

Per il riconoscimento automatico suggeriamo di utilizzare una di queste 2 Metodologie:

1.0 Identificare automaticamente l’ iphone: creare un sito ad hoc ottimizzato iPhone (es: mobile.nomesito.it)

1.1 Identificare l’iPhone, ipod touch
Per riconoscere l’iphone o l’ipod touch e’ necessario identificare il tipo di browser attraverso l’user agent.
Come abbbiamo gia scritto nell’articolo “iphone layout : le giuste dimensioni per il web“, tutti gli apparati Apple utilizzano , di serie, Safari Mobile che come ogni browser ha un suo user agent, ossia la stringa che lo identifica ai web server.

L’user agent della versione 1 dell’iPhone e’ il seguente:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/X Mobile/Y Safari/Z
Dove al posto di X, Y e Z vi saranno le versioni dei vari componenti.

Identificando l’iPhone e ipod e’ possibile eseguire un rindirizzamento verso una pagina appositamente creata per iPhone o mostrare contenuto solo a chi si collega con quel dispositivo.
Per indirizzare un utente iPhone o ipad ad una nuova pagina (es: mobile.sito.it) si puo’ usare il seguente codice JavaScript:

< script type="text/javascript">
if ((navigator.useragent.indexof('iPhone') != -1) ¦¦
  (navigator.useragent.indexof('iPod') != -1)) {
  location.href = 'http://mobile.sito.it/';
  }
</script> 

Il seguente codice javascript:

navigator.useragent.indexof(‘mini’) != -1

Riconosce invece il browser “Opera mini” che viene utilizzato come browser alternativo , non di serie, in numerosi telefoni e apparati.

1.2 Identificare l’ ipad

Safari per iPad dispone di uno specifico user-agent diverso da quello dell‘ iPhone, in modo da ricevere le pagine web nel loro formato originale.

Di seguito la stringa user agent per l’ipad di Jeff dePascale:
Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

La nuova release del simulatore per iPad, contenuta nell‘ SDK 3.2 beta 2, offre la possibilit√† di provare in anteprima la versione di Safari appositamente creata per sfruttare al massimo le potenzialita‘ di questo dispositivo.

La risoluzione dello schermo dell‘ iPad, 1024 x 768 pixel, ha permesso ad Apple di realizzare un browser ibrido, una via di mezzo tra Safari per Mac OsX e Safari per iPhone.

Come per il browser per iMac troviamo una barra degli strumenti in una posizione fissa, pur mantenendo un controllo multitouch per lo zoom e lo scroll della pagina.

La barra degli strumenti di Safari per Ipad e’ fissa e contiene tutti i controlli: dalle frecce di navigazione al box di ricerca.

1.3 Visualizzare un testo solo per chi naviga con iPhone

Con il seguente codice e’ possibile visualizzare sulle nostre pagine web un testo solo per chi naviga con iPhone.

<script type=”text/javascript”>
 window.onload = function () {
 if (navigator.userAgent.indexOf(’iPhone’) != -1) {
 var o = document.getElementById( ‘iphone’ );
 o.innerHTML = “<h1>Benvenuto iPhone!</h1>”;
 }
 }
 </script > 

Infine ci bastera‘ posizionare il seguente div nella nostra pagina web, nel punto in cui vogliamo far visualizzare la frase.

<div id=‘ iphone‘ ></div>

2.0 Utilizzare lo stesso sito modificando o utilizzando il file CSS.

2.1 Assegnare un file CSS specifico per iPhone
Se non si vuole creare un sito web separato per l’iPhone, e reindirizzare Safari Mobile verso una diversa pagina html come abbiamo suggerito nel paragrafo precedente,e‘ possibile impostare i file CSS in modo che prevedano per l’iPhone stili diversi da quelli utilizzati da altri browser.
L’iphone utilizza di una metodologia dei CSS3 chiamata Media queries.
Una media query verifica che il browser supporti determinate caratteristiche di visualizzazione (come la risoluzione) e sceglie in base alla risposta il CSS adatto.
Sull’iPhone che, come detto, puo‘ avere in larghezza una risoluzione di 320 pixel o, se ruotato in orizzontale, di 480 pixel, bastera‘ utilizzare la seguente sintassi per differenziare il suo foglio di stile da quello di altri dispositivi:

<link media=”screen and (min-device-width: 481px)” rel=”stylesheet” type=”text/css” href=”style.css” />

<link media=”only screen and (max-device-width: 480px)” rel=”stylesheet” type=”text/css” href=”iphone.css” />

Il codice legger√† il foglio di stile iphone.css per tutti i dispositivi che hanno una larghezza dello schermo minore o uguale a 480 pixel (max-device-width: 480px) mentre per tutti quelli che hanno una larghezza maggiore o uguale a 481 pixel (min-device-width: 481px) il foglio di stile sara‘ style.css. Grazie alla chiave only i vecchi browser salteranno completamente la seconda istruzione.

2.2 Css specifici
Safari Mobile accetta alcuni codici (tag) proprietari che son compatibili esclusivamente per il webkit di iPhone.
Alcuni di questi sono utili per visualizzare elementi dalla grafica piu‘ integrata con l’ambiente Apple.
E’ possibile richiamare i moduli di ricerca, i box testuali o le immagini dell’iPhone con classico contorno rettangolare arrotondato.
Per gestire gli angoli si usa la proprieta‘ -webkit-border-radius. Un semplice CSS come questo:

.iphone {
 background-color: silver;
 padding: 10px 10px 10px 10px;
 width: 320px;
 -webkit-border-radius:10px;
 }
 .iphone img {
 margin: 5px 5px 10px 5px;
 border: 3px solid #666666;
 float: left;
 -webkit-border-radius: 5px;
 }

Richiamato nella pagina HTML da questo codice:

<div><img alt=”XXX” src=”immagine.png” />testo</div>

Visualizza un box con angoli arrotondati contenente un’immagine gli spigoli smussati.

Una proprieta‘ CSS che puo‘ essere utile nella creazioni di pagine web per iPhone e‘ -webkit-text-size-adjust.
Essa interviene per adattare la grandezza del testo della pagina in modo che sia leggibile quando un utente esegue uno zoom. Il browser dell’iphone (Safari Mobile) esegue lo zoom automaticamente ma, in alcuni casi, e‘ possibile che il testo venga adattato male. Si puo‘ quindi disabilitare l’adattamento automatico (-webkit-text-size-adjust:none) oppure impostarlo a percentuali di grandezza piu‘ elevate (-webkit-text-size-adjust:150%). Tale proprieta‘ puo‘ essere impostata per tutti o solo per alcuni elementi della pagina.

2.3 In conclusione : sara‘ possibile utilizzare lo stesso file .CSS

Abbiamo la possibilita‘ di condizionare la lettura del CSS a seconda della risoluzione del browser.

Sapendo che la massima larghezza dello schermo dell’ iPhone e di 480 pixel ( se tenuto in orizzontale!) possiamo inserire tra i tag <head> </head> il seguente codice nella nostra pagina web.

<link media=‘ screen and (min-device-width: 481px)‘ rel=‘ stylesheet‘ type=‘ text/css‘ href=‘ stile.css‘ />

<link media=‘ only screen and (max-device-width: 480px)‘ rel=‘ stylesheet‘ type=‘ text/css‘ href=‘ iphone.css‘ />

La prima linea di codice abilita la lettura di stile.css se il browser e‘ almeno 481 pixel mentre la seconda abilita‘ la lettura di iphone.css se il browser in questione arriva a una larghezza massima di 480 pixel.

Nel primo caso staremo utilizzando un browser qualsiasi, mentre nel secondo caso si tratta di un browser iPhone.

Questa semplice stratagemma ci permette di creare per la stessa pagina web delle classi differenti che verrnno attivate a seconda del browser.

3.0 Codici utili da inserire in un sito per iphone, ipod touch e ipad

Ecco alcuni codici utili da usare per ottimizzare il vostro sito per iPhone.

3.1 Inserire icona sito mobile

L’iPhone permette di aggiungere l’icona di un sito direttamente sulla pagina principale del telefono (Springboard o Home) per facilitare un accesso rapido.
E‘ possibile personalizzare l’icona (web clip) che il telefono usera‘ per identificare il sito semplicemente aggiungendo alla cartella principale del sito un’icona in formato .png chiamata apple-touch-icon.png.
Se si vuole limitare l’icona ad una pagina si usa questo codice:

Inserire tra i tag <head> </head>

<link rel=”apple-touch-icon” href=”/icona.png” />

3.2 Inserire numero di telefono attivo

Ecco come inserire un numero di telefono attivo da iPhone

<a href=‘ tel:02-831212‘ ≥>02831212</a>

3.3 Nascondere la barra indirizzo

In questo modo molto semplice possiamo nascondere la barra degli indirizzi quando una pagina viene caricata, e guadagnare cosi‘ 60 pixel:

<body onload=”setTimeout(function() { window.scrollTo(0, 1) }, 100);”>

Dalla versione due dell’iPhone si puo‘ utilizzare un sistema piu‘ semplice:

<meta name=”apple-touch-fullscreen” content=”YES” />

3.4 Identificare browser iPhone

Basta inserire il seguente codice nella nostra pagina web e il link alternativo per il browser iPhone

< script type=‘ text/javascript‘ > if (navigator.userAgent.indexOf(‘ iPhone‘ ) != -1) { location.href = ‘ http://iphone.sito.it/‘ ; } </script>

3.5 Bordi arrotondati con CSS

WebKit, il motore del browser accetta alcuni tag proprietari che possono aiutarci a creare una grafica piu‘ elegante e curata.

Potete vedere tutti i tag su Safari CSS Reference.

.iphone img { margin: 5px 5px 10px 5px; border: 3px solid #666666; float: left; -webkit-border-radius: 5px; }

3.6 Scalare la visualizzazione del browser

Quando un sito web viene caricato nel browser viene effettuato uno scaling da 980 pixel a 320 pixel verticale, 480 pixel orizzontale.

Se il nostro sito web e ‘ minore di 980 pixel avremo delle bande laterali bianche.

Per ovviare a questo problema basta impostare la misura iniziale su cui fare lo scaling in questo modo.

<meta name=‘ viewport‘ content=‘ width=800‘ />

3.7 Impostare proprieta‘ ZOOM browser iPhone

In questo modo possiamo limitare il massimo e minimo zoom durante la navigazione su browser iPhone

<meta name=‘ viewport‘ content=‘ initial-scale=0.6, minimum-scale=0.4, maximum-scale=0.8‘ />

3.8 Inserire un video manualmente

Per includere un video all’interno di una pagina Web destinata all’iPhone si puo‘ utilizzare questo codice:

<embed src=‘ immagine.jpg‘ href=‘ movie.m4v‘ type=‘ video/x-m4v‘ target=‘ myself‘ scale=‘ 1‘ [...]>

In questo modo l’iPhone visualizzera‘ , al posto di un poco significativo triangolo grigio, l’immagine Jpeg specificata dall’attributo src. I filmati che l’iPhone accetta sono quelli codificati in H.264 o MPEG-4 Part 2 video, gli stessi riproducibili sull’iPod.

4.0 Link specifici: numeri di telefono, mappe google e video Youtube

L’iPhone gestisce almeno tre tipi di link in modo differente rispetto ad un tradizionale browser: i link a numeri di telefono, i link a mappe di Google Mappe e i link a video di Youtube.
La prima volta che Safari Mobile carica una pagina in memoria questa viene scansionata alla ricerca di numeri di telefono. Se trovati, i numeri di telefono vengono resi cliccabili in modo che toccandoli si avvii automaticamente una chiamata.
A volte alcuni numeri di telefono non sono interpretati correttamente e altre volte vengono resi cliccabili anche numeri di partita IVA o altri. Per evitare che altri numeri vengano interpretati come numeri telefonici si usa questo meta-tag:
<meta name=”format-detection” content=”telephone=no”>
che disabilita la ricerca di numeri per l’intera pagina. Per attivarli singolarmente si dovr√† dunque usare quest’altro codice:

<a href=”tel:02-831212″>02831212</a>

I link a video di YouTube o a una mappa di Google Mappe aprono, rispettivamente, l’applicazione Youtube e l’applicazione Mappe dell’iPhone.
Per Google Maps funzionano i link dai vari siti di Google, per Youtube per aprire un video si deve invece inserire un link che punti al sito .com (sito madre) del servizio e non a quelli localizzati..

Ad esempio: questo link non sempre funziona sull’iPhone in quanto punta al sito italiano di Youtube:

<a href=”http://it.youtube.com/watch?v=g7_2qI-VQYM”>Gol di Grosso</a>

I seguenti links invece funzionano sempre:

<a href=”http://www.youtube.com/watch?v=g7_2qI-VQYM”>Gol di Grosso</a>
<a href=”http://www.youtube.com/v/g7_2qI-VQYM”>Gol di Grosso</a>

In questo articolo riassumeremo gli elementi fondamentali da implementare quando si sviluppano pagine web che devono essere fruite da un Iphone o un Ipd Touch e a breve anche ipad.

1.1 Safari Mobile: il Browser dell’iphone, Ipod touch e ipad

Il browser utilizzato da Apple in ogni iphone, ipod touch e ipad e’ Safari Mobile (basato su WebKit).

Safari Mobile supporta linguaggi HTML 4.01, XHTML 1.0, CSS 2.1, CSS 3 (in parte), JavaScript 1.4, supporto del Dom e Ajax; la possibilit di visualizzare file Pdf e Microsoft Office (Word, Powerpoint, Excel), immagini Gif, Jpeg, Png e Tiff.

Inoltre e’ possibile riprodurre filmati QuickTime e file MP3 direttamente dalle pagine Web.

Attualmente non vi e’ compatibilita’ con le tecnologie Adobe Flash o Java.

1.2 L’area di visualizzazione (Viewport): 320 x 480 px dimensioni dello schermo dell’iphone

La viewport e’ l’area di un dispositivo destinata a presentare i dati e ad offrire l’interazione con l’utente i cui non sono fissi: l’utente puo’ eseguire uno zoom di un elemento di una particolare area per fruire meglio del contenuto pubblicato.

Lo schermo dell’iPhone ha una risoluzione di 320×480 pixel.
Per visualizzare una pagina web occorre tener presente che 20 pixel sono occupati dalla barra di stato e 44 px dalla barra dei pulsanti.

Quindi la viewport per i contenuti e’di 320x356px; considerando la barra dell’indirizzo, l’unica che si puo’ nascondere utilizzando codice HTML, quest’area cresce a 320x416px.
Posizione orizzontale:
L’iphone e l’ipod touch possono essere ruotati in posizione orizzontale, in tal caso la risoluzione per i contenuti si riduce a 209 x 480px (269 x 480 senza barra degli indirizzi).

Pertanto il browser Safari Mobile di iPhone e Ipod Touch e’ composto da alcuni elementi come la barra di stato di 20 px (status bar) e di indirizzo che misura 60 pixel, e l’area inferiore dei pulsanti standard che e’ di 44 pixel. Dobbiamo tener presente che le dimensioni di visibilita’ del browser iPhone (senza lo scrolling della pagina) sono di 320 x 356 pixels.

1.2.1 Riassumiamo:
Visualizzazione in Verticale:
480 x 320 px – Dimensione Schermo
416 x 320 px – Dimensione utile dello scrolling data la presenza dei pulsanti e della barra di stato
356 x 320 px – Dimensione utile prima dello scrolling , comprende la barra di stato di safari.
Visualizzazione in Orizzontale:
209 x 480 px – Dimensione utile data la presenza della barra degli indirizzi
269 x 480 px – Dimensione utile dello scrolling senza barra degli indirizzi

Area di visualizzazione browser di iphone e ipod touch

There is a really interesting experiment that you can follow day by day in the web: following a new iPhone app creation from the initial concept up to the final code and Apple store submission.
The app is called “Dayta” and the author is Sahil Lavingia.
The app will be created from scratch, all graphics will be custom (a part a few icons) and it’s also quite useful.

You can follow Dayta creation with the blog or twitter.

And if own an iPhone or iPod you can ask Sahil to be a beta tester. We are doing it too…

Niente di piu’ intuitivo che scambiare informazioni tra due iPhone affiancati, giusto?

Ebbene questa cosa, apparentemente banale, non e’ poi cosi’ scontata.

Attualmente, a meno di non iniziare una complessa connessione Bluetooth oppure sviluppare un proprio protocollo di comunicazione via web, la cosa non e’ facilmente implementabile.

Bump technologies e’ una start-up nota soprattutto perche’ la sua applicazione Bump e’ stata riconosciuta come quella applicazione installata che ha consentito di superare il miliardo di app di terze parti scaricate sugli iPhone/iPod touch.

Bump consente semplicemente di scambiare i propri biglietti da visita tramite il semplice gesto di avvicinare, o meglio urtare (bumping), due iPhone tra loro.

Adesso ogni sviluppatore puo’ installare nelle proprie applicazioni – e gratuitamente – l’SDK di Bump e sfruttare questa tecnologia per poter realizzare divertenti e utili forme di interazione tra due iPhone.

Per saperne di piu’ e scariare l’SDK potete andare direttamente sul sito di Bump technologies.

Programma Windows per scaricare video da youtube

Youtube HD Transfer e’ un piccolo programma per Windows ,completamente gratuito, che permette di scaricare i video da YouTube, in tutti i formati , incluso l’HD [low/high quality FLV, High Definition MP4 (720p) and even Full High Definition MP4 (1080p)].
Dall’intefaccia potrete effettuare ricerche sui video da visualizzare, per scaricarli successivamente! L’applicazione e’ supportata da tutti i sistemi Windows ed e’ disponibile anche in versione portatile!

Visita il sito