2009年7月アーカイブ

MarketにうpしてからQVGA端末のことを思い出した。
今更ながらエミュでQVGA端末作って表示確認。ちゃんと想定して作ってはいたんだけど、意外と問題なくいけた。
世界的にはまだローエンドでQVGA端末が出てくる余地はありまくるので当面はQVGAも念頭に置いた方がいいんじゃないかなと思う。

なんか今年中にHTC以外からAndroid機がリリースされるそうですよ
というか
まあ
Samsungのような予感はプンプンしていますが...

欧州版のSamsung "I7500" が出るのかどうか分かりませんが、I7500は基本的にHTCのものと似たり寄ったりの構成です。

ディスプレイが解像度同じで有機ELになり、カメラが3.2Mから5Mに、ヘッドフォンがUSB(充電兼用)から3.5mmヘッドフォン端子に、トラックボールが十字キーに、RAMが192Mから128Mに、内蔵ストレージが512Mから8Gに、バッテリが1340mAhから1500mAh、といった違いでしょうか。
ヘッドフォン端子は良変更。HTCは変則USBヘッドフォンとかやめるべき。
トラックボールは痛し痒し。アプリによって一長一短ですがブラウザのナビゲート性では明らかにトラックボールが勝るでしょう。文字入力時は十字キーの方がいい気がします。
RAM減少はやや痛いですが今のところどうせ1アプリ16M制限があるので足りる気がする...。将来的には分かりません。128はちょっと少ないんじゃないのとは思います。
ストレージ増加は大きいです。iPhoneと違い音楽や動画などの領域はSDカードで補えますが、アプリ本体やアプリ内部のデータは内蔵Flashに入るため、HTC機は明らかに少なすぎでこれは最大の欠点です。
バッテリは大きいに越したことはないですね。iPhoneと比べて常駐アプリというのも大きな差別化点ですので多少厚くなってももっと思いきったバッテリ積んでもいいくらいだと思います。

まだどこが出すとも分かりません(ソニエリとかAcerとか有り得ます)が、各社創意工夫を凝らして是非変態的な端末で市場を沸かせて欲しいものです。
残念なのは日本メーカーが...ねぇ...Androidにおサイフやワンセグを付けちゃいけないなんて決まりはないですよ?

JVMを変えずに糖衣構文で乗りきりたかったってのは分かるんだけど

public class Hoge<T> {
private void hoge() {
T t = new T();
t.foo();
}
}

abstract protected T __newT();
private void hoge() {
T t = __newT();
t.foo();
}

Hoge<String> hoge;

class HogeImpl extends Hoge {
protected String __newT() { new String(); }
}
HogeImpl hoge;

new T()できないことを今知った。
いや以前それっぽい記述をどっかで見た気はしたけど猛烈にスルーしてた。
致命的じゃんこれ。どこがGenericだよ。
関数の入り口で型チェックしてくれて、出口でキャストしてくれる、という糖衣構文以外の何物でもないじゃないか。

ないわー

完成しても当面公開のアテがない(中間サーバ必須の状態では公開する気がない)ニコニコ閲覧アプリの開発を一旦Pending
OpenCore2.0で期待してた改善が行われず、かつブラウザにしれっとFlash10が載った日にゃアホ臭いので...
まだほんの触りを作り掛けてただけだけど色々勉強にはなった。さて、何を作ろうかな。

スパボ一括で安かったのでSIM目当てに買いました。
UI設計の参考にしようとここしばらく常用しています。以前軽く触ったことはあるんだけど常用してると色々気づく。大きいものから重箱の隅まで。

◆良い点
・全体的に高速
iPhone3Gでも十分高速で快適。3GSとかいらなくね。

理由としてはまず全てのアプリが(Objective-Cで書かれた)ネイティブアプリであることが挙げられる。Androidは少なくともUIのイベントハンドラが全てDalvikになるためこの点が非常に大きなハンデになる。DalvikJITは大変だと思うが優先度を思いっきり上げるべきだと思う。

・ブラウザが快適
ブラウザを比べて思ったのは、ピンチ操作云々が問題ではないということ。端的に言えばSafariは間引きが上手い。
レンダラは画面サイズの縦横3倍程度にクリッピングした領域しかレンダリングしておらず、またスクロール中は移動が終わるまでレンダラは停止され再レンダリングしない。そのためある程度一気にスクロールすると画面は真っ白になる。また、拡大縮小時も確定するまでレンダリングはしていない。単にピクセル単位で伸縮しているだけで実際画面は読めたものではない。
移動にしても拡大縮小にしても指を止めて新しい視野が決定した時点でやっとレンダリングが開始するので、開始から移動先で読めるようになるまでの時間は意外と掛かるのだが、移動そのものはすんなり完了するので体感的に非常に早く感じる。これはAndroidもぱちるべきだ。
またそれに伴って、Androidの拡大縮小は本当にいけてないことを痛感した。せめて押してから1秒程度はiPhoneのようなルーズな伸縮をし、連打されていない程度の時間が経ってから再レンダリングするだけでも見た目の速度は大きく変わるはず。もっと言えば最初からスライダーにすれば同様の処理が可能になっていたはずだ(繰り返すがピンチ操作は本質ではない)

・美しい
全体的に見た目の美しさが圧倒的に勝っている。ボタンのデザインは美しく、それぞれの操作がこれ見よがしにアニメーションする。実にスイーツだ。俺にとってはまったくもってどうでもいいことではあるが一般ユーザに対する訴求は大きく違う。
とりあえずAndroidのウィジェットデザインの洗練性はいかんともし難いとして、標準添付のアイコン系リソースくらいはもっと増やして欲しいのだが。

・ソフトキーボード
ソフトキーボードもAndroidより良い。といってもsimejiを入れてしまえばソフトキーボードそのものの優劣はさほどないのだが、むしろソフトキーボードを出した時の元画面の取扱いが違う。
iPhoneではソフトキーボードが出た時点でビュー領域は画面の上半分のサイズに変更されウィジェットは再配置もしくはスクロール可能な状態になる。
Androidでは単にウィンドウにオーバーレイする。そのため「画面の下半分にあるテキストエリアに入力しようとするとソフトキーボードで入力エリアが隠れる」という頭の悪い動作をする。早急に改めるべきだ。

・AppStore
アプリは圧倒的に洗練されている。メジャーなアプリは生き残っているだけあってUI設計は素晴らしく使いやすい。大変参考になる。Androidは原始時代だ。がんばってぱちっていきたい。

◆悪い点
・ボタン小さい
ソフトウェアキーが小さい。ボタン類がとても小さく、またラベルがない。押しにくく、また始めてのアプリでボタンを押すと何が起こるか想像が付かない。
Androidの場合は頻繁に使わないようなボタンは普段画面に出ておらず、Menuボタンを押すとでろっと下から生えてくる。とてもださいがボタンは大きくボタンの意味が文字列で書いてあり分りやすく押しやすい。
これは好みの問題もあるだろうが俺はAndroidのやり方が好きだ。

・ハードウェアキーがなさすぎる
ハードウェアBackキーが無いのが特に感じ悪い。画面のどこか(通常は左上か左下、時々右上)にBack相当のソフトウェアキーがあるのだが特に左上に出る時は小さく押しにくい。Backキーを付けろとは言わないがもう少しマシな方法は無かったのだろうか。
これも好みの問題だろうが個人的にはBackボタンはハードウェアで搭載すべきだと思っている。

・日本語変換
日本語変換がプア。これはAndroidも酷いところ。
ガラケーだと分節区切りにカーソルキーが使えるのだが、iPhoneで効率的にやる方法が分からなかった。分節の間を(ルーペ見ながら)押すとか狂気の沙汰だ。入力ミス時の訂正もめんどくさい。
二本指スワイプして中指付けたまま人差し指でトントンするとKEY_LEFTイベントを押した回数だけ発行するみたいなインターフェースは無理なんすかね。

・その他
アプリがランチすると行ったっきりとか、常駐できないとか、よく言われる難点はまあありまくるけど、言われてるほどには気にならないかな。そういうものかと割と早期に諦めが付く。ただしできることはもちろん狭いので狭い方向に適応しているだけなんだけども。

あと、iPhoneのフルブラウザはとてもよくできているけど、じゃあこれで全てまかなえるかと言われるとまったくもって現実的ではない。個人的に携帯にフルブラウザを搭載するのは緊急避難的な用途であってメインではないと思っている。どう頑張ってもフルブラウザなんて使えたものではないのだ。もし本気でそういう方向で搭載するならば我々はWAP3.0だのを必要としているのではないか。
(初期iPhoneはブラウザだけで全て完結するような端末を考えていたようだが、結局それでは全く使い物にならず黒歴史となり、アプリが解禁されてブレイクしたわけで)
アプリのプラットフォームとしては(DalvikJITが出れば、だけど...)AndroidはiPhoneよりずっと優れていると思う。ただ、既存のアプリの完成度は圧倒的にiPhoneが上。一旦軌道に乗れば一気に抜き去れるポテンシャルはあるんだけどそこまでがきついなぁという感じ。

って何を使えばいいのかな、かな。
いや、ベタで書こうと思えばそりゃ書けるけどあるもの使いたいじゃん。
android.text.Htmlってのが何となくそれっぽく見えるんだけどどうなのどうなの。なんかすっげ使いにくそうなふいんきだからラッパーはどのみち必要そうな気がする。

→どうも違う臭い。TextViewにHTML(的な装飾を施したテキスト)を投入するためのもののようだ。
これはこれで良いものだけど全然別物だなぁ。

→結論→諦めてJTidyをパッケージに入れる
まあライセンス的には非常に緩いので入れる分には全く問題ないんだけど多少サイズがでかくなるなぁ。いっそAndroidの標準で入れてくれてもいいのに。

→XPathはどこだー

→http://code.google.com/p/android/issues/detail?id=515
(流れ)
java.javax.xml.xpath.XPath入れてくれよ無いと死ぬ
→おっけーアサインしとく
→あれ、1.0で入ってないんだけど
→XPath無いと死ぬ
→dom4j使えば?
→XPath使いたいおー
→だからdom4j使えカス
→oh
だから標準で入れてくれよー

最近pthreadベタ打ちみたいなことをやってたのでJavaのスレッドが(相対的に)使いやすく感じる。
でも、パスワード間違ってていつの間にかニコニコからロックされてたり、なんか変な方向で地味にはまった...。

で、次はニコニコ動画APIをしばいてもにょもにょしたいわけだけど、動画のURLとコメントを取ってくるのはともかく検索系のAPIとかどないなっとるん。特にタグでの検索。
スクレイピングとかしたら追従めんどくさいやん。

複数作れないのかなぁ。
階層化できないとアンダーバー区切りのだっせぇ名前が大量に増えるんだけど。

今日やったこと
・SurfaceViewのライフサイクル
　・ActivityがonCreateになった段階ではSurfaceが無いのでHolderにCallbackを仕掛けてsurfaceCreatedを待つ必要がある
　・ActivityがonPauseの時点でSurfaceはDestroyされてしまう。といってonResumeで勝手にsurfaceCreatedしてくれるわけでもなくて復活方法が分からんかった。
　　onPauseで明示的にSurfaceViewを破棄してonResumeで作り直せば解決したけど、これだとXMLで定義できんやん。どうするのが正しいのだろう。
・PreferenceActivity
　EditTextPreferenceはDialogPreferenceとEditTextの両方の属性が使えるので、android:password="true"でパスワードフィールドにできる。

次にやりたいこと
・Preferenceで設定したアカウントを使ってニコニコAPIをしばく

Androidネタはこっち(どっち?)に移すことにしました。
べつに人里離れた場所で細々とやりたいとかそういうわけではないです。たぶん。

オーディオについてはaacかmp3だが現実的な範囲ではほぼ何でもOKで、引っかかる可能性があるとすれば超高音質動画でaacの最大ビットレート160kbpsに引っかかる可能性がある?くらいか。
基本的にそのまま再生できると考えて良いと思われる。

ビデオについては問題が多い。
まずflvが一切再生できない。OpenCoreでも現時点で対応予定がないので絶望的。
再生可能なのは.3gpか.mp4で、コーデックはH.263,H.264,MPEG-4が可能。ニコニコのH.264なmp4動画はフォーマット的には再生可能だ、が、実際は再生できない。現在のAndroidでは最大解像度が480x320で600kbps以下に限られる。表示の解像度ではなくファイル側の解像度がこれを越えてしまうとその時点で拒否られる。ニコニコの解像度はデフォルトで512x384なので解像度がオーバーしてしまう。実際、拒否られた。
よって何らかのトランスコードを行わなければニコニコ動画を見るアプリは作れない。mp4限定なら何とかとも思ったがそれも無理のようだ。
(解像度についてはAndroid2.0とか出れば状況が変わる可能性はある)

ニコニコ側に(youtubeのような)iPhone用のAPIがあればいいのだが、ニコニコのiPhoneアプリはいわゆる「ニコニコ紙芝居」でありまともな低解像度mp4はどこにも用意されていないようだ。
うーん、めんどくさいね。解決策としてはffmpegを使って俺俺トランスコードサーバを用意してしまうとかあるけど、Android側で解像度制限が緩和されたりニコニコ側で低解像度mp4が用意されたりすると意味がなくなるし、地球にもやさしくない。
NDKでffmpegをコンパイルする的なことも考えたけどそれこそ酬われる気がしねえ。

とりあえずffmpegを使ってAndroidで見られる形式に変換するだけなら

ffmpeg -i video.mp4 -s 480x320 -vcodec libx264 -r 30 -bufsize 65536k -b 160k -maxrate 160k -minrate 120k -nr 600 -qmin 10 -qmax 51 -subq 6 -refs 5 -flags2 bpyramid -acodec copy -threads 0 video2.mp4

Android1.5に上げた。
方法は公式の通りでいいけど、日本語だとここを参考にした。
今までエミュしか触ってこなくて知らなかったんだけど、ADP1では英語ロケールしかないらしい。えーん。まあいいけどさ...
1.5に上げたら少しブラウザが軽くなった気がする?ソフトウェアキーボードが使えるようになったのでキーボード用なし伝説。

EclipseでHello Worldはどうするのかなーと調べてみたら、何もしなくていいらしい。
USBで繋いで何も考えずにデバッグしようとするとエミュが起動する代わりに実機でデバッグできた。すげえ。

さて、色々いじって遊ぶか。なんか世間から半年遅れだけど...

ADP1とどきました。
Android Marketの認証通ってADP1発注したのが6/30なので4日ですね。
なんか今更な感じですがauの動きが遅いので仕方ない...
興奮しすぎてやばい俺

早速このへん見ながらアクティベートしました

雑感ですが、思っていたよりは小さいです
キーボードは非常に小さく、日本人の中でも特に手が小さい方だと思われる俺ですら打つのが苦痛なレベルなのでキーボードは無くてもいいなと思いました
ブラウザ起動してみましたが、確かにiPhoneに比べるとスクロールはもっさりです。指に吸い付くような感じはまるでしません。拡大縮小も応答悪い。
トラックボールは神。
今後Android端末が出た場合、キーボードは無くてもいいですが、トラックボールは有ると無いでは段違いだと思います。今後他社からもAndroid機は出てくるでしょうがトラックボールのある機種を選ぶべきです。

さて、Android1.5にバージョン上げてくるか...