Do czego powinienem używać menedżera kont Android?

Widziałem AccountManagera w Android SDK i służy on do przechowywania informacji o koncie. Dlatego nie mogę znaleźć żadnej ogólnej dyskusji na temat tego, do czego jest przeznaczony. Czy ktoś zna jakieś pomocne dyskusje na temat intencji stojącej za AccountManager i tego, co kupuje? Jakieś opinie na temat tego, dla jakiego typu kont jest to odpowiednie? Czy w tym miejscu umieściłbyś informacje o koncie użytkownika dla ogólnej usługi internetowej?

To pytanie jest trochę stare, ale myślę, że nadal jest interesujące.

AccountManager, SyncAdapterI ContentProvideriść w parze.

• Nie możesz mieć pliku SyncAdapterbez AccountwAccountManager .
• Nie możesz mieć pliku SyncAdapterbezContentProvider .

Ale ty możesz:

• użyj ContentProviderbez innych.
• używaj AccountManagerbez innych (ale nie możesz używać AccountManagerbezSyncAdapter wcześniejszego Android 2.2 / Froyo API 8)

Z AccountManager/ SyncAdapter/ ContentProvider:

• AccountManager daje użytkownikom centralny punkt (Ustawienia> Konta) do definiowania ich poświadczeń
• Android decyduje, kiedy synchronizację można przeprowadzić za pośrednictwem SyncAdapter. Może to być dobre rozwiązanie do optymalizacji baterii (na przykład synchronizacja nie jest wykonywana, gdy sieć jest wyłączona)
• ContentProviderto wygodny sposób udostępniania danych między aplikacjami Uwaga: istnieją inne metody komunikacji między procesami w systemie Android .
• ContentProviderPrzeważnie dostępu do bazy danych w tle wątkuAsyncQueryHanlder pomaga kwerendy ContentProviderw wątku tła, zapobiegając aplikacja nie czuły (ANR) błędów jednocześnie nie wymagając, aby jawnie obsłużyć wątków.
• ContentProviderwiąże się ContentResolverz obserwatorem: oznacza to, że łatwo jest powiadomić widok o zmianie treści

Konkluzja : struktura AccountManager/ SyncAdapter/ ContentProviderpomaga, jeśli chcesz synchronizować dane z zasobów sieciowych. W API 7. wymagane są fałszywe / głupie implementacje

• Jeśli chcesz tylko przechowywać dane, powinieneś rozważyć prostszy mechanizm przechowywania danych
• Jeśli potrzebujesz tylko pobrać jedyny zasób, możesz użyć pliku AsyncTaskLoader
• Jeśli chcesz ładować obrazy asynchronicznie, możesz użyć wyspecjalizowanych bibliotek, takich jak Square Picasso
• Jeśli chcesz wykonać tylko jakiś kod w określonym czasie, możesz rozważyć usługę / alarm
• dostępne tylko z API> = 7 (to już nie ma znaczenia)

Wreszcie, jeśli używasz SyncAdapter, poważnie rozważ Firebase Cloud Messaging (wcześniej Google Cloud Messaging), czyli „powiadomienia push”, aby mieć bardziej aktualne aktualizacje i zoptymalizować zużycie baterii.

Klasa AccountManager jest zintegrowana z kontami telefonicznymi. Jeśli więc zastosujesz się do wszystkich wskazówek i sprawisz, że będzie działać poprawnie, zobaczysz swoje konta w menu „Ustawienia-> Konta i synchronizacja”. Stamtąd możesz je dostosować, a nawet usunąć. Ponadto accountManager ma pamięć podręczną biletów uwierzytelniających dla twoich kont. Można tego użyć również, jeśli nie planujesz synchronizować swojego konta (o ile wiem).

Jeśli nie chcesz, aby Twoje konta pojawiały się w tym menu, nie powinieneś używać Menedżera kont i przechowywać dane kont w innym miejscu (może w udostępnianych preferencjach) http://developer.android.com/guide/topics/data/data -storage.html

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

Pierwszy element układanki nazywa się Account Authenticator, który definiuje, w jaki sposób konto użytkownika będzie wyglądać w ustawieniach „Konta i synchronizacja”. Wdrożenie Account Authenticator wymaga 3 elementów: usługi, która zwraca podklasę AbstractAccountAuthenticator z metody onBind, działanie zachęcające użytkownika do wprowadzenia swoich poświadczeń oraz plik xml opisujący, jak Twoje konto powinno wyglądać po wyświetleniu użytkownikowi. Musisz także dodać uprawnienie android.permission.AUTHENTICATE_ACCOUNTS do pliku AndroidManifest.xml.

Jest AccountManagerto dobre z następujących powodów:

• Pierwszym jest przechowywanie wielu nazw kont z różnymi poziomami dostępu do funkcji aplikacji w ramach jednego typu konta. Na przykład w aplikacji do strumieniowego przesyłania wideo jedno może mieć dwie nazwy kont: jedno z dostępem do wersji demonstracyjnej do ograniczonej liczby filmów, a drugie z dostępem przez cały miesiąc do wszystkich filmów. Nie jest to jednak główny powód, dla którego Accountswarto korzystać z aplikacji, ponieważ możesz łatwo zarządzać tym w swojej aplikacji bez potrzeby korzystania z tej fantazyjnej Accountsrzeczy….
• Inną zaletą korzystania Accountsjest pozbycie się tradycyjnej autoryzacji za pomocą nazwy użytkownika i hasła za każdym razem, gdy użytkownik zażąda autoryzowanej funkcji, ponieważ uwierzytelnianie odbywa się w tle, a użytkownik jest proszony o podanie hasła tylko w określonych warunkach, które Wrócę do tego później.
• Korzystanie z tej Accountsfunkcji w Androidzie eliminuje również potrzebę definiowania własnego typu konta. Prawdopodobnie spotkałeś się z aplikacjami używającymi kont Google do autoryzacji, co oszczędza kłopotów z tworzeniem nowego konta i zapamiętywaniem jego poświadczeń dla użytkownika.
• Accounts można dodać niezależnie poprzez Ustawienia → Konta
• Autoryzacją użytkowników między platformami można łatwo zarządzać za pomocą Accounts. Na przykład klient może uzyskać dostęp do chronionych materiałów w tym samym czasie na swoim urządzeniu z Androidem i komputerze bez konieczności wielokrotnego logowania.
• Z punktu widzenia bezpieczeństwa stosowanie tego samego hasła w każdym zapytaniu do serwera pozwala na ewentualne podsłuchiwanie niezabezpieczonych połączeń. Szyfrowanie hasła nie wystarczy tutaj, aby zapobiec kradzieży hasła.
• Wreszcie, ważnym powodem używania tej Accountsfunkcji w systemie Android jest oddzielenie dwóch stron zaangażowanych w jakąkolwiek działalność zależną Accounts, tak zwanego wystawcy uwierzytelnienia i właściciela zasobów, bez narażania poświadczeń klienta (użytkownika). Określenia mogą wydawać się dość niejasne, ale nie poddawaj się, dopóki nie przeczytasz następnego akapitu… 😉

Opowiem o tym ostatnim na przykładzie aplikacji do strumieniowego przesyłania wideo. Firma A jest właścicielem firmy zajmującej się strumieniową transmisją wideo na podstawie umowy z Firmą B o świadczenie jej określonym członkom usług przesyłania strumieniowego premium. Firma B stosuje metodę nazwy użytkownika i hasła do rozpoznawania swojego użytkownika. Aby firma A mogła rozpoznać członków premium należących do B, jednym ze sposobów byłoby pobranie ich listy od B i wykorzystanie podobnego mechanizmu dopasowywania nazwy użytkownika / hasła. W ten sposób osoba uwierzytelniająca i właściciel zasobu są takie same (firma A). Oprócz obowiązku zapamiętania drugiego hasła przez użytkowników, jest bardzo prawdopodobne, że ustawili to samo hasło, co profil firmy B do korzystania z usług firmy A. To oczywiście nie jest korzystne.

Aby złagodzić powyższe niedociągnięcia, wprowadzono OAuth. Jako otwarty standard autoryzacji, w powyższym przykładzie, OAuth wymaga, aby autoryzacja została przeprowadzona przez firmę B (podmiot uwierzytelniający) poprzez wystawienie tokenu zwanego tokenem dostępu dla uprawnionych użytkowników (strony trzeciej), a następnie przekazanie firmie A (właściciel zasobu) token. Więc brak tokena oznacza brak uprawnień.

Omówiłem więcej na ten temat i więcej AccountManagerna mojej stronie internetowej tutaj.