Ad esempio, se l’account utente è archiviato nelle preferenze condivise in modo da poter essere ripristinato all’installazione, non occorre pensare da quale account sia stato utilizzato per eseguire precedentemente l’accesso: è sufficiente inserire la propria password e andare avanti!
Se gli sviluppatori supportano vari metodi di accesso (Google Sign-In e altri provider, nome utente/password), è semplice tener traccia del metodo di accesso precedentemente utilizzato in modo che non debba farlo l’utente.
Transizione dai backup per chiave/valore
Se lo sviluppatore ha precedentemente implementato il backup di legacy per chiave/valore creando sottoclassi
BackupAgent e impostandole nel Manifesto (
android:backupAgent), manca veramente poco per la transizione ai backup di tutti i dati. È sufficiente aggiungere l’attributo android:fullBackupOnly="true" in <application>. Questo viene ignorato nelle versioni di Android precedenti alla M, per cui onBackup/onRestore viene comunque richiamato, mentre sui dispositivi M+ consente al sistema di sapere che lo sviluppatore desidera utilizzare i backup di tutti i dati fornendo contemporaneamente il proprio BackupAgent.
Lo sviluppatore può utilizzare lo stesso approccio anche se non utilizza i backup per chiave/valore, ma preferisce eseguire un’elaborazione personalizzata in onCreate(), onFullBackup() o essere avvisato quando viene eseguita un’operazione di ripristino in onRestoreFinished(). Basta ricordare di richiamare super.onFullBackup() se si preferisce mantenere l’implementazione da parte del sistema della gestione delle regole di inclusione/esclusione XML.
Qual è il ciclo di vita del backup/ripristino?
Il ripristino dei dati viene eseguito in quanto parte dell’installazione del pacchetto, prima che l’utente abbia la possibilità di avviare l’app. Il backup viene eseguito al massimo una volta al giorno, quando il dispositivo è in carica e connesso a una rete Wi-Fi. Se l’app supera il limite di dati, attualmente impostato su 25 MB, non vengono eseguiti altri backup e per i ripristini successivi viene utilizzata l’ultima snapshot salvata. Il processo dell’app viene terminato dopo l’esecuzione di un backup completo e prima di un ripristino, se questo richiamato manualmente tramite il comando bmgr, approfondito di seguito.
Per testare subito le app
Prima di iniziare a provare Auto Backup, occorre accertarsi di disporre della versione più recente di M Developer Preview sul proprio dispositivo o emulatore. Dopo aver installato l’APK, utilizzare il comando shell adb per accedere allo strumento bmgr.
Bmgr è uno strumento utilizzabile per l’interazione con Backup Manager:
- bmgr run pianifica un’operazione di backup immediata; questo comando deve essere eseguito dopo aver installato l’app sul dispositivo in modo tale che Backup Manager abbia la possibilità di eseguire correttamente l’inizializzazione.
- bmgr fullbackup <packagename> avvia un’operazione di backup completo.
- bmgr restore <packagename> ripristina i dati precedentemente sottoposti a backup
Se lo sviluppatore dimentica di richiamare bmgr run, potrebbe riscontrare errori in Logcat quando prova i comandi fullbackup e di ripristino. Se i problemi persistono, accertarsi di aver abilitato Backup e di aver impostato un account Google in Impostazioni -> Backup e ripristino del sistema.
Approfondimento
Nel nostro
GitHub è disponibile un esempio di applicazione che mostra come utilizzare Auto Backup. La documentazione completa è reperibile su
developer.android.com
Per ulteriori informazioni sulle funzioni di Android M è possibile partecipare alla
Android M Developer Preview Community su Google+. Si prega di segnalare eventuali bug riscontrati in Auto Backup nel
bug tracker.
