i3Factory

La tua Iphone, iPad & Android Application Factory

Visualizza gli articoli pubblicati da Igor Wolfango Schiaroli

    Rivista della provincia di Milano

    Rivista della provincia di Milano

     

    La Provincia in Casa ha scelto di entrare nel mercato mobile e tablet con i3Factory utilizzando il sistema editoriale i3F Editorial, una soluzione tecnologicamente all’avanguardia senza alcun costo di gestione. La tecnologia avanzata di i3F Editorial permette agli editori di pubblicare nuovi numeri della rivista o magazine senza alcun costo. Appare incredibile ma è vero.

    La versione per i dispositivi iOS Apple, tutti gli iPhone e iPod Touch (iPhone 3, iPhone5, iPhone 5) e iPad (iPad 3 Retina, iPad 4 Retina, iPad 1, iPad2) la trovate al seguente link:

    https://itunes.apple.com/it/app/la-provincia-in-casa/id606239216?mt=8

    La versione Android per tutti gli smartphone e tablet android (Samsung , Kindle, Sony, Asus, etc..):

    https://play.google.com/store/apps/details?id=org.imaginor (GOOGLE PLAY- Android Market)

    http://www.amazon.com/Provincia-Casa-Milano-italian-Magazine/dp/B00BUL9THS (Amazon App Store – Kindle fire)

     

      i3Factory accompagna il Ministero del Lavoro che attraverso il Sistema Editoriale i3Editorial sbarca su App Store.
      Uno strumento agile per essere sempre aggiornati sul mondo del lavoro. La newsletter di Cliclavoro è un appuntamento mensile che raccoglie le più importanti novità del settore: tendenze del mercato del lavoro, opportunità dall’Europa, interviste a personalità di spicco.

      La Newsletter si articola in 5 sezioni:

      • In apertura
      • Approfondimento
      • L’intervista
      • Dall’Europa
      • Dai Social Network

      Tieniti aggiornato sull’andamento del mercato con dati e informazioni arricchiti da link e contenuti multimediali.
      Per seguire in tempo reale le news dal mondo del lavoro scarica l’applicazione CliComunica.
      Versione Apple iPhone e iPad: https://itunes.apple.com/it/app/clicomunica/id582587332?mt=8

      Versione per Android: https://play.google.com/store/search?q=clicomunica&c=apps

        Spesso ci capita di dover aggiornare le nostre applicazioni con  le immagini ad alta risoluzione necessarie per il nuovo iPad (iPad 3 o iPad 4). Fortunatamente il nuovissimo iPad Mini ha mantenuto la stessa risoluzione del primo degli iPad che è di 1024 x 768 pixels.
        Poichè non è sempre semplice trovare i documenti ufficali di  Apple , in questo articolo ho nuovamente raccolto tutte le informazioni di cui abbiamo bisogno per aggiornare le icone, le immagini di intro o splash, e così via.

        Innanzi tutto partiamo da questa utile tabella:

        Device/Screen File Name (PNG) Icon Size (pixels)
        iPhone and iPod
        Application Icon for iPhone (retina display) Icon@2x.png 114 x 114
        Application Icon icon for iPhone Icon.png 57 x 57
        Settings/Spotlight icon for iPhone (retina display) Icon-Small@2x.png 58 x 58
        Settings/Spotlight icon for iPhone Icon-Small.png 29 x 29
        Launch image Portrait (retina display) Default@2x.png 640 x 960
        Launch image Portrait Default.png 320 x 480
        iPhone 5
        Launch image for iPhone 5 Portrait (retina display) Default-568h@2x.png 640 x 1136
        iPad
        Application Icon for the new iPad (retina display) Icon-72@2x.png 144 x 144
        Application Icon for the iPad Icon-72.png 72 x 72
        Settings/Spotlight icon for iPad Icon-Small-50@2x.png 100 x 100
        Settings/Spotlight icon for iPad Icon-Small-50.png 50 x 50
        Launch image Portrait (retina display) Default-Portrait@2x.png 1536 x 2008
        Launch image Portrait Default-Portrait.png 768 x 1004
        Launch image Landscape (retina display) Default-Landscape@2x.png 2048 x 1496
        Launch image Landscape Default-Landscape.png 1024 x 748
        iTunes App Store
        App icon for the App Store (retina display) iTunesArtwork@2x.png 1024 x 1024
        App icon for the App Store iTunesArtwork.png 512 x 512

         

        Ricordiamo che con il passaggio da iOS 5 a iOS 6 è nato il nuovo iPhone 5, insieme con l’iPod touch di 5 ° generazione.
        Questi nuovi dispositivi Apple hanno solo un grande cambiamento che aggravia il lavoro di sviluppo delle App: la risoluzione dello schermo.
        Questi dispositivi hanno un ampio schermo 4″ , WDVGA (Wide VGA doppia) 640 × 1136 pixels, 326 DPI-Retina display.
        Questi dispositivi hanno la stessa larghezza 4/4S iPhone ma più 176 pixel di altezza in modalità Portrait.

        App Icon Template

        Segnalo nuovamente, come ho gia fatto in un’altro articolo, questo utilissimo tool scaricabile direttamente dal sito “appicontemplate.com” .

        Scaricando il file otterrete un modello PSD del’ icona dell’App che, attraverso oggetti avanzati in Photoshop, vi permette di automatizzare il processo di esportazione delle varie dimensioni del file icon.png che devono essere necessariamente incluse nel bundle di ogni iOS App.

        Attraverso questo modello Photoshop potremo modificare solo l’icona di dimensione più grande e verrà automaticamente eseguito il rendering che permetterà di avere le icone di dimensioni minori attraverso un veloce flusso di lavoro.
        Questo modello è stato creato dal designer danese Michael Flarup.

        Come si usa (How to) App Icon Template ?
        Il modello funziona con Photoshop CS2 o versioni successive.
        Basta aprire il file PSD con la vostra versione di Photoshop e fare “clic destro” sul LAYER (Livello) chiamato “EDIT THIS SMART OBJECT” (MODIFICARE QUESTO OGGETTO SMART) e premere  su ’Edit Contents’ (“Modifica contenuto”).
        Verrà aperto il file Icon.psb e potrete creare il vostro Artwork  in questo canvas (quadro).
        Dopo aver salvato il Icon.psb, dovrebbe essere automaticamente eseguito il rendering per le diverse dimensioni del file PSD principale .
        E’ possibile utilizzere le Actions (azioni automatizzate) di Photoshop che sono in bundle con la risorsa per esportare i file dell’icona nelle versioni squared and rounded corner (squadrate e arrotondate).

        Buon Design!

          Prendendo spunto da  articoli trovati scorrendo diversi blogs, segnalo queste importanti informazioni utili a qualsiasi designer o sviluppatore che intenda disegnare UI (User Interface o Interfacce Utente) per differenti dispositivi smartphone.

          Il successo di Android, come sistema operativo per dispositivi mobile, ha portato i produttori di smartphones a produrre una grande varietà di schermi (display) di diverse dimensioni  e risoluzioni. Nel Blog phonearena.com/ (http://www.phonearena.com/news/Display-Comparison-Apple-iPhone-5-vs-Samsung-Galaxy-S-III-vs-HTC-One-X-vs-Nokia-Lumia-900_id35171) viene fornito un elenco di dispositivi di esempio.

          Considerando il dispositivo in orientamento verticale (Portrait), definiamo  l’asse X come  la larghezza in pixel e l’asse Y come lunghezza o l’altezza in pixel. Ovviamente si consideri che il dispositivo viene anche tenuto in orientamento orizzontale (Landscape) dato che anche Android ha il supporto per entrambi gli orientamenti.
          Si potrà notare che il numero totale di pixel di uno schermo corrisponde al numero dell’asse X moltiplicato per il numero in Y. Maggiore è il numero di pixel per ogni pollice (Dpi)  più nitida sarà la visualizzazione delle immagine (a condizione che tali immagini siano ad alta risoluzione).

          Esempio Android Screen Sizes and Resolutions
          # Pixels X Y ACRONYM Device Example 1 Size Device Example 2 Size
          76800 240 320 QVGA ZTE Tureis 2.6 Samsung Galaxy Fit (GT-S5670 ) 3.3
          96000 240 400 WQVGA400 Samsung Galaxy Apollo 3.2 Archos 32 Internet Tablet 3.2
          153600 320 480 HVGA HTC ChaCha 2.6 HTC Explorer 3.2
          230400 360 640 nHD Dell Aero 3.5 Dell Mini 3ix 3.5
          307200 480 640 VGA Motorola Pro+ MB632 3.1 Motorola Admiral 3.1
          384000 480 800 WVGA800 Google Nexus One 3.7 Dell Streak 7 7
          409920 480 854 WVGA854 Sony Xperia Ray 3.3 Archos 43 Internet Tablet 4.3
          480000 600 800 SVGA Elonex eTouch 702ET 7 Pandigital SuperNova 8
          491520 480 1024 UWVGA Acer Iconia Smart S300 4.8 Sony Tablet P 5.5
          518400 540 960 qHD Motorola Atrix 4 HTC Vivid 4.5
          614400 640 960 DVGA Sharp IS03 3.5 iPhone 4S 3.5
          614400 600 1024 WSVGA Amazon Kindle Fire 7 Archos 101 Internet Tablet 10.1
          786432 768 1024 XGA Archos 80 G9 8 Malata T8 9.7
          921600 720 1280 WXGA720, HD, 720p Galaxy Nexus (GT-i9250) 4.6 Sony Xperia S 4.3
          983040 768 1280 WXGA Ramos W15 8 LG Optimus PAD (V900) 8.9
          1024000 800 1280 WXGA800 Samsung Galaxy Note (GT-N7000) 5.3 Motorola Xoom 2 10.1

          L’iPhone 4S è indicato nella tabella per confronto, vedere la linea DVGA, non è un telefono Android.
          Nota: a Full High Definition (FHD) o lo schermo 1080i/1080p è 1080 × 1920 che è 2.073.600 pixel.

          Stimolato dal blog Tekeye.biz (http://tekeye.biz/2012/example-list-of-android-device-screen-resolutions-and-sizes) andrò ora a confrontare lo schermo HD da 4,8 pollici Super AMOLED del Samsung Galaxy S III, il display 4,7 pollici 720p Super-LCD 2  su HTC One X, e lo schermo del Lumia 900 con is suoi 4,3 pollici ClearBlack AMOLED che viene ostentato dalla Nokia.

          Come per ogni confronto di dispositivi elettronici ciò che veramente conta non sono solo le specifiche hardware , ma bisogna vedere come questi telefoni se la cavano in situazioni reali, in quanto si sa, questo è esattamente ciò che più conta.

          Vediamo quindi come se la cavano in termini di Luminosità e contrasto (Brightness and Contrast):

          Non c’è niente di meglio per attirare la gente che avere un display luminoso, giusto? John V. di Tekeye ha quindi impostato manualmente tutti e quattro gli smartphone per la loro impostazione di luminosità più alta. I nuovi iPhone 5 di IPS-LCD schermo salta subito all’occhio per  avere la più alta luminosità,   il vantaggio è che quindi siamo in grado di avere visibile tutto sul display dell’iPhone 5 quando lo si utilizza all’aperto – anche quando il sole batte direttamente sulo schermo. Inoltre, il pannello Super-LCD 2  in uso da parte del HTC One X mostra il suo valore, in quanto si tratta di un pannello con un cuore LCD che dimostra bene il suo valore in condizioni esterne. Infine, il Samsung Galaxy S III e Nokia Lumia 900 sono allo stesso livello in termini di visibilità esterna, in quanto i rispettivi pannelli HD Super AMOLED e ClearBlack AMOLED sono così efficaci che ci permettono di vedere correttamente quando siamo fuor, ma allo stesso tempo, il calo di contrasto, inclinando leggermente provoca riflessi che interferiscono con la loro usabilità.

          Risoluzione:

          Leggendo sul foglio delle specifiche, si potrebbe supporre che i due smartphone Android  in questo confronto abbiano  la vittoria visto che hanno una  risoluzione di 720p, ma ancora una volta, ciò che si legge sulla carta e non tiene conto di densità di pixel. Tuttavia, se non dovessimo tenerne conto, allora  l’iPhone 5 dovrebbe essere preso in considerazione con la sua densità di pixel di 326 ppi. Tuttavia, prima di concretamente dire che è il vincitore all’unanimità, gli occhi hanno bisogno di confermare ciò che sembra ovvio.

          Caricando il  sito web su tutti e quattro gli smartphone e, guardandoli, da una view ingrandita, è innegabile che la  risoluzione 640 x 1136  dell’ iPhone 5  presenta invisualizzazione dettagli più nitidi. In realtà, il testo sullo schermo ha spigoli vivi che aiutano a rafforzare le sue immagini nitide per renderli facilmente visibili ad occhio nudo. Allo stesso tempo, l’HTC One X da 4.7-pollici e 720p può visualizzare  immagini interessanti – però, la visualizzazione è un po ‘po’ più morbida, cercando intorno ai bordi, in parte a causa della sua densità di pixel inferiore che è di 312 ppi. Al terzo posto, è la  risoluzione del Samsung Galaxy S III da 4,8 pollici con 720 x 1280 px che impiega la PenTile Matrix. Indipendentemente da questo, la sua carenza non pregiudica l’aspetto dei  dettagli guardando il suo display da una distanza normale. E, infine, il Lumia Nokia 900 non riesce a stupire con il suo display da 4,3 pollici WVGA (480 x 800), come la sua risoluzione in pixel di 217  ppi si allontana  drasticamente dalla concorrenza, con conseguente immagini che mancano della stessa nitidezza dei concorrenti.

           

            Perché parliamo di Produzioni video cenematografiche

            Si potrebbe pensare che la gestione video sia limitata ad applicazioni come iMovie o Vimeo e a una nicchia di esperti video. Invece può essere esteso ad una gamma più ampia di applicazioni, non è essenzialmente limitato a editing video. In questo articolo forniremo una panoramica del Framework AV Foundation applicato su un esempio pratico.

            Nel nostro caso particolare, la sfida era quella di creare un’applicazione che, partendo da una serie di clip video esistenti, fosse stata in grado di costruire una storia fatta collegando un sottoinsieme di queste clip sulla base di decisioni prese dall’utente durante l’interazione con l’applicazione.
            Il gioco finale è un insieme di scene, girato in luoghi diversi, che compongono una storia. Ogni scena è composto da un prologo, una conclusione (epilogo) e una serie di piccole clip che verranno eseguite dall’applicazione sulla base di alcune scelte fatte dagli spettatori – utenti- giocatori.  Se le scelte sono corrette, lo spettatore sarà in grado di riprodurre tutta la scena fino al suo lieto fine, ma in caso di errore dovrà tornare sulla scena prologo iniziale o in una certa scena intermedia. Lo schema seguente mostra un possibile schema di una tipica scena: un prologo, un flusso vincente (verde) alcuni rami (giallo sono intermedie, il rosso stanno perdendo filiali) e di un lieto fine. Così gli spettatori da qualche parte nel TRACK1 saranno chiamati a prendere una decisione, se lui / lei è in quel momento in gioco continuerà con TRACK2, se non entrerà nel giallo Track4, e così via

             

            iPhone & iPad: Movie Game Storyboard
            Quello che abbiamo tra le mani è la serie completa di tracce, ogni traccia rappresenta una sottosezione specifica di una scena, e uno storyboard che ci fornisce le regole da seguire per costruire la storia finale. Così lo storyboard è fatto dalle scene, dalle tracce del compongono ogni scena e dalle norme che stabiliscono il flusso attraverso queste tracce.
            La sfida principale per lo sviluppatore è quello di mettere insieme queste clip e riprodurre un video in base allo stato attuale dello storyboard, quindi passare alla successiva, selezionare un nuovo clip di nuovo e così via: tutto deve trascorrere fluidamente senza interruzioni.
            Lo spettatore deve prendere le decisioni, interagendo con l’applicazione-gioco e questo può essere fatto sovrapponendo al film con alcuni controlli personalizzati.

            AV Foundation Framework

            Sarebbe impossible raggiungere gli obiettivi spiegati nel paragrafo precedente utilizziando lo standard Media Framework view controllers, MPMoviePlayerController e MPMoviePlayerViewController. Questi conrollers sono buoni per riprodurre un filmato e fornire i controlli di sistema, a schermo intero e la rotazione del dispositivo di sostegno, ma assolutamente non adatti per i controlli avanzati.
            Dopo il rilascio di iPhone 3GS dell’utility per la fotocomara avevamo la possibilità di fare un po ‘di tagli e l’esportazione, ma queste capacità non sono state date agli sviluppatori attraverso le funzioni pubbliche del SDK. Con l’introduzione di iOS 4, l’attività svolta da Apple con lo sviluppo delle app iMovie ha dato agli sviluppatori un ricco insieme di classi che consentono la manipolazione completa dei video . Tutte queste classi sono state raccolte ed esportate in un unico framework pubblico, denominato AV Foundation. Questo framework esiste da iOS 2.2, a quel tempo era dedicato alla gestione audio con la ben nota classe AVAudioPlayer, poi è stato esteso in iOS 3 con il AVAudioRecorder e le classi AVAudioSession ma il set completo di funzionalità che consentono capacità video avanzate ha avuto luogo solo a partire dal iOS 4 e sono stati pienamente presentati al WWDC 2010.

            La posizione della AV Foundation nello iOS Frameworks stack si trova  sotto UIKit, dietro l’application layer, e immediatamente sopra i basic Core Services frameworks, in particolare Core Media che viene utilizzato da AV Foundation per importare strutture di temporizzazione e le funzioni necessarie per la gestione dei media . In ogni caso si può notare la diversa posizione nello stack rispetto Media Player di alto livello. Ciò significa che questo tipo di struttura non è in grado di offrire una classe plug-and-play  per la riproduzione di semplici video , ma si potranno apprezzare i moderni concetti di alto livello che sono alla base di questo framework, di sicuro non siamo allo stesso livello dei vecchi framework come core Audio.

             

            (image source: from Apple iOS Developer Library)

            Building blocks

            L’organizzazione dele classi di AV Fondation è abbastanza intuitiva. Il punto di partenza e il building block principale è data da AVAsset. AVAsset rappresenta un oggetto statico multimediale ed è essenzialmente un aggregato di tracce che sono rappresentazioni temporizzate  di una parte de media. Tutti i brani sono di tipo uniforme, in modo che possiamo avere tracce audio, tracce video, tracce sottotitoli, e un complesso di attività può essere fatto di più tracce dello stesso tipo, ad esempio siamo in grado di avere più tracce audio. Nella maggior parte dei casi un asset è fatto di un audio e una traccia video. Si noti che AVAsset è una classe astratta per cui è indipendente dalla rappresentazione fisica dei media che rappresenta, inoltre la creazione di un’istanza AVAsset non significa che noi abbiamo tutti i media pronti per essere riprodotti, si tratta di un puro oggetto astratto.


            Ci sono due classi di attività disponibili: AVURLAsset, per rappresentare un supporto in un file locale o in rete, e AVComposition (insieme con la sua variante mutevole AVMutableComposition ) per un’attività composta da più supporti. Per creare una risorsa da un file abbiamo bisogno di fornire l’URL del file:

            NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:AVURLAssetPreferPreciseDurationAndTimingKey];
            AVURLAsset *myAsset = [AVURLAsset URLAssetWithURL:assetURL options:optionsDictionary];

            L’ options dictionary poò risultare nullo ma per i nostri scopi – per fare una composizione film – abbiamo bisogno di calcolare la durata esatta e fornire l’accesso casuale ai media. Questa opzione extra, che è l’impostazione su YES della chiave AVURLAssetPreferPreciseDurationAndTimingKey, potrebbe richiedere più tempo durante l’inizializzazione delle attività, e questo dipende dal formato di film. Se questo film è in QuickTime o MPEG-4, il file contiene informazioni aggiuntive che in sintesi annulla il tempo in più, ma ci sono in altri formati, come MP3, in cui queste informazioni possono essere estratte solo dopo la decodifica del media file, in tal caso l’inizializzazione del tempo non è trascurabile. Si tratta di una prima raccomandazione che diamo agli sviluppatori: si prega di utilizzare il formato del file a seconda dell’applicazione.
            Nella nostra applicazione dobbiamo già conoscere le caratteristiche dei film che stiamo usando, ma in un diverso tipo di applicazione, in cui è necessario fare un po ‘di editing dei filmati, si può essere interessati a ispezionare le proprietà delle risorse. In tal caso si deve ricordare la regola di base che l’inizializzazione di un asset non significa aver caricato e decodificato in memoria: questo significa che ogni proprietà del file multimediale può essere ispezionata, ma questo potrebbe richiedere un poco di tempo in più. Per completezza abbiamo semplicemente introdotto il modo asset inspection che può essere fatto lasciando l’utente interessato alla documentazione di riferimento (vedere l’elenco proposto letture alla fine di questo post). Fondamentalmente ogni proprietà dell’attività può essere verificata utilizzando un protocollo asincrono chiamato AVAsynchronousKeyValueLoadingwhich che definisce due metodi:

            - (AVKeyValueStatus)statusOfValueForKey:(NSString *)key error:(NSError **)outError
            – (void)loadValuesAsynchronouslyForKeys:(NSArray *)keys completionHandler:(void (^)(void))handler

            Il primo metodo è sincrono e restituisce immediatamente lo stato di conoscenza del valore specificato. Ad esempio si può chiedere lo status di “durata” e il metodo restituisce uno di questi stati possibili: carico, carico, fallito, sconosciuto, annullato. Nel primo caso il valore di chiave è noto e quindi il valore può essere immediatamente recuperato. Nel caso in cui il valore è ignoto è opportuno richiamare le loadValuesAsynchronouslyForKeys:completionHandler: metodo che alla fine dell’operazione chiamerà il callback dato nel completionHandlerblock, che a sua volta interroga lo stato di nuovo per l’azione appropriata.

            Video composition

            Come abbiam detto all’inizio, il nostro storyboard è composto da una serie di scene e ogni scena è composta da diverse clip il cui ordine di riproduzione non è nota a priori. Ogni scena si comporta indipendentemente dalle altre in modo da creare una composizione per ogni scena. Quando abbiamo un insieme di attività, o tracce, e da loro si costruisce una composizione nel complesso stiamo creando un altro asset. Questo è il motivo per cui le classi AVComposition e AVMutableComposition sono sottoclassi della classe  AVAsset base.
            È possibile aggiungere contenuti multimediali all’interno di una composizione mutevole, semplicemente selezionando un segmento di un bene, e l’aggiunta di una gamma specifica di nuova composizione:

            - (BOOL)insertTimeRange:(CMTimeRange)timeRange ofAsset:(AVAsset *)asset atTime:(CMTime)startTime error:(NSError **)outError

            Nel nostro esempio abbiamo una serie di tracce che si desidera aggiungere una dopo l’altra per generare un insieme continuo di clip. Così il codice può essere semplicemente scritto in questo modo:

            AVMutableComposition = [AVMutableComposition composition];
            CMTime current = kCMTimeZero;
            NSError *compositionError = nil;
            for(AVAsset *asset in listOfMovies) {
            BOOL result = [composition insertTimeRange:CMTimeRangeMake(kCMTimeZero, [asset duration])
            ofAsset:asset
            atTime:current
            error:&compositionError];
            if(!result) {
            if(compositionError) {
            // manage the composition error case
            }
            } else {
            current = CMTimeAdd(current, [asset duration]);
            }
            }

            Prima di tutto abbiamo introdotto il concetto di tempo. Si noti che tutti i media hanno un concetto di tempo diverso dal solito. Prima di tutto il tempo può muoversi avanti e indietro, oltre il lasso di tempo può essere superiore o inferiore a 1x se si sta visionndo il filmato al rallentatore o in avanzamento rapido. Inoltre si ritiene più conveniente  rappresentare il tempo non come virgola mobile o un numero intero, ma come numeri razionali. Per tale ragioneil framework  Core Media  fornisce la CMTimestructure e un insieme di funzioni e macro che semplificano la manipolazione di queste strutture. Quindi, al fine di costruire una specifica istanza time instance:

            CMTime myTime = CMTimeMake(value,timescale);

            che infatti specifica un numero di secondi proposto dal value/timescale. La ragione principale di questa scelta è che i film sono fatti di frames e i fotogrammi sono dati ad una razione fissa al secondo. Così, per esempio, se abbiamo una clip che è stata ripresa a 25 fps, allora sarebbe conveniente per rappresentare l’intervallo singolo fotogramma come un insieme variabile CMTime con valore = 1 e tempi = 25, corrispondente a 1/25th di secondo. 1 secondo  è dato da un CMTime con valore = 25 e timescale = 25, e così via (ovviamente si può ancora lavorare con i secondi, se volete, è sufficiente utilizzare i CMTimeMakeWithSeconds (seconds) function). Quindi, il codice di cui sopra inizialmente imposta l’ora corrente a 0 secondi (kCMTimeZero) quindi avvia l’iterazione su tutti i nostri film che sono assets in. Poi si aggiunge ciascuna di questi asset nella posizione corrente della nostra composizione con la loro gamma completa ([asset duration]). Per ogni asset spostiamo la composition head (current) per la lunghezza (in CMTime) dell’asset. A questo punto la composizione è fatta di un set completo di brani aggiunti in sequenza. Ora possiamo giocare.

            Playing an asset

            Il framework AVFoundation non offre alcuna player integrato, come siamo abituati a vedere con MPMovieViewController. Il motore che gestisce lo stato di riproduzione di un asset è fornito dalla classe AVPlayer. Questa classe si occupa di tutti gli aspetti relativi al play dell’asset ed essenzialmente è l’unica classe in AV Foundation che interagisce con i controller di visualizzazione dell’applicazione per mantenere in sincronia la logica dell’applicazione con lo stato di riproduzione: questo è rilevante per il tipo di applicazione che stiamo prendendo in considerazione in questo esempio, come lo stato di riproduzione può cambiare durante l’esecuzione del filmato base alle specifiche interazioni dell’utente  in momenti specifici all’interno del film. Tuttavia non abbiamo una relazione diretta tra AVAsset e AVPlayer, la loro connessione è mediata da un’altra classe denominata AVPlayerItem. Questa organizzazione delle classi ha lo scopo di separarel’asset, considerato come un’entità statica, dal player, puramente dinamico, fornendo un oggetto intermedio, che rappresenta uno stato specifico di presentazione di un asset. Ciò significa che per un determinat e unicoo asset  possiamo associare elementi di più players, tutti  rappresentano diversi stati dello stesso asset e eseguito da diversi players. Quindi, il flusso in questo caso è dato da un determinato asset che crea un elemento di player e poi lo assegna al pleyer finale.

            AVPlayerItem *compositionPlayerItem = [AVPlayerItem playerItemWithAsset:composition];
            AVPlayer *compositionPlayer = [AVPlayer playerWithPlayerItem:compositionPlayerItem];

             

            Al fine di eseguire il rendering sullo schermo, dobbiamo fornire una view in grado di rendere lo stato attuale di player. Abbiamo già detto che iOS non offre on-the-shelf una vista per questo scopo, ma quello che offre è un livello speciale CoreAnimation chiamato AVPlayerLayer. Quindi è possibile inserire questo livello nella gerarchia a livello di Anteprima del player o, come nel seguente esempio, utilizziamo questo come livello di base per questa view. Quindi, l’approccio suggerito in tal caso è quello di creare un MovieViewer personalizzato e il  set AVPlayerLayeras base layer class:

            // MovieViewer.h

            #import <UIKit/UIKit.h>
            #import <AVFoundation/AVFoundation.h>
            @interface MovieViewer : UIView {
            }
            @property (nonatomic, retain) AVPlayer *player;
            @end

            // MovieViewer.m

            @implementation MovieViewer
            + (Class)layerClass {
            return [AVPlayerLayer class];
            }
            – (AVPlayer*)player {
            return [(AVPlayerLayer *)[self layer] player];
            }
            – (void)setPlayer:(AVPlayer *)player {
            [(AVPlayerLayer *)[self layer] setPlayer:player];
            }
            @end

            // Intantiating MovieViewer in the scene view controller
            // We suppose “viewer” has been loaded from a nib file
            // MovieViewer *viewer
            [viewer setPlayer:compositionPlayer];

            A questo punto siamo in grado di riprodurre il filmato, che è abbastanza semplice:

            [[view player] play];
            Osservando il playback status

            È rilevante per la nostra applicazione  monitorare lo stato della riproduzione e osservare alcuni particolari eventi temporizzati  durante la riproduzione.
            Per quanto riguarda il monitoraggio dello stato, si seguirà l’approccio standard basato KVO osservando i cambiamenti nella proprietà dello stato del player:

            // inside the SceneViewController.m class we’ll register to player status changes
            [viewer.player addObserver:self forKeyPath:@"status" options:NSKeyValueObservingOptionNew context:NULL];

            // and then we implement the observation callback
            -(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
            if(object==viewer.player) {
            AVPlayer *player = (AVPlayer *)object;
            if(player.status==AVPlayerStatusFailed) {
            // manage failure
            } else if(playe.status==AVPlayerStatusReadyToPlay) {
            // player ready: manage success state (e.g. by playing the movie)
            } else if(player.status==AVPlayerStatusUnknown) {
            // the player is still not ready: manage this waiting status
            }
            }
            }

            Diversamente dalle KVO-observable properties l’ osservazione di eventi  non è basata su KVO: la ragione di questo è che la player head si muove continuamente e solitamente la riproduzione viene effettuata su un thread dedicato. Quindi il sistema preferisce certamente  inviare notifiche suoi attraverso un canale dedicato, che in questo caso consiste in un block-based callback che possiamo registrare per monitorare tali eventi. Ci sono due modi per osservare eventi programmati:

            • registering for periodic intervals notifications
            • registering when particular times are traversed

            In entrambi i metodi l’utente sarà in grado di specificare una serial queue in cui i richiami saranno spediti (e il default è la coda principale) e, naturalmente, il blocco callblack. E ‘importante notare il comportamento della serial queue: ciò significa che tutti gli eventi verranno messi in coda ed eseguiti uno dopo l’altro, per gli eventi frequenti è necessario assicurarsi che questi blocchi sono eseguiti abbastanza velocemente da permettere alla coda si elaborare i blocchi successivi, e questo è particolarmente vero se si sta eseguendo il blocco nel thread principale, al fine di evitare all’applicazione di non rispondere. Non dimenticate di programmare questo blocco da eseguire nel thread principale se si aggiorna l’interfaccia utente.
            La registrazione ad intervalli periodici è fatta in questo modo, dove chiediamo un callback 1 secondo il cui scopo principale sarà quello di aggiornare l’interfaccia utente (in genere l’aggiornamento di un barra di avanzamento e il tempo di riproduzione corrente):

            // somewhere inside SceneController.m
            id periodicObserver = [viewer.player addPeriodicTimeObserverForInterval:CMTimeMakeWithSeconds(1.0) queue:NULL usingBlock:^(CMTime time){
            [viewer updateUI];
            }];
            [periodicObserver retain];

            // and in the clean up method
            -(void)cleanUp {
            [viewer.player removeTimeObserver:periodicObserver];
            [periodicObserver release];
            }

            // inside MovieViewer.m
            -(void)updateUI {
            // do other stuff here
            // …
            // we calculate the playback progress ratio by dividing current position of playhead into the total movie duration
            float progress = CMTimeGetSeconds(player.currentTime)/CMTimeGetSeconds(player.currentItem.duration);
            // then we update the movie viewer progress bar
            [progressBar setProgress:progress];
            }

             

            LA eegistrazione agli  timed events viene fatta usando un metodo simile che prende come argomento una lista di rappresentazioni NSValue di CMTime (AVFoundation fornisce una categoria NSValue che aggiunge il supporto a CMTime NSValue):

            // somewhere inside SceneController.m
            id boundaryObserver = [viewer.player addBoundaryTimeObserverForTimes:timedEvents queue:NULL usingBlock:^{
            [viewer processTimedEvent];
            }];
            [boundaryObserver retain];// inside MovieViewer.m
            -(void)processTimedEvent {
            // do something in the UI
            }
            In both cases we need to unregister and deallocate somewhere in our scene controller the two observer opaque objects; we may suppose the existence of a cleanup method that will be assigned this task:
            -(void)cleanUp {
            [viewer.player removeTimeObserver:periodicObserver];
            [periodicObserver release];
            [viewer.player removeTimeObserver:boundaryObserver];
            [boundaryObserver release];
            }

            Anche se questo codice è il modo generale di chiamare un evento, nella nostra applicazione è più opportuno assegnare ad ogni evento una specifica azione,  abbiamo bisogno di personalizzare ogni blocco di comunicazione. Guardando l’immagine qui sotto, si può vedere che a specifici intervalli di tempo all’interno di ciascuna delle nostre clip abbiamo assegnato un evento specifico.


            La figura è piuttosto complesso e non tutte le relazioni sono state evidenziate. Essenzialmente quello che potete vedere è la sequenza  “vincente” in tutti i blocchi verdi: sono stati posizionati in modo consecutivo, al fine di evitare il salto dell’indicatore di riproduzione sei diversi segmenti in cui il giocatore prende le decisioni giuste, in modo che la riproduzione continua senza interruzioni e sarà liscio. Con l’eccezione della traccia prologo, che è solo un prologo della storia e nessuna interazione con l’utente è richiesta in questa fase, ed è la conclusione corrispondente, semplicemente un epilogo quando l’utente è invitato a passare alla scena successiva, tutte le altre tracce sono stato caratterizzate da alcuni eventi temporizzati, identificati con le linee rosse tratteggiate verticali. In sostanza abbiamo individuato 4 tipi di eventi:

            • segment (clip) starting point: this will be used as a destination point for the playhead in case of jump;
            • show controls: all user controls will be displayed on screen, user intercation is expected;
            • hide controls: all user controls are hidden, and no more user interaction is allowed;
            • decision point, usually coincident with the hide controls event: the controller must decide which movie segment must be played based on the user decision.

            Si noti che questo approccio è molto flessibile e, in teoria, è possibile qualsiasi tipo di evento, questo dipende dalla fantasia dei game designer. Dal punto di vista del codice, abbiamo infatti la sottoclasse AVURLAsset aggiungendo una serie di eventi cronometrati. Al momento della  composizione, questo evento sarà nuovamente temporizzata secondo la base di un nuovo tempo (ad esempio: se un evento viene giocato al secondo 0:35 di una clip, ma il punto di partenza della clip è esattamente a 1: 45 della intera sequenza, il caso deve essere ri-programmato per 1:45 + 0:35 = 2,20). A questo punto, con l’elenco completo degli eventi è possibile riscrivere la registrazione confine:

            // events is the array of all re-timed events in the complete composition
            __block __typeof__(self) _self = self; // avoids retain cycle on self when used inside the block
            [events enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
            TimedEvent *ev = (TimedEvent *)obj;
            [viewer.player addBoundaryTimeObserverForTimes:[NSArray arrayWithObject:[NSValue valueWithCMTime:ev.time]]
            queue:dispatch_get_main_queue()
            usingBlock:^{
            // send event to interactiveView
            [viewer performTimedEvent:ev];
            [_self performTimedEvent:ev];
            }];
            }];

             

            Come si può vedere il codice è molto semplice: per ogni evento programmato si registra l’unico limite che chiama semplicemente due metodi, uno per il lettore di film e uno per il controllo delle scene, in entrambi i casi dobbiamo inviare l’evento specifico in modo che il ricevitore sappia esattamente cosa fare. Il visualizzatore di norma prenderà cura dell’ interazione utente (che si sovrapporrà un paio di controlli sulla parte superiore dello strato di giocatore, quindi a seconda degli eventi  questi controlli saranno visualizzati o nascosti, inoltre lo spettatore sa che il controllo è stato selezionato dall’utente), mentre lo scene controller gestirà la logica del gioco, specialmente nel caso degli eventi decisione. Quando il controller rileva un evento di decisione, deve spostare la barra nella giusta posizione nella composizione:

             

            CMTime goToTime = # determines the starting time of the next segment #
            [viewer hide];
            [viewer.player seekToTime:goToTime toleranceBefore:kCMTimeZero toleranceAfter:kCMTimePositiveInfinity completionHandler:^(BOOL finished) {
            if(finished) {
            dispatch_async(dispatch_get_main_queue(), ^{
            [viewer show];
            });
            );
            }];

             

            Che cosa succede nel codice qui sopra nel caso in cui abbiamo bisogno di spostare la barra di un timing specifico, per prima cosa determiniamo questo tempo e poi chiediamo all’istanza AVPlayer di cercare , questa volta cercando di spostare la testina (head) in questa posizione o dopo con un po ‘tolleranza (kCMTimePositiveInfinity) ma non prima (kCMTimeZero nel toleranceBefore: parametro; abbiamo bisogno di questo perché la composizione è fatta di tutti i clip consecutivi e quindi spostando la testina prima dell’ora di partenza della clip potrebbe mostrare una piccola porzione del clip precedente). Notare che questa operazione non è immediata e anche se abbastanza veloce potrebbe richiedere un secondo circa. Cosa succede durante questa transizione , il livello player mostrerà una cornice ancora da qualche parte nella regione di timing di destinazione, che inizierà la clip completa di decodifica e riprende la riproduzione a partire da un altro frame, in genere diverso da quello precedente. L’effetto finale non è veramente buono e, dopo una sperimentazione abbiam deciso di nascondere il livello player immediatamente prima di iniziare la ricerca e mostralo di nuovo non appena il la classe player ci informa (attraverso il blocco di callback completionHandler) che il film è pronto per essere riprodotto .

            Conclusioni e references

            Speriamo che questo lungo articolo spingerà altri sviluppatori ad iniziare a lavorare su applicazioni per film interattivi e  che cercheranno di sfruttare le funzionalità avanzate di editing video per iOS. Il framework AVFoundation ci offre strumenti molto potenti e che non sono difficili da usare. In questo post non abbiamo esplorato alcune classi più avanzate, come ad esempio AVVideoComposition e AVSynchronizedLayer. La prima è utilizzata per creare transizioni, l’ultima è utilizzato per sincronizzare effetti di animazione di base con la temporizzazione interna media.

            Grandi riferimenti sull’argomento si possono trovare nella  iOS Developer Library o i video WWDC con codice di esempio:

            • For a general overview: AVFoundation Programming Guide in the iOS Developer Library
            • For the framework classes documentation: AVFoundation Framework Reference in the iOS Developer Library
            • Video: Session 405 – Discovering AV Foundation from WWDC 2010, available in iTunesU to registered developers
            • Video: Session 407 – Editing Media with AV Foundation from WWDC 2010, available in iTunesU to registered developers
            • Video: Session 405 – Exploring AV Foundation from WWDC 2010, available in iTunesU to registered developers
            • Video: Session 415 – Working with Media in AV Foundation from WWDC 2011, available in iTunesU to registered developers
            • Sample code: AVPlayDemo from WWDC 2010 sample code repository
            • Sample code: AVEditDemo from WWDC 2010 sample code repository

             

            Translated from Carlo’s post

              iPhone5 ha uno schermo più grande rispetto ai suoi precedessori. Gli sviluppatori di iOS6 devono supportare risoluzioni di 640 x 1136 px al posto di 640 x 960 px dell’iPhone4.
              Ma anche in questo caso se si segue la logica Apple il lavoro da fare non è per nulla complicato.

              Il blog http://blog.mugunthkumar.com/coding/supporting-the-iphone-5/ propone di seguire quattro fasi:

              Fase 1:

              iPhone 5 richiede un nuovo set di istruzioni, le armv7s. Solo nell’ultima versione Xcode ( 4.5) supporta la generazione del set istruzioni armv7s. Doa notare che, Xcode 4,5 non supporta più armv6 e depreca iPhone 3G e i dispositivi più vecchi. Quindi bisogna ora sviluppare le nostre applicazione utilizzando Xcode 4,5

              Fase 2:

              Il passo successivo è quello di aggiungere una immagine di lancio (Default-568h@2x.png). Quando si genera il progetto con Xcode 4.5, viene visualizzato un avviso, “Missing Retina 4 launch image”. Fare clic su “Aggiungi” per aggiungere un immagine di default al progetto.

              Al lancio dell’ app apparirà in full screen on iPhone 5

              Fase 3:

              Tuttavia, la maggior parte dei nib file non sarà ancora in scalata correttamente. Il passo successivo è quello di controllare la maschera ridimensionamento automatico (auto resizing mask) di tutti i file nib e assicurarsi che la vista (view) all’interno del file nib si dimensioni automaticamente in base alla nuova altezza della vista.

              Le proprietà che si usano sono:

              UIViewAutoresizingFlexibleTopMargin,
              UIViewAutoresizingFlexibleBottomMargin,
              UIViewAutoresizingFlexibleHeight.

              Si utilizza la UIViewAutoresizingFlexibleHeight per la visualizzazione on top in modo che auto dimensioni con la finestra principale. Si utilizza il UIViewAutoresizingFlexibleTopMargin e / o UIViewAutoresizingFlexibleBottomMargin per subviews.

              UIViewAutoresizingFlexibleTopMargin viene utilizzato se si desidera che la visualizzazione secondaria eimanga “inchiodata” alla parte inferiore (il margine superiore è flessibile) e UIViewAutoresizingFlexibleBottomMargin viene utilizzato se si desidera che la visualizzazione secondaria sia “inchiodata” alla parte superiore (iò margine inferiore è flessibile).

              Se invece si utilizza Cocoa auto Layout, questo passaggio diventa facoltativo. Tuttavia, l’auto Layout non è supportato su iOS 5.

              Fase 4:

              Infine, qualsiasi Layer che avete aggiunto alla vista dovrà essere ridimensionato manualmente. Il codice seguente mostra come eseguire questa operazione. Usiamo patternLayer per aggiungere un pattern per tutti i view controller. È necessario ridimensionare  nel metodo viewWillLayoutSubviews.

              -(void)viewWillLayoutSubviews {
              
              self.patternLayer.frame = self.view.bounds;
              [super viewWillLayoutSubviews];
              }Step 5 (if you were a messy coder):

               

              Fase 5

              Se l’altezza della view è stata codificato  a 460 o 480, potrebbe essere necessario cambiarle tutte  iinsrendo bounds. Ad esempio,

              self.window = [[UIWindow alloc] initWithFrame: [[mainScreen UIScreen] bounds]];

              invece di

              self.window = [[UIWindow alloc] initWithFrame: CGRectMake (0, 0, 320, 480)];

               

              Creare immagini con le nuove dimensioni

              Come ho potuto constatare sul blog http://redth.info/get-your-monotouch-apps-ready-for-iphone-5-ios-6-today/ , purtroppo, la convenzione di denominazione di immagini-568h @ 2x.png sembra solo di essere utilizzata per l’immagine di default, ma non viene applicata per le altre immagini dell’ applicazione. Ciò significa che se si sta utilizzando un’immagine di sfondo personalizzata per la visualizzazione (ad esempio: UITableView background), è probabile che sia necessario creare una nuova immagine di sfondo alla risoluzione corretta, e determinare nell’applicazione quando utilizzare ciascuna immagine.
              Sarebbe bello se Apple avesse esteso nel nuovo SDK il supporto al nuovo schermo per mezzo del metodo:
              [UIImage imageNamed:@"my-image"]
              Attualmente possiamo indicare per “my-image” il nome della mia immagine (anche senza estensione) e il sistema operativo effettua la ricerca dell’immagine nell’application bundle secondo questo criterio: se lo schermo è di tipo retina cerca un’immagine con il suffisso @2x nel nome, se non la trova va a cercare l’immagine senza suffisso. Ci saremmo aspettati da parte di Apple l’estensione dell’algoritmo includendo la possibilità di cercare per il suffisso -568h@2x nel caso di schermo da 4″. Purtroppo non è così e per questo motivo dovremo codificare la cosa espressamente nel nostro codice.

              Per esempio, nella nostra app non-4inch  compatibile, ho due immagini:

              Images / TableViewBackground.png – 320×358
              Images / TableViewBackground@2x.png – 640×716

              Con la nuova risoluzione, ho bisogno di creare una terza immagine (abbiamo deciso di utilizzare l’opzione-568h @ 2x.png convenzione di denominazione, anche se non è processata da Apple):

              Images/TableViewBackground-568h@2x.png

              Un approccio elegante è quello di creare una nuova categoria per la classe UIImage (che definiamo con poca fantasia UIImage+Retina4), e effettuare a runtime all’interno della categoria una sostituzione del metodo “imageNamed:” con uno che gestisca la nuova convenzione:


              // all'interno di UIImage+Retina4.h
              #import

              @interface UIImage (Retina4)

              @end

              // all’interno di UIImage+Retina4.m
              #import “UIImage+Retina4.h”
              #ifdef TARGET_MAC_OS
              #import
              #else
              #import
              #endif

              static Method origImageNamedMethod = nil;

              @implementation UIImage (Retina4)

              + (void)initialize {
              origImageNamedMethod = class_getClassMethod(self, @selector(imageNamed:));
              method_exchangeImplementations(origImageNamedMethod,
              class_getClassMethod(self, @selector(retina4ImageNamed:)));
              }

              + (UIImage *)retina4ImageNamed:(NSString *)imageName {
              NSMutableString *imageNameMutable = [imageName mutableCopy];
              NSRange retinaAtSymbol = [imageName rangeOfString:@"@"];
              if (retinaAtSymbol.location != NSNotFound) {
              [imageNameMutable insertString:@"-568h" atIndex:retinaAtSymbol.location];
              } else {
              CGFloat screenHeight = [UIScreen mainScreen].bounds.size.height;
              if ([UIScreen mainScreen].scale == 2.f && screenHeight == 568.0f) {
              NSRange dot = [imageName rangeOfString:@"."];
              if (dot.location != NSNotFound) {
              [imageNameMutable insertString:@"-568h@2x" atIndex:dot.location];
              } else {
              [imageNameMutable appendString:@"-568h@2x"];
              }
              }
              }
              NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageNameMutable ofType:@”png”];
              if (imagePath) {
              return [UIImage retina4ImageNamed:imageNameMutable];
              } else {
              return [UIImage retina4ImageNamed:imageName];
              }
              return nil;
              }

              @end

              Quel che fa questo codice è in fase di inizializzazione sostituire l’implementazione di Apple di “imageNamed:” con la nostra “retina4ImageNamed:” (e viceversa). Nel momento stesso in cui il runtime chiama “imageNamed:” in realtà andrà a richiamare la nostra funzione che andrà a caricare l’immagine ottimizzata per lo schermo a 4″ a condizione che sia presente e che stiamo eseguendo l’app su un device con tale schermo (incluso il simulatore). Nel caso l’immagine non fosse presente o lo schermo fosse il tradizione 3.5″ allora verrebbe chiamata la funzione originale (rinominata a causa dello scambio iniziale).
              Ovviamente questa implementazione non può essere usata nel caso il caricamento delle immagini avvenga esplicitamente per mezzo di chiamate del tipo
              [UIImage imageWithContentsOfFile:...]
              in cui il nome del file va costruito in maniera esplicita.

                Il fuggitivo dello spazio, missione a Roma

                Il fuggitivo dello spazio, missione a Roma.
                Disponibile su App Store

                Il fuggitivo e’ arrivato!

                Il fuggitivo dello Spazio e’  il primo gioco cinematografico interamente dedicato alle bellezze di Roma.
                E’ un  movie game interattivo e divertente dedicato alle famiglie o a tutti coloro che si vorranno cimentare in questa interessante avventura,  compresi bambini e adolescenti.
                Interamente girato nella città di Roma, in Italia, è un gioco divertente e didattico. Vi permetterà di scoprire le meraviglie della città eterna e contemporaneamente seguire la storia e le avventure del protagonista, il nostro Fuggitivo nello Spazio.

                Scaricalo su App Store

                La Storia

                Il giovane Fuggitivo è appena arrivato sul pianeta Terra e si trova a passeggiare per la splendida città di Roma vicino al Colosseo, tra le rovine romane.
                E’ arrivato dal suo pianeta NubiriX utilizzando il tele-trasporto. E’ fuggito dal proprio pianeta d’origine perchè non voleva sposare una ricca e potente principessa del suo regno alla quale era stato promesso sposo.
                Essendo il nostro amico sempre stato un tipo romantico e dato che l’aspetto della sua promessa sposa non poteva ispirare il vero amore, decide di scappare sulla Terra seguendo l’istinto e il proprio cuore.
                Purtroppo la brutta principessa, dopo aver saputo della fuga,  ha ingaggiato il capo delle Guardie Reali per dare la caccia al suo promesso sposo con la speranza di riportarlo a casa.
                Il cattivo, assieme al suo equipaggio, parte nell’iperspazio seguendo le tracce lasciate dal tele-trasporto così da portare la navicella spaziale aliena nel sistema solare e poi sulla Terra.
                Gli inseguitori non hanno però informazioni affidabili sul nostro amato pianeta Terra e sopratutto, durante il viaggio,  riescono a visualizzare sul computer di bordo delle Guardie Reali solo alcune immagini della città di Roma che, essendo il pianeta Nubirix a più di 2000 anni luce dalla terra, si riferiscono alla Roma Imperiale di 2000 anni fa…

                Riuscirà il nostro Fuggitivo a sfuggire ai suoi inseguitori e a trovare il vero amore sulla Terra?

                La sorte del Fuggitivo è ora nelle vostre mani.

                Clicca Qui per il download su App Store

                RSS: http://itunes.apple.com/it/rss/customerreviews/id=506689674/sortBy=mostRecent/xml

                Alcune immagini:

                  i3Factory ha sviluppato e  pubblicato per conto di ISNART e per il Ministero delle Politiche Agricole e Forestali e di Unioncamere ,sugli App store Apple e Android queta interessante e utile applicazione applicazione:

                  10Q Ricette Italiane

                  Descrizione

                  10Q Ricette Italiane è un APP con oltre 1000 ricette italiane scelte tra le più rappresentative a livello regionale e tra le più note nel mondo e rappresenta un viaggio gastronomico che permette di conoscere virtualmente l’Italia, attraverso i suoi sapori tipici.

                  Lo scopo è di far conoscere nel dettaglio le caratteristiche qualitative dei prodotti a denominazione d’origine (239 tra DOP – IGP –STG), prodotti che rendono unico un piatto grazie alla tradizione, al lavoro ed alla dedizione dei produttori presenti esclusivamente su alcuni territori italiani.

                  I Ristoranti Italiani nel mondo segnalati mettono a disposizione i piatti presenti nel loro menu, arricchendo costantemente questa APP.

                  Consultando le “Ricette” si accede facilmente agli ingredienti che occorrono, alle modalità di preparazione, alla località di produzione degli ingredienti (con chiare mappe geo-referenziate) e alle informazioni turistiche per conoscere al meglio i territori di riferimento.

                  Non avete voglia di fare la spesa e volete usare gli ingredienti che avete a casa (frigo/dispensa)? Niente di più semplice: inserite gli ingredienti a vostra disposizione e l’APP vi fornirà tutte le ricette che li contengono, suggerendovi anche qualche curiosità sugli ingredienti a denominazione di origine. Se poi non siete soddisfatti della riuscita del vostro piatto, potete sempre ricorrere alla lista dei ristoranti dove è possibile assaggiare la ricetta che avete scelto e il palato sarà soddisfatto!

                  Buon appetito a tutti, augurandovi di poter fare presto un viaggio del gusto in Italia, alla scoperta di quei territori che rendono speciali i prodotti tipici!

                  E’ una iniziativa del Ministero delle Politiche Agricole e Forestali e di Unioncamere

                  Di seguito trovate i link per scaricare l’applicazione Ricette Italiane 10Q.

                  Link per Android: https://play.google.com/store/apps/details?id=ricetteItaliane.Fragment&feature=search_result#?t=W10

                  Link per iOS (iPhone, iPod Touch e iPad): http://itunes.apple.com/us/app/10q-ricette-italiane/id510911650?mt=8

                    Recentemente in alcune app, abbiamo notevolmente diminuito le dimensioni del file IPA che inviamo ad Apple.
                    Sviluppando un’app con molti contenuti grafici siamo riusciti a ridurre di circa il 60% la dimensione del pacchetto da inviare ad Apple, il cosidetto bundle file.

                    Quando si sviluppa un’ universal  iPad / iPhone app e , sopratutto, se si vuole aggiungere il supporto per la visualizzazione retina per  il nuovo iPad 3 possiamo incombere i dimesioni del pacchetto piuttosto eccessive.
                    Molte app vengono pensata per avere una moltitudine textures a schermo intero , questo accade in quanto molti designers preferiscono illustrare al meglio le proprie idee. Tali immagini ,se pensate per iPad 3, alla dimesione di 2048 x 1536 e in formato PNG possono risultare molto pesanti. La conversione di alcune di queste immagini in formato JPEG farà risparmiare parecchio spazio.
                    E ‘un peccato che le jpeg non vengono caricate più rapidamente, ma alcuni PNG che possono essere anche maggiori du 10MB , quando vengono convertote in jpeg pesano circa ~ 200Kb.
                    Questo è  un buon primo passo, ma bisogna stare molto attenti a non deteriorare la qualità.

                    La conversione da png a jpg non basta: anche dopo aver convertito il maggior numero di grandi texture il peso del bundle IPA puo’ risultare ancora consistente.
                    Il nostro obiettivo è quello di essere quasi sempre sotto i 20 MB cosi’ che i vecchi dispositivi possano scaricare l’app anche senza il WiFi.

                    ImageOptim: Basterà lanciare al suo interno la singola immagine o anche un gruppo, e saranno immediatamente compressi senza ridurre la qualità . Si riduce in media di circa il 15–35 %

                    Leggendo tra i diversi siti ho trovato alcuni utili consigli nel blog di Sam Soffes (http://samsoff.es/posts/image-optimization-on-ios ) che in suo articolo consiglia l’utilizzo di  ImageOptim, un piccolo programma che ottimizza le immagini. Con questa app per Mac osx i flis vengono processato in modo da occupare meno spazio su disco e in modo che possano essere caricate più velocemente , attraverso l”uso de i migliori parametri di compressione provvedendo a rimuovere i commenti inutili e i profili colore. Il software gestisce PNG, JPEG e GIF animate.
                    ImageOptim integra perfettamente  i vari strumenti di ottimizzazione: PNGOUT, AdvPNG, pngcrush, esteso OptiPNG, jpegoptim, jpegrescan, jpegtran e Gifsicle.
                    Particolarmente adatto per la pubblicazione di immagini sul web (restringe facilmente le immagini  “salvate” per il Web in Photoshop) si è rivelto utile per creare applicazioni Mac e iPhone / iPad sempre più leggere.

                    Inoltre è possibile convertire molte immagini come PNG8;  in Photoshop, nel sezione File>Salva per Web  e’ possibile esportare come PNG8 invece di PNG24 quelle immagini che vanno bene come GIF. Anche se non supporta alpha variabile, è ideale per immagini semplici.
                    Sam considera  ImageOptim addirittura fantastico; processa le immagini attraverso una serie di strumenti comprimendo il più possibile e senza ridurre la qualità. Anche se avete salvato “for-web” tutte le immagini, ImageOptim è in grado di comprimere ancora oltre il 50%. Alcuni files hanno un incredibile riduzione sino al  90%.

                    Sam ha processato tutte le immagini attraverso ImageOptim per ben due volte. La seconda volta è stato in grado di comprimere alcune immagini ancora più in profondità.
                    E’ importante notare che tutto questo è fatto in compressione lossless.

                    E’ possibile di rendere le immagini ancora più leggere con ImageAlpha (dai creatori di ImageOptim). Si tratta di uno strumento che permette di creare immagini con alpha PNG8 variabile.
                    Ciò farà risparmiare molto spazio. Si tratta di un processo più manuale rispetto a ImageOptim, ma funziona bene per ingrandire le immagini con alpha che non hanno un molti colori.

                    Nota: Assicuratevi di disattivare l’ottimizzazione delle immagini Xcode o si annullerà tutto il vostro duro lavoro, quando crerete il vostro bundle.

                    Conclusione

                    Abbiamo sentito pareri contrastanti su questi prodotti. Alcuni sostengono di aver avuto problemi con questi strumenti, mentre altri sono pienamente soddisfatti.
                    Secondo la nostra esperienza tutto funziona abbastanza bene;
                    se state cercando di ridurre la dimensione dell’app (bundle), raccomandiamo quindi di utilizzare questi strumenti.

                    Per i piu’ esperti:
                    Se si desidera provare a fare una compressione ancora più elevata, potete provare ad utilizzare il fork di Scribd del AdvanceCOMP di John Englehart (il creatore di JSONKit);
                    si tratta di un prodotto un po troppo hardcore, ma si consiglia comunque -ai piu’ smanettoni- di fare un tentativo.

                      Yahoo! lancia Axis (http://axis.yahoo.com/) , sia  come plugin per computer che come app iOS per iPhone e iPad.

                      Il nuovo browser permette la navigazione in modalità del tutto grafica, praticamente il web appare come un magazine , una vera e propria rivista per il web.

                      Yahoo! propone Axis per PC o Mac come estesione (plug-in) di Safari, Chrome e Firefox, e si limita ad apparire in un box in basso che visualizza una barra per ricerca alternativa, che e’  basata su Bing. Inoltre Axis permette la sincronizzazione automatica tra PC e dispositivi smartphone (per il momento iOS Apple ma presto anche per Android), come i segnalibri, cronologia e le ricerche possono essere condivise tra i diversi dispositivi (iPhone e iPad  e iPod Touch).

                      Rapidià:
                      Yahoo! cerca di stupire con la rapidità della risposta. L’app è in grado di offrire dei risultati mentre si scrive, con priorità sulle informazioni meteo e dati su mappa, oppure offre dei semplici sugerimenti visivi delle pagine a cui porterebbe il completamento della digitazione. Quet’ultimo aspetto, ad alcuni, sembra essere stato ispirato dal progetto di motore di ricerca italiano Volunia (http://www.volunia.com).

                      Privacy:
                      I risulati suggeriti sono mostrati in base alle precedenti navigazioni effettuate dall’utente. Rumors in rete sostengono che alcuni sviluppatori abbiano già individuato un bug all’interno dell’estensione Chrome di Axis, che renderebbe poco sicuri i dati di navigazione degli utenti. Tale bug avrebbe già costretto Yahoo! a disabilitare il plugin per  Google Chrome .

                      Il web è un’immagine:
                      Esplorare la rete con  Axis equivale, di fatto, a navigare sfogliando un magazine illustrato del web con particolare attenzione all’argomento di ricerca.
                      Axis è incentrato su due punti chiave: la ricerca – affidata per accordo a Bing di Microsoft, nonostante il search sia stata, storicamente, la funzione primaria di Yahoo! – e le immagini, che sono lil modo in cui vengono visualizzati i risultati.
                      Un’esperienza simile a quella presentata da alcune estensioni per browser come ad esempio Cooliris (http://www.cooliris.com/).
                      Cio’ che pero’ sembra essere molto valido in Axis è proprio la sincronia, rendendo la navigazione contigua su tutti i dispositivi che adremo a registrare; il risultato è che possiamo interrompere una sessione sul computer per poi prendere il tablet e continuare esattamente dal quel punto.

                      Yahoo! si rilancia:
                      Yahoo comprende che gli utilizzatori di internet hanno molta dimestichezza con i tablet , sopratutto con iPad di Apple.
                      Axis si presenta in maniera intuitiva e semplice e se Yahoo riuscirà ad integrarla con i servizi di cui già dispone, potrebbe rilanciarsi a sorpresa in quella new economy nata dal modello dell’app store.