投稿

3月, 2017の投稿を表示しています

Handler(mainLooper).post() を使うやり方と、runOnUithread() を使うやり方の違い

基本的に runOnUiThread() は Handler(mainLooper).post() へのラッパーとして用意されているが、メイン UI スレッドから実行する場合は挙動が異なる。メイン UI スレッドから実行した場合は、Handler(mainLooper).post() されずにスルーされて、そのまま Runnable の内容を実行する扱いとなる。なので、View の再描画など、強制的にタスクを発生させたいがために Handler(mainLooper).post() したい場合に、メイン UI から runOnUiThread() を使っても無意味なので、この場合は明示的に Handler(mainLooper).post() を記述して実行する必要がある。cf. runOnUiThread vs Looper.getMainLooper().post in Android

PreferenceFragment

1 年以上ぶりくらいに本格的な Android プログラミングに回帰。そのせいか、固定観念から多少自由になったかもしれない。例えば、PreferenceFragment。古い PreferenceActivity が obsolete になって、代わりに PreferenceFragment を使うように公式リファレンスに書かれている。それで、ネット上の情報をいくつか見ても、受け売りの解説ばかりなものだから、皆が自前の MyPreferenceActivity 的なるものを用意して、その中で PreferenceFragment を実装するような感じにしてる。そこで今回、「そもそも、MainActivity で直接 PreferenceFragment を使っちゃいけない理由なんてあるのかい」と思って、やってみたら──できた!今までの MyPreferenceActivity をわざわざ専用に用意して PreferenceFragment を使うやり方って、何だったのだろうか……。受け売り情報撒き散らすのやめて欲しい。いや、まあ、ブログなんだから、本来は各人の私的なメモという性格のものではあるんだろうけど。

Yahoo! JAPAN カード(JCB)

イメージ
Mastercard のものは先日、解約したわけですが、JCB で改めて出直ししました。

AMEX 解約

イメージ
結局こうなりました…… YJ カード同様、手元にカードを用意すれば、電話の自動音声のみで解約手続を完結させることが可能でした。

プログラミング・パラダイム

結局、「オブジェクト指向プログラミング(OOP)」というのは、1) 手続指向は構造化で、2) データは構造体で、ということであり、この両者を、3) 構造化された手続(メソッド)を、構造体(オブジェクト)単位で整理することでまとめた、というだけの話であり、これ以上でもないし、これ以下でもないのではないかと思う。手続自体は、あくまでも構造化プログラミング的な観点で整理を行なうべきで、これを生半可なオブジェクト指向的観点で整理すると、コードが無茶苦茶になって却って“百害あって一利なし”といっても言い過ぎにはならない気がする。少なくとも、自分の場合はそうである。そうやって、構造化プログラミング的にすっきりと整えられた個々のコードが、集合して複数のコード群としてそのままそこいらにぶちまけられている時に、手続指向の限界が急にクローズアップされてくる。この時に整理整頓の“容れ物”として俄かに脚光を浴びることになるのが、構造体(オブジェクト)である。手続のためのコードをそのまま“裸”でそこいらにぶちまけては置かないようにしよう、必ず、構造体に入れられた(カプセル化)状態で置いておくことにしようね、というのが僕流のオブジェクト指向像である。上のことをちゃんと自覚していないで、「オブジェクト指向スゲー」で何でもかんでもオブジェクト指向のノリを持ち込もうとすると、むしろコードの見通しが悪くなって、あっちへ飛んだり、こっちへ飛んだりと、ダイクストラ先生が「goto は使わないようにしよう」といった時代の事情に逆戻りして、あっちのメソッドこっちのメソッドを飛び回るような、いわば「goto なきスパゲッティ化プログラミング」に陥ってしまう。新しいコードをスクラッチで組んでいく時、ここは手続指向で素直に、一つ一つの処理を継ぎ足して行ってプログラミングするのが、やはり王道なのではないかと思う。そしてそのコードが伸びるにつれ、(2回以上)多用される同様の処理は、サブルーチンとして分離する。そのことで、「コードをコピー&ペーストして使い回すことを避ける」というのが、構造化プログラミングの単純かつ肝となる原点だと思う。ある処理に関するコードが記述される場所を一元化することで、後に変更の必要が生じた時に、あちこちを修正して回るというようなことは避けないと、例えば、一部を修正し、一部は修正し漏らしていたり…