2017年3月22日水曜日

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

2017年3月21日火曜日

PreferenceFragment

1 年以上ぶりくらいに本格的な Android プログラミングに回帰。そのせいか、固定観念から多少自由になったかもしれない。

例えば、PreferenceFragment。古い PreferenceActivity が obsolete になって、代わりに PreferenceFragment を使うように公式リファレンスに書かれている。それで、ネット上の情報をいくつか見ても、受け売りの解説ばかりなものだから、皆が自前の MyPreferenceActivity 的なるものを用意して、その中で PreferenceFragment を実装するような感じにしてる。

そこで今回、「そもそも、MainActivity で直接 PreferenceFragment を使っちゃいけない理由なんてあるのかい」と思って、やってみたら──できた!

今までの MyPreferenceActivity をわざわざ専用に用意して PreferenceFragment を使うやり方って、何だったのだろうか……。

受け売り情報撒き散らすのやめて欲しい。

いや、まあ、ブログなんだから、本来は各人の私的なメモという性格のものではあるんだろうけど。

2017年3月20日月曜日

2017年3月15日水曜日

カードのポートフォリオ

AMEX と Yahoo! JAPAN (MasterCard) をリストラしたので、ここいらでまたカードポートフォリオの現状を整理:

  • VIEW Suica (MasterCard) → Suica
  • 楽天 (JCB) → nanaco
  • ファミマT (JCB) → LINE Pay (JCB)
  • d GOLD (MasterCard) → iD
  • JACCS 横浜インビテーション (VISA)
  • MUFG VISA デビット (VISA) ※近日中に解約予定

依然、電子マネーに特化した陣容となっているのがわかりますね。

AMEX 解約

結局こうなりました……

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

Android の前方互換

2017-03-06 時点での Dashboards によると、Android のバージョン別シェアはこんな具合だった。

これならもはや、Jelly Bean (API16〜18) は切り捨てて問題ない。KitKat (API19) すら、戦略的な切り捨ての対象となる時期に入ったと言える。

Lollipop 以降を前提として開発すると、使える API 的に随分とコードをすっきりされられると思う。

2017年3月12日日曜日

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

結局、「オブジェクト指向プログラミング(OOP)」というのは、1) 手続指向は構造化で、2) データは構造体で、ということであり、この両者を、3) 構造化された手続(メソッド)を、構造体(オブジェクト)単位で整理することでまとめた、というだけの話であり、これ以上でもないし、これ以下でもないのではないかと思う。


手続自体は、あくまでも構造化プログラミング的な観点で整理を行なうべきで、これを生半可なオブジェクト指向的観点で整理すると、コードが無茶苦茶になって却って“百害あって一利なし”といっても言い過ぎにはならない気がする。少なくとも、自分の場合はそうである。

そうやって、構造化プログラミング的にすっきりと整えられた個々のコードが、集合して複数のコード群としてそのままそこいらにぶちまけられている時に、手続指向の限界が急にクローズアップされてくる。

この時に整理整頓の“容れ物”として俄かに脚光を浴びることになるのが、構造体(オブジェクト)である。手続のためのコードをそのまま“裸”でそこいらにぶちまけては置かないようにしよう、必ず、構造体に入れられた(カプセル化)状態で置いておくことにしようね、というのが僕流のオブジェクト指向像である。


上のことをちゃんと自覚していないで、「オブジェクト指向スゲー」で何でもかんでもオブジェクト指向のノリを持ち込もうとすると、むしろコードの見通しが悪くなって、あっちへ飛んだり、こっちへ飛んだりと、ダイクストラ先生が「goto は使わないようにしよう」といった時代の事情に逆戻りして、あっちのメソッドこっちのメソッドを飛び回るような、いわば「goto なきスパゲッティ化プログラミング」に陥ってしまう。

新しいコードをスクラッチで組んでいく時、ここは手続指向で素直に、一つ一つの処理を継ぎ足して行ってプログラミングするのが、やはり王道なのではないかと思う。そしてそのコードが伸びるにつれ、(2回以上)多用される同様の処理は、サブルーチンとして分離する。そのことで、「コードをコピー&ペーストして使い回すことを避ける」というのが、構造化プログラミングの単純かつ肝となる原点だと思う。ある処理に関するコードが記述される場所を一元化することで、後に変更の必要が生じた時に、あちこちを修正して回るというようなことは避けないと、例えば、一部を修正し、一部は修正し漏らしていたりした場合に、バグを生む。

まずは、メインルーチンという一本道のコードに立ち戻って、そこから構造化的にサブルーチンを分離するという作業に立ち返るのが重要である。構造化の後、構造体の容れ物に構造化された手続ルーチンを収納するところまで終ったとする。次に、類似の別のクラスを作成する場面になり、既に完成されたクラスを意識して内部の一部の処理をいじって済ませようとするのだが、不思議なことに大概が上手くいかないのである。仕方がないので、オブジェクトというカプセル化されたシャーシ(筐体)をひっぺがして、手続指向的に一本道的な処理から一つ一つを確認して組み直していくと、面倒な作業のようでいて、不思議とスーッと進められていく。一つ一つ新しい処理を継ぎ足していくだけなのだから、「どこに問題があるのだろうか?」と悩んで、四苦八苦する苦労がないのである。

つまり、オブジェクト指向という、カプセル化作業は、あくまでも、内部処理が完成してから行なうべきであって、内部処理のコーディング作業が終ってない段階から、カプセル化の部分を並行して、混ぜて、作業を行ってはいけないのである。


この手続指向部分で作業を行なう段階と、オブジェクト指向で作業を行なう段階との間には、厳然たる断絶があって、互いの領分と先後の序列はキッチリと守られるべきであると思うのだ。例えば、同じ「食べ物」に関する産業でも、農業の分野と、外食産業の分野で、全く人材人種が別個であるというような、そのくらいの世界の違いが。農家の人に、「このレンコンは、洗ってお客様に出すから、最初から泥が付かない状態で育てておいて!」などと要求する料理長がいたら、レンコンが育つのだろうか? と。農家の人は作物を見てるし、料理人はお客さんを見ている。それぞれの立場によって、最適な視点というものが違う。世界に単一の視点(パラダイム)を押し付けようという発想こそが邪悪な根性なのだ。