Каков наилучший выбор потоков в приложении Android для RESTful API, передающего данные JSON?

Question

Я новичок в Android.Я пытаюсь написать приложение, которое будет отображать несколько частей информации об открытых магазинах.Я получаю эту информацию, используя RESTfull API, который передает данные JSON.

Вот мой вопрос: Каков наилучший вариант реализации сервиса / потоков?Вот мои требования к продукту:

• Я хочу инкапсулировать все API и JSON в класс, который может вызывать одна или несколько Android «Деятельности».Я думаю, что это может диктовать службу, но эта служба должна будет работать только во время работы моего приложения и не будет доступна другим приложениям.Пользователь должен будет пройти аутентификацию в удаленной системе через RESTfull API.

• Он должен быть в отдельном потоке, поскольку вызовы API могут занимать слишком много времени.Я не думаю, что он должен быть многопоточным, поскольку я не вижу, чтобы более чем одно «действие» одновременно взаимодействовало со службой.

• Служба должна смотреть на кэширование некоторыхинформация, которую он возвращает, так что, когда «Activity» выполняет вызов (например, «GetStoreList»), он может вернуть список магазинов, к которым он уже запрашивал ранее.Я не уверен, стоит ли мне хранить эту информацию в памяти или использовать функцию SQLite в Android.У меня могло быть несколько сотен магазинов в списке с десятью-двенадцатью другими частями информации, связанной с каждым магазином.Часть этой информации будет отображаться в списке «Активность», а другая - нет.Поскольку у меня нет никакого опыта работы с SQLite, я не уверен, что затраты на производительность будут выше, чем хранение информации в памяти.

• Будет около дюжины или около того методов, которые понадобятся службезаключать в капсулу.Например: как только я получу список магазинов, я, возможно, захочу снова вызвать API, чтобы узнать, открыт ли магазин в данный момент.Часть передаваемой информации будет являться пользовательскими классами и, следовательно, потребует определения классов «Parceable», если мне придется использовать IPC как часть моего решения (если я правильно понимаю документацию Android).

• Я также хотел бы«Ленивая загрузка» списка в мою «Активность», чтобы мне не пришлось ждать полного списка перед обновлением пользовательского интерфейса.

Возможные решения (это все догадки, поэтому, пожалуйста, неt распни меня ... вот почему я задаю вопрос):

1. Я мог бы использовать класс, расширенный от «Service». Он должен был бы сам обрабатывать потоки, чтобы длинные интернет-вызовычерез RESTful API не зависнет система.В качестве альтернативы, я мог бы сначала выполнить манипулирование потоками и вызвать API, предполагая, что я могу занять столько времени, сколько захочу.Я думаю, что мне нужно было бы реализовать связь между «Деятельностью» и сервисом через IPC.Это кажется немного сложным для меня.Я не уверен, что смогу использовать класс Messenger.Это выглядит проще, чем AIDL.

2. Думаю, я мог бы использовать «IntentService».Это автоматически создаст отдельный поток и поставит в очередь сообщения / задачи.Я думаю, что я мог бы связаться со службой (например, чтобы получить списки магазинов), «привязав» к службе.Проблема, которую я вижу, заключается в передаче данных взад и вперед, и я не уверен, как я буду кэшировать данные между вызовами API, поскольку служба завершает работу после вызова API.

В любом случаеЯ предпочел бы учиться у кого-то, кто уже сделал этот тип приложения, вместо того, чтобы делать это неправильно и дважды его кодировать.Спасибо за помощь.

Answer 1

Ваш сценарий почти такой же, как и в моем предыдущем проекте.Вот то, что мы придумали (я уверен, что это не оригинально, но скопировано с одного из этих видео Google io)

• Служба обрабатывает запрос-ответ вызовов RESTful длясервер.Это вызвано действием, вызывающим startService(Intent), которое включает параметры в Пакете, включенном в намерение.Пакет содержит информацию о том, какой API будет вызываться, и какие параметры включены.

• Служба не передает результат непосредственно в операцию - вместо этого она записывает результат вбаза данных sqlite.Деятельность будет знать, что транзакция завершена, наблюдая за БД (через ContentObserver).Аналогичным образом, Сервис может уведомить об активности, как только транзакция завершена через широковещательную рассылку;действие может поймать это, зарегистрировав BroadcastReceiver - однако полученные данные по-прежнему не должны напрямую передаваться в действие через Bundle, так как могут быть случаи, когда данные слишком велики для Bundle, чтобы содержать (есть предел длядлина строки, которая может быть включена в пакет) - вы все равно хотите поместить результат в поставщик.Действие должно запросить данные, как только Служба уведомит действие о том, что результат есть.

• Кроме того, вы можете включить флаг «успех» или «сбой» в Broadcastчто служба сгенерирует для действия, поэтому она будет знать, нужно ли ей запрашивать результат - это устраняет дополнительные издержки для неудачных транзакций.

Если вам нужно спросить, нетмы не использовали AIDL для этой архитектуры (но мы использовали его в другом модуле, который поддерживает чат Facebook / YM через xmpp).

«Ленивая загрузка», я думаю, может быть задана в другом вопросе,поскольку это совершенно другой процесс.

Answer 2

AbstractThreadedSyncAdapter был создан только для подобных вещей. Здесь есть довольно полный (но сложный пример) здесь . Кроме того, один из моих любимых видео Google IO дает довольно хороший обзор того, как его использовать.