Синхронизация в Android приложениях. Часть первая 2


На дворе 2014 год, доля Android JellyBean перевалила за 60%, появились новые тренды в дизайне. В общем, случилось много всего интересного. Но синхронизация данных с сервером осталось неотъемлемой частью большинства приложений. Существует много способов реализации ее в приложении. Android предоставляет нам SyncAdapter Framework, который позволяет автоматизировать и координировать этот процесс и предоставляет множество плюшек в довесок.

Account

Для начала нам потребуется собственный аккаунт на устройстве. Сначала, я думаю, стоит ответить на вопрос, зачем? Действительно, зачем?

Краткое резюме преимуществ:

  • Поддержка фоновых механизмов вроде SyncAdapter
  • Стандартизация способа авторизации
  • Поддержка различных токенов (прав доступа)
  • Шаринг аккаунта с разграничением привилегий (возможность использовать один аккаунт для различных приложений, как это делает Google)

Шаги для получения плюшек:
1) Создание Authenticator’а
2) Создание Activity для логина
3) Создание сервиса для общения с нашим аккаунтом


AccountManager — управляет аккаунтами устройства. Приложения запрашивают авторизационные токены именно у него.

AbstractAccountAuthenticator — компонент для работы с определенным типом аккаунта. Вся механика по работе с аккаунтом (авторизация, разграничение прав) осуществляется здесь. Может быть общим для различных приложений. AccountManager работает именно с ним.

AccountAuthenticatorActivity — базовый класс активити для авторизации/создания аккаунта. Вызывается AccountManager’ом в случае необходимости идентифицировать аккаунт (токен отсутствует или протух).

Как это все работает, можно посмотреть на диаграмме из документации
image

Когда нам понадобился токен, мы работаем с методом AccountManager’а — getAuthToken. Стоит заметить, что это асинхронный метод и его можно безопасно вызывать из UI потока. Существует также синхронная версия этого метода — blockingGetAuthToken. К диаграмме еще вернемся.

Создание Authenticator’а

Для создания собственного Authenticator’а, нам необходимо расширить AbstractAccountAuthenticator и реализовать несколько его методов (7 если быть точным). Но для нас, на данный момент, представляют интерес всего два.


Метод, как видно из названия, вызывается при попытке добавить новый аккаунт. Все, что мы должны в нем сделать — это вернуть Intent, который должен запустить наше Activity. Чтобы иметь возможность добавить аккаунт из приложения, нам потребуются соответствующие разрешения.

 


 

Что же происходит в момент вызова этого метода: пытаемся получить текущий токен методом peekAuthToken, если токен существует, можем добавить проверку на валидность (напомню, что это асинхронный метод, так что можем ломиться на сервер) и возвращем результат. Если токена нет и/или сервер нам не отдал его, мы возвращаем тот же интент что и в методе addAccount. В этом случае пользователя выбьет на экран авторизации.

Создание Activity авторизации

Наше активити должно наследоваться от AccountAuthenticatorActivity (строго говоря, не должно а может: в AccountAuthenticatorActivity 20 строчек вспомогательного кода, который можно написать руками в любом другом активити). У нас будет самое простое активити с полями логин/пароль и кнопкой войти. В целом, в AccountManager’е можно сохранять произвольную информацию о профиле пользователя. Отвечать за получение токена будет AuthTokenLoader, но можно использовать любой понравившийся механизм. Задача-то простая — получить от сервера токен.


 

Данный метод вызывается, когда токен от сервера получен (а это говорит о валидности аккаунта) и, соответственно, можно добавить аккаунт на устройство. setAccountAuthenticatorResult — метод для передачи результата обратно в AccountManager.

Сервис для интергации в систему

Сервис позволит системе и другим приложениям связываться с нашим Authenticator’ом. Код сервиса максимально прост:


 

Все, что он делает, это возвращает IBinder нашего Authenticator’a. Причем метод getIBinder уже реализован в AbstractAccountAuthenticator. Осталось только прописать наш сервис в манифесте приложения.

Осталась совсем маленькая деталь: вы могли заметить такую строчку

Это метафайл, который описывает наш Authenticator. Его необходимо создать в папке res/xml. В нем мы указываем иконку нашего аккаунта, его название и тип. В самом простом случае, он выглядит так:

Вот, в целом, все. После этих хитрых манипуляций мы получили возможность создавать свой аккаунт на устройстве. При всей кажущейся сложности, этот процесс на самом деле сводится к реализации 2-х методов, создания xml метафайла и описания сервиса в манифесте. Остальные методы Authenticator’а необходимы для шаринга нашего аккаунта во внешний мир с разделением привилегий, о чем мы поговорим в следующих статьях.

P.S. В качестве бонуса: у AccountManager’а есть метод setUserData(final Account account, final String key, final String value) который по сути предоставляет нам возможность хранения любой информации в формате key-value. Это то, о чем я говорил немного выше. Это еще одна плюшка в довесок к остальным — возможность хранить профиль пользователя без необходимости создания/использования внутренних хранилищ.

Исходники проекта можно взять тут.

via dev_troy

Синхронизация в Android приложениях. Часть вторая


Оставьте комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

2 мыслей про “Синхронизация в Android приложениях. Часть первая