Per cosa dovrei usare AccountManager Android?

Ho visto AccountManager nell'SDK Android e che è utilizzato per archiviare le informazioni sull'account. Pertanto, non riesco a trovare alcuna discussione generale su ciò a cui è destinato. Qualcuno è a conoscenza di discussioni utili su quale sia l'intenzione dietro AccountManager e cosa ti compra? Qualche opinione su quale tipo di account sia adatto? Dovresti inserire le informazioni sull'account del tuo utente per un servizio Web generale?

Questa domanda è un po 'vecchia, ma penso che sia ancora di buon interesse.

AccountManager, SyncAdapterE ContentProvidervanno di pari passo.

• Non puoi avere un SyncAdaptersenza un AccountnelAccountManager .
• Non puoi avere un SyncAdaptersenza aContentProvider .

Ma tu puoi:

• usa il ContentProvidersenza gli altri.
• usa il AccountManagersenza gli altri (ma non puoi usare un AccountManagersenza unSyncAdapter Android 2.2 / Froyo API 8 precedente)

Con AccountManager/ SyncAdapter/ ContentProvider:

• AccountManager fornisce agli utenti un punto centrale (Impostazioni> Account) per definire le proprie credenziali
• Android decide quando è possibile eseguire la sincronizzazione tramite SyncAdapter. Questo può essere utile per ottimizzare la batteria (ad esempio, non viene eseguita alcuna sincronizzazione quando la rete è inattiva)
• ContentProviderè un modo conveniente per condividere dati tra le applicazioni Nota: esistono altri metodi di comunicazione tra processi su Android .
• ContentProviderorari l'accesso al database in un thread in background La AsyncQueryHanlderaiuta a interrogare il ContentProviderin un thread in background, evitando di applicazione non risponde errori (ANR), senza richiedere di gestire in modo esplicito threading.
• ContentProvidersi lega ContentResolverall'osservatore: ciò significa che è facile notificare le visualizzazioni quando il contenuto viene modificato

In conclusione : il framework AccountManager/ SyncAdapter/ ContentProvideraiuta se si desidera sincronizzare i dati da una risorsa Web. Implementazioni false / stupide sono richieste sull'API 7. Inoltre

• Se si desidera solo archiviare i dati, è necessario considerare un meccanismo più semplice per l'archiviazione dei dati
• Se hai solo bisogno di recuperare una sola risorsa, puoi usare un AsyncTaskLoader
• Se desideri caricare le immagini in modo asincrono, puoi utilizzare librerie specializzate come Square Picasso
• Se si desidera eseguire solo un codice in un determinato momento, è possibile prendere in considerazione un servizio / allarme
• disponibile solo da API> = 7 (questo non ha più importanza)

Infine, se usi un SyncAdapter, considera seriamente Firebase Cloud Messaging (precedentemente Google Cloud Messaging), noto anche come "notifiche push", per avere aggiornamenti più recenti e un utilizzo della batteria ottimizzato.

La classe AccountManager è integrata con i tuoi account telefonici. Quindi, se segui tutte le guide e lo fai funzionare correttamente, vedrai i tuoi account nel menu "Impostazioni-> account e sincronizzazione". Da lì puoi personalizzarli o persino eliminarli. Inoltre accountManager ha una cache dei ticket di autenticazione per i tuoi account. Questo può essere usato anche se non prevedi di sincronizzare il tuo account (per quanto ne so).

Se non vuoi che i tuoi account appaiano sotto quel menu, non dovresti usare AccountManager e archiviare i dati degli account altrove (forse nelle preferenze condivise) http://developer.android.com/guide/topics/data/data -storage.html

Da http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/ :

Il primo pezzo del puzzle si chiama Account Authenticator, che definisce come apparirà l'account dell'utente nelle impostazioni "Account e sincronizzazione". L'implementazione di un Account Authenticator richiede 3 pezzi: un servizio che restituisce una sottoclasse di AbstractAccountAuthenticator dal metodo onBind, un'attività che richiede all'utente di inserire le proprie credenziali e un file XML che descrive come dovrebbe apparire il proprio account quando visualizzato all'utente. Dovrai anche aggiungere l'autorizzazione android.permission.AUTHENTICATE_ACCOUNTS al tuo AndroidManifest.xml.

Il AccountManagerè un bene per i seguenti motivi:

• Il primo è quello di memorizzare più nomi di account con diversi livelli di accesso alle funzionalità dell'app in un unico tipo di account. Ad esempio, in un'app di streaming video, uno può avere due nomi di account: uno con accesso demo a un numero limitato di video e l'altro con accesso per un mese intero a tutti i video. Questo non è il motivo principale per l'utilizzo Accounts, tuttavia, poiché puoi gestirlo facilmente nella tua app senza la necessità di questa Accountscosa dall'aspetto fantasioso ....
• L'altro vantaggio dell'utilizzo Accountsè di eliminare l'autorizzazione tradizionale con nome utente e password ogni volta che l'utente richiede una funzione autorizzata, poiché l'autenticazione avviene in background e all'utente viene richiesta la password solo in determinate condizioni, che Ci arrivo più tardi.
• L'uso della Accountsfunzione in Android elimina anche la necessità di definire il proprio tipo di account. Probabilmente ti sei imbattuto nelle app usando gli account Google per l'autorizzazione, il che evita il fastidio di creare un nuovo account e ricordare le sue credenziali per l'utente.
• Accounts può essere aggiunto indipendentemente tramite Impostazioni → Account
• L'autorizzazione utente multipiattaforma può essere facilmente gestita tramite Accounts. Ad esempio, il client può accedere contemporaneamente al materiale protetto nel proprio dispositivo Android e PC senza la necessità di accessi ricorrenti.
• Dal punto di vista della sicurezza, l'utilizzo della stessa password in ogni richiesta al server consente possibili intercettazioni in connessioni non sicure. La crittografia della password non è sufficiente qui per prevenire il furto della password.
• Infine, un motivo importante per l'utilizzo della Accountsfunzione in Android è quello di separare le due parti coinvolte in qualsiasi attività commerciale dipendente Accounts, cosiddetto autenticatore e proprietario delle risorse, senza compromettere le credenziali del cliente (utente). I termini possono sembrare piuttosto vaghi, ma non mollare fino a quando non leggi il paragrafo seguente ... 😉

Consentitemi di approfondire quest'ultimo con un esempio di un'app di streaming video. La società A è titolare di un'attività di streaming video in contratto con la società B per fornire a determinati membri servizi di streaming premium. La società B utilizza un metodo con nome utente e password per riconoscere l'utente. Affinché la società A riconosca i membri premium di B, un modo sarebbe quello di ottenere l'elenco di essi da B e utilizzare un meccanismo di corrispondenza nome utente / password simile. In questo modo, l'autenticatore e il proprietario della risorsa sono gli stessi (Azienda A). A parte l'obbligo degli utenti di ricordare una seconda password, è molto probabile che abbiano impostato la stessa password del profilo della loro azienda B per l'utilizzo dei servizi di A. Questo ovviamente non è favorevole.

Per eliminare le suddette carenze, è stato introdotto OAuth. Come standard aperto per l'autorizzazione, nell'esempio sopra, OAuth richiede che l'autorizzazione venga eseguita dalla società B (autenticatore) emettendo un token chiamato token di accesso per gli utenti idonei (terze parti) e quindi fornendo alla società A (proprietario delle risorse) il token. Quindi nessun token significa nessuna eleggibilità.

Ho approfondito di più su questo e di più AccountManagersul mio sito Web qui.