MIT App Inventor 2 per l’apprendimento – Immagini e grafica: elementi essenziali di personalizzazione

Post tecnico, più volte promesso, per affrontare, almeno in parte, le problematiche relative all’utilizzo di grafica con MIT App Inventor.

Se proponiamo uno strumento come MIT App Inventor 2 per sviluppare esperienze educative digitali è perché crediamo nelle sue potenzialità di personalizzazione (tagliare un abito, formativo, su misura).

E’ chiaro che immagini (e grafica in generale) sono una parte importantissima nella individualizzazione dell’interfaccia utente della nostra App.

Abbiamo già visto semplici esempi di App personalizzabili (e rese quindi concrete e significative per il singolo utilizzatore) utilizzando immagini acquisite con la fotocamera del telefono o del tablet.

Proprio però la gestione di immagini ed elementi grafici (Canvas, Sprite) può creare qualche grattacapo, soprattutto nel rendere la nostra App compatibile con dispositivi differenti per grandezza schermo e risoluzione.

MIT App Inventor 2 gestione immagini risoluzione tablet apprendimento

La questione è un po’ tecnica e complessa e può essere appieno compresa, a mio modo di vedere, solo scontrandosi con la problematica e sperimentando soluzioni.

Fixed Design

Fino alla metà del 2015, MIT App Inventor 2 non dava strumenti per gestire schermi di risoluzione differente da quella standard (320 pixel di larghezza per 480 pixel di altezza): il risultato erano App molto sgranate nei dispositivi più grandi.

C’era però una soluzione abbastanza funzionale, anche se un po’ macchinosa, basata sui seguenti passi:

  • Durante l’inizializzazione della App calcolare il rapporto tra le dimensioni reali dello schermo e quelle teoriche di MIT App Inventor.
  • Ri-scalare le dimensioni di tutti gli oggetti (dai Bottoni, ai Canvas, agli Sprite) moltiplicando altezza e larghezza impostate nel Designer per il fattore di scala calcolato al punto 1.

MIT App Inventor 2 Immagini Canvas Risoluzione schermo

Ecco un Tutorial che vi accompagna passo passo ed in modo molto semplice alla risoluzione del problema.

Responsive Design

Da agosto 2015, lo Staff del MIT di Boston ha licenziato una versione di MIT App Inventor 2 che inizia a prendere seriamente in considerazione le problematiche di differente risoluzione dei dispositivi.

Approfondiamo il tema prendendo in considerazione, separatamente, immagini ed elementi di animazione (Canvas e Sprite).

Immagini

I problemi principali legati all’uso di immagini nelle App sono due: la risoluzione e l’impiego di memoria.

Pochi mesi fa, lo staff del MIT che segue il progetto App Inventor è intervenuto sul tema con un documento che ripropongo tradotto in italiano:

Utilizzo di immagini con MIT App Inventor

Evitare alcuni problemi comuni!

Sommario: App Inventor funziona meglio se si utilizzano piccole immagini che corrispondono alle dimensioni che si desidera vengano visualizzate sullo schermo. Se si importano molte immagini di grandi dimensioni nella app, essa esaurirà la memoria di sistema.  Ci sono molti modi in cui è possibile utilizzare immagini con MIT App Inventor. Tuttavia ci sono alcune cose da tenere a mente al fine di far sì che l’applicazione funzioni in modo efficiente.

 Consumo di memoria.  Ogni immagine ha una dimensione dipendente dalla sua larghezza e altezza. Fondamentalmente, è possibile moltiplicare questi due numeri insieme per ottenere una stima della quantità di memoria che consuma una data immagine su un dispositivo. Non è possibile utilizzare la dimensione del file dell’immagine come criterio, perché la maggior parte dei formati di file di immagine prevede una certa quantità di compressione: una grande immagine può essere compressa in un piccolo file. Il fattore di compressione può essere particolarmente significativo con la grafica più che con le fotografie.

In alcuni contesti, quando si utilizza un’immagine, la dimensione dell’immagine sarà utilizzata per determinare le dimensioni dell’oggetto sullo schermo. Per esempio se si utilizza un’immagine su un pulsante, la dimensione dell’immagine direttamente determinerà la dimensione del pulsante.

In altri contesti l’immagine viene ridimensionata per adattarsi a una certa dimensione. Per esempio se si inserisce un componente “Immagine” sullo schermo e si impostano le proprietà larghezza e altezza diciamo a 100 pixel, l’immagine sarà visualizzata a 100 pixel per ogni dimensione, anche se l’immagine che avete caricato è molto più grande!  Android ridimensionerà automaticamente l’immagine per adattarla alle dimensioni dell’oggetto che la contiene quando questo viene visualizzato. Tuttavia, sui dispositivi Android l’immagine occuperà ancora una quantità di memoria basata sulle dimensioni effettive.

Facciamo un esempio.

Si supponga che si voglia visualizzare una griglia contenente lettere dell’alfabeto e si dispone di un’immagine per ogni lettera. Diciamo anche che per ogni lettera viene caricato da un file di immagine e che la dimensione dell’immagine è di 3000 x 3000 pixel.  Sullo schermo si intende allocare ogni immagine in una casella 30 pixel per 30. Quando visualizzerete la griglia nella vostra App, per Android sarà necessario caricare e mantenere ogni immagine in memoria. A causa delle sue dimensioni, ogni immagine consumerà circa 10 megabyte di memoria. Con 26 immagini, in totale saranno richiesti 260 megabyte di RAM. La maggior parte dei dispositivi Android limita la quantità di RAM che ogni applicazione può utilizzare ad una frazione della memoria effettiva sul dispositivo, generalmente si va da 20 a 50 megabyte. Quindi il nostro esempio semplicemente non funzionerà, produrrà un errore di “OutOfMemory” durante il caricamento.

 Il rilascio della versione  “Responsive” nel mese di agosto del 2015 ha cambiato le cose

Prima del rilascio della versione “Responsive” di App Inventor, le app create sono state adattate ad Android API 3. Ciò significa che è possibile eseguire applicazioni MIT App Inventor su telefoni vecchi con Cup Cake (Android 1.5). Tuttavia c’è un problema. Con API 3 Android viene supportata solo una dimensione del dispositivo ed una densità – un telefono con schermo di 320 pixel di larghezza per 480 pixel di altezza. 

Dispositivi più recenti possono essere avere entrambe le dimensioni più grandi e supportano una “densità” maggiore di pixel (ci sono più pixel per pollice sullo schermo). Tuttavia quando in un dispositivo più recente viene caricato un programma progettato per API 3, viene ridimensionato automaticamente lo schermo per far “sembrare” che dispositivo sia analogo ai “vecchi”. Questa modalità di compatibilità tratta i tablet come telefoni giganti!  Con l’evoluzione di Android e MIT App Inventor le persone hanno espresso il desiderio di essere in grado di progettare applicazioni per Tablet utilizzando MIT App Inventor. Inoltre alcuni dispositivi più recenti sono stati licenziati senza la modalità di compatibilità API 3.

Ciò fa sì che MIT App Inventor crei applicazioni che utilizzano solo una piccola parte dello schermo e davvero ciò non sembra adeguato. 

Per supportare i dispositivi più recenti abbiamo bisogno di abbandonare il supporto per Cup Cake e andare almeno a Donut (Android 1.6, 4 API). A partire da API 4, Android tratta schermi con differenti dimensioni e densità di pixel. Ciò rende anche lo sviluppo di applicazioni Android più complicato, perché lo sviluppatore dell’applicazione deve ora progettarla per adattarsi a densità e diverse dimensioni dello schermo. L’approccio adottato da Google è progettare diverse versioni dell’interfaccia utente per l’applicazione, completa con i propri file di immagine forniti tutti nel file APK. La periferica sceglie quindi il set corretto in fase di esecuzione.  Abbiamo deciso che questo approccio era più complicato di quanto avremmo voluto sottoporre al programmatore App Inventor. Non volevamo una modifica di App Inventor che avrebbe richiesto ad ogni programmatore di trattare con dispositivi di diverse dimensioni, abbiamo voluto mantenere la modalità di compatibilità che avevamo con API 3.

Dimensionamento responsivo o fisso

Nella versione “Responsiva” di MIT App Inventor è possibile impostare la proprietà “Dimensionamento” (Sizing) dello schermo a “Responsivo” o a “Fisso” (quest’ultima è l’impostazione predefinita per nuovi progetti e progetti precedenti che vengono automaticamente aggiornate). La modalità fissa emula il comportamento della modalità compatibilità API 3. La modalità responsiva non richiama la funzionalità di compatibilità e per i programmatori che la utilizzano esso potrebbe essere necessario prestare attenzione alle differenze tra i dispositivi. Per rendere ciò un po’ più facile, abbiamo introdotto un modo per specificare la larghezza e l’altezza degli elementi dello schermo in base a una percentuale dello schermo dei dispositivi, invece di dover dare la dimensione assoluta in pixel.

 Un altro cambiamento che viene fornito con questo aggiornamento è la nozione di “Density Independent Pixels ” o “Dips”. Density Independent Pixels  è una misura della dimensione che prende in considerazione la densità dello schermo di un dispositivo. Un Dips su alcuni dispositivi potrebbe essere mappato a un pixel mentre sugli altri può essere di nove pixel.

L’idea è che la maggior parte degli schermi avrà lo stesso numero di “Dips” in un pollice di schermo.

Anche se è ancora possibile dare dimensioni agli elementi dell’interfaccia utente in “pixel” in App Inventor, i pixel sono in realtà Dips. 

Tuttavia, le immagini ancora sono basate su pixel “reali”. Così, se si carica un’app contenente un’immagine su un dispositivo con risoluzione più densa, le foto appariranno più piccole.

Per risolvere questo problema ridimensioniamo le immagini quando le carichiamo in base alla densità dello schermo del dispositivo. Ciò può causare problemi con il consumo di memoria. Torniamo al nostro esempio di alfabeto. Se si tenta di caricare in un dispositivo con una densità di schermo di 3 (non raro) ci vorrà 9 volte la quantità di memoria rispetto l’esempio originale, ovvero 2,3 gigabyte di memoria. Così anche se l’esempio originale girerebbe a malapena in memoria su un dispositivo con una densità di schermo di 1, certamente non è adatta su un dispositivo con una densità di schermo di 3!

 Che cosa dovrebbe fare il programmatore MIT App Inventor

La soluzione più semplice è assicurarsi che le immagini che si caricano siano della dimensione corretta e adattare quanto più possibile alla dimensione effettiva in DIP che consumeranno sullo schermo.

Per utilizzare l’esempio dell’alfabeto, le immagini delle singole lettere devono essere scalate per essere di 30 x 30 pixel.

Se si esegue questa operazione, ogni immagine richiede solo circa 1000 byte di memoria (invece di 10 megabyte!). Così l’intero alfabeto si adatta a 26.000 byte di memoria. Anche se questo si carica su un dispositivo con una densità di schermo di 3, utilizzerà solo 200.000 byte di memoria.

Ci sono molti strumenti che è possibile utilizzare per ridimensionare le immagini. Gli esempi includono Photoshop, Preview (su MacOS), GIMP (su MacOS e Linux). Ce ne sono molti altri. Alcuni sono software commerciale altri sono gratis o forniti con sistema operativo del computer. Non è necessario un programma particolarmente oneroso solo per ridimensionare le immagini. Esistono anche siti Web sui quali è possibile caricare le immagini che saranno ri-scalate per voi. Una ricerca su Google con “programmi per ridimensionare immagini” probabilmente produrrà più di qualche candidato.

Canvas e Sprite

Il supporto al responsive design per ora è incompleto: in particolare non supporta canvas e sprite (che sono poi gli elementi base per le animazioni, per creare una app con oggetti che si muovano, anche al tocco).

Gli oggetti vengono animati sugli schermi attribuendo loro delle posizioni basate su coordinate (sull’asse delle x e delle y) espresse in pixel: quindi complicato gestire questa cosa con misure diverse degli schermi.

Per ora il team di MIT App  Inventor raccomanda queste soluzioni:

  1. Usare il metodo “Fixed” per questo tipo di app (e pensare a soluzioni quali quelle proposte nella prima parte del Post).
  2. Usare il metodo “Responsive” ma impostare la misura del “Canvas” ad un valore fisso di pixel. In poche parole tutta la vostra app sarà responsive, ma il canvas (e gli oggetti in esso) avranno misure fisse in pixel.
  3. Usare il metodo “Responsive” ed impostare il canvas ad una percentuale appropriata della misura dello schermo. Poi nel canvas fare dei calcoli matematici per computare le distanze delle coordinate relative al valore attuale della dimensione del canvas (tornando, ancora una volta, all’idea del fattore di scala illustrato nella prima parte del post).

Come accennato, il tema è un po’ complesso ma, per esperienza, posso garantire che con un po’ di prove si riescono ad ottenere buoni risultati grafici anche sui tablet e, essendo questi dispositivi ovviamente più funzionali all’utilizzo didattico e riabilitativo, val la pena spendere un po’ di fatica per rendere le nostre App, nel complesso, più Responsive…

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...