Android Media Query サイズ再考

　先週、Android バージョンのアプリがリリースする予定でしたが、横向きを追加すべきとの観点が顧客から出てきました。phone サイズだと、横向きがの高さが本当に小さいから、それに加えて私たちのアプリにヘッダとフッターがあるから、いっそう立て幅が小さくなります。。。
　ただ、ユーザがより多くのコンテンツを読みたいことが予想できますので、今月中のリリースに向けて、着々アプリの修正が進んでいます。その中に、私メインで作った天気ページは縦方向しか対応してないため、横になると、字がかぶったり、位置がずれたりしています。対応が必要です。
　私たちの Phone サイズテスト機は Nexus 5となっています。実際使って見ると、なんと、WebView の横幅は 800 px もあります。。。一般的な Tablet は 1024 となっていますが、接近していますね。。。何とも言えないけど。。。
　それで、480px 以下だと、phone レイアウトを表示するとか、下記の一般的な表があります。
    Phone width =< 480px,   Tablet 480px < width =< 1024px,  Desktop > 1024px
　iPhone 5や、Nexus 5がリリースされると、上記のサイズは実際とあわないことになりました。
　それで、多分上記の分け方に問題があるような気がしています。なぜなら、Android ではタブレットのサイズが違いすぎるためです。今まで見たアンドロイドタブレットの中に、1024x360 のものもあります。縦になると、実は Phone と変わらない横幅です。
　多分、これから開発するとき、Responsive デザインを実装する時、Phone サイズなどの分類を考えずに、直接デバイスのサイズを考えたほうが良さそうです。
　まず、>= 1024px、これは大きいサイズのタブレットとデスクトップ。
　次 < 1024px、これは普通のタブレットサイズ。
　さらに、< 480px、これは小さいデバイス。
　これで、まず全部の要素をできるだけパーセンティジで定義して、全部の要素をブラウザリサイズするとき、隠さないようにします。次、画面のサイズにあわせて、Media Query を使って、個別要素のサイズを調整します。
　注意点としては、位置が Absolute の要素に対して、たまに他の要素とかぶったりします。どの親と一緒かをはっきり設定しなければなりません。BEM、スマックスなどの Methodologies を参考にすれば、面白いでしょう。
　もし、CSS では難しいであれば、背景画像を使いましょう。小さい画像なら、base64 でエンコードして、CSS に入れれば、余計な HTTP Request なしで済むから、便利でしょう。
　ほんの小さい考えですが、デザイナにインプットして、使いやすいアプリになりますように。
　それでは。

HTML5 要素構造 Design

　今まで、結構 HTML5 ページを書きましたけど、レイアウトを実現ために、どのような要素 (tag) を使うかとか、親 div に入れるかとか、結構ややこしいです。最近の考えをここでメモして、将来また best practice として、後輩に伝えよう。
　HTML 4 から、HTML 5になって、一ついいことは Web page 構造と意味が明確になります。例えば、以前何でもかんでも div を使うところ、今は article, section などで情報の構造により、適切にタグが定義してくれました。ただ、 Gmail などのページを開くと、驚きほど数の div タグが結構使われています。実際自分は Sigle page web app を使うとき、いざ何かを実現したい場合、まず親 div 要素を定義します。これはもう解決できないような気がしていますが、それ以下の子要素、孫要素の構造はもっとエレガントに書かないと、将来のメンテナンスや拡張が難しくなると思います。
　実際の考え方として、データの構造を理解した上で、それにあわせて、要素を決めようと。その後、CSS3 で位置を調整したり、z-index を使ったり、web app を完成します。それで、HTML を読むとき、実際のデータとあっているし、レイアウト変更する場合、例えば responsive デザインを導入する際に、新しい css を書けば済むでしょう。
・まず、Array に定義しているすべての複雑なデータアイテムをページにリストする場合。
　ul > li を使った方がいいと思います。inline 要素、block 要素でも全部 li に入れられますし、親子関係も見ればすぐわかります。もし全部 div を使う場合、class に一つ共通的なものを振りましょう。なぜなら、jQuery 一つで、または native js 一つで、すべて同類のものが取れるからです。そうすると、動画や、文字を大きくするとか簡単になります。
・次、数字などのデータをページに表示したい場合。
　table を使いましょう。以前なら、（IE 6 ぐらいの時代？）ページ全体を一つの table のおさめて、レイアウトを調整しましたが、現在では、それは bad practice の一つになっています。 table は数字など、ものを比べるとき使うべきです。例えば、月ずつの返済額とか、エリアの対象一覧とか、同類データは table に入れると、わかりやすいし、js で tr td 文字列を簡単に作れます。
・文章や説明など article と section, p, span を使いましょう。
　例えば、不動産の説明文書など、実際見れば、一つの article です。このようなタグを使うことで、 HTML 読みやすいなります。もう一つの例として、dt dd pair で使うことで、定義、説明であることはすぐ気づきます。

つまり、実際のデータ構造にあわせて、タグを使うことで、HTML がわかりやすくなります。
ただ、例外も結構あります。例えば、drop down の select に対して、特別なスタイルを使いたい場合、jQuery ui では新しい div , a , ul li を動的に作成して、select の上にカバーする形になっています。実際の a タグの意味はあってないけど、構造としてはこれもわかりやすいです。後日また整理します。

それでは。

初めて、サムソン gear smart watch を触った

　今日、いろいろ悩んでいる間、同僚から AJAX の質問が来ました。それはサムソン Gear Smartwatch で動く widget の UI についてでした。
　ちょっと意外なのは widget はほぼ JS + HTML5 + CSS3 で開発することでした。Tizen という開発環境の中で、index.html や Lib などがありました。ちなみに、widget 内部では jQuery を使っているらしいですが、外部には公開されてなくて、自分で jQuery Lib を html ファイルに include する必要です。Tizen は Eclipse をベースにしているので、ちょっと使いにくいけど。。。
　後、サンプルはそれほどあって、何かアプリを作るとき、それをシードとして使えます。まぁ、ほとんどは JS コードですが。

　最初の感想は iPod nano みたいです。使いにくい、使いやすいより、同僚はおもちゃとしてはそこそこ面白いらしいです。

　本題に戻ります。内部のシステムは Andoroid らしくて、動くアプリは Webview で実行されて、後親機が必要で、いつも通信しているそうです。彼は天気情報などネットで取得できるのに、何で Widget では動かないかと。。。
　実際 Debug ボタンを押したら、Chrome の Web Inspector が起動され、要素や、JS などは Debug できます。画面が小さい以外、あまり感想がないです。
　調べてみたら、Widget では Web と通信するために、サービスを作る必要があります。まぁ、予想とおりですけど。 Android はデフォルトで Web をアクセス機能を有効するわけがないから。
　あまり深くどのようにサービスを作るかを調べてないけど。一応、原因が見つかりました。実際 XMLHttpRequest を発行すると、Debug モードでアプリが異常終了します。Release モードでは何も起きない。。。ちょっとわかりにくいです。
　
　一ついいことはまた JS の面白さを同僚に伝わったそうです。：）
　それでは。将来は本当の Watch を使いたいですけどね。

Android WebView 謎。。。

　最近、HTML5 Ads ページのバグが報告されました：Android の WebView で全ページ表示できない。。。
　本来なら、スクロールバーが表示されるので、問題がないでしょうと思っていました。ただ、営業の方達はぜひ全ページを表示できるようにと。
　以前は JS で設定し直す手段で Ads を正しく表示できるようにしましたが、原因がわからなくて、未だに調査中です。。。また今回のバグが出てきました。。。　orz
　ただ、iOS では Ads の表示が正しいと。多分 Android は Webkit をベースにしていますが、 WebView の実装が iOS と比べると、まだまだ W3C の標準になってないでしょう。また、各要素のデフォルト margin, padding がブラウザの設定が違うでしょう。
　そうすると、iOS では正しく表示できているので、 Android の開発者に依頼して、WebView の設定を調べてみようと。２０分で、setInitialScale(1) をコメントアウトしたら、iOS と同様に表示できたとの連絡が来ました。。。
　一応 Ads ページの中に、viewport がちゃんと設定しているし、なぜ setInitialScale をもう一度呼び出すか、デフォルト値はなにになっているか、ページ中の Viewport ではだめですかとかいろいろ質問がありましたけど。今週中に Android バージョンが公開されますので、後回しにしました。
　自分は設定する必要がないと思いました。後日、詳細を調べてみよう。

　また、アンドロイドディバイスのサイズが本当にいろいろあって、media query で Responsive レイアウトをスタイリングする時、実際のディバイスが確認するようと。たまにはシミュレータとディバイスとブラウザリサイズの表示が異なります。実機で確認するのは不可欠です。
　
　早めにリリースできるように。：）
　それでは。

アンドロイドの WebView CSS Refresh問題 <= JSで再度設定し直す。原因調査中。。。

　ニュージーランドに旅行に行きました。：）しばらく更新してないから、いろんなものを忘れないうちに、メモしておこう。
　今日アンドロイド Phone サイズの対応作業がありました。基本的に Media Query を使いますが、たまには HTML の書き方に疑問を持つようになりました。なぜなら、最初 Web Page を作るとき、Tablet を想定してから、Phone サイズになると、文字のサイズや、本来なら絶対２行にならないところが切れたりして、ちょっと対応しにくかったです。幸いコンセプトが違うから、矢印などいらない部分を全部隠して、２時間で作業をほぼ完了しました。
　ただ、 広告ページを対応するとき、iPhone では綺麗に表示できたのに、アンドロイドでどうしてもうまくいかないことがありました。CSS で写真の高さを 100% 設定しても、スクロールバーが出るし、押してしばらくすると、スクロールバーが動けるようになりました。原因はわからない。。。
　基本的にアンドロイドとiPhone は WebKit をベースにしているから、表示も同じのはずですが。まぁ、基本的にデフォルトのスタイルがちょっと違ったりしていますけど。意外にアンドロイドの WebView 使いにくいなと感じました。
　それで、setTimeout を使って、ある程度遅延を入れて、再度 CSS を設定し直したら、うまく行きました。
　Android 4.4 Chrome での表示は正しいですけど。。。
　何でだろうね。明日時間があったら、見てみよう。。。