mixiアプリ スマートフォン版でできるコトできないコト

iPhone用のWeb制作は、すばらしき諸先輩方のブログなどがあるので、こちらではmixiアプリ スマートフォン版について言及していきます。（もちろんちょいちょい他TIPSも出しますが）

今回はmixiアプリ スマートフォン版において、技術的に「こういうコトができる／できない（やらない）」ことを見ていきます。

できるコト

基本的には後述の「できないコト」以外は、ほとんど制限を受けません。が、「なんだこれ？」とハマって解決できたコトはありました。

ページ遷移時にページトップへ移動する

これは結構ハマる方多そう。mixiアプリ スマートフォン版が、という限定ではありません。iframeで読み込んでいるコンテンツ全てに起こります。
iframe内でページ遷移をすると、スクロール位置は保持したまま次のページを表示してしまいます。この仕様、わけわからん。。

解決方法は簡単、リンク先の末尾に「#」を付けてください。

index.html#

それによりウインドウがアプリの上端に移動した状態で遷移します。
また、副作用ですが「アプリの上端」なのでmixiのヘッダーも表示されません。ブラウザの表示領域を全てアプリで埋めることができます。これはうれしい誤算。
本来ならばmixiの広告が表示されないこの方法はmixiからお叱りを受けそうですが、現状表題のスクロール位置の問題を解決する術が無いためか、注意はうけていません。
（※今後もこの方法を使い続けられることを保証するものではありません）

formでpostする場合もactionのurlの末尾に「#」を付けてあげれば大丈夫なはず。

やらないコト

アプリアイコンの設定【iPhone】

iPhoneではWebページでもブックマークをホームに保存したときのため、アプリアイコンを設定ができます。

↑こんな感じ。

しかしコレ、mixiアプリ スマートフォン版では意味がありません。

mixiアプリ スマートフォン版はiframe内でアプリ用のhtmlを呼び出す仕様のため、あくまでアプリのurlはmixiの親フレームのモノになります。

mixi Touchでは

http://img.mixi.jp/img/smartphone/touch/favicon/x001_prec.png

がアプリアイコンとして指定されているため、アプリをプレイ中に「ホーム画面に追加」を教えてもmixiのアイコンが適用されてしまいます。

それならばわざわざアイコンを作る必要も無さそうですね。mixiが気をきかせて、アプリ側でアプリアイコンが設定されているとそちらを優先するとかしてくれるといいんですが。。

※若干蛇足になりますが、ホーム画面アイコンとして登録できるのは半角14文字までとなります。mixiアプリスマートフォン版の場合は「[mixi] xxxx」（xxxxはアプリ名）となり、既に7文字がmixiのタイトルで占められています。となるとアプリ名に許された文字数は半角7文字。

更にホームに登録した段階で、11文字以上のアプリ名は勝手に短縮されるため、実質的には半角4文字分しかアプリ名に許された文字数はありません。

これに合わせてアプリ名を付けるのは潔く諦めたほうが良さそうです。

また、ホームアイコンと同様の理由で、フルスクリーンモード／起動画面／ステータスバーの色変更などの記述もしても意味はありません。
もしかしたら将来的にmixiでアプリ側の情報を取得してmetaタグをアプリごとに書き換える、などの対応があるかもしれませんが、現状では意味なしということで。

横にしたとき（ランドスケープモード）のレイアウト対応

こちらは先日のエントリーでも触れましたが、mixiのヘッダーの領域と、デフォルトのステータスバーなどのおかげで、ファーストビューが以上に狭くなっています。
そのため「ランドスケープモードの時は2カラムに」などのステキ仕様も正直活かされない様に思います。その手間はまだRetina Displayなどの高解像度などの対応に回したほうがよさそうです。

絵文字の表示

iPhoneの絵文字は、実はメールだけでなくWebでも表示することが可能です。（formへの入力はできません）
しかしあくまでそれは「iPhone用の絵文字」を表示するだけなため、Androidでは表示できません。
弊社では既にモバイル用絵文字をPCで表示する変換エンジンを持っているため、スマートフォン版では画像に変換して表示しています。
Android対応アプリとするならば、絵文字は使わない方が無難です。

できないコト

親フレーム（mixi）側のJavaScriptでの情報取得

別にmixiアプリ スマートフォン版に限った話では無いのですが、「iframeの中に別ドメインのページを読み込む」場合このような制限が生まれます。

parent.document.xxx

などの記述で同ドメインであれば、jsで取得できるほとんどの情報を取得できるのですが、別ドメインの場合はセキュリティの関係所全て不可です。
こういう制限があるからこそ、もちろんmixiもこの方法を採用しているのかと思いますが、これにより困ったことを上げてみます。

• スクロールした座標を取得できない
  

これで何が困るかというと、現在のコンテンツの座標を取得できないため、スクロールに追従するオブジェクトを配置できません。
例えばmixi Touchで表示される右図の「ホーム画面に追加しよう！」のようなものです。
cssの [ position:fixed ] が使えれば困らないという考えもありますが、mixiアプリ スマートフォン版ではiframeの高さをそのコンテンツの高さに自動調整します。つまりiframeの中の要素は読み込まれた時点で上からしたまで全て読み込まれた扱いとなり、そのコンテンツではスクロールが一切発生しないということになります。
また、そもそもiPhone版Safariでは仕様上それも使えないため意味がないんですが。。

他にも裏側でのシステム的な制限はちょいちょいあるのですが、とりあえず表面的なものはこんなものかと。
また何か発生したら追記していきます。

FlashでのiPhoneアプリ開発が、ソーシャルアプリに与える影響について

mixi meetup 2010で盛り上がった9/10、アメリカ西海岸でとんでもないニュースが発表されていましたね。

• アップルが iOS 開発者規約を変更、開発ツール制限を緩和。審査ガイドラインも公開
• iPhoneアプリ審査での111の禁止項目（意訳）
• Appleが発表したApp Storeの審査ガイドラインについて知っておくべき点

Adobeさんにお怒りだったはずジョブズ閣下が、「Objectev-C以外でも開発してもいいよん、別にー」と言ったものだからさぁ大変。AdobeはPackager for iPhoneの開発を再開し、Adobeの株価は12.1%も上がったり大騒ぎでした。

ま、正直「Objecteve-C今から導入するのも手間だし、HTML5で行こうぜ！俺の時代だぜ！」と会社に大見得切っていた僕としてはかなり涙目な状況なのですが、ここは冷静に「FlashでiPhoneアプリが作れるようになると、ソーシャルアプリにはどういう影響を与えるか」を考察してみます。

まず、今の現状のiPhoneでのソーシャルアプリのまとめ。
今は選択肢が少ないため、公開されたばかりのmixiアプリ スマートフォン版（仕様書の段階では「mixiアプリ for Touch」だったのに、、ブログの名前どうしてくれんだよ。。ちょい変更しました）と、iPhoneのネイティブアプリでfacebook connect使用しているもの（iPhone版のFarmVille by Zyngaなど）を比較してみます。

	Webアプリ	ネイティブアプリ
公開場所	mixi touch	Apple App Store
ソーシャル性	mixi上	facebook connectを利用
アプリへの誘導	mixi新着アプリ おすすめアプリ	App Storeランキング おすすめ
開発言語	html/css/Javascript	html/css/Javascript Objective-c
開発工数	少	大
実行速度	中	速

とにかく今までは比較するにも「Flashは使えない」くらいしか共通項はありません。
またAppleのApp Storeは「売れるアプリだけ売れればいい」というステキ仕様のために、まず普通のアプリは露出されることがありません。つまり新規の流入が極端に少ない。SEOなどのも無いため、モバイルの勝手サイトよりもお寒いツライ現状。
正直mixi／gree／モバゲーでソーシャルアプリ作っているSAPには、選択肢としてmixiアプリ スマートフォン版しかない"はず"でした。

ここから本題。

9/10に発表された３つの事柄により、実は大きく今後が変わってきます。

1. 前述のPackager for iPhoneによる、Flashからネイティブアプリ制作が可能になった
2. mixi meetup 2010で発表されたmixi Graph APIにより、mixiのソーシャルグラフを外部サービスから取得可能になった
3. さらっと発表されましたが

   今後は、Webブラウザベースのゲームだけでなく、スマートフォン用アプリにも対応させていく計画だ。
   「mixiアプリ」がスマートフォンにも　「世界初、3デバイス対応」

   ということで、今年中に"mixiアプリ"がiPhoneのネイティブアプリとしてリリースできるようなる

この３項目を視野に入れると、先程の表は大きく変わってきます。
ってことでまとめなおし。

	mixiアプリ （Web）	ネイティブアプリ （mixi Graph API）	mixiアプリ （ネイティブアプリ）
公開場所	mixi touch	App Store	mixi touch App Store
ソーシャル性	mixi上	mixi Graph APIを利用	mixi上
アプリへの誘導	mixi新着アプリ おすすめアプリ	App Storeランキング おすすめ	mixi新着アプリ おすすめアプリ App Storeランキング
開発言語	html/css/Javascript	html/css/Javascript Objective-c Flash 他	html/css/Javascript Objective-c Flash 他
開発工数	少	？	？
実行速度	中	速	速

この表題だけ見ると、mixiアプリ（ネイティブアプリ）サイコーじゃーん！となりますね。むしろmixiアプリ（Web）はFlashが使えない分不利に思えるくらい。うん、サイコーです。工数／予算気にしなければ。

とはいえ、技術的な面で障害と考えていたものに関して朗報であることには変わりません。
すでにFlashで組んでいるPCアプリが存在しその移植をしたいという会社さんには非常に魅力的な話ですね。
ただ、まだPackager for iPhoneを利用していないので憶測ですが、PCのFlashをそのまま移植してネイティブアプリ簡単に作れるーとは思わない方が良いでしょう。もちろん細かな制約はあるとしてそれ以上に考えられるのがiPhoneのスペックに対する負荷対策。当然PCでもファンをうぃんうぃん唸らせながら動いているFlashアプリたちが、そのままiPhoneで動くはずがありません。

よい例としてZyngaのFarmVilleは本家facebook版とiPhone版では機能やアニメーションが大きく削減されています。見た目以上におそらくかなり細かい部分で容量削減／動作改善をしていることでしょう。
ですから「Packager for iPhoneを利用すれば、一から作るよりは速いよね」くらいな気持ちでいましょう。このあたりはFlashエンジニアの腕にかかってます。

また、モバイルで利用したFlash liteなどは、正直Packager for iPhoneを使って変換するよりも、一からつくり直してHTML5を使ったほうが実行速度／開発工数共に速いと思います。表現力や技術がかなり限られているものですから、本来Flashで表現するほどでは無いものばかりですからね。

つまり今回のまとめでいうと（かなり偏った私見）

• PC版アプリの移植：Packager for iPhoneを利用してネイティブアプリへの移植もアリ
• モバイル版アプリの移植：HTML5でWebベース開発。ネイティブアプリへ変換してもいいけど、特に意味無いかも？
• 新規アプリ：表現力に合わせて選択。余裕があればPackager for iPhoneで作ったほうが技術制限受けず表現力豊か

まだまだ未知の領域の事柄も多いため、今後も目が離せません。

スマートフォンのユーザビリティあれこれ

ボタンの縦横サイズ

指で操作するために必然的に自分の指の下になる箇所は隠れます。
そのために縦にボタンを並べると、上のボタンを押しているとき下のボタンは見えません。
ボタン類を縦に並べる場合は、ある程度の距離を取りましょう。

逆に横にボタンを並べる場合、ボタンを教えている最中に横のボタンも見えるため、縦に並べる場合よりも押し間違いが少ないようです。

近い距離にボタンを並べる場合は、横に並べる方がいいかもしれません。
（もちろんそんな風には並べない、というガイドラインを作るのがベストですが）

inputタグとlabelタグ

テキストテキスト

やタグで選択肢を用意する際に、クリック領域を広くするためにタグで囲う、もしくはlabel forで対象を指定するなどしている方が多いかと思います。
しかしなぜかiPhone／Androidではに対するlabelが反応してくれません。（はOK）
そのため指では非常に押しにくい。。appleの標準インターフェースでも、そのせいかラジオボタンは使われていませんでした。

とはいえラジオボタンが必要な箇所はあります。
そこで簡単なJavaScriptで、label部分をクリックしたらラジオボタンが選択されるようにしました。（今回はjQueryを使っています）

$(function(){

	$('form label').click(function(){

		$(this)

			.children('input[type="radio"]')

			.attr('checked','checked');

	});

});

これでPCと同様にテキスト部分を選択してラジオボタンをチェックできるようになりました。

以下追加------

textareaã‚¿ã‚°

ほげほげ

当たり前のように使っているtextareaですが、実はスマートフォンだと若干難があります。
textareaで表示領域を超える文字数を入力した場合、PCだとスクロールバーが表示されますが、ご存知のようにiPhoneではスクロールバーはありません。（Androidはあります）
ここでその文字数があぶれたことに気づかない場合があるのが第一関門。

第ニ関門はtextareaのスクロールがiPhoneの場合「二本指のフリック」といういかにもマイナーなジェスチャーなところ。これはかなり知名度低そうです。

だからみんなでケンテイ(´∀｀)では下記のようなcssを記述して、若干のお茶にごしをしています。

textarea {

	height: 5em;

}

textarea:focus,

textarea:hover {

	height: 10em;

}

textareaにフォーカスしている時だけ、textareaの領域を縦に拡大するというワケ。
iPhoneだけの場合textarea:focusだけでいいんですが、XPERIAの場合はなぜか:focusが効かず。代わりにスマートフォンには効かないと言われている:hoverは双方有効なようです。
:hoverの挙動としては指がタッチ中に反応するわけではなく指をタッチして離した瞬間onreleaseのような挙動をするようです。

このあたりは今後も要調整。

mixi meet upもあって疲れてしまったので、今日はここまで。参加した皆様お疲れ様でした。

スマートフォンでのアニメーション描画

ソーシャルアプリをmixi上で展開するとなると、何らからの形でFlashアニメーションの代替が必要になってくるのではないでしょうか。

例えば怪盗ロワイヤルのレベルアップアニメーションとか。
今回はそれらの代替手段を考えてみます。

Flash

ジョブズ閣下はお怒りなので、iPhoneではまず今後も対応しないでしょ。Androidも現状未対応なので却下。

アニメーションGIF

今でもモバイルでは結構使ってる。間違いなく堅実な方法。ただ、1コマの容量×コマ数と言えるほど圧縮率は低い。キャッシュを活用できれば有効。

アニメーションpng

マイナーだが、実はpngの画質でアニメーションができます。アルファチャンネルにも対応。
けど現状はFirefoxのみ対応。却下。

Canvas

html5の新技術。iPhone・XPERIA共に対応。ベクターデータを扱えるので拡大・縮小をしても劣化をしない。しかしアニメーションの規格として制定されたわけではないので、コマごとにすべてを再描画しなおす必要があり、正直iPhoneのスペックではアニメーションは難しい。保留。

SVG

SMILと呼ばれるアニメーション規格あり。XMLベースのファイルのためサーバーサイドでの動的な書き換えも可能。ただ、新たに覚える規格としては障壁高そう（未確認）保留。

html5 video

html5のvideo規格。動画をjsで操作可能。
しかしXPERIAが非対応な上に、iPhoneもページ上でのインライン再生はできずQuickTimeが立ち上がるオマヌケ仕様。動画コンテンツ以外は却下。

css3 Transitions / Animations

css3ではアニメーション機能が追加され、htmlで定義された要素をcssで表現できる範囲でアニメーションさせることができる。内容によってはかなり有効。でもレベルアップ表示とかは表現力不足か。保留よりの有効。

画像の切り替え

とても原始的な発想だが、コマごとの画像を全て書き出しておき、jsで切り替えていく。
Appleのhtml5デモでもこの手法が使われている。当然コマ数を追うごとに重くなっていくがキャッシュを活用できれば有効。

こうなるとアニメーションGIF／css3 Transitions / Animations／画像の切り替えあたりが無難な線でしょうか。
通常の要素の変形（拡大／縮小・回転・移動・湾曲・反転）でできる範囲のものは、間違いなくcss3を用いるのが一番軽いです。
それ以外のものはFlashで作ってアニメーションGIFで書き出し、かな。

決定打にかけますね。個人的には今後のhtml5 videoに期待！

スマートフォンにおけるHTML5対応状況 (2) input typeについて

今回はマニアックにinputタグについて掘り下げようかと。

html5からinputタグのtype属性が大量に追加されています。

今までは

• type="checkbox"
• type="radio"
• type="image"
• type="text"
• type="password"

なんかを使っていたと思いますが、html5では

• type="tel"
• type="url"
• type="number"

など、内容に合わせた専用のtype属性が用意されています。
これで id="tel" とか id="url" なんて指定がいりません。

ただ、当然ブラウザごとに対応状況が違います。
せっかくのスマートフォンブログなので、iPhoneとXperiaでの対応状況を調べてみました。

	iPhone（iOS）		Android（Xperia）
	対応 可否	入力モード	対応 可否	入力モード
type="checkbox"	â—¯		â—¯
type="radio"	â—¯		â—¯
type="file"	×		×
type="submit"	â—¯		â—¯
type="image"	â—¯		â—¯
type="reset"	â—¯		â—¯
type="button"	â—¯		â—¯
type="text"	◯	英字	◯	日本語
type="password"	◯	英字 （言語切替無し）	◯	英字（テンキー）
type="tel"	◯	テンキー	◯	日本語
type="search"	◯	英字	◯	日本語
type="url"	◯	英字（.comあり）	◯	日本語
type="number"	◯	数字	◯	日本語
type="email"	◯	英字（@あり）	◯	日本語
type="datetime"	？	英字	？	日本語
type="date"	？	英字	？	日本語
type="week"	？	英字	？	日本語
type="month"	？	英字	？	日本語
type="time"	？	英字	？	日本語
type="datetime-local"	？	英字	？	日本語
type="range"	？	英字	？	日本語
type="color"	？	英字	？	日本語

共通仕様

• type="search" を使ってもSafariã‚„ChromeのようなWebkitブラウザの検索窓のデザインになりません。もしかしたら未対応なのかもです。

それにつられてautocomplete / datalist属性も無効

iPhone

• autocorrect：スペルチェック機能。英文入力のみをする箇所（どんな？？）以外はoffでいいかと。特にログインIDなどを入れる箇所ではoffにしとかないとウザイかも
• autocapitalize：先頭文字が大文字になる処理。これがonになっていると先頭文字入力時のみShiftキーが押されている。英文を書かない限りはこの処理は邪魔になるので、デフォルトoffを指定していいかも
  ちなみに text / search / url / email あたりがこのモード。url / emailではかなり邪魔な処理なのでoffにするのを忘れずに設定しましょう。
• placeholderは積極的に利用
• autofocusは未対応なのでJSで対応が必要

  $('#foo input:first-child').focus();

  みたいなね。

入力モードの切替

periaと一番の違いとして、入力モードがtypeによって切り替わります。
切り替わるモードについては表参照。

入力モードが切り替わるのは、type="password" / type="number" / type="tel" の3種類。

標準時は英字のQWERTYキーモードですが、一度日本語のテンキーモードに切り替えると、type="tel"などで一度数字入力モードに切り替わっても他のフォームにフォーカスすれば元のテンキーモードに切り替わります。
ただ、type="password" は強制的に英字モードに移行後、他のフォームに戻ってもQWERTYキーモードのまま。テンキーモード愛好者にはツライ仕様ですね。
type="password" の項目を最後に持ってきたりすると、ちょっと親切かも。

蛇足

左上の「次へ」ボタンを押すと、PCでのTabキーのように次のフォームへ自動で移動してくれます。そうするとモードによって微妙に「123」「言語切替」キーの場所が左にずれたり、「Shift」キーの矢印が小さくなったりするようです。これってバグ？もしくは内部的には入力モードが切り替わってる？

Xperia

• placeholder：挙動が若干おかしいようです。ロード直後は正常に動作するんですが、何回かフォーカスを続けるとvalue値に設定されているような挙動。今回はAndroidのみ振り分けて非表示にしました。
• autofocus：対応しています。iPhoneのためにJS対応をしないならば、入れておいてもいいかも

スマートフォンにおけるHTML5対応状況 (1)

今回はmixiアプリ for Touch限定ではなく、スマートフォンにおけるHTML5の対応状況について。

まず、基本的にiPhone・Android共に標準のブラウザではWebkitを描画エンジンとして用いており、共通する仕様が非常に多いです。
それらはSafari・Google Chromeを使ってご存じの方も多いかと。

webkitと言えば常に新しい規格を作り標準規格として採用された実績を持つブラウザ、HTML5の対応にも期待が持てます。基本的にhtml5の技術は進んでバリバリ使ってOKと考えましょ。
ただ、XPERIAはAndroid1.6ということで、現存するAndroid端末の中でもかなり古いため、webkitのバージョンが古いのでしょう。ちょっと心配な面もあります。

また、HTML5と言っても実はかなり広義にわたる意味を持っており、今までのXHTMLと違いCSSã‚„JavaScriptなどの技術も含めたもののようですね。そのあたりはググッてください。

ここでは簡略してHTML5の

• html
• css3
• JavaScript

について簡単にまとめて行きます。

まずざっくりとした対応状況

	iPhone（iOS）	Android（Xperia）
@font-face		â—¯
Canvas	â—¯	â—¯
Canvas Text	â—¯	â—¯
HTML5 Audio	â—¯
HTML5 Video	â—¯
rgba()	â—¯	â—¯
hsla()	â—¯	â—¯
border-image:	â—¯	â—¯
border-radius:	â—¯	â—¯
box-shadow:	â—¯	â—¯
opacity:	â—¯	â—¯
Multiple backgrounds	â—¯	â—¯
CSS Animations	â—¯	â—¯
CSS Columns	â—¯	â—¯
CSS Gradients	â—¯	â—¯
CSS Reflections	â—¯	â—¯
CSS 2D Transforms	â—¯	â—¯
CSS 3D Transforms	â—¯
CSS Transitions	â—¯	â—¯
Geolocation API	â—¯
localStorage	â—¯
sessionStorage	â—¯
SVG	â—¯
SMIL	â—¯
SVG Clipping	â—¯
Drag and Drop	â—¯	â—¯
hashchange	â—¯
X-window Messaging	â—¯	â—¯
History Management	â—¯
applicationCache	â—¯
Web Sockets
Web Workers
Web SQL Database	â—¯
IndexedDB
Input Typesâ€
Input Attributes‡

こっからいくつかクローズアップして見ていきます。

@font-face

最近話題になったWeb fontです。いわゆるWebFontsで、サーバー上に置いたフォントファイルをダウンロードすることにより、ユーザー環境に関わらず、共通のフォントを表示できます。
Google font directoryã‚„デコもじなんかのサービスが始まって注目を集めましたが、残念がらiPhoneは非対応。

rgba()／border-image:／border-radius:／box-shadow:／Multiple backgrounds／CSS Gradients

日常的に使うレベルの便利CSS3。長くなるので別エントリーで。

Canvas

図形やグラフなど、ベクトル描写ができる技術。JSで記述。iPhone・Android両対応なので、ベクトル描写をする場合はCanvasに限定される。

HTML5 Video

Flashなどを利用せずにVideo素材を再生する。動画の制御はJSで可能だが、XPERIAは非対応。また、Androidでは将来的にFlashへの対応を発表しているが、XPERIAは未定。
そうなると動画をiPhone・XPERIA双方で再生るる方法はYouTubeだけ。

SVG

Canvasと同様ベクトル描画が可能。Canvasと異なるのはJSではなく、画像と同様に一ファイルでの書き出しが可能、またAdobe Illustratorでの書き出しが可能で、非常に現状のデータとの親和性が高い。しかし残念ながらXPERIA非対応。。

更に深く後ほどのエントリーで掘ります。
てなわけでこのエントリーはここまで。

mixiアプリ for touchを考える (4.5)【デザイン】

前回のエントリーのデザイン周りの補足。
ちょっとより突っ込んだニッチな情報です。

iPhone固有のおはなし

フォント

iPhoneには嬉しいことにMac OS Xと同様にヒラギノがインストールされてます。
特に何も指定しなければ日本語は全てヒラギノ角ゴで表示されます。
ただ、残念ながらウェイトがW3とW6の二種類。せめてW8も欲しかった。。。
Helvetica／Futura／Times／Georgiaといった定番の英文フォントも入っているので、英字コンテンツの場合は積極的に利用したい。
こちらのサイトでiPhoneの搭載フォント一覧が紹介されてます。iPhoneフォントの一覧画像 - 小酒井輝の断片2

また、TypefacesというiPhoneアプリでインストールされているフォントの一覧を確認できます。日本語のフォントもcssで指定する際は全て「HiraKakuProN-W3」の様に英語名で指定します。
これ、Safari（webkit系）の独自仕様なのでお気をつけください。

Android固有のおはなし

解像度とスクロールバー

もしかしたらXPERIAのみかもしれないですが。
XPERIAの横の解像度は480ピクセル。しかしコンテンツ幅を480ピクセルで指定する、なぜか横に少しあぷれている状態になり横にスクロールがわずかにできてしまう状態に。
んーと思って調べてみると、どうやらスクロールバーの幅はWebの描画ができないようです。ふぁっくだネ！

これはモバイルのコーディングをしている方にはauでよくある現象。
auは240ピクセルの画像を配置すると勝手にスクロールバーの分縮小しやがりましたが、XPERIAの場合は横スクロールが発生するということに。まだauの方がましや。

弊社のフレームワークではユーザーエージェントから振り分けることもできるのようになっているのですが、どうもmixi Touchがこのスクロールバー問題に対応してません。
つまりはそのmixi Touchのフレーム内で展開されるアプリでいかに対応をしても無意味、と。
だもんで気にしないでいきましょう。頭の片隅に置いておく程度で。

共通のおはなし

操作方法

スマートフォンを使うときってどっちの手でどうやって操作してます？

• 両手派
  • 左手で持って右手人差し指で操作
  • 右手で持って左手人差し指で操作
  • 両手で持って両手親指で操作
• 片手派
  • 左手で持って左親指で操作
  • 右手で持って右親指で操作

ぱっと思いつくのはこんなもん。社内で聞いてみたところ結構みんなバラバラでした。右利きでも案外「左手で持って左親指で操作」派もいましたね。

ただ共通して考えたいのは、画面の下の方から指を出して操作しているということ。つまり画面上の方のボタンを押すと、絶対に自分の手で下の方のコンテンツは隠れてしまいます。
だからiPhoneのタブバー（前回エントリー参照）は画面下に張り付いているんだな。とはいえmixiアプリ for Touchの場合、下に張り付きのタブバーを作りにくい事情があるのも前回のエントリー通り。

そう考えると右端 or 左端にメニューを持ってくるのも無しではないと思います。
図はポータルサイトexciteのiPhone版Web。左側にメニューリンクを縦に並べています。

これだと「右手で持って左手人差し指で操作」派、「両手で持って両手親指で操作」派、「左手で持って左親指で操作」派の場合は、右側の切り替わるコンテンツが自分の手で隠れることはありません。
もちろん右手で操作派の人はコンテンツ隠れちゃいますが、どうせ上だとみんな隠れてしまうので、少しでも救われる方法を選ぶのも一つ。

今回のみんなでケンテイ(´∀｀)では採用しませんでしたが選択肢の一つしてはよさげです。