俺用メモ
- Serviceクラスを継承する
- AndroidManifest.xmlに登録が必要
- startServiceでIntentを投げると起動する
- 複数回startされるとどうなる→1回onCreateされて2回onStartされる
- bindServiceでActivityにバインドされる
- バインドとは何?
- AIDLとかいうのでインターフェースを定義するらしいよ。AIDLってなんやねん
- ServiceConnectionが必要→サービスに接続したり切断したりした時にコールバックを受け取る人っぽい→やることはサービスをActivityから参照できるようにするだけ?→適当にローカルで作ってprivateでもっとけばいいくさ
- AIDLてなんぞ
- http://developer.android.com/intl/ja/guide/developing/tools/aidl.html
- interface定義からコード生成するみたいな何か
- 結果はどうやって受け取る?
- 「バインド」して受け取る?
- ブロードキャスト?
てんぷれ処理
private IFooService foo_service_;
private ServiceConnection service_conn_ = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder binder) {
foo_service_ = IFooService.Stub.asInterface(binder);
}
@Override
public void onServiceDisconnected(ComponentName name) {
foo_service_ = null;
}
};
// snip…
public void onCreate(Bundle savedInstanceState) {
// snip…
Intent intent = new Intent(this, FooService.class);
bindService(intent, service_conn_, BIND_AUTO_CREATE);
}
// unbindServiceはいつやるべきか。onDestroyでやるのはライフサイクル的におかしい気がする。であるならばonResumeでbind、onPauseでunbindじゃないのかJK
別にServiceってのは専用のスレッドが立ち上がってHandle作って安全に受け渡してくれるような高度なバックグラウンドサービス機構ではないようだ。
単にActivityのように安易に抹殺対象にならないというだけで、バックグラウンドで処理したければてめえでスレッド立ててがんばれ的な?
単にタスクサービスが欲しいだけなら現状のスレッドでがんばる方式でいいような気がしてきたぞ……
anちゃんくらい本格的なことをやりたいなら必要
もちろん別プロセスから呼べるとかそういう利点はある(んだよね?)のだろうけど、つまり裏を返すとAIDLで定義されるインターフェースの引数やらなんやらにはシリアライズ可能なデータ(=Parcelable)しか渡せないという認識でよろしいのかしら。
どちらにしてもAIDLで作ったIFooServiceからinvokeした場合、IFooService.Stubのinvokeで結果を返すまではブロッキングされるわけだから、非同期に処理したい時にはここだけでは完結しないことになる。
であるならば、requestFoo()→(何かで蹴る)→fetchFoo()といった過程が必要なのだけど、つまり何かで蹴るというのはServiceが完了したらIntentをブロードキャストするって話になるので、Activity側はregisterReceiverで引っ掛けろみたいなことになるんですかね。
一旦シリアライズされるという前提であるならば(同一プロセスであっても参照渡しは期待できないので最低でもコピーは発生するはず)fetchFooで大きなデータを受け渡すようなServiceは筋が悪いように思われる。
そもそもとしてTuboroidに必要なのはServiceなのか。実はContent Providerではないのか。