Comments 12
Спасибо, очень полезно.
Спасибо! Буквально пару дней назад задавал вопрос по поводу аутентификации на stackoverflow. В ответ дали ссылку на хороший туториал.
Спасибо за статью! Когда-то с этим разбирался и нашёл 2 очень хорошие статьи на английском:
Надеюсь, в следующей части будет покрыт и случай, когда синхронизация нужна, а авторизация — нет (клиент просто регулярно скачивает обновленную информацию с сервера).
Да, информации полно, если поискать. Но суть статей на харбе в централизации этой самой информации и доступе к ней на великом и могучем.
Информации много, да. Но всё-таки было бы интересно прочесть «часть вторую» именно в вашей интерпретации :)
Если интересно в моей — вот. С пылу, с жару =)
Можете дать небольшой комментарий по классу GitHubAuthenticator?
В else-блоке метода getAuthToken(...) создается Intent, а следом создается Bundle, в который помещается созданный Intent. Но метод возвращает другой Bundle (который result, созданный в начале метода). То есть, созданные в else-блоке Intent и Bundle нив чем не участвуют. Может, подразумевалось помещение Intent в тот Bundle, который result, а не тот, который bundle?
В else-блоке метода getAuthToken(...) создается Intent, а следом создается Bundle, в который помещается созданный Intent. Но метод возвращает другой Bundle (который result, созданный в начале метода). То есть, созданные в else-блоке Intent и Bundle нив чем не участвуют. Может, подразумевалось помещение Intent в тот Bundle, который result, а не тот, который bundle?
«у AccountManager'а есть метод setUserData(final Account account, final String key, final String value) который по сути предоставляет нам возможность хранения любой информации в формате key-value. Это то, о чем я говорил немного выше. Это еще одна плюшка в довесок к остальным — возможность хранить профиль пользователя без необходимости создания/использования внутренних хранилищ»
Как клиентскому приложению затем получить доступ к профилю? Эти методы доступны из приложения с аутентификатором — да. Но пусть клиентское приложение имеет другую подпись, вызовы getUserData() кинут exception (из документации — «This method requires the caller <...> to have the same UID as the account's authenticator»). Как тогда клиентскому приложению получить эти данные?
Как клиентскому приложению затем получить доступ к профилю? Эти методы доступны из приложения с аутентификатором — да. Но пусть клиентское приложение имеет другую подпись, вызовы getUserData() кинут exception (из документации — «This method requires the caller <...> to have the same UID as the account's authenticator»). Как тогда клиентскому приложению получить эти данные?
Избежать ошибки «Activity to be started with KEY_INTENT must share Authenticator's signatures» можно если в манифесте аутентикактора в XML указать android:customTokens=«true». Интересен другой вопрос — как работать с AccountManager из бекграунд-сервиса (в частности как вызвать метод getAuthTokenByFeatures так чтоб он показал логин активити при необходимости)? Похоже без хаков с dummy активини не вийдет.
(наверное ответ достоин награды Necromancer :D )
(наверное ответ достоин награды Necromancer :D )
Спасибо за статью. На данный момент попробовал внедрить AccountManager в свой проект, в связи с чем возникли несколько вопросов: можно ли каким-либо образом прослушивать изменения токенов для конкретного аккаунта? Можно ли прослушивать изменения токенов конкретного типа для аккаунта? Заранее спасибо.
Sign up to leave a comment.
Синхронизация в Android приложениях. Часть первая