ASP.NET MVC4 が面白い!

今、ASP.NET MVC 4 が面白い。まだBetaだけど、正式リリースが待ち遠しくなって来た。

ASP.NET MVC 4 Beta 関連ドキュメント

特に興味を引かれるのは、「Web API」と「Single Page Application (SPA)」だ。

Web APIについてはこの動画と次の説明を見ればほぼ概要がつかめる様になっている。

http://www.asp.net/web-api/videos

ASP.NET Web API を使ってみよう: MVC 4 新機能シリーズ - THE TRUTH IS OUT THERE

出来ればいつかはこういう解説が出来るぐらいには詳しくなりたいものだ。

ControllerとApiController - 無聊を託つ

SPAについてはこのサンプルをチェックして次の説明を読めばなんとなく分かった気になれる。

SPA Samples: The Official Microsoft ASP.NET Site

Single Page Application (SPA) を使ってみよう: MVC 4 新機能シリーズ - THE TRUTH IS OUT THERE

SPAの標準テンプレートではクライアント側のJavascriptライブラリとして「Knockout.js」と「Upshot.js」などが使われている模様。またまた憶える事が増えたなぁ。。。


早速実際に試してみた方の記事も非常に参考になる。

ASP.NET MVC 4 Beta で追加された Web API プロジェクトを試す - まめしば雑記
ASP.NET MVC 4 Beta で追加された Single Page Application を試す - まめしば雑記

現時点の感触としては、Web APIとSPAの組み合わせで、プラグイン無しでクライアントサイドで動く操作性の良いアプリケーションが作れて、かつValidationなどはサーバーサイドのロジック（というより宣言的な記述）としっかり同期させられて、とっても良い感じ！ という印象だ。

早速何か作って色々試してみたい。



（こちらはMVC 3ベースのWeb APIの例。実際にDBからデータを取得する部分などはこちらも参考になりそうだ。）

WCF Web API, WCF Data Servicesとはまた違うREST APIライブラリ | OPC Diary

Sony Tablet Sを数時間触ってみた感想

仕事でたまたまAndroidタブレット用アプリの開発案件が入って来た。
ターゲットの端末は今の所「Sony Tablet S」の予定なので、試しに実機を触らせてもらった。

Googleアカウントは設定せずに単にOSの設定画面やプリインストールのアプリをいじっただけなのだけれど、数時間ほど触った現時点での感想を書いてみたい。

1．外観

背面がプラスチックっぽくて少しチープに見えるけれども、慣れれば違和感は無くなりそうだ。手に取った時の体感的な重さはiPadとほぼ同じか少し軽いぐらい。片側が厚くなっているので持ちやすいのは確か。

2．液晶画面　

見やすく綺麗だけど照明の具合によっては指紋が目立ってしまう。

3．UIの反応

動作は軽快で快適。特にブラウザの起動は速く感じる。

4．最大の問題

OS(Android 3.2)のフリーズが何回か発生した。普通に設定画面を操作しているだけなのに、下の画面の様に「システムUI」のエラーが出て、「強制終了」ボタンを押すしか無くなる事がある。

アプリではなくOSの設定画面で「システムのエラー」が出るとは。

最悪なのは、その後、画面左下に3つ並んでいるバックボタン、ホームボタン、タスク一覧ボタンが消えてしまい、全く何も操作が出来なくなる事だ。

こうなると結局電源ボタンを長押しして端末を再起動するしか無く、本当にストレスが溜まる。

ちなみに、「タブレット情報」の画面で確認すると、

Androidバージョン：3.2
カーネルバージョン： 2.6.36.3
ビルド番号： 1.10.001100001

だった。

Androidのバージョンが4になれば改善するのかも知れないが、ソニーがOS標準のUIにだいぶ手を加えている様なので、その辺りとの兼ね合いで本当に不具合が完全に無くなるのか疑問が残る。

正直、ハードメーカーには、OSのカスタマイズには手を出さずにひたすら丈夫で軽くてバッテリーの持ちが良いハードウェアを作る事に徹してくれた方が有り難いと思う。

Android SDKのサンプル「LunarLander」でエラーが出るので修正してみた

Android SDKに含まれている「LunarLandar」というサンプルを試していて、エラーが出る事があるのに気付いた。

Homeキーなどで他のアプリケーションに移ってから LunarLander に戻って来た時に「Thread is already started」というエラーになる。

surfaceDestroyed で破棄されたThreadに対して、surfaceCreated で再び start() を呼んでしまっている事が原因らしい。

それにしても、標準のサンプルがどうしてこんな状態で放置されているんだろう。。。

ターゲットのVersionを1.5, 2.2, 4.03に変えて試してみたけれどもどれも同じ。
同じくSurfaceViewを使っている「JetBoy」というサンプルも試して見た。これも同じだった。

検索しても日本語の情報はあまり見つからなかった。

SurfaceViewとThreadのonPause、onResumeの処理について - shumach217の日記

英語だといくつかもう少し詳しい説明が見つかった。

Fixing the Lunar Lander example: a threaded gameloop for Android at michi's log 

Android - How to pause/unpause thread in games | Robert Green's DIY

Android crash when app is closed and reopened - Stack Overflow

対策方法としては以下の3つの選択肢が考えられそうだ。

1. surfaceCreated で thread.start() する前にスレッドが無効な状態ではないか確認する。無効な場合はスレッドを新規作成(new)してから start する。
2. surfaceDestroyed でスレッドを終了させずに、フラグを用いて擬似的に一時停止状態にする。
3. surfaceDestroyed でスレッドを終了させずに、 object.wait() を用いてスレッドを一時停止状態にする。

まず1の方法でLunarLanderのソースを修正して試して見た。

これだとエラーは出なくなったけれども、復帰後の画面が真っ暗なまま何も表示されない。おそらく他の変数の内容が復元されていない状態になってしまうからだと思うが、きちんと動くようにしようとすると結構面倒そうなので、あきらめた。

次に2の方法。
変更点は以下の通り。

• LunarThreadクラスに変数 mInBackground を追加。
• isInBackground() and setInBackground() メソッドを追加。
• run() メソッドで、isInBackground() をチェックして true なら 100ms スリープする様に変更。
• surfaceDestroyed() メソッドでスレッドを停止しない様に変更。
• surfaceCreated() メソッドで isInBackground() をチェックして true ならスレッドを start() するのではなく setInBackground(false) を呼ぶ様に変更。

変更後のLunarViewクラスのソースはこちら。

Fixed LunarView class in Android SDK Sample LunarLander. — Gist

これで一応問題なくバッチリ動く様になった。^^

ただ、100msのスリープを入れて擬似的にスレッドを一時停止状態にしているだけ、というのが、ちょっと気になる。

どうせならJavaの標準として定義されているwait/notifyの仕組みを使った方が良さそうな気がする。多分その方がCPUリソースの消費が少なくなりそうな気がする。多分。。。

ということで3の方法も試して見た。

変更点は、 run() メソッドでスレッドを待機させる時に sleep() ではなく wait() を使う様にした点だ。

変更後のLunarViewのソースはこちら。

Fixed LunarView class in Android sample LunarLander, using object.wait() method. — Gist

実際に2と3でCPUリソースの消費に違いがあるのか、Eclipseのデバッグモードでスレッドの状態を確認して見た。

2の方法の場合、Statusの表示が「timed_wait」になった後、何もしなくても utime, stimeの値が少しずつ増えていく。やはり少しずつCPUリソースを消費している様だ。

それに対して3の方法だと Statusが「wait」になり、utime, stime の値はピタっと止まったまま増えない。

端末のバッテリーにも多分この方が優しいだろうと思う。

ということで、スレッドを待機状態にする場合は、object.wait() と notify()/notifyAll() メソッドを使う方が良いみたいだ。