Add correction

documentazione.md

@@ -64,8 +64,8 @@ Potendo opera unicamente nello spazio utente non è stato possibile superare que
 Tutte le funzionalità legate al bluetooth sono state *incapsulate* all'interno della classe `BluetoothManager`.
 L'interfaccia di questa classe espone due metodi, `startService()` e `stopService()` che consentono di avviare e stoppare sia la scansione che la trasmissione del beacon.
 Poiché queste operazioni vanno ad interagire con le funzionalità del sistema operativo, l'istanza di questa classe deve essere collegata ad un oggetto di tipo `Context`.
-Si è scelto di collegare l'oggetto `BluetoothManager` alla *application* e non ad una `Activity` in quanto i servizi devono essere utilizzati anche quando non sono presenti *activity* in *foreground*.
-Per questo motivo è stata sviluppata anche una classe `BluetoothApplication` che va ad estendere le funzionalità di `Application` e fornisce a sua volta due metodi di start e stop che vanno a richiamare quelli esposti da `BluetoothManager` in modo tale che sia possibile controllare i servizi legati al bluetooth anche da altre componenti dell'applicazione.
+Si è scelto di collegare l'oggetto `BluetoothManager` all'*application* e non ad una `Activity` in quanto i servizi devono essere utilizzati anche quando non sono presenti *activity* in *foreground*.
+Per questo motivo è stata sviluppata anche una classe `BluetoothApplication` che va ad estendere le funzionalità di `Application` e fornisce a sua volta due metodi di start e stop che vanno a richiamare quelli esposti da `BluetoothManager` in modo tale da rendere possibile il controllo dei servizi legati al bluetooth anche da altre componenti dell'applicazione.
 
 ### Trasmissione
 
@@ -119,16 +119,16 @@ Per questo motivo si è scelto di utilizzare il livello LOW che permette di rile
 
 ### Scansione
 
-Le operazioni di scansione sono meno limitate dalle funzionalità dell'API di Android e per questo motivo si ha avuto maggiore libertà di scelta.
+Le operazioni di scansione sono meno limitate dalle funzionalità dell'API di Android e per questo motivo c'è stata maggiore libertà di scelta.
 In particolare è stato possibile settare sia l'intervallo temporale che deve intercorrere tra una scansione e la successiva, sia la durata della singola scansione.
 Si è scelto di far trascorrere un minuto tra una scansione e la prossima e di avere una scansione della durata di un secondo.
-Per quanto detto già in precedenza in base ai vari dispositivi e alle varie condizioni di funzionamento l'intervallo tra una scansione e la prossima potrebbe essere più ampio rispetto a quello stabilito.
+Per quanto detto già in precedenza in base ai vari dispositivi e alle varie condizioni di funzionamento l'intervallo tra una scansione e la successiva potrebbe essere più ampio rispetto a quello stabilito.
 Entrambi i parametri sono stati settati tramite una costante in modo tale da poter configurare facilmente il comportamento dell'applicazione.
 
-Quando l'applicazione rivela un beacon nelle vicinanze esso viene trasmesso ad un'ulteriore componete applicativa tramite l'impiego del `LocalBroadcastManager` @BroadcastsOverview.
+Quando l'applicazione rivela un beacon nelle vicinanze esso viene trasmesso ad un'ulteriore componente applicativa tramite l'impiego del `LocalBroadcastManager` @BroadcastsOverview.
 Questa componente non consuma direttamente il beacon, ma ha il compito di smistarlo ad ulteriori componenti in base alla modalità di funzionamento dell'applicazione.
-Il codice necessario a smistare i dati di contatto è stato riportato nel listato @lst:contact-receiver.
-Come si può notare a linea 2, la prima operazione consiste nel recupero dei dati di contatto dall'`Intent`, mentre dala linea 7 si seleziona la funzione da invocare in base alla modalità di funzionamento.
+Il codice necessario a smistare i dati di contatto è stato riportato nel @lst:contact-receiver.
+Come si può notare nella linea 2, la prima operazione consiste nel recupero dei dati di contatto dall'`Intent`, mentre dalla linea 7 si seleziona la funzione da invocare in base alla modalità di funzionamento.
 
 ``` {.kotlin .numberLines #lst:contact-receiver caption="Codice necessario allo smistamento dei dati di contatto."}
 // ...
@@ -147,14 +147,14 @@ onMode(context, contactData)
 ```
 
 Nel caso della modalità *A* il beacon viene trasmesso alla classe `NetworkReceiver` che si occupa di trasmettere il contatto al server remoto.
-Mentre nel caso delle modalità *B* e *C* il beacon viene consumato dalla classe `StoreReceiver` la quale si occupa della memorizzazione permanete del contatto all'interno di un database locale.
+Mentre nel caso delle modalità *B* e *C* il beacon viene consumato dalla classe `StoreReceiver` la quale si occupa della memorizzazione permanente del contatto all'interno di un database locale.
 
 ### Stima della distanza
 
 In base all'intensità dell segnale (***rssi***) misurato dal dispositivo ricevente è possibile ottenere una stima della distanza che intercorre tra chi invia il beacon e chi lo riceve attraverso l'@eq:distanza.
 Per poter calcolare la distanza è necessario conoscere anche il valore di $n$ e $TxPower$.
 $n$ è una costante che generalmente assume valori compresi tra uno e quattro e ci permette di modellare i diversi ambienti in cui si può operare.
-Generalmente si utilizza $n$ pari a due quando si ipotizza di lavorare in ambienti *free space*.
+Generalmente s'impone $n$ pari a due quando si ipotizza di lavorare in ambienti *free space*.
 
 $$
 d = 10^{\frac{TxPower - rssi}{10 \cdot n}}