Blockly on Melabit

Programmazione visuale: App Inventor 2

Fri, 30 Jan 2015 06:00:00 +0000

Lo dico subito, da App Inventor 2 mi sarei aspettato molto di più. Sarà per la sua origine (Google), sarà per chi lo sviluppa attualmente (il MIT), pensavo fosse molto più rifinito e facile da usare di quanto sia in realtà.

Con App Inventor 2 (da ora in poi AI2) lo sviluppo dell’interfaccia grafica e del codice a blocchi di una applicazione viene effettuato interamente nel browser web, ma per eseguirla bisogna compilare ogni volta l’applicazione e trasferirla su un cellulare o un tablet Android.

Alla ricerca dell’emulatore

In teoria esiste un emulatore per AI2 in grado di eseguire l’applicazione direttamente sul computer utilizzato per lo sviluppo, ma per quanto ci abbia provato non sono riuscito a farlo funzionare sul mio Mac con Yosemite. L’emulatore può essere installato senza problemi, ma smette di funzionare una volta eseguito l’aggiornamento all’ultima versione disponibile online. L’emulatore ha anche bisogno di un programma, aiStarter, che sul Mac viene eseguito al boot da launchd e rimane sempre attivo in background, anche quando l’emulatore non viene utilizzato. Una cosa assolutamente inutile, tanto più che sia su Windows che su Linux aiStarter viene eseguito manualmente solo se e quando serve.

Può darsi che l’emulatore abbia bisogno per funzionare di qualche componente di Java non installato sul mio Mac, magari il Java SE Development Kit (JDK) 8 (vedi sotto), ma durante l’installazione e l’aggiornamento dell’emulatore non compare nessun messaggio di avviso in proposito.

Come se non bastasse, l’emulatore dimAI2 è piuttosto complicato da disinstallare: tutto deve essere fatto rigorosamente a mano e obbliga a riavviare il Mac.

Non pensate nemmeno di risolvere il problema scaricando Android Studio e utilizzando l’emulatore integrato nel sistema di sviluppo di Android. Io l’ho fatto, ho scaricato Android Studio e ho scoperto solo al momento della prima esecuzione di dover installare anche il Java SE Development Kit (JDK) 8. Una volta installato il JDK, ho dovuto installare anche un certo numero di componenti aggiuntivi obbligatori. Insomma, dopo aver riempito il disco rigido con un paio di GB di roba praticamente inutile, sono riuscito finalmente a lanciare l’emulatore di Android 5.0/Lollipop e… non è successo niente! L’emulatore ha cominciato a caricare Android ma dopo mezz’ora era sempre allo stesso punto, bloccato senza speranza.

Per fortuna Android Studio è relativamente facile da disinstallare, ma anche in questo caso manca un disinstallatore che renda il processo automatico.

Ma chi la dura la vince.

Dato che non riuscivo a far funzionare sul Mac gli emulatori ufficiali, ho provato BlueStacks App Player, un emulatore indipendente. La versione per OS X non viene più sviluppata (da quanto dicono sul sito per il troppo successo di quella per Windows), ma ho trovato su MacUpdate una vecchia versione di BlueStacks App Player per Mac che funziona senza problemi su Yosemite.

Maggiori dettagli sull’installazione e la configurazione di BlueStacks App Player si possono trovare in Emuliamo Android sul Mac: BlueStacks App Player.

Sviluppo del codice

A questo punto è possibile iniziare ad usare l’interfaccia web di AI2 per implementare il Crivello di Eratostene in questo linguaggio. L’interfaccia assomiglia a quella di un classico ambiente di sviluppo integrato (IDE) e integra due strumenti complementari: Designer per il disegno dell’interfaccia grafica e Blocks per lo sviluppo del codice vero e proprio dell’applicazione.

Premendo il bottone Designer si accede alla pagina di realizzazione dell’interfaccia grafica. La colonna di sinistra contiene gli elementi grafici (widget) disponibili, suddivisi in base alla loro tipologia. L’interfaccia dell’applicazione viene costruita trascinando e posizionando uno alla volta i vari elementi grafici dalla colonna di sinistra all’area centrale di disegno. La colonna di destra permette di visualizzare e modificare le proprietà dell’elemento selezionato nell’area di disegno.

[caption id=“attachment_1623” align=“aligncenter” width=“605”] Fig. 1 - Disegno dell’interfaccia grafica dell’applicazione che implementa il Crivello di Eratostene in App Inventor 2.[/caption]

Premendo il bottone Blocks si passa alla pagina di sviluppo del codice vero e proprio tramite l’assemblaggio dei blocchi funzionali che compongono il linguaggio di programmazione.

[caption id=“attachment_1624” align=“aligncenter” width=“605”] Fig. 2 - Codice a blocchi dell’applicazione.[/caption]

Il linguaggio a blocchi di AI2 è molto più ricco di quello di Blockly, anche perché deve gestire gli elementi dell’interfaccia grafica, che mancano in Blockly. Inoltre AI2 supporta le procedure (dette anche funzioni o subroutine in altri linguaggi), blocchi di codice richiamabili dall’applicazione principale o da altre procedure, e distingue fra variabili globali (valide per tutto il programma) e locali (valide solo all’interno di una procedura).

Tutto ciò rende AI2 più complesso di Blockly, e i programmi diventano facilmente più grandi di una singola schermata, rendendo difficile mantenere una visione complessiva dell’applicazione in fase di sviluppo.

Ho trovato però molto comodo il fatto che, quando si rinomina una variabile, il nuovo nome viene aggiornato nell’intera applicazione. Sarebbe veramente utile se gli editor di codice classico implementassero una funzione analoga.

All’opposto mi sembra sconcertante la totale mancanza di un undo: spesso mi è capitato di cancellare involontariamente interi blocchi di programma senza avere la possibilità di recuperarli in alcun modo. Se si aggiunge il fatto che ogni modifica al codice dell’applicazione in fase di sviluppo viene salvata automaticamente sul server di AI2, si può capire quanto sia facile commettere errori e rovinare il lavoro fatto. Anche Blockly non ha un undo ma, non so perché, con Blockly non mi è mai capitato di cancellare per sbaglio interi blocchi di codice.

Non serve nemmeno usare i checkpoint per salvare via via i diversi stati dell’applicazione in fase di sviluppo. La gestione dei checkpoint è assolutamente confusa – provare per credere – e allo stato attuale sono inutili.

Usando AI2 è quindi necessario salvare spesso il progetto esportandolo sul proprio computer in formato .aia. Questi file non sono altro che dei file compressi in formato zip e possono essere scompattati (ad esempio usando il comando unzip da Terminale) per mostrare come è fatto un progetto di AI2. Immagino che i file del progetto possano essere modificati con un editor e che, una volta compressi, possano essere importati di nuovo da AI2, ma io non ho mai provato a farlo.

Proviamo l’applicazione

Durante lo sviluppo di una applicazione è consigliabile provare ogni tanto ad eseguirla nell’emulatore, in modo da controllare che l’interfaccia grafica e le funzioni implementate nel codice a blocchi funzionino come dovrebbero.

Selezionando dal menu Build la voce app (save .apk to my computer), l’applicazione viene compilata e impacchettata automaticamente, salvandola sul Mac come file .apk (normalmente nella stessa directory che contiene il codice .aia del progetto). Il formato .apk è il formato dei package di Android e contiene l’eseguibile vero e proprio insieme a tutti i file accessori.

Ma come trasferire il package dell’applicazione in BlueStacks App Player?

Il modo più semplice è installare Dropbox nell’emulatore e usarlo per sincronizzare il package fra il Mac e BlueStacks App Player. Una volta completato il trasferimento, basta aprire Dropbox sull’emulatore e cliccare con il mouse sull’icona del file .apk appena sincronizzato per lanciare il processo di installazione del package.

[caption id=“attachment_1625” align=“aligncenter” width=“605”] Fig. 3 - Sincronizzazione tramite Dropbox sull’emulatore del package in fase di sviluppo.[/caption]

[caption id=“attachment_1626” align=“aligncenter” width=“605”] Fig. 4 - Installazione del package.[/caption]

In alternativa, si può usare il Terminale, eseguendo i comandi riportati nel post relativo all’installazione e all’uso di BlueStacks App Player sul Mac. Supponendo che il package dell’applicazione di Figura 2 si chiami sieve_original.apk e che sia stata salvato nella directory ~/Documenti/AI2/ (il simbolo ~ indica come al solito la cartella Inizio dell’utente), lanciamo BlueStacks App Player ed eseguiamo da Terminale i comandi

$ cd  /Applications/BlueStacks.app/Contents/Runtime/
$ ./uHD-Adb install ~/Documenti/AI2/sieve_original.apk

Indipendentemente dal metodo usato, alla fine troveremo l’icona dell’applicazione sulla schermata principale dell’emulatore e potremo eseguirla cliccando con il mouse sulla sua icona.

[caption id=“attachment_1628” align=“aligncenter” width=“605”] Fig. 5 - Schermata principale dell’emulatore con il package appena installato.[/caption]

Alla prima esecuzione però avremo una sorpresa sgradita: la finestra dell’applicazione è minuscola, molto più piccola delle dimensioni della finestra principale di BlueStacks App Player.

[caption id=“attachment_1629” align=“aligncenter” width=“605”] Fig. 6 - La finestra dell’applicazione è veramente minuscola.[/caption]

Per ingrandirla, bisogna premere l’icona Settings (quella con il simbolo di una chiave inglese e di un cacciavite incrociati), selezionare la voce Manage Applications e selezionare in correspondenza dell’applicazione la dimensione Tablet al posto di quella di default. Riavviando l’applicazione questa avrà dimensioni più normali, anche se sempre piuttosto ridotte rispetto alla finestra principale.

[caption id=“attachment_1630” align=“aligncenter” width=“605”] Fig. 7 - Ingrandiamo la finestra dell’applicazione.[/caption]

[caption id=“attachment_1631” align=“aligncenter” width=“605”] Fig. 8 - Ora va un po’ meglio.[/caption]

Finalmente si può provare ad eseguire l’applicazione, verificando che funzioni tutto come previsto.

[caption id=“attachment_1632” align=“aligncenter” width=“605”] Fig. 9 - Esecuzione dell’applicazione per calcolare i numeri primi.[/caption]

Qualche miglioramento

Uno degli aspetti positivi di AI2 è il supporto per le procedure (funzioni o subroutine in altri linguaggi). Le procedure permettono di raggruppare una sequenza di istruzioni in un unico blocco funzionale, una specie di scatola nera che elabora le variabili di ingresso e restituisce un risultato ben definito in uscita. Le procedure diventano a tutti gli effetti delle nuove istruzioni del linguaggio di programmazione e sono richiamabili sia dall’applicazione principale che da altre procedure, semplificando la gestione e l’analisi del codice del programma.

Proviamo quindi riscrivere il codice dell’applicazione utilizzando le procedure, senza però modificare l’interfaccia grafica che rimane la stessa di Figura 1.

In questo caso particolare l’utilità delle procedure è soprattutto didattica: ciascuna procedura viene richiamata una sola volta dal programma principale e quindi il loro uso non comporta nessun vantaggio rispetto ad un programma monolitico come quello di Figura 2.

Anche se non è semplicissimo capire come utilizzare le procedure in AI2, dopo un po’ di tentativi infruttuosi si ottiene il codice a blocchi mostrato in Figura 10.

[caption id=“attachment_1633” align=“aligncenter” width=“605”] Fig. 10 - Codice a blocchi della nuova versione dell’applicazione.[/caption]

Eseguendo la nuova versione del programma sull’emulatore, si ottiene il risultato mostrato in Figura 11. Come si vede, è stato anche semplificato l’output del programma, mostrando nella finestra dell’applicazione solo l’elenco dei numeri primi calcolati, in modo da permettere di compattare un numero maggiore di informazioni nella piccola finestra disponibile.

[caption id=“attachment_1634” align=“aligncenter” width=“605”] Fig. 11 - Esecuzione della nuova versione dell’applicazione.[/caption]

Conclusioni

Una applicazione per Android sviluppata interamente nel browser è un risultato interessante. Purtroppo i problemi di usabilità descritti rendono il giudizio finale su AI2 decisamente meno positivo di quanto ci si potrebbe aspettare.

Risorse

Chi vuole provare ad usare AI2 può scaricare il codice sorgente del programma mostrato in Figura 1 e 2 e della versione migliorata di Figura 10. Sono anche disponibili i package precompilati per Android del programma originale e della versione con le procedure.

Programmazione visuale: introduzione

Mon, 19 Jan 2015 06:00:00 +0000

Il modello di programmazione tradizionale si basa sulla scrittura di codice sorgente secondo una struttura logica e ad una sintassi ben definita e dipendente dal linguaggio di programmazione prescelto.

L’idea di sostituire questo modello con uno fondato su una interfaccia grafica sulla quale trascinare dei blocchi funzionali predefiniti, manipolandoli ed assemblandoli l’uno all’altro quasi fossero dei mattoncini del LEGO, data dalla fine degli anni ‘80 a livello commerciale e si basa su ricerche iniziate già negli anni ‘60. Questo cambio di paradigma aveva l’obiettivo di rendere la programmazione accessibile anche ai non iniziati, permettendo di insegnarne i rudimenti già ai bambini della scuola elementare.

Ma non voglio farla lunga e rimando chi fosse interessato ad approfondire l’argomento a questa eccellente infografica e alla bibliografia alla fine del post. Ricordo solo che anche in questo campo Apple ha fatto da apripista con il suo HyperCard, il primo ambiente visuale di programmazione uscito dal chiuso dei laboratori di ricerca.

A parte HyperCard, finora l’unico linguaggio di programmazione visuale che ha avuto un vero successo è stato LabVIEW (Laboratory Virtual Instrument Engineering Workbench), un ambiente di programmazione grafica sviluppato dalla National Instruments per il controllo della strumentazione di misura, l’acquisizione dei dati e l’automazione dei processi industriali.

Un linguaggio utilissimo in un ambito professionale molto specializzato, ma decisamente molto lontano dall’idea di programmazione per i ragazzini. E nato anch’esso, non a caso, prima sul Mac alla fine degli anni ‘80 (ho usato a lungo su un Macintosh II la prima versione di LabVIEW divertendomi moltissimo) e portato solo in seguito su Windows e poi finalmente anche su Linux e OS X.

Ma allora perché trattare di programmazione visuale? Perché mentre preparavo i post sull’implementazione in BASIC e in Python del Crivello di Eratostene mi sono imbattuto in tre diverse implementazioni di linguaggi di programmazione visuali derivanti chiaramente da Scratch, il più noto linguaggio di programmazione visuale per insegnare la programmazione ai bambini:

Blockly, sviluppato da Google e di cui ho già parlato brevemente in un post precedente;
App Inventor 2, sviluppato inizialmente presso i laboratori di Google ma gestito ora dal Massachusetts Institute of Technology (MIT), che permette di creare applicazioni per Android;
SNAP!, sviluppato presso l’Università della California a Berkeley.

A differenza di Scratch, questi linguaggi sono utilizzabili direttamente dal browser e non richiedono nessuna installazione sul proprio Mac (o quasi).

Leggendo la descrizione delle caratteristiche dai rispettivi siti web mi sono chiesto quanto fosse facile implementare un algoritmo semplice come quello del Crivello di Eratostene in uno di questi linguaggi rispetto al Python (o al BASIC). Ma perché chiederselo soltanto, senza provare direttamente?

Nel seguito ho riassunto le mie considerazioni personali su Blockly, i prossimi post saranno dedicati rispettivamente a App Inventor 2 e a SNAP!

Blockly

Su Blockly ho già scritto qualcosa: mi è bastata una mezz’oretta di lavoro per implementare in Blockly l’algoritmo del Crivello di Eratostene a partire dalla versione originale in Python (e in BASIC).

Usare Blockly è divertente ed è abbastanza facile capirne la logica di funzionamento. È chiaro che conoscere già dei rudimenti di programmazione in un linguaggio tradizionale aiuta parecchio, ma imparare ad usare Blockly non dovrebbe essere troppo difficile anche per chi è del tutto a digiuno ma abbia voglia di applicarsi e di sperimentare un po’.

Purtroppo il codice Python (ma anche JavaScript) generato automaticamente è troppo verboso rispetto ad una versione sviluppata direttamente in uno dei due linguaggi. La ragione principale è che il linguaggio cerca di prevedere esplicitamente i diversi casi che possono presentarsi a seconda del segno delle variabili utilizzate, complicando notevolmente l’implementazione del ciclo. Un aspetto che probabilmente verrà migliorato con il tempo.

Il codice del programma che implementa il Crivello di Eratostene in Blockly (Fig. 1) è accessibile al link https://blockly-demo.appspot.com/static/demos/code/index.html#d93qba, e da quanto ho capito, ogni volta che vi si accede da un browser diverso Blockly crea automaticamente un link diverso, permettendo di provare a modificare il codice senza danneggiare la versione originale.

Tutto sommato Blockly è un bel giocattolino.

[caption id=“attachment_1615” align=“aligncenter” width=“605”] Implementazione del Crivello di Eratostene in Blockly.[/caption]

Bibliografia

Visual Programming Language - Infograph and Introduction, http://constructingkids.com/2013/05/15/vpl/.
Stack Exchange, Why did visual programming never take off and what future paradigms might change that?
Documentazione e risorse su HyperCard, http://hypercard.org/.
J. Nickerson, “Visual Programming”, (1994), http://www.nickerson.to/visprog/visprog.htm.
M. Boshernitsan, M. S. Downes, “Visual Programming Languages: A Survey”, Università della California, Berkeley (2004), http://www.eecs.berkeley.edu/Pubs/TechRpts/2004/CSD-04-1368.pdf.

Setacciare a blocchi

Tue, 16 Dec 2014 06:00:00 +0000

L’algoritmo del Crivello di Eratostene è stato implementato in almeno 103 linguaggi diversi, alcuni decisamente curiosi o esoterici. Chi ha mai sentito parlare di AutoIt, Bracmat, M4, Nimrod o zkl?

Manca una implementazione in Blockly, un linguaggio di generazione di codice visuale a blocchi.

Blockly è stato sviluppato da Google e deriva da Scratch, StarLogo TNG e SNAP!, linguaggi di programmazione didattici rivolti soprattutto ai programmatori più giovani, e anche da AppInventor, un linguaggio più avanzato con cui si possono sviluppare applicazioni per Android.

Blockly non è però un linguaggio di programmazione vero e proprio, ma è piuttosto “un editor visuale che traduce programmi creati mettendo insieme blocchi standard nel corrispondente codice JavaScript, Python, Dart e altri”.

Nonostante queste limitazioni, una mezz’oretta di lavoro basta per sviluppare una versione in Blockly dell’algoritmo del Crivello di Eratostene (purtroppo il codice in JavaScript e Python generato automaticamente non è un granché).

[caption id=“attachment_1497” align=“aligncenter” width=“605”] Algoritmo del Crivello di Eratostene in Blockly.[/caption]

Chissà se vale la pena aggiungere questa implementazione del Crivello alle 103 precedenti…