Главная » Разработка для Android » АУТЕНТИФИКАЦИЯ И СИНХРОНИЗАЦИЯ в Android приложении

0

 

В Android 2.0 (API уровня 5) и выше появилась возможность писать собственные поставщики синхронизации для интегрирования с системными контактами, календарями и т. д. В таком случае синхронизация с удаленной службой является, к сожалению, слишком рискованной авантюрой, поскольку малейший сбой на любом этапе этого процесса попросту вызовет крах системы Android и спровоцирует перезагрузку (причем практически невозможно будет понять, что именно пошло неправильно). Но по мере развития Android синхронизация также становится проще и надежнее. На данный момент этот процесс протекает в два этапа: аутентификация (аутентификатор учетных записей) и синхронизация (поставщик синхронизации).

Прежде чем приступить к детальному рассмотрению двух этих этапов, отметим, что примеры, которые мы здесь приводим, состоят из двух компонентов – серверной части и клиентской части на самом устройстве Android. Серверная часть, которой мы пользуемся, – это простая серверная служба, принимающая специфические запросы GET и выдающая ответ в формате JSON. Релевантный URI запроса GET, а также пример ответа мы приводим в каждой из рассматриваемых частей. В исходном коде, прилагаемом к этой книге, для полноты картины приведен весь серверный код.

Следует также отметить, что в приводимом нами примере мы решили синхронизироваться с контактами учетной записи. Но синхронизироваться можно не только с ними. Возможна синхронизация с любым поставщиком содержимого, к которому у вас есть доступ, и даже с сохраненными данными, специфичными для конкретного приложения.

Аутентификация

Чтобы клиент мог пройти аутентификацию на удаленном сервере при помощи системы аутентификации учетных записей, присутствующей в Android, необходимы три элемента.

Служба, которая запускается намерением android, accounts. AccountAuthenticator и возвращающая в своем методе onBind подкласс AbstractAccountAuthenti cator.

Активность, приглашающая пользователя ввести свои учетные данные.

XML-файл, описывающий, как должна выглядеть учетная запись, которая отображается пользователю.

Поговорим сначала о службе. В файле описания нам необходимо активировать

Потом служба должна быть охарактеризована в файле описания. Обратите внимание: намерение android. accounts .AccountAuthenti cator включается в описатель іntent- fіlter. Кроме того, в файле описания содержится информация о ресурсе для

AccountAuthenti cator:

Далее следует ресурс, который мы указали в файле описания. В частности, он описывает тип accountType, отличающий аутентификатор от других аутентификаторов, которые используют определение данной учетной записи. Аккуратно работайте с XML-документом (например, нельзя напрямую присваивать строку android: label или допускать отсутствие отрисовываемого объекта), поскольку в Android произойдет крах системы в тот самый момент, когда вы попытаетесь добавить новую учетную запись (из настроек учетной записи и синхронизации):

Теперь, когда информация о службе есть в файле описания, можно заняться самой службой. Обратите внимание: метод onBi nd() возвращает класс Authenti cator. Этот класс дополняет класс AbstractAccountAuthenti cator:

Прежде чем перейти к рассмотрению полного исходного кода класса Authenti cator, следует упомянуть один важный метод класса AbstractAccountAuthenti cator. Он называется addAccount(). Этот метод вызывается именно в тот момент, когда на экране Add Account (Добавить учетную запись) мы выбираем кнопку, соответствующую нашей учетной записи. Активность LoginActi vity (созданная нами, запрашивает у пользователя данные для входа) описывается в намерении (Intent), который находится в возвращаемом пакете (Bund! е). Очень важен ключ AccountManager. KEY_ ACCOUNT_AUTHENTICATOR_RESPONSE, входящий в состав намерения, поскольку в нем находится объект AccountAuthenti catorResponse. Этот объект нужен, чтобы доставить обратно на устройство ключи учетных записей, после того как пользователь успешно пройдет сертификацию с удаленной службой.

Вот полный код активности Authenti cator, дополняющей класс AbstractAccountAuthenti cator:

В данном случае у удаленного сервера есть метод API входа в систему (доступный посредством HTTP URI), принимающий имя пользователя и пароль в качестве переменных. Если вход в систему пройдет успешно, ответ вернется со строкой в формате JSON, и в этой строке будет содержаться метка (token):

Активность LoginActi vity, требующая от пользователя ввести имя и пароль к учетной записи, затем устанавливает контакт с удаленным сервером. После того как будет возвращена ожидаемая строка в формате JSON, вызывается метод handl eLogi nResponse(), передающий важную информацию об учетной записи обратно к AccountManager:

XML макета активности LoginActivity таков:

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

Синхронизация

Синхронизация данных определенной учетной записи опять же состоит из трех частей. В ее состав входят: служба, регистрируемая для слушания намерения android.content.SyncAdapter и возвращающая методу onBindO дополненный класс AbstractThreadedSyncAdapter; описатель XML, сообщающий информацию о структуре тех данных, которые будут синхронизироваться и просматриваться; и, наконец, класс, дополняющий AbstractThreadedSyncAdapter, – он и занимается самой синхронизацией.

В нашем примере мы собираемся синхронизировать контактную информацию с учетной записью, описанной в предыдущем разделе. Обратите внимание: синхронизировать можно не только контактную информацию. Можно синхронизироваться с любым поставщиком содержимого, к которому у вас есть доступ, и даже со специфичными для конкретного приложения сохраненными данными.

В файле описания прописываются следующие права доступа:

Теперь опишем службу, с которой мы собираемся работать. Обратите внимание на то, что здесь присутствует намерение android.content.SyncAdapter, а также указывается структура контактных данных и сам адаптер SyncAdapter:

В XML-pecypce для sync-adapter обратите внимание на описатель accountType. Содержимое, с которым мы собираемся работать, – это информация о контактах Android:

Вот XML для описателя контактов. Обратите внимание на названия различных столбцов, описанных нами:

Созданная нами служба SyncServi се возвращает класс SyncAdapter. Это созданный нами класс, дополняющий AbstractThreadedSyncAdapter:

Продолжая данное упражнение, создаем метод getf ri ends на стороне удаленного сервера. Он принимает метку, переданную нам обратно с сервера и сохраненную в результате успешного входа в систему, – об этом мы говорили выше. Он также передает время, указывающее, когда был сделан последний вызов (если вызов был сделан впервые – передается значение 0). Ответ представляет собой еще одну строку в формате JSON, описывающую друзей (в том числе сообщающую их ID, имя и номер телефона) и указывающую время, в которое был сделан вызов (или Unix-время на сервере). Здесь также приводится история добавления или удаления друзей в данной учетной записи. В истории в поле type может стоять значение 0 или 1. Первое соответствует добавлению друга, второе – удалению. Поле who содержит ID друга, а поле time сообщает, когда была произведена операция:

Далее следует класс AbstractThreadedSyncAdapter, дополняющий SyncAdapter:

Далее приведен весь класс SyncAdapter, содержащий различные действия, которые происходят, когда метод синхронизации получает данные. Здесь же включены различные добавления и удаления контактной информации:

В предыдущем классе SyncAdapter легко упустить важную деталь. Она заключается в следующем: во время вызова onPerf ormSync () мы пытаемся получить authtoken от AccountManager и пользуемся при этом методом blockingGetAuthTokenO. В итоге это приводит к вызову AbstractAccountAuthenti cator, связанного с данной учетной записью. В этом случае происходит вызов класса Authenti cator, рассмотренного нами в предыдущем разделе. В классе Authenti cator вызывается метод getAuth-TokenO. Рассмотрим эту ситуацию на примере:

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии