#onstartcommand

original source : https://www.codeproject.com/Articles/1068249/A-Sticky-Intent-Service-for-long-running-tasks-wit

Introduction

Android services, are Android components that allow work to be done in the background. While, as the name implies, services can be used for building long running persistent background tasks, this is not their default behavior. Android services come into two main flavours:

the Service class, and,

the derived IntentService class.

While the IntentService class is very easy to use, and suitable for most cases, it fails to support cases where a persistent TCP connection, e.g. a XMPP connection, or a long running waiting background service is required. In order to do so, the Sticky service behavior is required, available only to the base Service class. In this article, the new StickyIntentService class is presented, for Xamarin Android. This class combines:

The ease of use and built in features of the IntentService, i.e. operations running in a separate background thread, necessity to implement only the OnHandleIntent method, etc.

The Sticky backgrounding behavior, available only to the Service class, which enables the service to be restarted, if it is stopped by Android.

StickyIntentService is suitable for including a reference to a long running background listening TCP connection, such as the one required by XMPP libraries, e.g. Sharp.Xmpp.  The class features an IntentServicelike interface to use, but with the missing IntentService "sticky" behavior.

Background

Android services are provided by the Service class. By default, Service object's operations run on the main thread, so a background thread must be constructed for such operations. Thus, Service class can be complicated to use. As an additional option Android provides the IntentService class. The IntentServiceworks by sending all intents to a worker queue for processing. This queue processes each intent serially on a separate thread, passing the intent to the OnHandleIntent method. When all the intents have been processed, the IntentService stops itself by calling StopSelf internally.

This last point is crucial for the purpose of having long running TCP connections, or other background tasks, such as the one required e.g. for XMPP, in an IntentService object.   When the supplied Intent is processed, the IntentService stops itself and the IntentService is available for Android to destroy. Any references to objects or long running connections, e.g. TCP connections, can now be destroyed by the OS. Furthermore, since the IntentService  can not be made Sticky, the service is not restarted later on. Thus, while IntentService  is suitable for a wide range of applications, it is not suitable as a long running background service, or for supporting a long running TCP connection, e.g. a XMPP connection with Sharp.Xmpp.

It should be noted that,  when the system is under memory pressure, Android may stop any running services. However, for Service objects, a Sticky or RedeliverIntent Intent could be delivered, in order to restart the background service.  Copying from Xamarin Guides:

"When a service is stopped by the system, Android will use the value returned from OnStartCommand to determine how or if the service should be restarted. This value is of type StartCommandResult, which can be any of the following:

Sticky – A sticky service will be restarted, and a null intent will be delivered to OnStartCommand at restart. Used when the service is continuously performing a long-running operation, such as updating a stock feed.

RedeliverIntent – The service is restarted, and the last intent that was delivered to OnStartCommandbefore the service was stopped by the system is redelivered. Used to continue a long-running command, such as the completion of a large file upload.

NotSticky – The service is not automatically restarted.

StickyCompatibility – Restart will behave like Sticky on API level 5 or greater, but will downgrade to pre-level 5 behavior on earlier versions"

For a more detailed explanation of  Services see the relevant section in Xamarin Android Guides.

original source : http://stackoverflow.com/questions/14182014/android-oncreate-or-onstartcommand-for-starting-service

onCreate() is called when the Service object is instantiated (ie: when the service is created). You should do things in this method that you need to do only once (ie: initialize some variables, etc.). onCreate() will only ever be called once per instantiated object.

You only need to implement onCreate() if you actually want/need to initialize something only once.

onStartCommand() is called every time a client starts the service using startService(Intent intent). This means that onStartCommand() can get called multiple times. You should do the things in this method that are needed each time a client requests something from your service. This depends a lot on what your service does and how it communicates with the clients (and vice-versa).

githubにpushしたサービスのサンプル： https://github.com/kei-naka/android_sample_service

サービスを使ったAndroidアプリの例： http://www.atmarkit.co.jp/fsmart/articles/android07/android07_1.html 時計を使ってるが、Bindを使ってることもあり、サービスをゼロから学ぶには難しい。 サービスとは、 ・バックグラウンドで処理を行うための仕組み ・アクティビティのように、画面を持たない とりあえずこの２つを押さえとけば、最初はOK（のはず）。 他にもいろいろまとめてくれてる： http://d.hatena.ne.jp/adsaria/20100914/1284435095 ■onStart vs onStartCommand

Googleドキュメント： http://developer.android.com/reference/android/app/Service.html#onStartCommand%28android.content.Intent,%20int,%20int%29 上記のGoogleの開発者用ドキュメントによると、 ・APIレベル５より高いものは onStartCommand を使う ・onStartCommand() と互換性のあるメソッドが onStart() であり、APIレベル５以下のバージョンで動かしたい時は、onStart() を使うべし。 と理解した。 ■ライフサイクル クライアントから startService(Intent); が呼ばれるたびに、onStartCommand() が実行される。 ■サービスが実行されるスレッド システムは、サービスのメインスレッド上で onStartCommand() を呼ぶ。 サービスのメインスレッドは、アクティビティが走っているプロセスと同じところである。 例えば、アクティビティと普通にサービスを起動すると、メインスレッド（この場合アクティビティ）のイベント処理を掴んでしまう。 具体的には、ボタンを押してサービスを起動したら、サービスを止めるまでボタンが押しっぱなしになる。 ボタンが押しっぱなしになる例： http://android.keicode.com/basics/services-simple.php 時間がかかる処理や、ネットワーク処理、ディスクIOを伴う重い処理を実行するときは、別スレッドでサービスを起動する必要があることに注意。 ■新規スレッドの生成

新規スレッドの作成例： http://wiki.livedoor.jp/moonlight_aska/d/%A5%B9%A5%EC%A5%C3%A5%C9%A4%F2%C0%B8%C0%AE%A4%B9%A4%EB new Thread(      new Runnable () {           @Override           public void run() {           }      } ); クリックリスナーの構成に似てる。 btn.setOnClickListener(      new View.OnClickListener() {           @Override           public void onClick(View v) {           }      } ); ■onStartCommand() の引数：intent onStartCommand(Intent intent, int flags, int startid); の１つ目にあるintentについて。 Activityから詰められたデータが入ってる。 ↓MainActivityというアクティビティから、"main text"というテキストをMainServiceというサービスに渡す例 # Activity Intent intent = new Intent(MainActivity.this, MainService.class); intent.putExtra("text", "main text"); startService(intent); # Service public int onStartCommand(Intent intent, int flag, int startId) {      Log.d("service", intent.getCharSequenceExtra("text")); } アクティビティからサービスを実行すると、ログにdebugレベルで main text という文字が出る。 ■onStartCommand() の引数：flags onStartCommand(Intent intent, int flags, int startid); の２つ目にあるflagsについて。 ↓のリファレンスによれば、 http://developer.android.com/reference/android/app/Service.html#onStartCommand%28android.content.Intent,%20int,%20int%29 flags は開始する際の追加情報らしい。 よく分からんが、値は0、1（START_FLAG_REDELIVERY）、2（START_FLAG_RETRY）の３つらしい。 1と2の違いはよく分からんが、再開した時に前のデータをもう一度渡すとか、そういうのじゃないかな。 多分ウソだけど。 ↓START_FLAG_REDELIVERYの説明 http://developer.android.com/reference/android/app/Service.html#START_FLAG_REDELIVERY これに、START_REDELIVER_INTENT（onStartCommandの戻り値の１つ）がどーのって書いてあるんで、戻り値と関係あんのかな。 当面は使わない予定なので、繰り返し呼ばれる時に見るべきものかくらいにしといて、これ以上は深堀りしない。 ■onStartCommand() の引数：startId onStartCommand(Intent intent, int flags, int startid); の３つ目にある startId について。 ↓のリファレンスによれば、 http://developer.android.com/reference/android/app/Service.html#onStartCommand%28android.content.Intent,%20int,%20int%29 開始時に割り振られる、ユニークなIDらしい。 実際にログを出してどんな値なのか確認してみた。 stopService(); を実行せずに、繰り返し startService(); を実行したところ、startId という値は1から始まり、1ずつインクリメントされていった。 stopService(); でリセットされるらしく、一度 stopService(); してから再度 starService(); すると、また１から割り振られた。 実際には、サービス内から自分を止める時に、このIDを使って止めるらしい。 まだそこまで行ってないので、そういう時に使うのか、で止めておく。 ■別スレッドでサービス実行してて、トースト出そうとしたら例外発生して怒られた Handlerを使うといいらしい。 # クラスのメンバ変数として private final Handler handler = new Handler(); # onStartCommand内で別スレッドを立ててサービスを実行 new Thread(cmd).start(); # スレッド内で実行される処理の実装（このままだとエラーバージョン） private Runnable cmd = new Runnable() {      @Override      public void run() {           // Loopが何とかって例外が発生して怒られる。           Toast.makeText(サービスクラス名.this, "text", Toast.LENGTH_SHORT).show();      } } この、Toastの行を以下のように置き換える。 # スレッド内で実行される処理の実装（このままでもエラー起きないバージョン） private Runnable cmd = new Runnable() {      @Override      public void run() {           // handler使うのがミソらしい。           handler.post(showToast);      } } # ToastをRunnableでラップした的な感じ？ private Runnable showToast = new Runnable() {      @Override      public void run() {          Toast.makeText(サービスクラス名.this, "text", Toast.LENGTH_SHORT).show();      } } ＜＜解説（のような自分なりの理解）＞＞ UIスレッドって何？ http://www.office-matsunaga.biz/android/description.php?id=8 UIを司るスレッドを、メインスレッドまたはUIスレッドと言うらしい。 UI＝アクティビティに置き換えてもいいかな。とりあえずは。 回避法：簡単に結論だけまとめてくれてる。 http://blog.fusic.co.jp/archives/704 AndroidのUI（＝アクティビティ）はシングルスレッドで動くらしく、アクティビティに関するスレッドは１つしかないらしい。 サービスは独自のアクティビティを持っていない。 サービスからtoastを表示しようとすると、そのtoastはアクティビティに投げられる。 つまり、アクティビティ（＝UI）に干渉することになる。 アクティビティを実行しているスレッドをスレッド１、サービスを実行中の別スレッドをスレッド２とする。 スレッド２から、toastを投げようとすると、そのtoastはスレッド１に投げられる。 この投げられた瞬間、UIを司るアクティビティは、自身のスレッド１ではない、スレッド２から投げられたtoastを処理しなければいけない。 しかし、Androidのアクティビティは、スレッドは１つしか処理できない仕様のため、スレッド２から投げられたtoastを処理できず、例外を発生させる。 これを回避するための方法として、スレッド２からスレッド１に直接toastを投げるのではなく、投げるtoastはスレッド１で実行されるべき処理だ、と設定してやるとよい。 この設定するためのクラスが Handler と呼ばれるものである。 Handlerは、設定された処理をアクティビティを司るスレッドの処理として追加する。 ※多分、この説明はウソ。 でも、他のサイトとかGoogleのリファレンス見てもよく分からないので、マルチスレッドでUIに干渉するために使うのがHandlerという程度の理解で留めといた方が、今はいいっぽい。 スレッド２でHandlerをnewし、投げたいtoastをpostメソッドで設定する。 すると、スレッド２でtoastをセットされたが、そのtoastはアクティビティを司るスレッド（この場合はスレッド１）で実行するべし、と解釈し、スレッド１でtoastを実行する。 その結果、スレッド間でUIに干渉することがなくなり、別スレッドからtoastによる通知を実現することができる。 Handlerって何？ http://www.adamrocker.com/blog/261/what-is-the-handler-in-android.html あんまちゃんとは読んでないけど、上記のページによると、別スレッドからメインスレッド（＝UIスレッド）に干渉すると、このエラーが起きるようなので、今回の例のようにtoastだけじゃなくっても、別スレッドからUIスレッドのTextViewに文字をsetする場合でも、同じ例が起きそう。   今のへなちょこ理解を絵にしてみた。

↓UIスレッドと同じスレッドでサービスを実行しているため、サービスからToast投げてもうまくいく例

↓UIスレッドとは別スレッドでサービスを実行しているため、toast投げようとするとマルチスレッド扱いになり、エラーになる例