AndroidでSQLite
多くの皆さんと同じように、僕もAndroidでSQLiteを使用する際にContextって？？？となった。
ちょっとここでの躓きは痛そうなので、納得いけるよう調べた軌跡を残しておこうと。
勝手に人様のブログや、developersサイトから引用してます。
まずはAndroid-Developersを読む
http://developer.android.com/intl/ja/reference/android/content/Context.html
Class Overview
Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
・アプリケーション全体の環境に関するインターフェイス
・activities, broadcasting and receiving intentsなどの他のアプリからの応答を行える。アンドロイド特有のリソース、クラスにアクセスすることも出来る。
と解釈できる？
？？？よくわからん。
「整理できない底辺プログラマのメモブログ : Contextとは？」http://individualmemo.blog104.fc2.com/blog-entry-41.htmlを見させてもらいつつ、http://magpad.jugem.jp/?eid=197 の秀逸な図を見ると、だいぶ意味はわかってくる。
C/C++で作る画面系のアプリもまあこういう親(this)を渡すのはよくある事だね。
であとは「this」と「getApplicationContext ()」と言うのがあるらしい。
>要するに、 Application Contextはアプリケーションに関連していて、アプリケーションのライフサイクルに関わらず同じContextオブジェ>クトとなっていること。それに反して、Activity ContextはActivityに関連していて、Activityが破棄される時(画面が回転するなどといったときに簡単に破棄される）、Contextオブジェクトも同様に何度でも破棄されて何度でも作られる。ということだろうか。
(整理できない底辺プログラマのメモブログ : Contextとは？より引用)
これについては、メモリリークの話はあるようだが基本的にはActivityベースのライフサイクルの方が扱いやすいのではないのでしょうか？
Application Contextはアプリケーションに関連しているので、生存時間が長すぎるというか、必要な時に必要なContextが使えば良いのでは？と個人的には思うのですが、実証してないので現時点はまだ何ともいえないです。
気になったので、再度developersを見てみると
public abstract Context getApplicationContext ()
Since: API Level 1Return the context of the single, global Application object of the current process. This generally should only be used if you need a Context whose lifecycle is separate from the current context, that is tied to the lifetime of the process rather than the current component.
Consider for example how this interacts with registerReceiver(BroadcastReceiver, IntentFilter):
If used from an Activity context, the receiver is being registered within that activity. This means that you are expected to unregister before the activity is done being destroyed; in fact if you do not do so, the framework will clean up your leaked registration as it removes the activity and log an error. Thus, if you use the Activity context to register a receiver that is static (global to the process, not associated with an Activity instance) then that registration will be removed on you at whatever point the activity you used is destroyed.
If used from the Context returned here, the receiver is being registered with the global state associated with your application. Thus it will never be unregistered for you. This is necessary if the receiver is associated with static data, not a particular component. However using the ApplicationContext elsewhere can easily lead to serious leaks if you forget to unregister, unbind, etc.
ビシッとくる訳があったので、引用させて頂いて(http://d.hatena.ne.jp/IchiRoku/20101230/1293717201)
■Activity Contextを使った場合
レシーバはアクティビティと共にレジスターされる。これはアクティビティが破棄される前にアンレジストされることを期待していることを意味する。実際にあなたがアンレジストしなければ、フレームワークがクリーンナップするよ。ついでにエラーもログに残してくれる。
■Application Contextを使った場合
レシーバはアプリケーションと関連付けされたグローバルな状態と共に登録される。だからアンレジスターはされないよ。Application Contextはスタティックなデータと関連付けを行う際に必要になる、特定のコンポーネントではなくてね。ただし、もしアンレジストを忘れると、簡単にメモリリークしちゃうから注意しよう。
と言う事なので、やっぱり使い分けが必要なのかな？ちょっと今後使いながら実証してみよう。
