GoogleApiClientデザインパターンとは何ですか？

Question

私はジオフェンシングのような他のAPIにアクセスするのに、しばらくAndroidのGoogleApiClientを使用してきました。私はGoogleApiClientとGoogle Play Servicesを通じて感謝しています.Googleは、新しいオペレーティングシステムのアップデートをまったく必要とせずに、古いAndroid搭載デバイスに含まれているAPIに連続したアップデートをダウンロードさせることで、Googleの断片化問題に取り組んでいます。

Javaのレベルで私に不明な点は、GoogleApiClientが接続/サスペンド/フェイルのコールバックを必要とし、サポートしている理由です。それ以上の詳細がなければ、本質的に他のAPIのラッパーであるGoogleApiClientがオーバーベーキングされ、強調されているようです。接続できない/中断する/ etcは開発者にとって透過的でしたか？最悪の場合、サービスへのアクセスに失敗した場合、例外をスローすることはできませんでしたか？

だから、批判するのではなく、私の知るところに穴があると思うので、私はデザインを理解できません。このようにGoogleがAPIクライアントを設計したのはなぜですか？彼らが従っていたデザインパターンはありますか？

Answer 1

は、それが構造化されている方法には多くの理由がありますが、まず第一に、という事実である：あなたがAndroidのUIメインスレッドからそれを呼び出すことができるように

• GoogleApiClientコードが設計されていますが（AsyncTaskまたはバックグラウンドスレッドを明示的に作成しなくても）
• GoogleApiClientコードの実行に時間がかかることがあります（たとえば、ユーザーがPlayサービスをインストールしていない場合、ユーザーにPlayサービスのダウンロード/インストールを要求し、 Playサービスのインストール後にアプリケーションに戻る）
• AndroidのUIメインスレッドが長時間実行される操作（Playストアからアプリケーションをダウンロードするなど）によってブロックされた場合、応答しなくなります。その結果、コールバックの登録は、Androidの土地にあるこのようなコードではかなり標準的です。 [Android UIのメインスレッドを長時間ブロックするのは、アプリケーションを強制終了するシステムの一般的な原因です。]

ここで、Playサービスの複雑さを増やす多くの要素の1つは、柔軟性の必要性、Playサービスを使用する各アプリケーションがなくても、さまざまな機能やライブラリをサポートする必要があること（サポートするすべてのライブラリをコンパイル/含める必要があります。 Playサービスを利用する各アプリで複製されたPlayサービスの機能）このため、Play Servicesではクライアント/サーバーアーキテクチャが使用されます。 Playサービスを使用するアプリケーションは、そのシステムの基本機能を提供するコードを含め、すべてのPlayサービスをインポートするわけではありません。むしろ、Play Servicesを使用する各アプリは、Play Servicesアプリでこれらのサービスの実装と通信できるインターフェイスを、より小さく、より集中的にインポートします（Play Servicesアプリだけで、これらのインターフェースを実際に実装するロジック）。ただし、このアーキテクチャのため、「インポート」に相当する必要がありますが、実行時には、機能を使用する前にPlayサービスアプリをダウンロードして初期化する必要があります。