HowTo: usare la fotocamera su Android

Domanda: sto facendo una mia app per Android. Devo permettere all'utente di scattare una foto per farci poi alcune cose, come faccio?

Risposta: chiedi in prestito la camera ad Android.

Il concetto di base è quello di sfruttare il meccanismo degli Intent per chiedere al sistema di prestarci la sua gestione della fotocamera. Gli Intent sono una caratteristica veramente interessante di Android e chiunque decida di fare sul serio con questa piattaforma dovrebbe studiarseli per bene. Volendo comunque riassumere in due righe cosa sono e perché ci servono, possiamo dire che gli Intent sono lo strumento a disposizione delle applicazioni per esprimere la propria necessità di fare qualcosa (scattare una foto, mostrare una pagina web, vedere un video...), anche senza specificare il come farla. Di questo si delega il sistema stesso, che sceglie l'applicazione più consona a soddisfare l'esigenza.

La nostra esigenza, ovviamente, è scattare una foto e averla poi a disposizione. Una volta impostata la nostra Activity e l'azione che deve scatenare la richiesta, come pigiare un button, non ci resta che scrivere il poco codice che serve.

NB: prima di iniziare, preciso che tutto il codice qui indicato è esente da qualsiasi gestione delle eccezioni, anche da quelle comandate, in favore della leggibilità. Non è un grosso problema, dato che l'IDE (e Java) stesso vi obbligheranno a gestire le Exceptions necessarie.

private static final int CAMERA_REQUEST = 100; // un numero a nostro piacimento 
File tmpFotoFile = null;

private void launchCamera(){

   // Fase 1
   //

   tmpFotoFile = File.createTempFile("myappprefix", null);

   // Fase 2
   //

   Intent cameraIntent = new Intent(android.provider.MediaStore.ACTION_IMAGE_CAPTURE);
   cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(tmpFotoFile));
   startActivityForResult(cameraIntent, CAMERA_REQUEST);
}

Come vedete il codice si compone di due fasi:

1. dobbiamo creare un'area di memoria in cui salvare i dati della foto che andremo a scattare. Volendo potremmo anche creare un file fisico, ma per questo tutorial supponiamo che non vogliate (o possiate) scrivere sulla SDCard. Il nostro file temporaneo in memoria è gestito da tmpFotoFile.
2. ora possiamo chiedere al sistema di lanciare la sua gestione della fotocamera. Per fare questo creiamo la giusta Intent, dicendogli che ci serve qualcosa per ottenere una ACTION_IMAGE_CAPTURE. Decoriamo ulteriormente la Intent con una informazione extra: l'output, caro Android, mettimelo per cortesia in tmpFotoFile. Come vedete è tutto estremamente generico, proprio perché adattabile anche ad altri contesti. Fatto questo, lanciamo la nuova Activity risultante dall'Intent specificata in modo da attenderne (e gestirne) il risultato.

A questo punto siamo già in grado di lanciare la gestione della fotocamera e scattare le foto. Alla chiusura dell'Activity della fotocamera, però, non abbiamo più il controllo sui dati della foto scattati. Per fare questo ci occorre gestire l'override di un metodo della classe base Activity, onActivityResult, intercettando il corretto codice di request. Ecco come:

byte[] bitmapdata;
ImageView preview;

protected void onActivityResult(int requestCode, int resultCode, Intent data) {
   
   if (requestCode == CAMERA_REQUEST) {
     Bitmap datifoto = android.provider.MediaStore.Images.Media.getBitmap(this.getContentResolver(), Uri.fromFile(tmpFotoFile));
     preview.setImageBitmap(datifoto);
    
     ByteArrayOutputStream bos = new ByteArrayOutputStream(); 
     datifoto.compress(CompressFormat.JPEG, 70, bos); 
     bitmapdata = bos.toByteArray();
       
     tmpFotoFile.delete();
  }
}

Ci facciamo restituire la Bitmap leggendone i dati dal nostro file temporaneo. Con questa, volendo, andiamo ad impostare una ImageView che ci fornisce l'anteprima dell'immagine (la ImageView deve essere opportunamente presente nella nostra Activity e referenziata attraverso findViewById(...)).

La seconda cosa che vogliamo fare è ottenere una immagine jpeg compressa partendo dalla grossa bitmap ottenuta. Lo facciamo con le tre righe che seguono l'impostazione della preview, nelle quali specifichiamo il grado di compressione (70, nell'esempio) tenendo conto che 0 significa massima compressione e 100 massima qualità.

Infine, puliamo la memoria eliminando il nostro file temporaneo, che ci sembra sempre cosa buona e giusta.

Non ci resta altro da fare che aggiungere nel Manifest le uses-permission necessarie a far funzionare il tutto, ovvero:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE">
<uses-feature android:name="android.hardware.camera" />

Buone foto!

Povero italiano!

Grazie ad internet abbiamo modo di accedere alle idee e ai pensieri di migliaia di nostri simili, tutti i giorni. Ciò è bene. Il male è vedere come molta di questa gente si esprime. Non saprei dire se la colpa sia di internet, quel che è certo è che la Rete ha fatto emergere una inquietante incapacità del giovane italiano medio nel maneggiare la propria lingua.

Scriviamo veramente male. Quel che è peggio è che ci stiamo abituando a tollerare certi orrori. I forum sono pugnalate agli occhi. I commenti nei blog nascondono spesso calci rotanti al dizionario. Gli stessi post, che ti aspetteresti editati con un minimo di cura, spesso non sono migliori.

Non parlo di qualche refuso. Non entro nel merito di accenti gravi o acuti. Ma il verbo avere, su! Quella benedetta acca sarà anche muta ma mica invisibile!

Le virgole non sono orpelli grafici, non se ne vanno a zonzo da sole per la frase; amano invece stare in compagnia, sempre attaccate alla parola che le precede, ma staccate dalla successiva, per aiutare il benedetto periodo ad acquisire un senso.

Il punto! Cosa c'è di più bello che mettere un bel punto al termine della frase? E' come fare una release. Ecco, ho finito un pensiero. Punto!

I due punti poi! Meraviglia della sintesi. Riassumono tutto un pensiero appena espresso. Il fatto che se ne vedano pochi è triste, ma anche significativo: nessun pensiero da riassumere, evidentemente.

Il punto e virgola... Carneade! Chi era costui? A differenza di virgole e punti, seminati qua e là e abbandonati a loro stessi, i punti e virgola sono proprio ignorati, spesso oggetto di oscure supposizioni.

Ad un maschio gli, ad una femmina le. Cavoli, persino i presentatori (ma ho sentito addirittura dei doppiatori) in tv ad una signora gli...

Volendo passare anche sopra la punteggiatura e le piccolezze particellari, non si fa un grande affare. Già, perché ci si costringe a guardare i verbi e le loro coniugazioni, e sono dolori. Il congiuntivo non è una malattia degli occhi! Villaggio ci ironizzava su vent'anni fa, con i suoi venghi e dichi, ma è ancora tutto tristemente attuale.

Le doppie! La z prolifica, la regola del zio, zia, zie è un patrimonio culturale ormai andato perduto. Le k e le x hanno guadagnato posizioni di potere persino nelle parole più intime della nostra povera lingua.

Ma tutto questo è ancora niente.

La cosa più inquietante è la palese confusione che regna nelle menti. Quando non si è capaci di formulare una frase di senso compiuto, io penso, è ora di iniziare a preoccuparsi sul serio, e di cose serie.

Quando il programmatore è anche musicista... MMA!

Una delle esigenze più comuni per i poveri mortali che gettano ore del proprio tempo libero nello studio di uno strumento musicale è avere a disposizione delle basi su cui suonare. Uno si studia un lick, ci si esercita a bocce ferme, cioè suonandolo solo sul proprio strumento, arriva a padroneggiarlo e poi, quando anche il metronomo gli da ragione, avrebbe ben piacere di sentire l'effetto che fa se suonato su un accompagnamento. Sacrosanto.

Ebbene, mi sono trovato spesso nella situazione ma ho sempre dribblato il problema vuoi con la band (complicato...), vuoi con veloci registrazioni di me stesso su una drum machine (macchinoso e poco scalabile... cambio accordi? cambio velocità?), vuoi arrangiandomi con qualche mezzo di fortuna, come editare accordi su un software per tabulazioni come PowerTab (uff...).

Ieri, complice una domenica nebbiosa e pigra, non avevo voglia di fare nulla di tutto ciò, solo di suonare il mio dannato lick su una base. E allora Google. E scopro che un settore di software apparentemente banale è in realtà pieno di applicazioni commerciali e di pochissimo free. Già mi prudevano le mani e nasceva l'idea per un progetto, quando mi sono imbattuto (per fortuna) in questo MMA: Musical MIDI Accompaniment.

E' in python, quindi portabile su diverse piattaforme. Per l'occasione navigavo con una macchina Windows, ma al più presto lo installerò anche sulla mia Fedora. Cercavo il modo quick and dirty per fare quel che mi serviva e... beh, più quick e, soprattutto, più dirty sarebbe stato difficile trovare!

MMA è software per un programmatore. Editare la propria base è proprio come scrivere un programma, e l'editor in sé è niente più che un editor di testo. Esatto, potete scrivere la vostra base anche con gedit, o notepad, proprio come fosse un listato C. Poi, tra le (poche) voci di menu che mi trovo? Build, naturalmente. Il risultato della build è un midi.

Ecco un esempio di base:

Tempo 120
Groove Tango

1  C
2  F
3  G7
4  C  / Em
5  C
6  /
7  F
8  C

L'impatto è stato un po' una sorpresa, un po' un ritrovarsi a casa propria, come potete immaginare. Per un programmatore nulla di più intuitivo che scrivere codice, fare build e verificare il risultato. Rimane da capire se anche gli utenti non del mestiere si trovino bene con questa modalità operativa.

Per quanto mi riguarda, un software assolutamente da segnalare! E ora scusatemi, ho dei fraseggi da debuggare...

Il blog che forse non conoscete: 1 Month Game!

Ci risiamo. Sembra proprio che la cosa di cui gli sviluppatori amatoriali sentono maggiormente la mancanza sia la condivisione. Condivisione dei propri sforzi, dei propri stimoli, delle proprie idee. Deve essere così, altrimenti non si spiegherebbero i successi di tutti i contest posti nella forma fai un gioco in X ore/giorni. E' chiaro che non è la sfida di fare un gioco in un certo lasso di tempo a convincere migliaia di sviluppatori a tapparsi in casa a produrre codice, sprite e musiche. La sfida e l'agonismo ci sono, ma in minima parte. Quel che realmente decreta il successo di tali iniziative è senza dubbio la gran voglia di condividere non solo il frutto delle proprie fatiche, ma le fatiche stesse. E tra persone che le capiscono e le apprezzano, cioè tra altri sviluppatori con lo stesso obiettivo.

E' bello vedere emergere lo spirito di animale sociale in una categoria, la nostra, tacciata troppo spesso (e sempre più senza ragione) di luposolitarismo e asocialità. Ed è bello anche un blog che mi è capitato di trovare un po' per caso, tra una catena non più producibile di tweet e link: 1 Month Game.

Non si tratta di un contest ma di un vero blog a cura di Sophie Houlden in cui, seguendo alcune semplici regole, chiunque può postare il devlog del proprio progetto. Unica regola: terminare in un mese!

Per i più timidi rimane comunque un bel posto dove passare un po' di tempo, confrontandosi con quel che producono gli altri. I progetti sono infatti facili da seguire grazie alle linee guida di Sophie che impongono titoli dei post che indicano numero di settimana e giorno di sviluppo, da Week 1 - Day 1 a Week 4 - Day 7.

Come sempre, leggere e capire cosa fanno gli altri (e come) rimane un'esperienza e un'opportunità impagabile, di cui forse siamo un po' assuefatti oggi, ma che continua a stupire quelli che quando internet ancora non c'era...

Quanta ne sai di C e C++?

Il saggio sa di non sapere. Il programmatore... beh... non sempre si dimostra saggio! Il programmatore in erba semplicemente non sa di cosa sta parlando, quindi ben che vada da fiato alle trombe e spara qualche orrore. Va corretto, ma con misericordia; in fondo è solo rumore ingenuo.

Più grave è la sindrome che troppo spesso colpisce i programmatori più esperti, o che si reputano tali. Sembra infatti che provino un certo gusto nel dare ai meno fortunati questuanti da forum mezze risposte, talvolta allusive, vedo e non vedo, che costringono i supplicanti a nuove richieste di spiegazioni. Il programmatore un-po'-più-esperto di solito riconosce questi personaggi come programmatori in erba evoluti, ma non ancora completi.

Ma attenzione. Anche il programmatore un-po'-più-esperto, quello che a prima vista può apparire saggio, che scrive tutorial, che dimostra pazienza, ha quasi certamente delle lacune. Il saggio sa di non sapere, dicevamo. Il difetto principale del programmatore è che, pur sapendo di non sapere (nei casi più fortunati), non lo ammette. Perché è cattivo? No di certo. Perché la programmazione è un lavoro di problem-solving, e la mente del programmatore è allenata ad affrontare quotidianamente sfide. Al mattino, quando si siede al pc, è conscio di affrontare qualcosa per la quale non ha ancora la soluzione, ma fiducioso sul fatto che a sera avrà la sua routine funzionante. Quindi ok, posso anche non sapere qualcosa, ma quel che so è sufficiente. Più che sufficiente. Sono un esperto.

...ne sei sicuro? Sì, dico a te, te che con il C hai passato gli anni dell'università, che hai già visto migliaia e migliaia di righe in C++, che credi di digerire poliformismo e allocazioni dinamiche come acqua fresca, te che in questo momento stai scrivendo questo post (io?) sì, sì, proprio te! Scendi dal piedistallo e vatti a fare questo test: Deep C!

Poi ne riparliamo!