Для чего нужно использовать AccountManager для Android?

Ответ 1

Этот вопрос немного стар, но я думаю, что он по-прежнему представляет большой интерес.

AccountManager, SyncAdapter и ContentProvider идут вместе.

• Вы не можете иметь SyncAdapter без Account в AccountManager.
• У вас не может быть SyncAdapter без ContentProvider.

Но вы можете:

• используйте ContentProvider без других.
• используйте AccountManager без других (но вы не можете использовать AccountManager без SyncAdapter перед Android 2.2/Froyo API 8)

С AccountManager/SyncAdapter/ContentProvider:

• AccountManager предоставляет пользователям центральную точку (Настройки > Учетные записи) для определения своих учетных данных
• Android решает, когда синхронизация может быть выполнена с помощью SyncAdapter. Это может быть полезно для оптимизации батареи (например, синхронизация не выполняется, когда сеть отключена).
• ContentProvider - удобный способ обмена данными между приложениями Примечание: есть другие методы межпроцессного взаимодействия на Android.
• ContentProvider планирует доступ к базе данных в фоновом потоке AsyncQueryHanlder помогает запросить ContentProvider в фоновом потоке, предотвращая ошибки Application Not Responsive (ANR), не требуя, чтобы вы явно обрабатывали потоки.
• ContentProvider связывается с ContentResolver observer: это означает, что легко уведомлять представления при изменении содержимого.

Нижняя строка: фреймворк AccountManager/SyncAdapter/ContentProvider помогает, если вы хотите синхронизировать данные с веб-ресурса. Fake/Неверные реализации требуются для API 7. Также

• Если вы хотите хранить данные, вы должны рассмотреть более простой механизм хранения данных
• Если вам нужен только один ресурс, вы можете использовать AsyncTaskLoader
• Если вы хотите загружать изображения асинхронно, вы можете использовать специализированные библиотеки, такие как Square Picasso
• Если вы хотите только выполнить какой-либо код в заданное время, вы можете рассмотреть Сервис/Тревога
• доступен только от API >= 7 (это уже не имеет значения)

Наконец, если вы используете SyncAdapter, серьезно рассмотрите Firebase Cloud Messaging (ранее Google Cloud Messaging), а также "push-уведомления" на имеют более свежие обновления и оптимизированное использование аккумулятора.

Ответ 2

Класс AccountManager интегрирован с вашими учетными записями телефона. Поэтому, если вы будете следовать всем руководствам и будете работать правильно, вы увидите свои учетные записи в меню "Настройки- > учетные записи и синхронизация". Оттуда вы можете их настроить или удалить. Кроме того, у AccountManager есть кеш аутентификационных билетов для ваших учетных записей. Это также можно использовать, если вы не планируете синхронизировать свою учетную запись (насколько я знаю).

Если вы не хотите, чтобы ваши учетные записи отображались в этом меню, вы не должны использовать AccountManager и хранить данные учетных записей в другом месте (возможно, в общих настройках) http://developer.android.com/guide/topics/data/data-storage.html

Ответ 3

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

Первая часть головоломки называется Аутентификатором учетной записи, который определяет, как будет выполняться учетная запись пользователя появится в разделе "Учетные записи и синхронизация" Настройки. Внедрение учетной записи Аутентификатор требует 3 штуки: служба, которая возвращает подкласс AbstractAccountAuthenticator из onBind, действие для подсказки пользователь вводит свои учетные данные, и xml файл, описывающий, как ваш учетная запись должна выглядеть, когда отображается Пользователь. Вам также необходимо добавить android.permission.AUTHENTICATE_ACCOUNTS разрешение на AndroidManifest.xml.

Ответ 4

AccountManager хороша по следующим причинам:

• Сначала нужно сохранить несколько имен учетных записей с различными уровнями доступа к функциям приложений под одним типом учетной записи. Например, в приложении для потоковой передачи видео могут быть два имени учетной записи: один с демо-доступом к ограниченному количеству видеороликов, а другой - полный месяц доступа ко всем видео. Однако это не основная причина использования Accounts, поскольку вы можете легко управлять этим в своем приложении без необходимости в этом причудливом стиле Accounts....
• Другим преимуществом использования Accounts является избавление от традиционной авторизации с именем пользователя и паролем каждый раз, когда авторизованная функция запрашивается пользователем, поскольку проверка подлинности происходит в фоновом режиме, и пользователю предлагается ввести пароль только в определенном состоянии, которое я получу позже.
• Использование функции Accounts в android также устраняет необходимость в определении собственного типа учетной записи. Вероятно, вы сталкивались с приложениями, использующими учетные записи Google, для авторизации, что избавляет от необходимости создавать новую учетную запись и запоминать ее учетные данные для пользователя.
• Accounts можно добавить независимо через Настройки → Учетные записи
• Авторизовать пользователя через кросс-платформу можно легко с помощью Accounts. Например, клиент может одновременно получить доступ к защищенному материалу в своем Android-устройстве и ПК без необходимости повторного входа в систему.
• С точки зрения безопасности использование одного и того же пароля в каждом запросе на сервер позволяет осуществлять подслушивание в незащищенных соединениях. Шифрование пароля здесь недостаточно, чтобы предотвратить кражу паролей.
• Наконец, важной причиной использования функции Accounts в android является разделение двух сторон, вовлеченных в любой бизнес, зависящий от Accounts, так называемого аутентификатора и владельца ресурса, без ущерба для учетных данных клиента (пользователя). Термины могут показаться довольно расплывчатыми, но не сдавайтесь, пока вы не прочитаете следующий параграф... 😉

Позвольте мне подробно остановиться на последнем примере приложения для потоковой передачи видео. Компания A является владельцем видеопотока в контракте с Компанией B, чтобы предоставить своим определенным участникам услуги премиум-потоковой передачи. Компания B использует метод имени пользователя и пароля для распознавания своего пользователя. Чтобы компания A узнала премиум-членов B, одним из способов было бы получить их список из B и использовать аналогичный механизм совпадения имени пользователя и пароля. Таким образом, аутентификатор и владелец ресурсов являются одинаковыми (компания A). Помимо обязательности пользователей помнить второй пароль, очень вероятно, что они устанавливают тот же пароль, что и профиль своей компании B для использования сервисов от A. Это, очевидно, не выгодно.

Чтобы устранить вышеупомянутые недостатки, OAuth был введен. В качестве открытого стандарта для авторизации в приведенном выше примере OAuth требует, чтобы авторизация выполнялась компанией B (аутентификатором) путем выдачи некоторого токена под названием Access Token для подходящих пользователей (стороннего), а затем предоставления Компании A (владельцу ресурса) токен. Таким образом, никакой токен не означает права на участие.

Я подробно рассказал об этом и более на AccountManager на моем веб-сайте здесь.