2013年8月30日金曜日

Effective Androidを読んでる。

「Effective~」というタイトルから、「デザインを定義するならばThemeを利用し、レイアウトと分離せよ」的な、格言めいた実用系ノウハウが載っているんだろうと思っていたんだけど、1章でいきなりその辺を外部の書籍に投げていて(というより自著の宣伝か)、出オチ感が…。

「すぐに使えるテクニック集」と「その辺に転がってるチュートリアル」と「マニアックな知識」が玉石混交で、ネイティブアプリ開発者もWeb系開発者もデザイナーもごった煮で対象としていて、ノリとしてはAndroid関係者向けの専門誌のような感じの本でした。

以下は、読んでて「う~~ん…」とか、「うおー!」ってなった部分。

DP値を実行時に取得するならば、dimension resourceで名前をつけて取得しよう。

<resources>
    <dimen name="card_padding">8dp</dimen>
</resources>
getResource().getDimension(R.dimen.card_padding);

Androidはレイアウトとスタイルとコードを分離できるとはいえ、コード上でdpとpx間の相互変換を行うこともよくある。ユーティリティメソッドを用意してもいいけれど、dimension resourceを使用し、dp値に名前をつけて管理した方がソースの可読性も高く保つことができる。

dimension resourceとリソースのバージョン分岐を組み合わせると、端末のフラグメンテーション対策にも応用できる。dimension resourceはもっと普及されるべきだと思うんだけど、なぜかプッシュする人が少ない印象…。何かトラップでもあるのだろうか。

AndroidでレイアウトをするならMetrics and Gridsは読もう。

最近Illustratorなども触っているので、3章のデザイナー視点で使いやすいpxなどを述べたお話は、面白い視点を提供してくれたのだけど、もうちょっと掘り下げて欲しいなという部分もあった。

  • 現実としてAndroidの案件の多くは、iOSとのマルチや移植であり、UITableViewCellが44ポイントな限り、3で割れない素材との戦いは終わらない。44ポイント(44px&88px)の素材に対してどう対抗すればいいのか?
  • さらにtvdpi(というかNexus 7)の登場せいで3の倍数で用意すれば万事解決、というほど単純でなくなってしまった。
  • dpに対してspが存在する説明がゼロだけど、spはユーザーがフォントサイズに対する多少の自由度を得るためのものだから、pt固定値素材を用意してしまうのは、ユーザービリティの低下に繋がるデメリットがあることも説明すべきでは。
  • iOSのユーザーインターフェースガイドラインほど厳密ではないものの、Androidにも類似したデザインガイドラインは提供されている。特にMetrics and Gridsは全ての開発者が読むべき。48dpのリズム、8dpの「mind the gap」(この言葉遊びのセンスが素晴らしい)は知っていて当然であって欲しい。

The AndroidManifest.xml Fileに一度は目を通そう

章が進むごとに内容が濃くなっていって、5章辺りからすごく面白くなる。

ただ、「AndroidManifestを活用しよう」というタイトルとは裏腹に、マニアックすぎて実用的か疑問符をつけたくなるような、AndroidManifest.xmlのマイナー設定の解説記事なのがもったいない。

著者的にはリファレンスに書いてあるからそれを読めば分かるでしょ?ってことなのかもしれないけど、現実的にはclearTaskOnLaunchとかnoHistoryとかの存在を知らずに、コード上で実装してるのをちらほらみたことがある。

実際、リファレンスは長い上に意味が通じない箇所もちらほらあるし、真面目に読むと非常に疲れるからね。

それでも、一度でいいからThe AndroidManifest.xml Fileを通して見るべきだと思う。

流し読みで「こんな設定があったのかー」と知るだけでも十分。それだけでもAndroidの可能性が広がったように感じる。まあ錯覚で終わると思うけど。

Eclipseの設定ファイルが何をやっているのか理解しよう

6章ではEclipseの設定ファイルに関する解説を行っているのだけど、これは必見だと思う。

Androidのプロジェクトをバージョン管理して、多人数で開発する方法論として、自分レベルのヌルい知識で語ると、
  • Eclipse関連のファイルをcommitせず、pullした純粋なAndroidコードをExisting Android Code Into Workspaceでインポートする
  • .projectや.classpathもバージョン管理の対象とした上で、eclipse import existing projects into workspaceでインポートする
の二通りが思いつく。

前者はpureなAndroidコードのみをバージョン管理の対象とするため美しく思えるけど、この方法はまずプロジェクトの規模が大きくなるとまず破綻する。

複数のプロジェクトが絡んで、class pathが入り乱れているような場合、Eclipseの設定ファイルが何をやっているのか理解していないと、自力でビルドパスを解決できずにハマったりするからだ。

幸いなことにEclipseの設定ファイルは人間にも読みやすい形式となっていて、マージツールで差分を取ることで原因追及することはできた。この記事にもう少し早く出会えていれば…。

gcm.jarはdeprecatedなので、Google Play Service APIを使いましょう

11章の内容はやや古い(7月ごろにGoogle Cloud Messaging APIの一部刷新があったのですが、反映されていない)ため、公式のものを読んだ方がいいです。有志の方による日本語翻訳も最新仕様には対応してません。

また用語も公式に定義されているものと対応していない(Registration IDをIDと大雑把に扱ったり、Sender IDをproductIDと呼称するなど)ので、技術書としても微妙な内容と思います。

結論.Theme ResourceとかFragmentの活用とかそういう話がもっと欲しかった

Android開発者の標準レベルって、流行り始めた2.3とかで止まってるような気がする。

巷には基本中の基本しか触れていない入門書が多いし、面白い本も何冊か知ってはいるけれど、進化スピードの速いモバイルの世界ではすぐに陳腐化してしまう。「先」を目指すとなると、英語の公式ドキュメントを読み漁るしかない。

「Effective~」系書籍は小手先のテクニックじゃなくて、フレームワークを十全に引き出すエッセイ集のようなイメージがあって、しかも同人というスピード感が加われば、「先」を切り拓いてくれるんじゃないかという期待があった。まあ勝手にイメージを押し付けてるだけなんだけど。

例えば、Activityと密結合を回避するための様々なテクニック、モデルクラスを作成することでActivity非依存のテストコードを書けるようにするとか、AsyncTaskをAsyncTaskLoaderにリプレースするとか、AlertDialogよりもDialogFragmentを好むべきだとか、それで全て上手くいくわけではなく、メリットもあれば落とし穴もある…。

…そういうノウハウが載っているのかな~と期待して買ったので、満足はできなかったけど、一部のマニアックな話については面白かった。増補改定にも期待。

0 件のコメント:

コメントを投稿