Si avvicina il WWDC e come al solito fioriscono le anticipazioni sulle novità che verranno presentate dalla Apple. Non sono particolarmente appassionato di queste pseudo-notizie, spesso completamente prive di fondamento, ma ogni tanto mi diverto a leggerle in giro per la rete.
Nel mare di cose inutili si trovano ogni tanto articoli intelligenti e ben fatti, in particolare quelli che invece che cercare di prevedere con una improbabile sfera di cristallo le mosse della Apple, provano ad elencare quello che sarebbe utile migliorare, in particolare nella struttura di base e nelle funzioni di OS X e iOS.
Fra gli articoli più interessanti che ho letto negli ultimi giorni, spiccano iOS 8 Wishes di Federico Viticci su MacStories – uno dei migliori blog in assoluto sul mondo Apple – e Why Apple should open up the iOS sandbox di Marco Tabini su MacWorld.
Entrambi gli articoli affrontano un tema che mi interessa moltissimo e che è di sicuro un grosso punto di forza di iOS, e contemporaneamente anche una grossa debolezza: il sandboxing delle applicazioni.
Il termine sandbox significa letteralmente recinto dei giochi e, in un contesto informatico, si può tradurre più o meno come ambiente protetto. Per semplicità da ora in poi userò quasi sempre il termine originale.
Il Sandbox delle applicazioni in iOS
Dalla iOS App Programming Guide:
For security reasons, iOS places each app (including its preferences and data) in a sandbox at install time. A sandbox is a set of fine-grained controls that limit the app’s access to files, preferences, network resources, hardware, and so on. As part of the sandboxing process, the system installs each app in its own sandbox directory, which acts as the home for the app and its data. To help apps organize their data, each sandbox directory contains several well-known subdirectories for placing files. Figure A-1 shows the basic layout of a sandbox directory.
Per motivi di sicurezza, nel corso dell’installazione iOS inserisce ciascuna app (incluse le preferenze ed i dati) in un ambiente protetto (_sandbox). Un sandbox è un insieme di controlli specifici che limitano l’accesso dell’app ai file, alle preferenze, alle risorse di rete, all’hardware e così via. All’interno di questo processo di sandboxing, il sistema installa ciascuna app in una cartella protetta che racchiude sia l’app che i suoi dati._ Per semplificare l’organizzazione dei dati di ciascuna app, ciascuna cartella protetta contiene una serie di cartelle ben definite in cui inserire i file. La Figura A-1 mostra l’organizzazione tipica di una cartella protetta.
[caption width=”975” align=”aligncenter”]<img src=”https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/Art/ios_app_layout_2x.png” width=”975” height=”1044” alt=”Figura A-1. Cartelle protette in iOS. La Figura è tratta da “iOS App Programming Guide”.” class /> Figura A-1. Cartelle protette in iOS. La Figura è tratta da iOS App Programming Guide.[/caption]
In pratica, quindi, ogni applicazione di iOS contiene al suo interno tutto quello che le serve per funzionare: l’eseguibile vero e proprio, i file di libreria, file vari di supporto e configurazione, i file delle immagini, le icone, i file temporanei ma anche i documenti prodotti usando l’applicazione stessa. Ci sono delle eccezioni, relative ad esempio alle foto, ma il concetto generale è questo.
Vantaggi
Quali sono i vantaggi di questo approccio?
Un primo vantaggio ovvio da quanto appena visto è che, essendo ogni applicazione completamente isolata dalle altre e dal sistema operativo, eventuali falle di sicurezza di una applicazione non compromettono le altre o il sistema operativo stesso.
Inoltre, il sandboxing evita all’utente di doversi preoccupare di gestire i file su iOS. Niente file o cartelle da creare, cancellare, rinominare, niente file da cercare chissà dove sul disco. Tutto è gestito dal sistema. Tutti i file sono visibili nell’applicazione usata, senza complicazioni inutili.
Un ulteriore vantaggio è che installare le applicazioni in iOS è facilissimo: basta copiare la cartella contenente tutto quello che serve all’applicazione per funzionare sull’iPhone o sull’iPad e via. Non servono installer che distribuiscano i file dell’applicazione qui e là sul disco. Una cosa pulita. Non ce ne accorgiamo solo perché il tutto è gestito da iTunes o direttamente dal dispositivo iOS.
Altrettanto facile è la disinstallazione delle applicazioni: basta tenere il dito sull’applicazione prescelta, aspettere che le icone inizino a tremolare e premere sulla piccola X
in alto a destra per disinstallarla, sicuri che non ne rimarrà traccia sul dispositivo.
Molto più semplice che sul concorrente Android, in cui in teoria le applicazioni possono essere disinstallate più o meno allo stesso modo, ma accettando di lasciare tracce più o meno pesanti della loro presenza. Anche la disinstallazione tramite la voce apposita delle Impostazioni di Sistema
lascia comunque rimasugli che possono solo essere rimossi manualmente o tramite tool appositi.
Svantaggi
Però l’approccio della Apple ha anche degli svantaggi.
Proprio perché la disinstallazione delle applicazioni rimuove tutto, si rischia di perdere insieme all’applicazione anche i documenti prodotti con essa. La cosa peggiore è che in caso di errore l’applicazione è facilmente reinstallabile ma i documenti sono comunque perduti per sempre.
Un altro svantaggio è che se si lavora su uno stesso file tramite più applicazioni, questo viene ogni volta copiato da una applicazione all’altra, per poter risiedere nella cartella protetta di ciascuna. Il problema non è tanto (o solo) lo spreco di spazio sul disco causato dalla duplicazione dei file, quanto il fatto che dopo un po’ si perde traccia delle modifiche effettuate sulle varie versioni dei file presenti nelle diverse applicazioni.
Prendiamo come esempio un file pdf. Il file inizialmente è sul Mac e viene sincronizzato con l’iPad tramite Dropbox per iOS. Da qui lo invio ad Adobe Reader per leggerlo. A un certo punto voglio aggiungere delle note o delle evidenziazioni al file, ma Adobe Reader non è adeguato e quindi lo trasferisco a GoodReader. Finito il lavoro, lo invio via email al Mac… Mi fermo qui ma è chiaro che dopo un po’ di passaggio (e dopo un po’ di tempo) ricordare la storia delle modifiche effettuate è praticamente impossibile.
Ancora peggio se si lavora su un progetto costituito da diversi file: documenti di testo, documentazione in pdf, presentazioni, immagini, filmati. Non c’è alcuna possibilità di accedere facilmente ai vari file del progetto e tutto è disperso fra le varie applicazioni, senza nessuno strumento che tenga insieme in qualche modo file di tipo diverso.
Un filesystem per iOS?
Insomma, con lo sviluppo dei dispositivi iOS, e soprattutto dell’iPad che ha ormai tutte le potenzialità per diventare un vero sostituto di un computer Desktop per la maggior parte degli utenti, si sente il bisogno di rendere più semplice ed efficiente la comunicazione fra le varie applicazioni.
Gli utenti avanzati, i power user, sarebbero favorevoli a che anche su iOS venga reso accessibile il filesystem (che esiste, ovviamente, ma è nascosto all’utente) o almeno una parte di esso (come su Android), vorrebbero avere a disposizione una specie di Finder per iOS che gli dia la possibilità di copiare o muovere i file ovunque o quasi all’interno del filesystem.
Mi metto anch’io fra questi. Per me l’uso del filesystem, la gestione di file e cartelle più o meno annidate, la scelta di volta in volta del programma da utilizzare per manipolare un determinato file, sono tutte cose ormai del tutto spontanee.
Ma so anche bene che per l’utente medio non valgono le stesse considerazioni.
I dispositivi iOS hanno successo non solo perché sono gestibili in modo più immediato con le dita, ma anche perché rendono naturale l’uso del computer e delle applicazioni, nascondendo all’utente tanti dettagli più o meno inutili. Si pensi ad esempio al non doversi preoccupare di salvare i file su cui si sta lavorando, ci pensa il sistema a farlo automaticamente. Per questi utenti un filesystem sarebbe una complicazione inutile. A quel punto i benefici di usare un iPad o un Phone verrebbero quasi a mancare del tutto.
Ma c’è una soluzione? Certamente e di certo più di una. Anche sfruttando le fondamenta stesse di Unix da cui deriva lo stesso iOS.