Para que devo usar o Android AccountManager?

Vi o AccountManager no SDK do Android e é usado para armazenar informações da conta. Portanto, não consigo encontrar nenhuma discussão geral sobre o que se destina. Alguém sabe de alguma discussão útil sobre qual é a intenção do AccountManager e o que ele compra? Alguma opinião sobre que tipo de contas é adequado? É aqui que você coloca as informações da conta do usuário para um serviço geral da Web?

Essa pergunta é um pouco antiga, mas acho que ainda é de bom interesse.

AccountManager, SyncAdapterE ContentProviderir juntos.

• Você não pode ter um SyncAdaptersem um AccountnoAccountManager .
• Você não pode ter um SyncAdaptersem aContentProvider .

Mas você pode:

• use o ContentProvidersem os outros.
• use o AccountManagersem os outros (mas você não pode usar um AccountManagersem umSyncAdapter anterior ao Android 2.2 / Froyo API 8)

Com AccountManager/ SyncAdapter/ ContentProvider:

• AccountManager fornece aos usuários um ponto central (Configurações> Contas) para definir suas credenciais
• O Android decide quando a sincronização pode ser feita via SyncAdapter. Isso pode ser bom para otimizar a bateria (nenhuma sincronização é feita quando a rede está inoperante, por exemplo)
• ContentProvideré uma maneira conveniente de compartilhar dados entre aplicativos Nota: existem outros métodos de comunicação entre processos no Android .
• ContentProvideragenda o acesso ao banco de dados em um encadeamento em segundo plano As AsyncQueryHanlderajudas para consultar o ContentProviderem um encadeamento em segundo plano, evitando erros de ANR (Application Not Responsive), sem exigir que você lide explicitamente com o encadeamento.
• ContentProvidervincula-se ao ContentResolverobservador: isso significa que é fácil notificar as visualizações quando o conteúdo é alterado

Conclusão : a estrutura AccountManager/ SyncAdapter/ ContentProviderajuda se você deseja sincronizar dados de um recurso da web. Implementações falsas / burras são necessárias na API 7. Também

• Se você deseja armazenar apenas dados, considere um mecanismo mais simples para armazenamento de dados
• Se você precisar apenas buscar um único recurso, poderá usar um AsyncTaskLoader
• Se você deseja carregar imagens de forma assíncrona, pode usar bibliotecas especializadas como o Square Picasso
• Se você deseja executar apenas algum código em um determinado momento, considere um Serviço / Alarme
• disponível apenas na API> = 7 (isso não importa mais)

Por fim, se você usar um SyncAdapter, considere seriamente o Firebase Cloud Messaging (anteriormente Google Cloud Messaging), também conhecido como "notificações por push", para receber atualizações mais recentes e o uso otimizado da bateria.

A classe AccountManager é integrada às suas contas de telefone. Portanto, se você seguir todos os guias e fazê-lo funcionar corretamente, você verá suas contas no menu "Configurações-> contas e sincronização". A partir daí, você pode personalizá-los ou até excluí-los. Além disso, o accountManager possui um cache dos tíquetes de autenticação para suas contas. Isso também pode ser usado se você não planeja sincronizar sua conta (tanto quanto eu saiba).

Se você não deseja que suas contas apareçam nesse menu, não use o AccountManager e armazene os dados das contas em outro lugar (talvez nas preferências compartilhadas) http://developer.android.com/guide/topics/data/data -storage.html

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

A primeira peça do quebra-cabeça é chamada de Autenticador de conta, que define como a conta do usuário aparecerá nas configurações de "Contas e sincronização". A implementação de um Autenticador de conta requer três partes: um serviço que retorna uma subclasse de AbstractAccountAuthenticator a partir do método onBind, uma atividade para solicitar que o usuário insira suas credenciais e um arquivo xml descrevendo a aparência da sua conta quando exibida para o usuário. Você também precisará adicionar a permissão android.permission.AUTHENTICATE_ACCOUNTS ao seu AndroidManifest.xml.

O AccountManageré bom pelos seguintes motivos:

• O primeiro é armazenar vários nomes de conta com diferentes níveis de acesso aos recursos do aplicativo em um único tipo de conta. Por exemplo, em um aplicativo de streaming de vídeo, um pode ter dois nomes de conta: um com acesso demo a um número limitado de vídeos e outro com acesso mensal a todos os vídeos. No Accountsentanto, esse não é o principal motivo de uso , já que você pode gerenciar isso facilmente no seu aplicativo sem a necessidade dessa aparência atraente Accounts….
• A outra vantagem do uso Accountsé livrar-se da autorização tradicional com nome de usuário e senha cada vez que um recurso autorizado é solicitado pelo usuário, porque a autenticação ocorre em segundo plano e o usuário é solicitado a fornecer sua senha apenas em determinadas condições, o que Eu vou chegar mais tarde.
• O uso do Accountsrecurso no android também elimina a necessidade de definir o próprio tipo de conta. Você provavelmente já encontrou os aplicativos usando as Contas do Google para autorização, o que evita o incômodo de criar uma nova conta e lembrar suas credenciais para o usuário.
• Accounts pode ser adicionado independentemente por meio de Configurações → Contas
• A autorização de usuário de plataforma cruzada pode ser facilmente gerenciada usando Accounts. Por exemplo, o cliente pode acessar o material protegido ao mesmo tempo em seu dispositivo Android e PC sem a necessidade de logins recorrentes.
• Do ponto de vista da segurança, o uso da mesma senha em todas as solicitações ao servidor permite uma possível interceptação em conexões não seguras. A criptografia de senha não é suficiente aqui para impedir o roubo de senhas.
• Finalmente, uma razão importante para usar o Accountsrecurso no android é separar as duas partes envolvidas em qualquer negócio dependente Accounts, chamado autenticador e proprietário do recurso, sem comprometer as credenciais do cliente (usuário). Os termos podem parecer bastante vagos, mas não desista até ler o parágrafo a seguir… 😉

Deixe-me elaborar sobre este último com um exemplo de aplicativo de streaming de vídeo. A empresa A é detentora de uma empresa de streaming de vídeo contratada com a empresa B para fornecer a seus membros certos serviços premium de streaming. A empresa B emprega um método de nome de usuário e senha para reconhecer seu usuário. Para a Empresa A reconhecer os membros premium de B, uma maneira seria obter a lista deles de B e utilizar um mecanismo de correspondência de nome de usuário / senha semelhante. Dessa forma, o autenticador e o proprietário do recurso são os mesmos (Empresa A). Além da obrigação dos usuários de lembrar uma segunda senha, é muito provável que eles definam a mesma senha do perfil da empresa B para usar os serviços de A. Isso obviamente não é favorável.

Para atenuar as deficiências acima, o OAuth foi introduzido. Como padrão aberto para autorização, no exemplo acima, o OAuth exige que a autorização seja feita pela Empresa B (autenticador) emitindo algum token chamado Token de Acesso para os usuários qualificados (terceiros) e fornecendo à Empresa A (proprietário do recurso) o token. Portanto, nenhum token significa nenhuma elegibilidade.

Eu elaborei mais sobre isso e mais AccountManagerno meu site aqui.