Automazione del flusso di lavoro su iOS (I).
Nonostante il fatto che per alcuni utenti l’iPad sia limitato a un dispositivo per il consumo di informazioni, la verità è che se combiniamo le sue funzionalità di base con le migliaia di applicazioni disponibili nell’App Store possiamo eseguire una moltitudine di attività legate al creazione di contenuti. Ovviamente iOS impone i propri limiti, quindi spetterà a noi cercare di superare questi vincoli per raggiungere gli obiettivi che ci siamo prefissati.
Nei prossimi articoli andremo a spiegare come, sulla base di una specifica esigenza (nel nostro caso, la pubblicazione di un articolo sul blog, anche se le opzioni e le casistiche a cui si può applicare sono molteplici), automatizzeremo il processo attraverso l’utilizzo di diversi strumenti. Per fare questo, inizieremo spiegando il Limitazioni iOSquali possibilità ci offre il sistema per evitarli e quali strumenti esterni possiamo utilizzare per il automazione. Concludiamo con un esempio per mettere in pratica tutto ciò che abbiamo “imparato”. L’idea finale è quella di riprodurre un flusso di lavoro OS X in iOS, adattandolo alle caratteristiche del sistema operativo mobile di Apple.
un po’ di contesto
Una delle caratteristiche principali di OS X è il gestione trasparente (all’utente) cosa fanno le applicazioni ai file con cui lavorano. Se utilizziamo iPhoto o iTunes, per fare due esempi di applicazioni Apple, si occupano di gestire foto, canzoni, video, ecc., senza che l’utente debba preoccuparsi della loro posizione sul disco. Certo, possiamo sempre accedere a questi contenuti tramite il Finder (più facile in iTunes che in iPhoto) e persino dire alle app che gestiremo noi stessi i file, ma probabilmente avremo meno problemi se lasciamo che OS X prenda il sopravvento questo lavoro. Qualcosa che, come diceva Apple, “funziona”.
Questa filosofia è portata all’estremo in iOS. Qui non è solo che le applicazioni gestiscono i propri file, ma lo fanno anche in isolamento. Ogni applicazione utilizza le proprie risorse e quindi non accedere a una struttura di file comune.
Cosa succede se vogliamo inviare un file da un’applicazione a un’altra? Qualcosa di semplice come, ad esempio, ricevere un’e-mail con un documento allegato che vogliamo vedere in Pages. Per aggirare questo blocco “autoimposto”, Apple offre la funzionalità “Apri in”.
In questo modo, se clicchiamo sull’icona del documento allegato all’e-mail, vedremo le diverse applicazioni con cui aprirlo, a patto che le abbiamo installate sul nostro dispositivo. Il problema fondamentale con questo modo di lavorare è il duplicazione filein modo che nell’applicazione Mail avremo una copia del documento e in Pages un’altra (ma questo punto è argomento per un’altra serie di articoli).
A complicare ulteriormente la situazione, l’assenza di un file manager in stile Finder ci impedisce di accedervi facilmente (sì, abbiamo applicazioni di terze parti disponibili su App Store che ci consentono di accedere “più o meno” ai file , ma sono non è la soluzione ideale e, inoltre, soffrono dello stesso problema visto al punto precedente).
Schemi URL
Apple implementa schemi URL, una funzionalità che consente aprire un’app da un’altra passaggio di determinate informazioni. Quando riceviamo un messaggio su iPhone con un numero di telefono o lo vediamo su una pagina web (ad esempio se vogliamo effettuare una prenotazione in un ristorante e fare una ricerca in Safari), cliccando sul numero possiamo chiamare direttamente. Allo stesso modo, possiamo avviare altre applicazioni come App Store o iTunes Store per acquistare rispettivamente applicazioni o brani che abbiamo visto durante la navigazione in Internet.
Questa integrazione non è limitata alle app Apple. Ad esempio, la versione 4.1 di 1Password ti consente di cercare il contenuto che abbiamo memorizzato nell’applicazione o utilizzare il tuo browser.
x-callback-url
Infine, iOS consente l’utilizzo della specifica x-callback-url (scritta da Greg Pierce) attraverso la quale alcune applicazioni possono eseguirne altre inviando parametri e ricevere il risultato dell’esecuzione. È, quindi, un miglioramento rispetto agli schemi URL menzionati in precedenza. Per fare ciò, le applicazioni “target” devono pubblicare i metodi di chiamata che le applicazioni di origine possono utilizzare. Sfortunatamente, il numero di applicazioni che supportano questa specifica è molto ridotto, anche se si prevede che più sviluppatori la implementeranno nelle loro app in futuro. Al momento della pubblicazione di questo articolo, le applicazioni che supportano questa specifica sono:
- Instapaper (3,59€): servizio per archiviare pagine web e leggerle successivamente senza essere connessi a Internet.
- Chrome (gratuito): il browser web di Google.
- Terminologia (€ 2,69): browser focalizzato sulla ricerca di definizioni di parole e frasi. Disponibile solo in inglese.
- Due (€ 4,49): un gestore completo di calendari e allarmi.
- Definizione (€ 0,89 in offerta): dizionario inglese senza connessione a Internet.
- Bozze (€ 3,59): strumento per acquisire e condividere testi.
- Scanner Go (0,89€): permette di leggere i codici a barre.
- iCab Mobile (€ 1,79): browser web.
- Fraseologia (€ 3,59): editor di testo ed elaboratore.
- iZettle (gratuito): trasforma il tuo dispositivo iOS in un terminale per effettuare pagamenti.
- Notesy ($ 4,49): app per prendere appunti con integrazione di Dropbox e TextExpander e supporto della sintassi Markdown
- Poster (€ 2,69): gestore di blog WordPress.
Nel seguente articolo vedremo quali strumenti utilizzeremo per svolgere il nostro compito dall’inizio alla fine. È un’esigenza specifica (come abbiamo già accennato, la pubblicazione di un articolo in un blog), ma crediamo che possa essere interessante come esempio. Inoltre, ci saranno parti della procedura che possono essere adattate ad altre esigenze specifiche e ci permetteranno di vedere il modo in cui le applicazioni comunicano tra loro.
Con informazioni da: Apple – iOS Developer Library | MacStorie
