はてなブックマーク

前回の日記で「ContextはApplicationを渡すのが基本（ドヤァ」なんてことを書いたが、それはちょっと言い過ぎで、やはり状況に応じたContextインスタンスを持つべきではある。 つまり、Applicationじゃ困ることもあるということだ。 例えば、三大Contextインスタンス（Activity、Service、Application…の3つと言えるだろう）の中でDialogを起動できるのはActivityだけである。DialogはWindowManagerやらを呼ぶためにコンストラクタでContextを要求する仕様になっているが、そこにServiceインスタンスを代入しても例外吐いて落ちるし、Applicationでもダメである。 正直この仕様は納得がいかない。Dialogを起動出来るのがActivityならば最初から引数型をActivityクラスにするべきではないのか？　

Android開発では、Context型のオブジェクトを使い回すことがやたら多い。 問題はActivity（もしくはService）の中で利用できるContext型のオブジェクトはActivity（Service）のインスタンス自身と、getApplicationContext() で取得できるApplicationのインスタンスの二種類があるということだ。 // 例えばActivity内でトーストを表示するとき、以下2通りのContextを渡せる。 Toast.makeText(this, "Activity", Toast.LENGTH_SHORT).show(); Toast.makeText(getApplicationContext(), "Application", Toast.LENGTH_SHORT).show(); このあたりについては各所でまとめられている。例えばこちら

前回の日記で「ContextはApplicationを渡すのが基本（ドヤァ」なんてことを書いたが、それはちょっと言い過ぎで、やはり状況に応じたContextインスタンスを持つべきではある。 つまり、Applicationじゃ困ることもあるということだ。 例えば、三大Contextインスタンス（Activity、Service、Application…の3つと言えるだろう）の中でDialogを起動できるのはActivityだけである。DialogはWindowManagerやらを呼ぶためにコンストラクタでContextを要求する仕様になっているが、そこにServiceインスタンスを代入しても例外吐いて落ちるし、Applicationでもダメである。 正直この仕様は納得がいかない。Dialogを起動出来るのがActivityならば最初から引数型をActivityクラスにするべきではないのか？　

また唐突だがAndroidアプリ開発の記事を書く。 アプリのユーザビリティを考えると、マルチスレッド処理は必須だ。 Android SDKでマルチスレッド処理を書く場合、いろいろな方法がある。どんな方法があるかはググってもらった方が早いだろう。一応、一通り便利に処理するための枠組みは用意されている。まぁ、「スレッドの存在は意識してもらうけど管理はライブラリに任せてくれたまえ」くらいな感じ。いいところだと思う。 別スレッド処理が必要な典型例としては「バックグラウンドで重い処理」と「周期的な処理」が考えられる。 AndroidではUIコンポーネント（画面上のボタンなど）はメインスレッド（UIスレッド）からしかアクセスできないという仕様があるので、別スレッドからUIコンポーネントを操作するにはUIスレッドとスレッド間通信みたいなことをする必要が出てくる。例えば、「バックグラウンドで重いファイルを