ソケット接続のためのシングルトンまたはサービス

Question

私はAndroid開発を初めて使いました。私はIOSアプリケーションをAndroidに移植しようとしています。基本的に私のアプリケーションはソケットIOでリアルタイムにサーバーと通信する必要があります。サーバーに接続し、サーバーが要求を処理するまでさまざまなメッセージを処理します。

IOSアプリケーションでは、シングルトンパターンを使用してwebsocketサーバーにリクエストを送信し、同じインスタンスを使用してサーバーレスポンスを委任します。 Androidでは、同じパターンを使用し、サーバー応答を取得した後にユーザーをリダイレクトするアクティビティにコールバックオブジェクトを使用しました。

アプリがバックグラウンドになっても、サーバーから適切なステータスが得られるまで、ソケット接続を開いたままにしておく必要があります。

一部の人は、シングルトンの代わりにブロードキャスト受信機でサービスを使用することをお勧めします。それは私の場合にするのが最善のことですか？ Serviceを使用して

Answer 1

は、私は非常に同様の目的（ブルートゥースおよびTCP/IPアプリケーションのためのソケット通信を行う）のために行われ、通信が場合でも、ユーザー続けるべきかどうかは確かServiceを使用したいと思うしている正確に何でありますアプリケーションを終了しました。

Serviceは、基本的にUIスレッド上でコードを実行するための手段であり、それに関連したUIを持ってActivityとは異なりますが、ユーザーインターフェースなし（もちろん、あなたはそれ内の他のスレッドを始めることができます）。

代替として提案しているように、静的なシングルトンクラスでこれを実行しようとしていた場合、問題は、そのライフサイクルを非常にうまく制御できないことだと思います。ユーザーがアプリケーションから離れて移動すると、プロセスとそれに伴うすべての静的オブジェクトを削除することがフレームワークに依存することになります。このため、シングルトンクラスにデータが移入され、アプリケーションを終了して後でアプリケーションに戻った場合、「古い」シングルトンインスタンスが依然として存在することがあります。この理由から、私のアプリケーション（大域的な大量の状態を使用しています）では、シングルトンの実際のインスタンスを.Applicationクラスの拡張で保持して、（うまくいけば）ライフサイクルをより適切に制御していました。 Serviceで

あなたはActivityと同じように（などonCreate()、onDestroy()、）適切なライフサイクルコールバックと明確に定義されたライフサイクルを持っています。

Answer 2

はい、間違いなくServiceを使用してください。 docsから：

Aサービスは、シングルトンを使用すると、しばらくのために働くかもしれませんが、ユーザー

と対話していない間に長いランニング動作を実行するために、アプリケーションの願望のいずれかを表すアプリケーション・コンポーネントでありますあなたのアプリケーションは、Serviceを持っていなければ、バックグラウンドに入るときにオペレーティングシステムによって殺される傾向があります。あなたがシングルトンのパターンにもっと慣れているなら、はをシングルトンで実装し、それを単にライフサイクルを維持するためにServiceに結びつけるだけですが、それは価値があるよりも混乱しているようです。 UIスレッドでネットワーク操作を行うべきではなく、デフォルトではサービスがUIスレッド上で実行されることに注意してください。あなたはあなたの仕事をするために別のスレッドをスピンアップする必要があります。

あなたの投稿にはBroadcastReceiverが必要ですが、android.net.ConnectivityManager.CONNECTIVITY_ACTIONのような有用なネットワーク関連のブロードキャストインテントがあるかもしれません。