Articoli con tag Holo

Google ha finalmente trovato uno standard per richiamare le sidebar

new-sidebar

Le sidebar, ossia le barre laterali richiamabili tramite swype o un apposito pulsante, sono sempre più diffuse nelle applicazioni Android, e in particolare in quelle di Google (basti pensare a Currents, Earth, Plus e Youtube); il loro comportamento però non è mai stato consistente e ben definito, tanto più che ognuna di essere si comporta in modo diverso.

Siamo quindi lieti di venire a conoscenza grazie a Dan Morrill, ingegnere di Google che lavora proprio sul robottino verde, che Matias Duarte (responsabile dell’esperienza utente su Android) e il suo team hanno fissato uno standard per le sidebar, già introdotto con il recente aggiornamento di Google Earth e di Shopper (quest’ultima però non è disponibile nel nostro paese).

In Earth la barra laterale è richiamabile sia tramite gesture (uno swype dall’estremo sinistro dello schermo) che tramite il nuovo pulsante che potete vedere nell’immagine in altro a sinistra, il quale di fatto sostituisce il pulsante indietro (il suo nome vero e proprio, per qualche strana ragione, è “Up”) attualmente presente nelle altre applicazioni, in modo da distinguere un semplice “Torna alla schermata precedente” da “Richiama la sidebar”.

Se siete sviluppatori e volete saperne di più, sappiate che ci sarà una sessione al Google I/O nella quale verrà trattato l’argomento, e che essa sarà trasmessa in live streaming. Dan Morrill ha infine annunciato che questo nuovo standard verrà applicato prossimamente anche alle altre applicazioni Google in futuri aggiornamenti.

Editoriale: ragionamenti ed ipotesi sulla prossima versione di Android

jelly

Il Google I/O è ormai a poco più di due settimane di distanza, e con esso aumentano le speculazioni e gli indizi su ciò che vedremo; a differenza di quanto riportato pochi giorni fa, appare probabile la presentazione di una nuova versione di Android, che sembrerebbe essere una nuova interazione di Jelly Bean, nonchéAndroid 4.3. Oggi proverò a fornire la mia interpretazione degli indizi che Google ci ha regalato negli ultimi mesi, per tentare di capire quali saranno i reali cambiamenti della prossima evoluzione del robottino verde.

 

Quello che sappiamo

Come già detto, la prossima versione dovrebbe essere la 4.3, nome in codice Jelly Bean, ma nulla vieta sorprese al riguardo; se ciò fosse confermato, quel poco che possiamo ricavare da questa informazione è che esso non sarà un aggiornamento volto a stravolgere l’OS che ben conosciamo, ma a perfezionarlo e ad aggiungere qualche utile funzione, un po’ come accadde con l’avvento di Android 4.2.

Uno dei miglioramenti più attesi da molti, me incluso, è Google Babel, il servizio di messaggistica unificato che molti utenti desideravano e chiedevano da tempo: gli indizi in questo caso sono concreti, e nonostante Google possa presentarlo al di fuori dell’I/O tramite un semplice post sul suo blog (un po’ come è successo per il nuovo Google Play), più il tempo passa più aumentano le probabilità che esso sia svelato proprio durante l’evento di metà maggio. Probabilmente sarà reso disponibile non solo all’interno della nuova versione di Android, ma anche come aggiornamento di Google Talk (similmente a quanto accadde nel passaggio da Docs a Drive), in modo da ottenere velocemente una larga base d’utenza in breve tempo (o almeno questo è quello che la logica suggerirebbe); alcuni potrebbero obiettare dicendo che Talk non è presente su Google Play, ma non mi stupirei se fosse pubblicato giusto per l’occasione; in fondo tutte le Gapps sono ormai presenti sullo store di Big G, e difficilmente Babel, o come verrà chiamato, farà eccezione.

L’altra novità di cui abbiamo una prova concreta riguardante la sua esistenza è una sorta di Game Center per Android dotato di multiplayer, chat, trofei e classifiche; non siamo a conoscenza del nome del servizio scoperto all’interno dell’apk dell’app MyGlass, ma esso sembra essere quasi pronto. La buona notizia è che potrebbe essere reso disponibile retroattivamente per altre distribuzioni (presumibilmente per ICS e JB) tramite un aggiornamento di Google Play Services.

Il kernel dovrebbe rimanere il 3.4, nonostante Google stia sperimentando con la versione 3.8 e 3.9; come sottolineato da Jean Baptiste Queru, l’uomo a capo dell’AOSP, questi non sono LTS (ossia supportati a lungo termine), e per questo motivo difficilmente faranno parte della prossima versione di Android. Inoltre dovrebbe essere risolto un vecchio bug riguardante il Wi-Fi, promesso direttamente da Google nel lontano novembre 2012.

Infine, le risposte vocali su Google Search sono state silenziosamente introdotte di recente per poi essere rimosse; è evidente che ci siano lavori in corso e a questo punto non mi meraviglierei di vedere presto annunciata l’espansione di questo servizio in molte altre nazioni (sperando porti con sé anche molte tra le schede mancanti nel nostro paese).

Ragionamenti ed ipotesi

Veniamo ora alla parte più difficile: non ci sono certezze vere e proprie al riguardo delle idee che scriverò ora, ma credo che esse non siano altro che la logica continuazione del lavoro che Big G ha svolto nell’ultimo anno e mezzo: innanzitutto mi aspetto alcuni aggiornamenti alle applicazioni di Google, il che accadde anche poche ore dopo il Google I/O dello scorso anno. Partendo da Google Maps, la cui modalità di navigazione ha ancora un tema Gingerbread, a differenza della ben più elegante applicazione per iPhone; a seguire Google Play Music avrebbe bisogno di un restyling (e magari di altri miglioramenti), essendo più vicina,  graficamente parlando, ad Honeycomb piuttosto che a Jelly Bean, ma non mi stupirei se anche Gmail (anch’esso più moderno su iOs) subisse un radicale cambiamento di interfaccia.

2013-04-27 12.15.22

Una delle schede di Google Now

Da Android 4.1, lo stile holo ha iniziato a mutare lentamente, sotto il comando di Google che ricerca un’impronta grafica sempre più simile su tutte le piattaforme supportate, ossia web, Android e iOs; le schede di Google Now, introdotte con la prima forma di Jelly Bean, e successivamente sposate anche da Google+, Youtube, Currents, Keep e Google Play, sono sempre più utilizzate e sembra una scommessa facile puntare sul fatto che una grafica simile, forse non in concomitanza con questa nuova versione, ma sicuramente avverrà col tempo, sarà adottata prima per le altre applicazioni, poi per altre parti del sistema operativo.

La nuova procedura di configurazione di Google+

La nuova procedura di configurazione di Google+

Questa evoluzione del tanto amato holo privilegia il colore bianco con l’apporto di elementi semplici ma eleganti, e linee più morbide, con una maggiore presenza di colori luminosi rispetto al passato: l’esempio più significativo è l’app di Google Keep, essendo l’ultima delle applicazioni Android prodotta da Google, nella quale schede e colori si uniscono per fornire un’esperienza utente intuitiva e piacevole; Keep inoltre include un nuovo font, Roboto Slab, e non mi meraviglierei se esso fosse introdotto in altre parti del sistema operativo. Infine, non sarebbe una sorpresa se Keep fosse incluso nelle applicazioni preinstallate nella prossima versione del robottino verde al fine di sopperire alla mancanza, spesso rimproverata ai dispositivi Nexus, di non avere un’app dedicata alle note.

Dopo il cambiamento tanto radicale quanto necessario avvenuto nel passaggio tra Gingerbread e Ice Cream Sandwich, Google sta modificando nuovamente l’estetica di Android, ma stavolta il passo sarà più breve, anche perché non indispensabile, e soprattutto distribuito nel tempo: non esiste modo di sapere se ciò avverrà nella prossima versione, ma ci sono parti del nostro sistema operativo preferito che, a mio parere, prima o poi si adatteranno a questa nuova grafica. A riprova di ciò, ci sono molti nuovi elementi grafici che Google sta introducendo nelle proprie applicazioni: ad esempio la “i” cerchiata presente in ogni scheda di Google Now che apre un menù, il pulsante (in realtà non è esattamente un pulsante) “Mostra altri” all’interno del nuovo Google Play, le nuove schermate di configurazione di Google+ con tasti che sembrano quasi in rilievo, oppure ancora l’action bar semi-trasparente di Keep; col tempo immagino che questi nuovi elementi siano sempre più presenti non solo nelle applicazioni, in quanto coerenti con il nuovo stile di Google.

Android 4.2 ha portato alcune novità utili ma con un’implementazione decisamente migliorabile: i widget nella lockscreen hanno trovato la loro vera e propria utilità grazie a Dashclock, applicazione open source sviluppata un ingegnere di Google e che forse sarebbe bene implementare all’interno di Android come nuovo widget dell’orologio; i quick setting poi, una delle novità più richieste dai molti utenti Nexus, sono forse la parte più inconsistente del robottino verde: alcuni funzionano come normali toggle tramite un tap (come la modalità aereo), altri sono toggle attivabili tramite pressione prolungata (come Wi-Fi e Bluetooth) oppure link alle impostazioni con una pressione instantanea, mentre altri sono solo link (come batteria, impostazioni e segnale) e la luminosità ha un comportamento tutto suo; il solo tentare di scrivere il loro funzionamento è complicato e irritante. Alla fine dei conti, oltre a non essere configurabili, il loro comportamento appare decisamente confuso e facilmente migliorabile; la speranza è che entrambi vengano rivisti, ma di questo non possiamo avere certezza.

Infine, gli ultimi due appunti: anche le gesture potrebbero avere più spazio in questa nuova versione di Android, in quanto molto amate da Matias Duarte, responsabile dell’esperienza utente di Android, e sono state recentemente introdotte anche in Gmail nella versione 4.2; in secondo luogo, nel caso non l’aveste ancora fatto, vi consiglio di leggere le idee di Aaron Gascoigne in merito.

Questa è la mia personale interpretazione nonché riassunto di ciò che penso vedremo nella prossima versione del robottino verde, e, per concludere, dopo essermi complimentato con voi per essere arrivati fino alla fine di questo lungo editoriale, vi invito a condividere la vostra personale opinione nei commenti.

ES File Explorer in salsa Holo disponibile in beta

unnamed

Molti di noi conoscono questo software con il nome italiano di ES Gestore File, uno dei migliori file manager disponibili sul Play Store che purtroppo non si è ancora adeguato allo stile Holo voluto da Google. Sarebbe meglio però dire che non si era allineato, perché la versione 3 di questo software, correntemente in beta, porta, oltre ad una serie di interessanti funzionalità, un corposo restyle della UI, che ora segue più da vicino quelli che sono i consigli di Big G.

L’apk è al momento disponibile solamente sul thread ufficiale su XDA e la lista delle aggiunte (e dei cambiamenti) è davvero notevole:

  • Compatibilità con Android 2.0+
  • App manager
  • Download manager
  • System manager
  • Analisi delle memorie esterne
  • Root Explorer
  • Gestione della clipboard
  • Net manager
  • Possibilità di nascondere file e cartelle

Oltre a queste funzionalità, sono presenti anche la solita gestione delle risorse nel cloud e sulla nostra rete, con annesse le opzioni di personalizzazione dell’applicazione, le impostazioni per le cartelle, per la sicurezza, il backup e gli strumenti integrati in questa nuova release.

Se volete partecipare al beta testing, fate un salto sul thread di XDA mentre, se volete solo farvi un’idea di come possa essere questo software, eccovi galleria di screenshot .

 

 

Backup e cambio di tema con le API di Android

Programmare Android

Come tutti sappiamo Android è caratterizzato, almeno da Ice Cream Sandwich in poi, dal tema Holo, che i ragazzi di Mountain View ci hanno rilasciato in diverse varianti, spingendoci ad utilizzarle per creare i nostri software. Ma come possiamo fare per scegliere tra i temi al momento del lancio dell’applicazione?

Il modo più semplice è senz’altro quello di salvarci il tema scelto nelleSharedPreferences e richiamarlo attraverso il metodo setTheme() di Context, ma questo ha alcune regole cui dobbiamo, necessariamente, sottostare:

  • il metodo va assolutamente chiamato prima di setContentView(), altrimenti non avrà effetto (va eseguito prima che venga disegnata l’Activity, altrimenti viene fermato dal runtime di Android)
  • per ogni nuova Activity che lanciamo, va richiamato, se vogliamo una continuità, altrimenti setContentView applicherà il tema specificato nel layout della singola Activity
  • dobbiamo ricaricare la prima Activity, se vogliamo che il tema venga applicato subito.

L’utilizzo di questo metodo è immediato e comporta solamente l’inserzione del tema come parametro:

setTheme(android.R.style.Theme_Holo);

E se volessimo invece salvare i nostri dati, in modo che l’utente possa ripristinarli quando installa l’applicazione su un altro dispositivo? Per questa specifica situazione, Google ci mette a disposizione un piccolo spazio, dove la nostra applicazione potrà effettuare un backup di file o preferenze: prima di iniziare a scrivere codice, dobbiamo quindi registrare la nostra applicazione sull’apposita pagina del portale per sviluppatori di Google, in modo da ottenere la chiave, che dovremo poi inserire nel nostro Manifest, nel tag relativo all’applicazione:

<application>
<meta-data android:name=”com.google.android.backup.api_key”
android:value=”AEdPqrEAAAAIXCOFOMfvAC8FViyU6A2NvyZPBwjp3xCxcHGdKw” />
</application>

 

A questo punto, iniziamo a creare il backup manager, che si occuperà di richiedere il salvataggio dei dati: per fare ciò, dobbiamo estendere la classeBackupAgentHelper e aggiungere al gruppo di preferenze (o al file) che vogliamo salvare un helper, che ci garantirà una richiesta di backup ogni volta che, attraverso il metodo dataChanged(), notifichiamo al servizio che abbiamo modificato i dati.

public class SimpleBackup extends BackupAgentHelper{
public void onCreate() {
SharedPreferencesBackupHelper helper = new SharedPreferencesBackupHelper(this, C.prefName);
addHelper(C.prefBackupName,helper);
}
}

Ora che il nostro backup manager è finito, dobbiamo scriverci un metodo per notificare al nostro applicativo che vogliamo effettuare una richiesta di backup:

public static final void requestBackup(Context mContext){
BackupManager b = new BackupManager(mContext);
b.dataChanged();
Toast.makeText(mContext, “Backup richiesto”, Toast.LENGTH_SHORT).show();
}

A questo punto, richiamando il metodo requestBackup() appena scritto, otterremo la nostra richiesta, ma ci manca ancora un tassello: la richiesta e il backup manager non sono ancora collegati in nessun modo e, per connetterli, dobbiamo nuovamente mettere mano al nostro file Manifest, precisamente nel tag su cui abbiamo già agito, application, inserendo il nome del nostro helper del backup:

<application
android:allowBackup=”true”

android:backupAgent=”SimpleBackup”>

Per quanto riguarda il ripristino dei nostri dati, Google dice che, normalmente, non si ha bisogno di chiamare il metodo requestRestore(), in quanto viene automaticamente chiamato dal sistema operativo al momento dell’installazione del software ma se, mentre l’utente non aveva il software installato, ci fosse stato anche solo un singolo avanzamento di versione, i dati non verrebbero ripristinati, perché il sistema dà per scontato che abbiamo apportato modifiche tali da impedire il corretto funzionamento del backup; per evitare questo comportamento, dobbiamo inserire nel nostro Manifest (nel tag application, tanto per cambiare), la dicitura:

android:restoreAnyVersion=”true”

per far sì che il servizio ignori la versione del nostro backup e lasci gestire a noi come ripristinare i dati a seconda della versione del nostro software, magari ricorrendo alle API del Package Manager, come suggerito dalla guida per gli sviluppatori.

Come di consueto, trovate i sorgenti e l’APK di prova sull’apposito thread , e buona programmazione a tutti!

  • Categorie

  • Pubblicità

  • Top Categorie

    • Selezione categoria
Torna all'inizio