改訂2版 Android SDK逆引きハンドブック/中西葵他

と言う事で、以前読んだ、Androidアプリ開発逆引きレシピに引き続いて、別の逆引き本を読んでみた。

内容的には、ウィジェットやハード寄りかなと言う印象。上記の逆引きレシピは、ソフト寄りだったため、あまりハードに興味のない自分が眺めるとスカスカな印象。
結構分厚いのに網羅性が薄いような気がするのも、上記の理由に加えて、ソースを全文掲載している点があるだろう。全くの初心者なら便利なのかも知れないが、これは冗長。レシピ本の様に、要点だけ数行ソースをのせる方が寧ろわかりやすいだろう。
対応バージョンが記載されているのはヨシ。というか基本だろう。書いてないレシピ本がおかしい。小口もキレイにインデックスしてあり引きやすい。

内容のレベル的には今ひとつで、痒いところに手が届かない。本当に基本の確認用、という感じ。
どちらか選べと言われればレシピ本かな。ただ、ハード系の記述が多いので、2冊並べても無駄という事はないだろう。

さて、アプリ開発の近況だが、絶賛難航中だ。
特にandroid特有の問題に、こってりとやられている。

おかしなバグに悩まされて、検索しても事例がヒットしないし、コードレビューしてもデバッグログ入れまくっても全く原因すら分からず解決しない。コードをいじり回して、悩んで悩んで、結局、エミュレータのバグだったよ、とか。こんなんで1週間は軽く飛ぶ。
逆に、エミュレータでは何のエラーも出ないのに、実機で実行すると謎のエラーを吐いて落ちるとか。こんなんばっかりでどんどん時間が過ぎてゆく。

結構複雑なアプリなので、いくつもワーカースレッドを立ててデータを処理している。すると、単体テストでは問題ないが、組み合わせて実行すると、スレッドの処理タイミングで、エミュレータや実機での実行タイミングがずれておかしな事が起こったりするわけだ。
普通のウィンドウプログラミングなら、メインのプログラムが終了するときには、ワーカー全部インタラプトして落とせば何も問題ないだろう。
が、androidプログラミングでは、Activityが何度も勝手に生成消滅する事を想定しなければならない。たとえば、画面の向きが変わったら消滅→生成が勝手に走るわけだ。
するとこの時、裏でDBゴリゴリいじってたワーカーを一緒に落とさなくてはならない。それだけなら簡単だが、直後の生成時にはワーカーを作り直して、DB作業の続きをさせねばならない。
しかししかし、DB作業のファイナライズ自体、多少時間が掛かる処理なので、さらに別スレッドを立てて、全てのワーカーが落ちたらDBクローズ、みたいな事をさせねばならない。
が、こうして待っている間に、Activityの再生成が突っ走り、DBへアクセスしてくる。作業継続するために新しいワーカーが立ち上がる。しかし平行してDBクローズが走っている。じゃあ、一体、今DBは閉じてるの？開いてるの？という様なトラブルになるわけだ。
動作の重いエミュなら、Activityの再生成に時間が掛かるので、新しいワーカーが出来る前にキチンとDBがクローズされているが、実機は処理が速いので、バッティングしてエラーとなるのだ。

もちろん、私の設計が拙いので、こうしたトラブルが出るわけだが、どうもまだ、androidの奇妙なアーキテクチャに慣れないものだ。
慣れない点：
・Activityの勝手気ままなライフサイクルにキチンと対応しなければならない。メモリリークが怖い。
・Activity間通信では、全てのオブジェクトがコピーになってしまう。データオブジェクト設計が破綻。
・画面が小さい。

しかし、山は越えた感じ。実装待ちが、中山1つに、小山３つ。完成までもう1ヶ月ぐらいだろうか。

中西葵他

改訂2版 Android SDK逆引きハンドブック