Indice generale
1. Introduzione………..3
1.1 Introduzione all’applicazione web del modello particellare ………...4
1.1.1 HTML5 e CSS3 ………....5
1.1.2 JavaScript client side ………7
1.1.3 XML e JSON ………8
1.1.4 SVG e Canvas………..11
1.1.5 Interfaccia utente risultante ………14
1.2 Introduzione alle tecnologie mobili di riferimento ………...26
1.2.1 Kotlin per Android ………..27
1.2.2 La libreria Kivy di Python ………..31
1.2.3 Il Framework Xamarin ………...34
1.2.4 La scelta di Apache Cordova ………..35
1.3 Definizione di un percorso didattico della chimica ………..47
1.3.1 Il modello particellare insegnato nelle scuole ………47
1.3.2 Possibilità di inserimento del simulatore in un piano didattico ………..50
2. Modifiche e debugging dell’applicazione web originaria ……….51
2.1 Il diagramma di stato ………51
2.2 Controllo delle sostanze tramite file JSON ………..58
2.3 Le funzioni Warm e Cold .……….60
3. Sviluppo dell’applicazione mobile con Apache Cordova ……….65
3.1 Strutturazione dei file e intestazione del documento HTML ………65
3.2 Implementazione del corpo della pagina ………..69
3.3 Implementazione dei fogli di stile a cascata ……….70
3.4 Sviluppo di nuove funzionalità con l’utilizzo di JavaScript ……….73
3.5 Analisi e profiling delle prestazioni ……….80
3.6 Suggerimenti per un buon uso del simulatore ………..86
4.1 Progettazione dell’attività didattica ………..87
4.2 Studio delle caratteristiche delle particelle ………...89
4.3 Prova di verifica ………...90
4.4 Presentazione dell’applicazione agli alunni ……….92
4.5 Conclusioni ……….….….….….….….….….….….….….….….….….….……….93
Bibliografia ………95
1. Introduzione
Sono passati venticinque anni da quando è iniziata l'era della tecnologia mobile. Nel 1988, il panorama della tecnologia mobile consisteva in telefoni cellulari di dimensioni di una ventiquattrore che aveva la funzione di un’agenda. Questi “telefoni” sembrava che glorificassero i calcolatori finanziari nonostante le reti wireless e l'accesso diffuso a risorse come Internet erano sogni distanti. Sarebbe stato molto difficile immaginare il mondo connesso, che stiamo vivendo correntemente, intorno al 1988, a meno che il mondo non rientrasse nella pura fantascienza.
Strumenti di sviluppo potenti e la creatività combinata di milioni di sviluppatori di applicazioni in tutto il mondo garantiscono praticamente che non si è in grado di indovinare quali funzionalità indispensabili appaiano sui dispositivi mobili domani o nei prossimi giorni. I dispositivi di domani saranno interfacciati direttamente ai sistemi nervosi umani? Si uniranno a composti organici e guariranno se si danneggiassero? Chi può saperlo? Qualunque sia il futuro della tecnologia mobile, finché c'è un mezzo per programmarlo o controllarlo in qualche modo, si può immaginare che gli sviluppatori possano dare vita a molteplici applicazioni, sia in ambito ludico o ad uso personale, sia in ambito scientifico e terapeutico1.
Per la realizzazione di questo elaborato verrà osservata e, successivamente, utilizzata una piccola percentuale dello sterminato universo che concerne le tecnologie di sviluppo di applicazioni mobili, e ne verranno utilizzate alcune per la trasposizione di un artefatto digitale già esistente approssimante un modello particellare, il quale dovrebbe essere in grado di descrivere la relazione che intercorre tra il fatto che una sostanza può trovarsi in ognuno dei tre stati di aggregazione della materia e che differenti sostanze, nelle stesse condizioni, possono coesistere in differenti stati di aggregazione.
Il progetto di riferimento consta nella produzione2 di un’applicazione mobile che simuli il
comportamento delle particelle costituenti la materia nei suoi stati di aggregazione e nei passaggi tra uno stato di aggregazione a un altro. Lo strumento ha la finalità di essere di supporto allo sviluppo della capacità di astrazione degli alunni e di agevolare una parte dell'insegnamento delle scienze incoraggiando gli studenti ad avere una prospettiva verosimile e condivisa di come le particelle di materia possano comportarsi nella realtà. La simulazione si inserirà in un percorso di didattica dalla chimica, suddiviso tra pratica e teoria, tra la dimostrazione e la spiegazione dottrinale, tra la 1 Da prendere in considerazione, ad esempio, i recenti sviluppi sulla diagnosi dei melanomi con un software desktop che prende in input uno scatto fotografico (https://goo.gl/6kroA). Si auspica che tale tecnologia possa essere trasportata anche nell’universo delle applicazioni mobili.
2 O meglio, nella trasformazione, ma a riguardo verrà discusso più avanti nella trattazione degli argomenti dell’elaborato.
definizione del modello e la sua astrazione. L'artefatto proposto non è stato concepito per rappresentare le minuzie del comportamento delle particelle nei vari stati di aggregazione; esso vuole semplicemente fornire una visione parziale ma verosimile di un più complesso fenomeno, in linea con gli obiettivi dei programmi di insegnamento delle scuole secondarie di primo grado. Inoltre, essendo stato progettato per essere eseguito su dispositivi mobili, è stato pensato per combinare la verosimiglianza del risultato con la scarsità di risorse hardware disponibili.
Una volta appresi i concetti di materia, di stato di aggregazione, di passaggio di stato, questi concetti dovrebbero poter essere utilizzati come paragone per tutte le sostanze. Gli studenti dovrebbero così familiarizzare con le basi del modello particellare, percepire la presenza delle interazioni tra le particelle, il loro continuo movimento e come queste siano disposte nei tre stati di aggregazione della materia. Dovrebbero apprezzare come il riscaldamento incrementi l'energia cinetica interna delle particelle e come questo conduca, oltre a cambiamenti di temperatura del sistema, a cambiamenti nell'organizzazione della loro struttura.
Verrà analizzata un’applicazione web pre-esistente, disponibile sia per essere utilizzata dagli alunni sul web, sia per essere scaricata e modificata dagli sviluppatori. Successivamente verrano prese in considerazione diverse tecnologie per lo sviluppo di applicazioni mobili rivolte alla creazione di un medesimo software simulante il modello particellare (capitolo 1); e, consequenzialmente, verrà scelta una sola tecnologia per lo sviluppo del modello particellare mobile ( capitolo 2). Infine verrà testata l’applicazione dalle insegnanti degli alunni che seguiranno il percorso di didattica della chimica (capitolo 3).
1.1 Introduzione all’applicazione web del modello particellare
In questo capitolo vengono introdotti: tutte le tecnologie che sono state utilizzate per la definizione dello scheletro della pagina che accoglie il simulatore prima di essere trasformato in un’applicazione mobile, la tecnologia che ha sotteso lo stile associato alla pagina e (sulla base di scelte implementative) il formato che è stato utilizzato per l'interscambio dei dati e la tecnologia con cui sono stati definiti i diagrammi per la visualizzazione delle particelle e dei grafici. Queste tecnologie verranno illustrate insieme ad alcuni frammenti di codice del modello particellare iniziale preso come modello per l’applicazione sviluppata.
Al fine di verificare quali fossero state le tecnologie idonee allo sviluppo dell’artefatto digitale, sono stati effettuati vari test con diversi strumenti. Di seguito sono introdotti quelli che hanno richiesto maggiore attenzione durante la fase progettuale, e viene riportato un accenno alla loro essenza e alle modalità di utilizzo all’interno del programma.
1.1.1 HTML5 e CSS3
HTML5 (HyperText Markup Language) ossia linguaggio a marcatori per ipertesti, è un linguaggio di markup usato per la strutturazione e la presentazione di contenuti sul World Wide Web. È la quinta e corrente versione dello standard HTML.
Venne reso ufficiale nell'ottobre del 2014 dal W3C, e finalizzato al miglioramento del linguaggio con il supporto degli ultimi multimedia, a una più facile leggibilità sia per gli esseri umani, che per macchine e dispositivi (come web browser e parser), e altri sistemi di lettura e scansione della pagina. HTML 5 è stato concepito non solo per essere ricondotto alla sua precedente versione, arrivata a HTML 4.01, ma anche XHTML (eXtensible HyperText Markup Language) e il DOM (Document Object Model) di secondo livello3 di HTML.
Include dettagliati modelli di processing atti a incoraggiare implementazioni più inter-operabili; estende e apporta migliorie al markup già disponibile per i documenti e introduce markup e API (Application Programming Interface) per applicazioni web complesse. È potenzialmente un candidato impiegabile per applicazioni cross-platform, in special modo per dispositivi mobili e ideale quindi ai fini della creazione di un progetto iniziale. Nativamente HTML 5 include e gestisce multimedia e grafica, compresa l'integrazione di grafica vettoriale con contenuti scalabili e MathML4 per formule matematiche.
Il W3C ha posto una grande attenzione alla modularità come meccanismo chiave per rendere più flessibile il linguaggio e più veloce il suo rilascio.
CSS3 (Cascading Style Sheets) è un linguaggio utilizzato per definire l'aspetto di presentazione di un documento scritto in un linguaggio di markup. Benché sia principalmente impiegato nella definizione di stili per pagine HTML, CSS può essere applicato anche a tanti altri tipi di documento (come ad esempio XML e SVG).
Assieme a HTML e JavaScript è la pietra miliare della tecnologia usata per la definizione della maggior parte dei siti web, interfacce per applicazioni distribuite web-based e interfacce utente per applicazioni mobili.
3 I livelli DOM sono le versioni della specifica per definire come funziona il Document Object Model, analogamente a come si hanno specifiche HTML4, HTML5 e CSS2.1. La specifica più recente è DOM Level 3, pubblicata nell'Aprile 2004. Inoltre, ci sono pezzi della specifica DOM che i fornitori possono scegliere di implementare, come Core, HTML e XML, così come il modello degli eventi. A seconda di ciò che viene costruito (un parser DOM, un motore di layout del browser web o un motore JavaScript), il fornitore può scegliere di implementare alcune o tutte le specifiche. La maggior parte dei browser web moderni implementano tutte le specifiche di livello 3. Il secondo livello gestisce il supporto ai Namespace XML (che servono a dichiarare l’appartenenza di elementi e attributi), query ai database con filtri, e gli eventi DOM.
4 Mathematical Markup Language (MathML) è un linguaggio derivato dall'XML usato per rappresentare simboli e
CSS è stato primariamente progettato per separare il contenuto dei documenti dalla loro presentazione, inclusi aspetti quali layout, colori e i tipi di carattere.
Quella corrente è la terza versione dei fogli di stile. Differentemente dalla precedente versione, che constava di un'unica enorme specificazione5, per i CSS 3 è stato deciso di dividere gli ambiti di
sviluppo in più documenti separati, chiamati moduli6. Ogni modulo aggiunge nuove funzionalità o
estende le caratteristiche definite nei CSS 2 preservandone la retro-compatibilità.
Le specificazioni CSS 3 sono definite dal W3C, il quale mette a disposizione un servizio di validazione per tali documenti.
Grazie alla modularizzazione, non è ancora prevista un'unica specificazione per avanzamenti verso il CSS 4, tuttavia esistono già moduli di quarto livello.
La parte statica di codice (che definisce la struttura e la presentazione del simulatore), consta di un'unica pagina HTML alla quale sono associati più fogli di stile, alcune librerie jQuery e il codice JavaScript che gestisce gli eventi generati dalla pressione dei pulsanti dell'interfaccia e il conseguente comportamento delle particelle definite in un diagramma.
Il corpo della pagina HTML è diviso in due sezioni, come due sono le pagine visualizzabili al caricamento del simulatore. Al fine di non rendere eccessivamente frammentario il corpo del 5 Le specificazioni sono dei grandi documenti contenenti tutte le informazioni dei linguaggi. Ogni linguaggio ha la
propria.
6 Nel novembre 2014, cinque moduli risultano pubblicati formalmente dal W3C:
• CSS Color Module Level 3: specifica i valori di colore e le proprietà per il colore di primo piano e l'opacità; alcune proprietà e valori sono attinte dal CSS 2, mentre altre sono completamente nuove;
• CSS Namespaces Module Level 3: definisce la regola @namespace per la dichiarazione del namespace predefinito e il binding dei namespace ai prefissi del namespace;
• Selector Level 3: Questo documento descrive i selettori già presenti nel CSS 1 e nel CSS 2 e introduce ulteriori selettori per CSS 3 e altri linguaggi che potrebbero essere necessari allo sviluppo, essi compongono la seguente funzione:
espressione * elemento → booleano
vale a dire, dato un elemento e un selettore, questa specifica definisce se l'elemento corrisponde al selettore. Queste espressioni possono essere utilizzate, ad esempio, per selezionare un insieme di elementi o un elemento singolo da un insieme di elementi, valutando l'espressione in tutti gli elementi di un sotto-albero (il linguaggio STTS, Simple Tree Transformation Sheets, dedito alla trasformazione degli alberi XML, utilizza questo meccanismo);
• Media Queries: HTML 4 e CSS 2 supportano i fogli di stile dipendenti dal supporto multimediale personalizzati, ad esempio, un documento può utilizzare i caratteri sans-serif quando viene visualizzato su una schermata e i font Serif durante la stampa. screen e print sono due tipi di supporti definiti.
Le Media Queries estendono la funzionalità dei tipi di supporti consentendo un'etichettatura più precisa dei fogli di stile.
Una media query è costituita da un tipo di supporto e da zero o più espressioni che controllano le condizioni di determinate funzioni multimediali. Tra i comandi più utilizzati nelle Media Queries troviamo width, height, e
color. Utilizzando le Media Queries, le presentazioni possono essere adattate a una specifica gamma di
dispositivi senza modificare il contenuto;
• CSS Style Attributes: i linguaggi di markup come HTML e SVG forniscono un attributo di stile per la maggior parte degli elementi, per contenere informazioni di questo tipo. Questo progetto descrive la sintassi e l'interpretazione del frammento CSS che può essere utilizzato in tali attributi di stile.
documento, sono stati utilizzati semplicemente dei tag <section> ed elementi di tipo blocco anonimi <div> per le varie sotto sezioni in cui la pagina è divisa.
L'ausilio della tecnologia CSS 3 è stata di supporto per definire la struttura della pagina, l'arrotondamento degli angoli del diagramma principale e tutti gli altri dettagli percepibili nell'aspetto con cui il simulatore si presenta. Per gli effetti di scrolling e di adattabilità della pagina ai dispositivi mobili si è preferito l'utilizzo della fullPage di Alvaro Trigo che fornisce un effetto di sliding laterale tra due pagine7 utilizzate per il sito web.
1.1.2 JavaScript client side
Javascript è un linguaggio di programmazione ad alto livello, dinamico, leggero e comunemente utilizzato per la generazione di pagine web dinamiche dato che ne facilita l'interazione da parte dell'utente.
Oltre a essere un linguaggio di programmazione aperto e cross-platform, è complementare e integrato con HTML.
Inizialmente conosciuto come liveScript, Netscape cambiò il suo nome in JavaScript nel 1995, anno in cui fece la sua prima apparizione. Oggi, ECMA-2628 definisce una versione standard del core del
linguaggio; la sua ultima versione, ECMAScript 6.0, è stata rilasciata nel giugno del 2015.
La scelta di utilizzare JavaScript piuttosto che un altro linguaggio è stata principalmente motivata dalla volontà di creare un artefatto digitale che fosse mobile friendly e accessibile via web.
A questo scopo JavaScript può essere usato per muovere un numero di elementi del DOM all'interno della pagina in conseguenza di alcuni ordini di modelli determinati da equazioni logiche
7 Non corrispondono prettamente a due pagine HTML distinte, bensì a due <div>, di cui uno viene visualizzato e considerato come homepage, mentre l’altro (immediatamente successivo nella medesima pagina, viene attivato dopo l’azione di scrolling, e considerato come la seconda pagina.
8 La ECMA (European Computer Manufacturers Association) fondata nel 1961, è un'associazione e dedicata alla standardizzazione. Nel 1994 viene è stata rinominata Ecma International. Attualmente Ecma International è responsabile per molti standard:
• Specifiche di JSON; • Specifiche linguaggio C#; • Specifiche linguaggio C++;
• Common Language Infrastructure (CLI), Infrastrutture di linguaggio comune (da non confondersi con
Command Line Interface della quale si parlerà più avanti);
• Specifiche linguaggio ECMAScript;
• Linguaggio di analisi, design e programmazione Eiffel (Linguaggio di programmazione Eiffel); • Considerazioni ambientali per prodotti elettronici;
• Formato file Universal 3D.
o funzioni. Per lo sviluppo del simulatore, è stata riservata una speciale attenzione allo studio delle seguenti funzioni native del linguaggio:
• setTimeout(<funzione_di_callback>, <durata>); • setInterval(<funzione_di_callback>, <durata>); • clearTimeout(<variabile>);
• clearInterval(<variabile>);
Le funzioni setTimeout() e setInterval() eseguono l'istruzione passata come parametro (rispettivamente, la prima dopo un dato intervallo in millisecondi, la seconda dopo ogni intervallo dato in millisecondi. Le ultime due funzioni sono impiegate per rimuovere i timer impostati rispettivamente tramite setTimeout() e setInterval().
1.1.3 XML e JSON
XML, acronimo di eXtensible Markup Language, è un linguaggio di markup che consente di strutturare dati attraverso l'uso di tag. Definisce, attraverso un insieme di regole, la codifica di documenti al fine di facilitarne l'interpretazione sia da parte degli esseri umani che delle macchine. JSON, acronimo di Javascript Object Notation, è un formato dati strutturato in coppie attributo-valore, utilizzato per la comunicazione asincrona di dati browser/server (AJAX). Anche se la progettazione di XML è focalizzata ai documenti9, sia questo che JSON sono formati standard adatti
all'interscambio di dati ed entrambi attualmente raccomandazioni del W3C.
L’applicazione non si è avvalsa di una base di dati perché le esigenze di progettazione non lo hanno richiesto. Tuttavia, come scelta implementativa per l'interscambio di dati si è optato per l'utilizzo di JSON, in parte perché più semplice da strutturare rispetto a un documento XML e in parte perché l'accesso ai dati, una volta eseguito il parsing del file, avviene tramite dot notation (e quindi in maniera molto più intuitiva rispetto alla navigazione di un documento attraverso il suo accesso al DOM).
I dati di tutte le sostanze selezionabili dal campo select dell'interfaccia sono definiti in questo file. La struttura di un singolo oggetto consta del nome della sostanza come chiave primaria e di una serie di coppie attributo-valore che ne definiscono i parametri rispettivamente di nome, nomenclatura IUPAC10, immagine della sostanza, immagine della molecola, dimensione del raggio
9 Nel senso di dati di tipi testuale.
10 Acronimo di International Union of Pure and Applied Chemistry, la IUPAC è un'organizzazione internazionale non governativa (in attività dal 1919), che promuove il progresso della chimica.
della particella, numero di particelle visualizzate, distanza di attrazione, fattore di repulsione, colore assunto dalla particella in ognuno dei tre stati di aggregazione, formula minima strutturata con tag MathML, massa molecolare, punto di fusione e punto di ebollizione (entrambi espressi sia in Celsius che in Kelvin), stato di aggregazione della sostanza a STP ( Standard Temperature and Pressure, ovvero lo stato di aggregazione in cui si trova la sostanza a venticinque gradi centigradi, considerata convenzionalmente la condizione standard), e densità; è inoltre presente un collegamento ipertestuale per gli approfondimenti. Mentre alcuni parametri, come densità e stato di aggregazione a STP, sono rappresentativi della sostanza nel mondo reale, altri (come la dimensione del raggio della particella o il fattore di repulsione) rendono conto del comportamento che si è voluto ottenere per il nostro simulatore. Nella pagina seguente viene riportata la struttura di una sostanza all’interno del file JSON:
{ "Acqua": { "particle_name": "Acqua", "iupac_name": "Ossidano", "particle_image": "img/acqua.jpg", "molecular_image": "img/molecola_acqua.jpg", "radius": 6, "num_part": 300, "solid_color": "#00008B", "liquid_color": "#0000FF", "gas_color": "#4169e1", "minimal_formula": "<math><mrow><msub><mi>H</mi><mn>2</mn></msub><mi>O</mi></mrow></math>", "molecular_mass": 18.0153, "melting_point": [0, 273.15], "boiling_point": [100, 373.15], "STP": "liquid", "density": "1.000 kg/m³", "deepening": "https://it.wikipedia.org/wiki/Acqua", "gridSize": "L" }, "Sale": { "particle_name": "Sale",
"particle_image": "img/sale.jpg", "molecular_image": "img/acetone.png", "radius": 6, "num_part": 220, "solid_color": "#32CD32", "liquid_color": "#00FF00", "gas_color": "#BFFF00", "minimal_formula": "<math><mrow><mi>N</mi><mi>a</mi><mi>Cl</mi></mrow></math>", "molecular_mass": 58.443, "melting_point": [804, 1077.15], "boiling_point": [1461, 1734.15], "STP": "solid", "density": "2.16 g/cm³", "deepening": "https://it.wikipedia.org/wiki/Cloruro_di_sodio", "gridSize": "S" }"Ossigeno molecolare": {
"particle_name": "Ossigeno molecolare", "iupac_name": "Ossigeno", "particle_image": "img/ossigeno.jpg", "molecular_image": "img/ossigeno.png", "radius": 6, "num_part": 200, "solid_color": "#BFFF00", "liquid_color": "#ADFF2F", "gas_color": "#7FFF00", "minimal_formula": "<math><mrow><msub><mi>O</mi><mn>2</mn></msub></mrow></math>", "molecular_mass": 32, "melting_point": [-222.8, 50.35], "boiling_point": [-182.97, 90.18], "STP": "gas", "density": "1,429 kg/m³", "deepening": "https://it.wikipedia.org/wiki/Ossigeno", "gridSize": "S" } }
Dato che l’applicazione web non poggia su una base di dati, non è stata necessaria una comunicazione asincrona per l'accesso alle informazioni contenute in questo file. È stato invece seguito con attenzione l'indirizzamento del file per il recupero dei dati tramite JavaScript attraverso la seguente procedura:
var http_request;
if(window.XMLHttpRequest){
http_request = new XMLHttpRequest(); } else{
http_request = new ActiveXObject("Microsoft.XMLHTTP"); }
http_request.open("get", "substances.json", false); http_request.send();
data = JSON.parse(http_request.responseText);
Questa procedura fornisce l’oggetto data che risulta essere una struttura dati chiave-valore alla quale accedere facilmente per la lettura di tutte le informazioni contenute nel file JSON.
1.1.4 SVG e Canvas
SVG (Scalable Vector Graphics), è un linguaggio per la descrizione di grafica a due dimensioni derivato da XML. Dal 2001 è una raccomandazione standard del W3C e ad oggi è supportato nativamente dalla maggior parte degli web browser. Essendo progettato su un linguaggio di markup, ogni suo elemento è raggiungibile e manipolabile tramite codice come un qualsiasi elemento all'interno del DOM.
Il tag <svg> fa da cesura tra il codice HTML della pagina, al quale appartiene, e il corpo del documento XML del quale è la radice. Ogni tag SVG è considerato come un nodo e l'accesso al documento (compresa gestione degli eventi) può essere effettuato anche da JavaScript.
Canvas è un elemento integrato in HTML 5 che permette di effettuare il rendering dinamico di immagini direttamente da codice. Venne introdotto nel 2004 da Apple al fine di ottimizzare l'utilizzo del proprio WebKit; due anni più tardi è stato standardizzato dal gruppo di lavoro WHATWG (Web Hypertext Application Technology Working Group).
Sia SVG che Canvas consentono di ottenere risultati analoghi anche seppur ciascuno dei due linguaggi conservi le proprie peculiari funzionalità. È possibile con i dovuti accorgimenti, inquadrare l’ambito in cui sia più appropriato utilizzare una tecnologia piuttosto che l'altra.
Generalmente, date le dimensioni di schermo sempre più grandi, specialmente per applicazioni web on mobile responsive, Canvas è carente nella risoluzione e la maggior parte dei pixel necessitano di essere ridisegnati a ogni frame per ovviare a questa problema; quando invece il numero di oggetti presenti sullo schermo è considerevole, è SVG a difettare. Si può facilmente ovviare alle mancanze appena segnalate per esempio compensandole con una buona scheda grafica; tuttavia non devono essere sottovalutate quando si effettuano scelte implementative.
l’elaborazione per complessi documenti vettoriali è una caratteristica a favore di SVG data la sua struttura dichiarativa (come un documento XML fornisce gli strumenti, lato client o server indistintamente) per la generazione di forme direttamente da base di dati. In aggiunta la scalabilità gioca un ruolo fondamentale nella visualizzazione di un diagramma schematico ma molto dettagliato.
SVG è un linguaggio di semplice utilizzo per la creazione di immagini all'interno di un'applicazione o di una pagina web, piccola o grande che sia. Ha la caratteristica di poter essere utilizzato all’interno di HTML come documento XML; perciò i suoi nodi possono essere manipolati (visitati, creati, eliminati o sostituiti) proprio come elementi di quest'ultimo.
I tag all'interno della radice di SVG possono essere tradotti in anticipo rispetto alla generazione dell'immagine, a costo di un calo di prestazione, accettabile se confrontata al costo computazionale del rendering di una pagina web.
Un elevato numero di mappe e grafici richiedono l'utilizzo di grafica vettoriale. La maggior parte di essi sono quindi ovviamente meglio definiti con SVG perché solitamente accade che: o i grafici sono generati da dati esistenti che possono facilmente essere tradotti in XML o è richiesta un'elevata interazione dell'utente o si vuole beneficiare di una stilizzazione all'interno della pagina.
Per quel che concerne la dimensione e quindi il peso delle immagini, SVG in alcune circostanze è leggermente più oneroso di Canvas a causa e in favore della scalabilità dell'immagine generata. Esistono comunque molteplici scenari in cui la scelta di Canvas è preferibile a quella di SVG: ad esempio quando si voglia utilizzare algoritmi di illuminazione globale quali il Ray Tracing11.
11 L’algoritmo è utilizzato nel campo della Computer grafica 3D: le visualizzazioni delle scene sullo schermo, modellate matematicamente, vengono prodotte usando una tecnica che segue i raggi partendo dal punto di vista della telecamera piuttosto che dalle sorgenti di luce. L’algoritmo semplifica alcuni effetti ottici avanzati, producendo un'accurata simulazione della riflessione e della rifrazione (la rifrazione è la deviazione subita da un'onda che ha luogo quando questa passa da un mezzo ad un altro nel quale la sua velocità di propagazione cambia, mentre la riflessione è il fenomeno che avviene quando l'onda si muove in contatto con la materia, una parte viene riflessa e una parte viene trasmessa), restando abbastanza efficiente da permetterne l'uso in caso si voglia ottenere un risultato di alta qualità.
Il Ray Tracing può essere utilizzato per rendere l'immagine più fedele grazie alla tracciatura del percorso compiuto dalla luce sulla scena e il suo contributo alla tonalità, luminosità e saturazione del colore dei pixel che formano le figure.
Gli effetti del Ray Tracing sono molto suggestivi e per questo ad oggi esistono librerie di codice, come ad esempio WebGL (Web Graphic Library), che permettono di realizzare i calcoli necessari in background con un'ottima resa dell'immagine finale.
Lo sviluppo del simulatore non ha implicato un utilizzo di Canvas. Per la definizione del comportamento di una particella soggetta al moto browniano, al fine di poterne saggiare la traiettoria, è stato utilizzato SVG.
Per moto browniano si intende:
Quel continuo, rapido e irregolare movimento, in tutte le direzioni, delle minute particelle in sospensione in un fluido e delle molecole stesse di un fluido. Nel 1828 il botanico scozzese Robert Brown osservò che particelle di polline sospese in un solvente erano in costante agitazione e si muovevano in modo disordinato. Inizialmente Brown, allora responsabile botanico del British Museum, credette di aver trovato la molecola base della materia vivente. Successivi esperimenti mostrarono però che lo stesso fenomeno poteva essere ottenuto utilizzando un pigmento, sicuramente una molecola non viva, il che portò Brown a rivedere la propria interpretazione. Sulla scorta di queste osservazioni diversi scienziati europei iniziarono a occuparsi del problema al fine di comprendere la motivazione di quel fenomeno che da allora in poi divenne noto come moto browniano. Nel 1888 Georges Gouy, dell’Università di Lione, dimostrò che il moto delle particelle non era influenzato né da campi elettromagnetici intensi né dall’interazione con la luce, ma che la viscosità del mezzo in cui erano disperse le particelle ne condizionava l’entità. Su questa base Gouy suggerì che il moto browniano fosse dovuto all’agitazione termica delle molecole del solvente. Tale spiegazione trovò una conferma indiretta in uno dei cinque lavori fondamentali che rivoluzionarono la fisica moderna pubblicati da Albert Einstein nel 1905. Einstein, che approfondisce l’intuizione originaria negli anni successivi, ipotizza che il moto delle particelle sospese (aventi dimensioni molto maggiori di una molecola) sia dovuto alle collisioni casuali tra le molecole del solvente in cui è dispersa la particella e la particella stessa12.
In conclusione, SVG ha un’attitudine migliore nella gestione dei corpi in movimento e nella descrizione di diagrammi dettagliati senza perdita di risoluzione. Inoltre, utilizzando SVG, le
particelle vengono disegnate una sola volta all'interno del diagramma13 e successivamente vengono
messe in moto tramite codice JavaScript con aggiornamenti delle rispettive coordinate; invece utilizzando Canvas sarebbe stato necessario ridisegnare sulla tela frame per frame ogni particella ad ogni nuovo movimento, operazione che avrebbe richiesto un eccessivo costo computazionale. 1.1.5 Interfaccia utente risultante
L'interfaccia utente attraverso cui gli studenti possono interagire con il simulatore è stata una delle parti fondamentali su cui si è focalizzato il lavoro di progettazione e di programmazione dell’artefatto digitale.
Appena si accede al link www.modelloparticellare.altervista.org, l’utente visualizzerà la seguente schermata:
Scorrendo a destra sul layout di Alvaro Trigo si trova il seguente layout:
13 Sia SVG che Canvas hanno coordinate di origine a partire dall'angolo in alto a sinistra e procedono con valori positivi sia per x che per y all'interno di tutto il diagramma.
1. Illustrazione: elementi della homepage del sito web www.modelloparticellare.altervista.org, che consistono nel titolo dell’applicazione e nell’anteprima di un video illustrativo del moto browniano, prodotto da Rai.
L’interfaccia è composta da un unico campo select attraverso cui è possibile selezionare la sostanza desiderata, due radio button per la visualizzazione delle scale di temperatura e quattro pulsanti: due rispettivamente per l'avvio e l'interruzione del simulatore e i restanti per l'aggiunta e la rimozione di calore dal simulatore.
Tutti i campi della problematica interfaccia iniziale (che afferivano ad altrettante variabili globali definite nel codice JavaScript) erano stati ideati e progettati in modo da poter intervenire a tempo di esecuzione sui parametri che modificavano il moto delle particelle all'avvio del simulatore; questo al fine di ottenere tramite successive, modifiche nei valori di tali parametri, il comportamento desiderato.
Allo stato attuale, la parte di interfaccia che raccoglie gli elementi per interagire con il sistema ha il seguente aspetto:
2. Illustrazione: layout della pagina risultante dopo il click sulla freccia destra dell’illustrazione precedente
La fase di progettazione ha rilevato anche la possibilità di un utilizzo individuale del simulatore (quindi non un utilizzo privilegiato del docente in una lezione frontale, ma soprattutto degli studenti, in modo che siano coinvolti attivamente nell’attività). Per quanto riguarda la posizione ottimale dei i pulsanti, bisogna considerare che i giovani hanno familiarità con dispositivi come smartphone e tablet (utilizzati principalmente per attività ricreative), i cui i comandi sono situati nelle zone inferiori dei dispositivi; è stato pensato dunque di collocare tutta la struttura con i comandi nella fascia bassa dello schermo in modo da favorire l’interazione con il dispositivo attraverso i movimenti del pollice.
L'etichetta inserita sui pulsanti sopra definiti non è limitata a un semplice più e un meno, ma riflette quello che ci si aspetterebbe di poter compiere per interagire con un sistema termodinamico, ossia avere la possibilità di riscaldarlo e di raffreddarlo.
Dunque l’utente non ha la possibilità di agire direttamente sul moto delle particelle se non attraverso un aumento della temperatura del sistema in conseguenza di un'aggiunta o di una sottrazione di calore in e da esso.
Sopra i pulsanti di avvio e arresto e di fianco ai radio button per lo switch sulla scala di temperatura e al campo select, è presente uno spazio che all'avvio del simulatore mostra la temperatura standard assunta dal sistema (che per convenzione è fissata a venticinque gradi Celsius, duecentosettantatré cioè Kelvin).
La temperatura, come già sottolineato, varia in base alle aggiunte e alle sottrazioni di calore in e dal sistema e rimane un parametro presente durante tutta l'esecuzione della simulazione. Questo permette di monitorare lo stato di aggregazione di una determinata sostanza e il comportamento delle sue particelle a una data temperatura.
Anche gli altri pulsanti presenti hanno etichette in linea con le funzioni a essi associate. Così, il pulsante “start” avvia la simulazione mentre il pulsante “stop” ne interrompe l'esecuzione.
Al caricamento della pagina web con il simulatore, le opzioni all'interno del campo select (ossia le sostanze selezionabili) vengono generate dinamicamente tramite JavaScript. Per comodità è stata scelta una sostanza di default, ovvero l'acqua, alla spiegazione dei concetti di materia, di stato, di aggregazione e di passaggi di stato.
È sufficiente interagire con il tasto start per visualizzare il comportamento della sostanza di default, ma è anche possibile selezionare una sostanza differente dall'acqua e premere il solito tasto per eseguire la simulazione.
Il precedente esempio rende l'idea di quanto sia semplice e intuitiva l'interfaccia utente sopra descritta.
Proseguendo l’analisi del layout, il diagramma SVG (inserito nella sezione a sinistra dell’interfaccia) presenta il sistema di riferimento dove saranno disegnate le particelle all'avvio del simulatore. A questo diagramma è stata riservata un’ampia porzione di interfaccia poiché è l’elemento principale che permette agli studenti di visualizzare il comportamento delle particelle e di confrontare la simulazione con le leggi imparate sui libri.
All'avvio del simulatore il cloruro di sodio, che a temperatura ambiente si trova allo stato solido, presenta le proprie particelle disposte secondo una struttura ordinata e reticolare. La seguente immagine illustra come sono strutturate, in ogni sostanza, le particelle di materia che allo stato solido:
Le particelle di cloruro di sodio (comunemente chiamato sale) assumono una struttura regolare, come se fossero incasellate all'interno di un reticolo. All'aumentare della temperatura il loro movimento vibrazionale aumenta. Tuttavia, fino a che si rimane nell'intervallo di temperatura in cui la sostanza si trova allo stato solido, le particelle, pur assumendo un comportamento più frenetico, rimarranno approssimativamente nella posizione ordinata e compatta (come nell'immagine precedente).
Differentemente dalla struttura ordinata dello stato solido, una sostanza come l'acqua, che a temperatura ambiente si trova allo stato liquido, all'avvio del simulatore verrà generata con le particelle aventi la seguente struttura disordinata:
Allo stato liquido alle particelle di una sostanza è permesso di scivolare le une sulle altre; tuttavia, quella che a livello di impatto visivo può sembrare una sovrapposizione, in realtà non è altro che uno stratagemma al fine di simulare un comportamento più fluido delle particelle e ottenerne un più intuitivo riscontro visivo.
L'ossigeno molecolare, che a temperatura ambiente si trova allo stato gassoso, all'avvio del simulatore presenterà la struttura particellare disposta come nella seguente immagine:
Come descritto in precedenza, allo stato gassoso le particelle si sovrappongono ma possono tangersi. Allo stato gassoso le particelle sono libere di muoversi all'interno del contenitore perché non soggette alla forza di gravità, bensì al moto Browniano.
In definitiva i ragazzi interagendo con il simulatore dovrebbero verificare, sulla base delle premesse dei concetti presentati durante le lezioni frontali che:
✔ Un gas è composto di particelle;
✔ Le particelle di un gas sono soggette a un rapido e continuo movimento caotico;
✔ Le particelle che formano i liquidi sono in movimento e libere di scivolare le une sulle altre; ✔ Le particelle dei liquidi sono tenute assieme da forze attrattive deboli e dalla forza di
gravità;
✔ Lo spazio tra particelle in un liquido è molto limitato;
✔ Le particelle allo stato solido sono disposte in modo ordinato;
✔ Le particelle allo stato solido occupano posizioni determinate e non cambiano mai di posto e si limitano a vibrare ciascuna attorno a un punto fisso;
✔ Per ogni data sostanza il punto di fusione corrisponde al punto di solidificazione e viceversa; ✔ Al variare della temperatura varia lo stato energetico interno delle particelle ma non la loro
struttura;
✔ Allo zero assoluto il moto particellare cessa di esistere.
L’illustrazione del movimento delle particelle di una sostanza allo stato gassoso può essere accompagnato con la spiegazione da parte del docente agli alunni riguardo riguardo al fatto che esse si trovano a collidere con le particelle di aria presenti nel contenitore.
Tutte le sostanze, indistintamente, manifestano nei tre stati di aggregazione lo stesso comportamento del moto particellare. Cambiano a livello visivo, da sostanza a sostanza, il colore di riempimento delle particelle e la loro dimensione.
Un modello visivo dinamico con il quale i ragazzi possano interagire, può ben contribuire molto a rafforzare e in alcuni casi a chiarire i concetti esposti con una spiegazione teorica.
All'avvio del simulatore, oltre all'animazione del moto particellare, è stata definita la generazione di un diagramma per le temperature in funzione della sostanza.
Anche questo diagramma è stato creato tramite SVG, in questo contesto utilizzato come tela e non come piano sul quale mettere in movimento degli oggetti.
Il diagramma isobaro viene disegnato alla destra dell'animazione, sopra i pulsanti. I criteri con cui viene generato seguono i parametri di ogni specifica sostanza.
Sull'asse delle ascisse è rappresentato il tempo in rapporto all'aggiunta di calore all'interno del sistema; sull'asse delle ordinate è rappresentata la temperatura. Sull'asse delle ordinate sono inoltre indicati i valori dei parametri della sostanza, rispettivamente punto di fusione e punto di ebollizione, (entrambi espressi sia in gradi Celsius sia tramite la scala Kelvin).
L'esempio seguente riporta un diagramma dove, partendo dall'origine e salendo sull'asse delle ordinate, si incontrano rispettivamente il valore del punto di fusione della sostanza e il valore del punto di ebollizione.
In corrispondenza di questi valori, sull'asse delle ascisse sono indicati i rispettivi segmenti che definiscono l'intervallo del calore latente di fusione e quello del calore latente di ebollizione. Questi intervalli identificano quando una sostanza allo stato solido si liquefa e quando una sostanza allo stato liquido passa allo stato gassoso. Le doppie frecce disegnate all'interno di questi intervalli rappresentano la reversibilità dei passaggi di stato.
Oltre alla sezione dove si trovano diagramma e interfaccia utente, la pagina HTML consta di un'ulteriore sezione (che per semplicità verrà definita come pagina terziaria), accessibile con uno scrolling verso destra sul layout di Alvaro Trigo. La pagina è composta dai seguenti elementi:
Nella pagina terziaria sono presenti, oltre a un diagramma isobaro del tipo definito precedentemente, tutta una serie di parametri specifici della sostanza selezionata quali:
• nome della sostanza; • nome iupac; • formula minima; • peso molecolare; • punto di fusione; • punto di ebollizione; • STP; • densità;
9. Illustrazione: Elementi sulla pagina dopo l’avvio del modello particellare e dopo 2 click sulla freccia destra, partendo dalla homepage
• collegamento alla pagina Wikipedia della sostanza.
Questo secondo grafico generato è arricchito con indicatori letterali per ogni segmento e una legenda che descrive più nel dettaglio a cosa corrispondano le conseguenze di aggiunta e sottrazione di calore al sistema nel tempo.
I parametri sono specifici per ogni sostanza, vengono generati all'avvio del simulatore e si presentano con il seguente aspetto:
Nella parte inferiore della pagina terziaria, subito dopo i succitati parametri, sono riportate due immagini: una mostra la natura molecolare della sostanza e l'altra che la presenta in un contesto reale, come nel seguente esempio, sempre per l'acqua:
Come accennato in precedenza, le sostanze sono definite come oggetti di un file JSON; il lavoro sul codice ha interessato la riduzione del livello di difficoltà di lettura (dello stesso) in previsione di più facili aggiornamenti futuri.
11. Illustrazione: Parametri della sostanza nella pagina terziaria
Così, se volessimo inserire ulteriori sostanze nel nostro simulatore, sarebbe sufficiente aggiungere un oggetto al file JSON sulla base dei criteri con cui è stato progettato; al successivo caricamento della pagina, troveremmo subito questo oggetto selezionabile fra le opzioni nell'interfaccia.
In ultima analisi, nel nostro simulatore sono omessi i casi relativi ai fenomeni di sublimazione e brinamento perché sono concetti che solitamente nelle scuole secondarie di primo grado vengono solo accennati per essere poi affrontati in dettaglio alle scuole superiori.
Le particelle non si ingrandiscono se riscaldate e non si rimpiccioliscono se raffreddate; mantengono sempre la stessa dimensione. È percepibile il cambiamento nel moto delle particelle in caso di aumenti o diminuzioni della temperatura. Nei passaggi tra uno stato di aggregazione a un altro alle particelle viene modificato il colore di riempimento delle particelle in modo tale che i ragazzi possano percepire che è avvenuto un cambiamento nel loro contenuto energetico ma non nella loro composizione dato che la loro forma rimane immutata. In altre parole, con l'immissione di calore nel sistema di riferimento, i ragazzi dovrebbero apprezzare il fatto che le particelle aumentano la propria energia cinetica interna (si muovono in maniera più frenetica) e che questo aumento energetico non corrisponde a un cambiamento della struttura particellare, ma riflette solo il movimento di tutte le particelle della sostanza.
Come già accennato, il parametro della pressione non è stato preso in considerazione in quanto nei programmi di insegnamento delle scienze nelle scuole secondarie di primo grado non è considerato come elemento condizionante del movimento particellare. Se questo fosse stato presa in considerazione, oltre alla definizione di un diagramma delle temperature, per ogni sostanza sarebbe stato necessario definire un secondo diagramma per le isoterme e un terzo che conciliasse entrambi i parametri di temperatura e pressione, comprendente il punto triplo e tanti altri aspetti non contemplati persino nel programma del biennio delle scuole secondarie di secondo grado.
1.2 Introduzione alle tecnologie mobili di riferimento
Per la creazione dell’applicazione mobile riguardante il modello particellare, sono state prese in considerazione diverse tecnologie. Fin da principio non si è immediatamente riconosciuto il target tecnologico di riferimento, e, prima di incominciarne lo sviluppo, la lettura di documentazioni, la ricerca e lo studio delle varie tecnologie messe a disposizione, sono state le prime operazioni eseguite.
A grandi linee si è ipotizzato che l’applicazione mobile sarebbe stata sviluppata in un linguaggio proprietario di un sistema operativo mobile (Android, Windows Phone, iOS), oppure il sito web originario sarebbe stato inserito all’interno di un wrapper, ovvero un contenitore che contiene generalmente un’altra applicazione.
In questo sotto capitolo verranno confrontate le varie tecnologie prese in considerazione per lo sviluppo del modello particellare mobile, quelle che non sono state utilizzate con i relativi motivi, e quelle che sono state adoperate nella creazione del risultato finale.
1.2.1 Kotlin per Android
Considerando solo Android come sistema operativo mobile target, originariamente è stato preso in considerazione di utilizzare la programmazione Java in Ambiente Android, utilizzando il compilatore Java principale (Javac) incluso nel Java Development Kit (JDK) e parte delle librerie J2SE, dedite allo sviluppo e alla distribuzione di codice per ambienti Desktop o Server, con l’aggiunta di Tools per trasformare il bytecode Java in DEX e impacchettare le classi nel formato apk14.
I file DEX, acronimo di Dalvik Executable sono file progettati per sistemi vincolati in termini di memoria e velocità di processore. Questi file vengono creati per essere eseguiti sulla macchina virtuale dentro la quale vengono eseguite la maggior parte delle applicazioni Android, ovvero Dalvik, una macchina virtuale molto simile alla JVM15 di Java con importanti differenze:
• basata su registri (e non su stack)16;
• avente un set di istruzioni ottimizzato per risparmiare memoria e aumentare la velocità di esecuzione;
• formata dai file eseguibili ottimizzata per risparmiare memoria;
• eseguibile da più processi con una sola istanza (progettato in modo che una singola copia del codice in memoria possa essere condiviso ed eseguito contemporaneamente da utenti multipli o processi separati);
14 APK, acronimo di Android Package Kit, è il formato del file di pacchetti utilizzato dal sistema operativo Android per la distribuzione e l'installazione di applicazioni mobili e middleware (software che fornisce servizi alle applicazioni oltre a quelle disponibili dal sistema operativo. Può essere descritto come "colla software".).
15 JVM è il componente della piattaforma Java che esegue i programmi tradotti in bytecode dopo una prima compilazione.
16 Il registro è una piccola parte di memoria utilizzata per velocizzare l'esecuzione dei programmi fornendo un accesso rapido ai valori usati più frequentemente (tipicamente i valori correntemente in uso in una determinata parte di un calcolo), lo stack è un indica un tipo di dato astratto che viene usato in diversi contesti per riferirsi a strutture dati, le cui modalità d'accesso ai dati in essa contenuti seguono una modalità LIFO (Last In First Out), ovvero tale per cui i dati vengono estratti (letti) in ordine rigorosamente inverso rispetto a quello in cui sono stati inseriti (scritti).
• Non appartiene al controllo di Oracle17;
Dalvik è la macchina virtuale di default per Android, dalla creazione di esso fino ad Android 4.4, versione nella quale era possibile passare ad un altra macchina virtuale, chiamata ART, che è diventata, da Android 5, la macchina virtuale di default per Android.
Le differenze tra ART e Dalvik sono diverse:
• ART compila al momento dell’installazione e non interpreta a differenza di Dalvik18;
• ART ha un’installazione più lenta ed un esecuzione più veloce, mentre nel caso di Dalvik è il contrario;
• le differenze tra le due macchine virtuali sono invisibili per il programmatore e l’utente dell’applicazione mobile;
• Dalvik è usato da tutti i dispositivi che attualmente sono in possesso degli utenti;
• Google ritiene che in futuro porterà avanti lo sviluppo soltanto di ART, poiché è più veloce in esecuzione, ha una migliore gestione del garbage collection19, ha una grafica più fluida, ha
una maggiore integrazione di con profiling e debugging ed un minor consumo di batteria, con consequenziale durata della batteria più a lungo.
17 Nel 2010, Oracle ha fatto causa a Google per l’utilizzo di Java come base per Android. La diatriba è ancora in atto e sembrano esserci nuovi sviluppi. Oracle, l’attuale proprietario di Java, chiede 9,3 miliardi di dollari di danni a Google, quasi il doppio dell’utile prodotto da Google nel 2015. Google ha sviluppò Dalvik che adesso è compatibile con Java, ma è stato sviluppato indipendentemente da Google, senza l’uso di qualsiasi codice effettivo da parte di Oracle. Google è stato impegnato in trattative con Sun Microsystems e successivamente, con Oracle, per quanto riguarda le licenze per Android. Tuttavia, nessun accordo è stato raggiunto entro il 2010 e Oracle ha deciso di citare in giudizio Google. Oracle sostiene che Google abbia violato alcuni dei brevetti e diritti d’autore di Oracle relativi a Java. Google insiste sul fatto che, anche se ha infranto il copyright di Oracle, che è stato coperto sotto fair
use, ovvero che non richiede il permesso del detentore del copyright originale e che le API coinvolte nello sviluppo
di Android non sono coperte da copyright; sembra però che per quanto riguarda la legge sul copyright, Oracle sostenga che la “struttura, la sequenza e l’organizzazione” delle API Java sia tutto coperto da copyright. Nel 2012, una giuria ha stabilito che Google aveva infatti violato il copyright di Oracle per quanto riguarda le API, ma non è stata in grado di decidere se il caso ricadeva nel fair use. Google ha ovviamente contestato la sentenza e ha spinto per un nuovo processo all’udienza del copyright. Un processo separato è stato condotto per le accuse di violazione di brevetto. Il nuovo processo per la sentenza del copyright ha comportato una sentenza a favore di Google, ma un ulteriore revisione del processo ha di nuovo deliberato in favore di Oracle. Il caso avrà importanti implicazioni per i brevetti sul software sulle licenze in tutto il mondo, specialmente per gli sviluppatori Java. Se essi fossero costretti a sottostare a costi di licenza elevata per ogni applicativo installato, il numero degli sviluppatori potrebbe assottigliarsi in favore di altri linguaggi meno vincolati.
18 A differenza di un interprete, un compilatore non esegue il programma che riceve in ingresso, ma lo traduce in linguaggio macchina (memorizzando su file il codice oggetto pronto per l'esecuzione diretta da parte del processore). Per qualunque linguaggio di programmazione si può scrivere sia un interprete che un compilatore, pertanto le espressioni linguaggio interpretato e linguaggio compilato sono scorrette, essendo interpretazione e compilazione concetti afferenti alla implementazione di un linguaggio e non al linguaggio in sé.
19 Il Garbage collector (GC) è una forma di gestione della memoria automatica. Il Garbage collector, o semplicemente il collector, cerca di recuperare la memoria occupata da oggetti che non sono più in uso dal programma.
Se con ART si può dire che sia avvenuto un buon cambiamento in termini di prestazioni, con l’avvento del linguaggio di programmazione Kotlin20 è stata diminuita la dipendenza di Android da
tecnologie proprietarie o non controllate da Google, con la conseguente riduzione di cause legali. Sviluppato da JetBrains, Kotlin è stato annunciato come linguaggio ufficiale per sviluppare applicazioni Android durante il Google I/O 201721.
Ciò significa che, mentre è ancora possibile sviluppare applicazioni Android utilizzando Java, dalla primavera del 2017 Kotlin è pienamente supportato e Google ha assicurato che tutte le nuove funzionalità Android, il framework, l'IDE e tutte le loro librerie funzionano senza problemi con il nuovo linguaggio.
Google ha ascoltato la comunità, che ha chiesto per anni che Kotlin diventasse un linguaggio di prima scelta. Quindi adesso si può approfittare di tutte le funzionalità di un linguaggio moderno sviluppando su Android.
Kotlin ha un suo ambiente di sviluppo integrato chiamato IntelliJ IDEA22, ed ha una serie di
caratteristiche, sia basilari e di semplice esecuzione, sia di gran lunga superiori a Java:
➢ Kotlin è molto intuitivo e facile da imparare per gli sviluppatori Java; la maggior parte delle parti della linguaggio sono molto simili a quelle che già sono conosciute, e le differenze nei concetti di base possono essere apprese in poco tempo;
➢ è stata eseguita un’integrazione totale con l’IDE, infatti Android Studio Canary è una nuova versione di Android Studio23 che può compilare ed eseguire il codice di Kotlin;
➢ Kotlin è più espressivo: questa è una delle sue qualità più importanti. Si può scrivere molta più logica di un programma con molto meno codice;
➢ è un linguaggio più sicuro: Kotlin è null safe, ciò significa che si occupa di possibili situazioni che possono risultare nulle durante la compilazione, per evitare eccezioni di tempo di esecuzione; si deve specificare esplicitamente che un oggetto può essere nullo e quindi si deve controllarne la sua “nullità” prima di utilizzarlo; sarà quindi possibile 20 https://kotlinlang.org/
21 Google I/O è una conferenza tenuta annualmente fin dal 2008 da Google a San Francisco, rivolta agli sviluppatori ed incentrata sullo sviluppo di applicazioni web e mobili attraverso Google e relative tecnologie come Android, Chrome, Chrome OS, Google Web Toolkit, Google App Engine e altre. La "I" e la "O" stanno per Input/output. 22 Sempre sviluppato da JetBrains.
23 Android Studio è l'ambiente di sviluppo integrato ufficiale (IDE) per il sistema operativo Android di Google, basato sul software IDEA di IntelliJ JetBrains e progettato appositamente per lo sviluppo di Android. È disponibile Windows, MacOS e Linux. È stato l’ambiente sostitutivo per gli strumenti di sviluppo Android di Eclipse (ADT) come IDE primario per lo sviluppo di applicazioni Android nativo.
risparmiare un sacco di tempo per eseguire il debug di eccezioni del puntatore null fissando un bug di nullità;
➢ è funzionale: Kotlin è fondamentalmente un linguaggio orientato agli oggetti, non un linguaggio funzionale puro; tuttavia, come molte altri linguaggi moderni, utilizza molti concetti di programmazione funzionale, come le espressioni lambda, per risolvere alcuni problemi in modo molto più semplice e intuitivo;
➢ utilizza funzioni di estensione; ciò significa che si può estendere qualsiasi classe con nuove funzionalità anche se non si ha accesso al codice sorgente;
➢ È altamente interoperabile: si può continuare ad utilizzare la maggior parte delle librerie e il codice scritto in Java, perché l'interoperabilità tra i due linguaggi è eccellente. È anche possibile creare progetti misti, con i file Kotlin e Java coesistenti.
Uno degli esempi più salienti riguardo l’utilizzo di Kotlin è avvenuto proprio al Google I/O 2017, durante il quale il leader del progetto Kotlin, Andrey Breslav, mostra la differenza tra i thread di Java e quelli di Kotlin, quelli di quest’ultimo chiamati coroutines (e da non definirsi prettamente thread).
Con due programmi a confronto che eseguivano esattamente le stesse operazioni, ovvero, dati centomila thread (coroutines per Kotlin), ognuno aspetta un secondo e restituisce il numero uno. La differenza sostanziale tra i due linguaggi è che Java semplicemente non funziona, perché non riesce a gestire i centomila thread, mentre Kotlin esegue il programma in un secondo24.
Per la creazione del modello particellare mobile (sfortunatamente) non è stato utilizzato Kotlin, e consequenzialmente nemmeno Java, per il semplice fatto che l’applicazione risultante funzionerebbe solo su un dispositivo con sistema operativo Android, e l’impegno di sviluppo di un’applicazione nativa sarebbe risultato molto più impegnativo. Inoltre l’obiettivo primario è quello di rilasciare un’applicazione cross-platform.
Nei capitoli successivi vengono presentate altre tecnologie, mirate ad uno sviluppo più incentrato sul modello particellare mobile.
24 Per la visione del video illustrativo di Kotlin al Google I/O 2017 visitare l’indirizzo sottostante: www.youtube.com/watch?v=X1RVYt2QKQE
1.2.2 La libreria Kivy di Python
Kivy25 è un moderno toolkit grafico per l'interfaccia utente sviluppato in Python. Permette di
sviluppare facilmente interfacce naturali per un'ampia gamma di dispositivi. Un’applicazione può essere scritta una volta sola e può funzionare su svariati device. Per una serie di sviluppatori è molto intuitivo approcciare a Kivy, per alcuni motivi principali:
• Kivy ha un elegante supporto integrato per i dispositivi multitouch.
• Kivy è l'unico modo utile per codificare in Python su dispositivi mobili (per adesso). • Kivy sostituisce le API di interfacce grafiche come HTML e CSS.
• Kivy consente di mantenere una singola applicazione per numerosi sistemi operativi.
Anche per chi non ha molta esperienza di programmazione, Kivy lo si può imparare in pochissimo tempo grazie alla semplicità di scrittura del codice Python, considerato spesso un ottimo compromesso tra prestazioni e semplicità di sviluppo.
Attualmente esistono due versioni attive di Python: Python 2 e Python 3. La sintassi e la librerie standard sono cambiati tra le due versioni ma entrambe sono molto popolari.
A partire dalla versione 1.8, Kivy supporta sia gli interpreti Python 2 che di Python 3, ma per lo sviluppo è consigliabile utilizzare Python 3, in quanto possiede una sintassi più semplice, ed ha una libreria standard più chiara.
Tuttavia, da una prospettiva di facile utilizzo, è più probabile che Python 2 sia già installato nei computer con sistemi operativi Linux e OS X. Inoltre, gli strumenti utilizzati per la distribuzione per Android e iOS funzionano solo su Python 2, e potrebbe non essere un problema se si volesse sviluppare un’applicazione mobile avente uno dei due sistemi operativi sopracitati.
Per avviare un progetto Kivy dopo aver installato la libreria, basta creare una directory dedita ad ospitare il progetto e aprire un nuovo file chiamato main.py con un qualsiasi editor di testo.
Il modulo Python di partenza per tutte le applicazioni di Kivy dovrebbe essere denominato main.py, in quanto gli strumenti di generazione utilizzati per automatizzare la distribuzione nei dispositivi mobili cercheranno quel file. Ora basta aggiungere le seguenti di righe di codice a questo nuovo file:
from kivy.app import App App().run()
Questo è il codice sul quale Kivy pone le fondamenta. Importa una classe App, la istanzia e chiama il metodo di esecuzione. Per eseguire questo codice, attivando l'ambiente Kivy, basta digitare su terminale il seguente comando:
python main.py
o, nel caso si stesse sviluppando sul sistema operativo Mac OS:
kivy main.py
dopo aver digitato i seguenti comandi, viene aperta una finestra vuota con uno sfondo nero, e quella corrisponderà alla nostra applicazione attualmente vuota. L'oggetto App di Kivy fa un'impressionante quantità di lavoro poichè si occupa di molteplici operazioni in background: interagire con l'hardware dello schermo; parlare con dispositivi di input quali display multitouch, tastiere e accelerometri, attività di pianificazione delle applicazioni come Promemoria, e molto altro ancora.
Un’altra caratteristica di Kivy è il KV language (talvolta chiamato kvlang o linguaggio kivy) il quale consente di creare in modo dichiarativo, come un linguaggio di markup, la struttura di widget e di associare le proprietà dei widget alle chiamate delle funzioni in modo naturale. Consente una prototipazione molto veloce e modifiche agili all'interfaccia utente. Facilita anche una buona separazione tra la logica dell'applicazione e la sua interfaccia utente.
Se si volesse creare, ad esempio, un tipo di contenuto che sia una riga di testo, non resta che creare un nuovo file, chiamato contents e salvarlo con l’estensione .kv:
#:kivy 1.8.0 <Label>:
text: “Hello World”
Successivamente, per leggere e interpretare questo file dedito alla lettura dei componenti dell’interfaccia, non resta che scrivere un programma di questo tipo:
from kivy.app import App #kivy.require("1.8.0")
from kivy.uix.label import Label
class contents(App): def build(self): return Label()
if __name__ == "__main__": contents().run()
Con semplicemente otto righe di codice in un file e tre in un altro, è stata creata un applicazione con una etichetta (Label) che può essere utilizzata sia su Desktop che su piattaforme mobili. Il programma per leggere almeno un componente dal file contents.kv, deve avere una classe che abbia lo stesso nome del file, ed un metodo che restituisca l’oggetto in questione. Importante inoltre l’uso delle parentesi angolate26 per i nodi padre all’interno del file kv. Senza di esse il programma
funzionerebbe, ma la scritta dalla seguente videata sparirebbe, poiché non interpretata:
Nonostante il potenziale osservato in Kivy, come è accaduto per Kotlin, non è stato possibile utilizzare questa libreria formidabile, poiché l’applicazione web originaria sarebbe stata completamente riscritta, abbandonando tutte le tecnologie web trattate nel precedente capitolo, e quindi utilizzando nuovi strumenti messi a disposizione dalla libreria di Python.
È stato scelto in un primo luogo, di non utilizzare il linguaggio di programmazione Kotlin per il suo problema di non essere un linguaggio OS agnostic, ovvero funzionante su tutti i sistemi operativi. Successivamente non è stato scelto Kivy che, pur funzionando su tutti i dispositivi mobili, non si è rivelato di facile utilizzo in previsione di un ipotetica riscrittura in codice Python del motore grafico
26 Caratteristica che rende il linguaggio k v simile ad XML e ed ancora più simile QML (Qt Meta Language o Qt
Modeling Language), un linguaggio di markup dedito proprio alla creazione di interfacce grafiche. 13. Illustrazione: Videata mostrante l’applicazione Hello World
del modello particellare composto da molteplici linguaggi sia di markup, sia di programmazione, tra cui JavaScript in primo luogo, HTML e CSS, non di minore importanza.
1.2.3 Il framework Xamarin
Xamarin27 è un framework per lo sviluppo di app native e cross-platform con C#. Il framework si
basa sul progetto open source Mono offrendo pieno supporto non solo alle piattaforme Android e iOS ma anche a Windows Phone.
Xamarin si compone di tre componenti principali:
• Xamarin.Android è basato su Mono, un framework framework open source per l’implementazione del .NET Framework di Microsoft su Linux;
27 https://www.xamarin.com/
• Xamarin.iOS è basato sulla libreria proprietaria MonoTouch, offre pieno supporto allo sviluppo di app iOS tramite un wrapping delle API native in C#;
• Xamarin.Forms si pone al di sopra dei precedenti componenti e permette la piena condivisione del codice.
Grazie a queste componenti è possibile gestire in C# tutte le caratteristiche di Android, iOS e Windows Phone, dall’interfaccia utente alle risorse hardware del dispositivo. Tale suddivisione permette di gestire la UI attraverso elementi tipici delle singole piattaforme (grazie al binding con le SDK native), e elementi definiti in Xamarin.Forms nel caso di app cross-platform in cui è necessario mostrare agli utenti una UI più familiare.
Pur essendo un framework cross-platform, Xamarin richiede un regno di conoscenze molto ampio comprendente il la piattaforma di sviluppo software .NET, e ampie conoscenze della programmazione nativa in ambienti MacOS, iOS e Android. Fondamentalmente, quindi, Xamarin viene definito come un framework nativo, e non web-based.
Potrebbe sorgere spontanea una domanda sul perché non creare nativamente tre webview28 per ogni
sistema operativo mobile (prescindendo dall’utilizzo di Xamarin) contenenti l’url della vecchia applicazione web del modello particellare. La risposta è che non sarebbe possibile far funzionare l’applicazione offline, cosa molto importante, dato che potrebbe capitare che una scuola secondaria di primo grado potrebbe non avere una connessione wireless, e gli studenti potrebbe avere dispositivi mobili non connessi alla rete, questione rara, ma plausibile.
1.2.4 La scelta di Apache Cordova
L’applicazione mobile è stata creata con Apache Cordova. Cordova29 è un framework open source
che utilizza HTML5 per la creazione di applicazioni native cross-platform. I creatori di Apache Cordova volevano un modo più semplice per costruire applicazioni mobili cross-platform e hanno deciso di implementarlo come una combinazione di tecnologie native e tecnologie web. Questo tipo di applicazioni mobili sono chiamate applicazioni ibride.
Il vantaggio iniziale di Apache Cordova è la capacità nativa al di sopra di ciò che è normalmente supportato nel browser. Fino al momento della sua nascita il modo migliore per costruire un’applicazione mobile che funziona su più dispositivi mobili era quello di crearla usando solo le 28 Una webview è una view (che sua volta rappresenta l’elemento costitutivo per i componenti dell'interfaccia utente ed è responsabile del disegno e della gestione degli eventi) che visualizza le pagine web. Questa classe è la base su cui è possibile ruotare il proprio browser web o visualizzare semplicemente alcuni contenuti online all'interno della activity corrente.
