0

Google IO Rest Structure パート A - サービス API の使用を実装しようとしています。そのため、構造の次の部分を特定しました。

  1. rest メソッドを提供するインターフェース。
  2. 上記のインターフェイスを実装するプロセッサ クラス。多くのプロセッサ クラスがあります。各プロセッサ クラスは、モデル クラス タイプを返します。
  3. シングル プロセッサを扱うサービス プロバイダ。プロセッサから返されたデータは、サービス プロバイダによって処理されます。これにより、プロセッサ関数が呼び出され、返されたデータが取得されます。
  4. サービス クラスである ServiceProcessor。アプリケーションには単一のクラスがあります。これは、渡された Bundle データに基づいてさまざまな ServiceProvides と通信します。
  5. アクティビティとサービスの間の高度な統合を提供するサービス ヘルパー

今、私はここで明確ではありません。サービスには、要求されたデータがあります。さらに進む方法。Service から ServiceHelper にデータを戻すにはどうすればよいですか。タグ BUNDLE_EXTRA を付けてバンドルに入れますか? このために、私の pojo は Serializable または Parceable のいずれかでなければなりません。Serializable が Android プラットフォームでは非常に悪いオプションであることは知っています。他にどのようなオプションがありますか。Broadcast Intent を使用しますか?

ここで助けてくれてありがとう。

4

1 に答える 1

4

いくつかのことができます。

  • インテントを介してサービス ヘルパーに通知します (ブロードキャスト レシーバーを実装できるようにします)。1 回の rest 呼び出しで多くの行を取得できるため、これは悪い考えかもしれません。この場合、送り返すインテントに pojo を入れる何らかの機能を実装する必要があります (fillIntent/getFromIntent メソッドなど)。

  • サービス プロバイダー内で、結果データをどこかに保存し (sqllite、contentprovider、ファイル)、requestId と呼び出しの結果のみを含むブロードキャスト インテントをスローします。サービス ヘルパーはブロードキャストを傍受し、要求が完了したことを関心のあるアクティビティに通知します。アクティビティはそれに応じて ui を更新します。この場合、servicehelper は進行中のリクエストを追跡し、結果を通知するためだけに使用されます。

私の意見では、UI とモデルを分離したままにし、アクティビティにデータのストレージを要求せず、より「休息志向」であるため、このアプローチの方が優れています。

プラス：少し前に、このアプローチを実装しようとしました。未完成ですが、サービスヘルパーとリクエスト/結果のインテントはこちらで確認できますpostman lib

より成熟した堅牢なライブラリはrobospice です。これは、残りのサービスを処理する必要がある場合に使用するものです。

于 2012-11-30T07:29:24.317 に答える