ページ

2011年6月30日木曜日

[WP7.1] Beta2 のリリースノートに書かれてることで気になったところ

今朝から Windows Phone SDK 7.1 Beta2 がダウンロードできるようになったようで一部で盛り上がってますが、とりあえず Release Notes を見てみました。
しっかり読んだわけじゃありませんが、ちょっと気になったところを覚え書き。

Known Issues のところ

  • Controls のところ、「マルチラインの TextBox は “\r\n” の代わりに改行として “\r” を使う」
  • Silverlight and XNA Framework のところ、「XNA Framework レンダリングしている ListBox は正しくスクロールしない。ScrollViewer.ManipulationMode=”Control” を付けると解決する」

これらってそのうち直るってことなんだろうか?それともこのまま?

Breaking Changes のところ

  • 最初にある 「ScrollViewer と ListBox の入力処理が UI スレッドじゃなくなった」 というのは 「[WP7] Mango で ListBox や ScrollViewer のパフォーマンスが向上する」 ここで書いたやつですね。
  • 次に 「画像のデコードは UI スレッドではなく、バックグラウンドスレッドで実行される」 なんてあります。ちょっとでも UI スレッドを軽くしようということですね。けど、「Caution: This change will be reverted in a future release. 」 なんて注意書きが。しかも、「You should not make any changes to your application code.」 なんてことまで。(この変更は将来のリリースで元に戻される。なので、あなたのコードを書き換えたりしないこと)良かれと思ってやってみたけど、イマイチだったから元に戻すってことなのかな?
  • その次には 「非同期 web client リクエストのレスポンスはバックグラウンドスレッドで動く」 なんてあります。今までこのあたりは非同期ではあるけど UI スレッドも使っている (詳しく調べてませんが、確か UI スレッドをブロックしてると WebClient からのレスポンスも返ってこなくなってたような) という感じでしたが、完全に別スレッドで動くようになるってことでしょうか?

[WP7] WebBrowser コントロール (WP7.0)

Windows Phone 7 の WebBrowser コントロールについてのもろもろ
注意: 以下は 7.1(Mango)ではなくすべて 7.0 の情報です。7.1 では IE9 ベースに変わってるので WebBrowser コントロールもいろいろと変わってるんじゃないかと思います。それらについてはまだまったく調べてません。

■ NavigateToString() メソッドで日本語表示
NavigateToString() メソッドで日本語を表示しようとすると化けます。内部では utf-8 に変換していないのに utf-8 で渡しちゃってるとかそんな感じなのかな?
とりあえず 「International UTF-8 Characters in Windows Phone 7 WebBrowser Control」 にあるように文字実体参照にして渡せば化けずに表示できます。

■ Data URI scheme は未サポート
Data URI scheme っていうやつ (HTML の中に <img src=="data:image/png;base64,ここにBASE64の文字列”> なんて書くやり方)について。
仕様については↓にあります。
data Protocol (MSDN Library)
The "data" URL scheme (RFC2397)
残念ながら NavigateToString() メソッドでこの書式の HTML を書きこんでも画像は表示されません。(×印になってしまう)
検索してみたら、このやり方ができるようになったのは IE8 からだそうです。で、WP7 の IE は 7+ くらいだからそもそもサポートしてないんじゃね?ということらしいです。
ということは、WP7.1(Mango) ではできるようになってるかも(未確認)

■ WebBrowser コントロールのリファレンス
WP7 の WebBrowser コントロールのドキュメントは↓
WebBrowser Control for Windows Phone
けど、ほとんど何も書いてないな。

■ WebBrowser コントロールから HTML 内の JavaScript を呼び出す
WebBrowser.InvokeScript() メソッドで HTML 内の JavaScript メソッドを呼び出すことができます。
(ただし、事前に IsScriptEnabled = true にしておく必要あり)
たとえば、HTML 内に func() という名前の関数があった場合には

this.webBrowser1.InvokeScript("func”);

といった感じです。
関数に引数がある場合は this.webBrowser1.InvokeScript("func”, “abc”, “あいう”); でいけました。(この場合、日本語も化けませんでした)

■ HTML 内の JavaScript からの呼び出しを WebBrowser コントロールのイベントで受け取る
WebBrowser.ScriptNotiry イベントで HTML 内の JavaScript から呼び出しをイベントとして受け取ることができます。
HTML 内に <input type="button" onclick="window.external.Notify('button1 click')" value="click"/> なんてのがあった場合、

this.webBrowser1.ScriptNotify += webBrowser1_ScriptNotify;

private void webBrowser1_ScriptNotify(object sender, NotifyEventArgs e)
{
    MessageBox.Show(e.Value);
}

という感じです。

■ 拡大縮小できないようにする
Web ブラウザーなので拡大縮小できてしまいますが、これは <head> に

<meta name="viewport" content="width=200"/>
<meta name="viewport" content="user-scalable=no"/> 

を入れておくと禁止できるようです。

2011年6月27日月曜日

[Silverlight] Silverlight を囲む会 in 大阪 #19 に参加しました

Silverlight を囲む会 in 大阪 #19 に参加してきました。
今回のメインテーマは SharePoint。
SharePoint MVP でもあり、SharePoint をメインに扱う会社の代表取締役でもある山崎さんをスピーカーに迎えて。
私自身は SharePoint のことはほとんど初心者レベルだったので、初めて知るようなことが多く、いろいろとおもしろかったです。
Silverlight Web パーツの開発のお仕事なんてできるとおもしろそう(残念ながら今のところ SharePoint を使っているという人(個人・法人)の心当たりがまったくありませんが)

また、30分ほどのショートセッションでしたが、マイクロソフトのエバンジェリストである大西さんの Windows Phone 7 Mango の紹介。
休憩時間中に実機もさわらせてもらいました。
あぁ、Mango が楽しみ。

伊勢シンさんの 「Socketプログラム Siverlight for Windows Phoneへの移植のポイント」 もおもしろかった。
伊勢シンさんは 「誰得だよ」 とおっしゃってましたが、私にとっては結構 「俺得」 でしたw

最後にいろいろなプレゼントの抽選会。
先週の VSUG DAY 2011 Summver 東京 の際にマイクロソフトの高橋忍さんから 「大阪で勉強会があったときにでも配ってください」 と Windows Phone 開発技術情報 DVD と WP-Arch シールを頂いていたのでそれも希望者に配布しました。DVD は 20枚くらいあったので余ると思ってたんですが、品切れになっちゃいました。ということは、ほぼ全員が持って帰ったってことですね。やっぱり、直前に大西さんに Mango 実機を見せてもらってるし、みんな興味を持ったのかもしれませんね。

その後はお楽しみの懇親会。
その後、大西さんを交えての二次会、さらに三次会と楽しい一日でした。

2011年6月17日金曜日

[VSUG] VSUG DAY 2011 Summer

2011/06/19 に品川にて開催される VSUG DAY 2011 Summer に参加します。

http://vsug.jp/tabid/228/EventID/17/Default.aspx

VSUG DAY 2011 Summer

「はじめてのWindows Phone 7 アプリケーション開発」 と題したセッションを担当させて頂きます。
(けど、マイクロソフトの高橋さんのセッションもあるので、WP7 について聞きたい人は高橋さんに聞くといいと思うよw)

2011年6月16日木曜日

[WP7] Mango で ListBox や ScrollViewer のパフォーマンスが向上する

Listbox – ScrollViewer performance improvement for Mango and how it impacts your existing application?
こちらの記事より。

「Outlook とかの標準アプリ(Windows Phone 7 に標準で入っているアプリ) のぬるぬるさに比べると、俺らのアプリいまいちなんだけど」 という声がそれなりにあったということでしょうか?ListBox のぬるぬるさが足りないというフィードバックが結構あったようで Mango では入力関係の入力スレッド、アニメーション関係のコンポジタースレッド、アイテム生成の UI スレッドに分けて処理することによって ListBox や ScrollViewer のパフォーマンスが向上するそうです。

ただ、そのために若干動作が異なる部分が出てくるみたい

  • ScrollViewer でスクロールしているときのプロパティの更新(UI スレッド上)
    • WP7 上の 7.0 アプリ
      プロパティが変化するとすぐさま更新
    • Mango 上(7.0 アプリと 7.1 アプリの両方)
       a. 指を離したとき
       b. 任意の方向にスクリーンの 1/4 以上ドラッグ、パン、フリックしたとき
      にプロパティが更新される
  • ScrollViewer の中でドラッグして Manipulation Delta イベントが発生するのは (UI スレッド上)
    • WP7 上の 7.0 アプリ
      ScrollViewer の中にあるエレメントによってハンドルされるこれが可能
    • Mango 上(7.0 アプリと 7.1 アプリの両方)
      入力スレッド上のイベントなので ScrollViewer によって飲み込まれる。スクロールしているときに不必要なイベントを発生しないようにするというパフォーマンス向上の一環

この非互換性が困ると言う場合は、どうやら

<ListBox ItemsSource="{Binding Items}" ScrollViewer.ManipulationMode ="Control" Height="652" Canvas.Top="80">

と言う風に ScrollViewer.ManipulationMode ="Control" を付けることができるようです。
ただし、これはまったくお勧めしない方法ということみたい。

もうちょっとましな方法は、ScrollViewer の中に横スクロールする TextBlock を組み込むとかそういう風にコードを書き換えることだそうです。
ちょっと詳しいことは読み取れてませんが、きっと縦スクロールは ScrollViewer のまかせてぬるぬるに、横スクロールはパノラマみたいにちょっとしか必要ないことが多いだろうからそっちは TextBlock とかを使って従来のスクロールにする、というような意味じゃないかと思います。横方向にたくさんのスクロールが必要な UI っていうのは普通は無いでしょうからね。

で、最後に、当然ながら ScrollViewer や ListBox を使ってない場合はなにも変わらないとあります。
たとえば、Silverlight for Windows Phone 7 Toolkit に入っている LongListSelector とかは効果なしだそうです。
えっ?と思って LongListSelector の XAML を見てみたら、これって Canvas に自前で描画してるみたいですね。誰か ScrollViewer を使う形に書きなおしてくれないかなぁ。

[.NET] スレッドセーフな ObservableCollection<T> が欲しい

Windows Phone 7 のコードを書いていると今まで以上に UI スレッドをブロックしたくなくなるんですよね。(ぬるぬるにしたいからw)

で、今更ながらに ObservableCollection<T> についてどうにかならないか考えてたんですが、どうにもなりそうにないですねぇ。
ObservableCollection<T> は INotifyCollectionChanged を実装してコレクションに変更があったことを通知してくれるようになってるわけですが、この INotifyCollectionChanged の CollectionChanged イベントは 「何番目の要素が変更されたか」 といった情報も伝えるようになってます (NotifyCollectionChangedEventArgs 参照)。で、CollectionChanged イベントを受け取るのは ListBox などの UI 要素であることが多いわけです。必ずしもそうと決まっているわけではないですが、ObservableCollection<T> を使うのは ListBox などの ItemsSource にしたいから、という場合がほとんどじゃないかと思います。そして、ListBox などの UI 要素のほとんどの機能は UI スレッド以外から呼び出すことはできません。呼び出すと例外が発生します。そのため、CollectionChanged イベントも UI スレッド以外で発生させるのは危険ということになります。
ObservableCollection<T> に対して Insert や Remove などを行うと自動的に CollectionChanged イベントが発生するわけですから、結局のところ UI スレッド以外でこういったコレクションの内容を変更することはできないわけです。もちろん、Insert や Remove の処理自体は別スレッドで行って、CollectionChanged イベントの発行のみ UI スレッドでやるという実装も可能ですが、CollectionChanged イベントの呼び出しが終わるまでコレクションの内容が NotifyCollectionChangedEventArgs の内容と整合性が取れていることを保証しなくちゃいけませんから、結局のところあんまり別スレッドで Insert、Remove などの処理を行う意味は無いって感じになってしまいます。

ObservableCollection<T> 単体で考えればスレッドセーフにする意味があるかもしれませんが、ListBox の ItemsSource にデータバインディングしている ObservableCollection<T> と考えると ListBox の中身まで含めて都合をつけなくちゃいけないのでどうにも手の出しようがないって感じですね。
こういう風に考えると、この記事のタイトルは 「スレッドセーフな ObservableCollection<T> が欲しい」 ではなくて、「UI 要素に任意のスレッドからアクセスできるようにして欲しい」 というところに行き着いちゃうわけです。

「ObservableCollection threadsafe」 で検索するとすぐに Thread safe observable collection この記事が見つかりました。
見てみると、これもやはりほとんどのメソッドを Dispatcher 経由で UI スレッドにスイッチしてますね。参照系は ReaderWriterLock で別スレッドからでもアクセス可にしてあるので、その部分はパフォーマンス向上に繋がるかもしれませんが、それくらいかなぁ?
あと、この例では Dispatcher.Invoke() メソッドを使って UI スレッドに同期的にスイッチしていますが、Silverlight/WP7 には Invoke() は無いんですよねぇ。(BeginInvoke() しかありません)
Dispatcher.BeginInvoke() を使って非同期的に UI スレッドにスイッチするとなると、上にも書いたように UI スレッド側での CollectionChanged イベントの呼び出しが終わるまでコレクションの内容を維持してやるとかいった仕組みが必要になります。(CollectionChanged イベントの呼び出しが終わるまで次の Insert や Remove の実行をブロックするとか) そういう実装もやれないことは無いですが、あんまりパフォーマンスは良くならないような感じがしちゃいます。

と、言うわけで、この件は考えるのやめましたw
何かいいアイデアがあったら教えてください。

2011年6月15日水曜日

[WP7] プログラミング生放送勉強会 第9回@大阪に参加しました!

6/11 開催の プログラミング生放送勉強会 第9回@大阪 に参加させて頂きました。
どのセッションもとてもおもしろかったです。

そして、私も 「Windows Phone 7 用の 2ch ブラウザーを C# で作ってみた」 と題したセッションを担当させて頂きました。
「作ってみた」 と言うより 「作ってみてる」 ところなんですが。しかも、最近時間が取れずほとんど進んでないです。
一応、セッション資料をあげておきます。ただ、これだけ見てもあまり意味ないかもしれません。
ニコニコ動画のコミュニティ プログラミング生放送 で、今ならまだ生放送がタイムシフトで見られるようです。(見れるのは生放送から 1週間だったかな?いずれにしろ予約してない場合はプレミアム会員じゃないとダメなまずですが)
また、それとは別にプログラミング生放送の 5zj さんが動画を上げてくれました。sm14747480 こちらはいつでも見れるはず。


 

勉強会のあとは懇親会に参加。
最近、寝不足気味だったこともありかなりのテンションだったような気もしますが、ほんとに楽しかったです。
(次の日は二日酔いでヘロヘロでしたが)

2011年6月9日木曜日

[Silverlight] Silverlight 4 の ScrollViewer がマウスホイールでスクロールしない!(バグってる?)

確か記憶では、、、

Silverlight 2 のころはそもそもマウスホイールはサポートされてなかったので HtmlPage のホイールイベントをひろってどうのこうのと。。。

そして、Silverlight 3 では Silverlight Toolkit に ScrollViewer のマウスホイール対応クラスが入ってて scrollViewer.SetIsMouseWheelScrollingEnabled(true) って呼び出せばいいだけになってくれて。。。(ちなみに、SetIsMouseWheelScrollingEnabled は ScrollViewer の拡張メソッドとして実装されてるとのでこういうことができる)

それから、Silverlight 4 で標準でサポートされて、ScrollViewer は何もしなくてもマウスホイールでスクロール可能になった!

、、、ような気がするんだけど、Silverlight 4 でマウスホイールに反応しない。
検索してみたら Connect にこんなのあった
Mouse wheel does not work correctly with the Silverlight 4 ScrollViewer
うーむ、ブラウザーのせいなのか何のせいなのかわかんないけど、どうやらダメなときはダメみたい。
で、「回避策」 にあるように

<ScrollViewer Background="Transparent" ... > 

としてやれば OK だった。
うーむ。

Background を透明にしたくないってときは以下のような感じでいけるみたい。

private void LayoutRoot_MouseWheel(object sender, MouseWheelEventArgs e)
{
    var point = e.GetPosition(this.scrollViewer1);
    if (point.X < 0 || this.scrollViewer1.ActualWidth <= point.X || point.Y < 0 || this.scrollViewer1.ActualHeight <= point.Y)
    {
        // マウスが ScrollViewer の上で無い
        return;
    }

    if (!e.Handled)
    {
        double position = CoerceVerticalOffset(this.scrollViewer1, this.scrollViewer1.VerticalOffset - e.Delta);
        this.scrollViewer1.ScrollToVerticalOffset(position);
        e.Handled = true;
    }
}

private double CoerceVerticalOffset(ScrollViewer viewer, double offset)
{
    return Math.Max(Math.Min(offset, viewer.ExtentHeight), 0.0);
}

どういうわけかわかんないけど、Background が Transparent で無いときはなぜか ScrollViewer に MouseWheel イベントがこず、背面の LayoutRoot の方にいっちゃうみたい。なので、LayoutRoot の方で MouseWheel を受けて ScrollViewer をスクロールさせてやる、と。
ちなみに、スクロール部分のコードは Silverlight Toolkit の SetIsMouseWheelScrollingEnabled のあたりでやってることそのまんまです。

[WP7] 起動ページを MainPage.xaml 以外にする

Visual Studio のテンプレートで Windows Phone 7 のプロジェクトを作ると、起動ページとして MainPage.xaml が指定されています。
これを他の xaml に変更するには、Properties フォルダの下の WMAppManifest.xml にある

<Tasks>
    <DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/>
</Tasks>

ここを書き換えれば OK です。

まぁ、それなりに WP7 開発をやってる人にとっては常識なのかもしれませんが、私はちょっと悩んじゃいましたw
始めは、「App.xaml か App.xaml.cs あたりに書いてあるんだろう」 と思って見てみてもそれらしいものは無し。「じゃあ、プロジェクトの設定なのか?」 とプロジェクトのプロパティや、.csproj ファイルを直接テキストエディターで見てもそれらしいものは無し。結局、grep して見つけました。

2011年6月8日水曜日

[WP7] ListBox のデータの仮想化

Windows Phone 7 の ListBox はデフォルトでも VirtualizingStackPanel を使います。そのおかげで、見えている部分+α 程度の要素だけを生成します。
要するに、1万行ある ListBox でも最初にいきなり 1万行作るわけではなく、見えている部分の 10行ちょっと程度だけ作ることによって高速化してくれるわけです。
ただこれはビジュアル要素(TextBlock やら Border やらのこと)についてです。
データについては、1万行だったらあらかじめ 1万行分必要です。
それを、最初に 1万行分作らなくても済むようにしようというのが「データの仮想化」です。

Virtualizing Data in Windows Phone 7 Silverlight Applications
この記事によると IEnumerable では無く IList を継承したクラスを ItemsSource にセットすることで、必要になったデータのみを取得するようになってくれるようです。
ちなみに、必要なのは Count、IndexOf、this[] の get のみでそれ以外は NotImplementedException を投げるようにしとくだけでも構わないようです。

で、さっそく試してみみても常に全件取得されちゃってなぜかまったく仮想化されず悩みました。
ふと気付いて試してみてわかりましたが、ItemTemplate が無いと仮想化されないんですね。

<ListBox>
    <ListBox.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding}"/>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

このようにほとんど意味が無くても ItemTemplate は必須みたいです。

これで試してみると、最初にだいたい 100件程度分 this[] が呼び出されて、あとは ListBox をスクロールすると必要に応じて適当に this[] が呼び出されるという感じです。
もちろん、IList ではなく IList<T> を継承したクラスでも問題無く仮想化されました。

というか、IList と IEnumerable の両方を継承している場合はちゃんと仮想化されるようです(IList の方が優先されてる)。
なので、List<T>、ObservableCollection<T>、普通の配列など、いずれも大丈夫なんじゃないかと。
ダメなのは IEnumerable、もしくは、IEnumerable<T> しか無い場合です。
この場合は、GetEnumerator() が呼び出されて最初に全件取得されます。

というわけで、普通にコレクションクラスを使ってる時は自然とデータの仮想化も使ってることになりそうです。
IEnumerable しか無いっていうと、一番ありそうなのは LINQ 関連のことをやってる場合ですね。

public IEnumerable<Data> GetItemsSource()
{
    for (var i = 0; i < 10000; ++i)
    {
        yield return new Data(i);    // ←このデータを作るのが重い処理
    }
}

こんなメソッドがあって、これを ListBox.ItemsSource に渡してるとか、
もっと直接的に

this.ListBox.ItemsSource = from i in Enumerable.Range(0, 10000)
                           select new Data(i);    // ←このデータを作るのが重い処理

こんな風なことをしてると、1万個の Data クラスのインスタンスが出来上がるまで UI が固まってしまいます。(Data クラスの中身が string がいくつかあるだけとかなら、1万個くらい一瞬で出来上がっちゃうかな。そういう場合はほとんど気にする必要は無いと思いますが)
LINQ を使ってると、便利なんでついつい 「from なんちゃら~」 で済ませてしまおうとしちゃいがちなのでちょっと気をつけた方がいいかも。(と、自分に対して言っておくw)

2011年6月6日月曜日

[Silverlight][WP7] DependencyProperty.RegisterReadOnly が無い

すごく今さらですが、Silverlight・Windows Phone 7 には DependencyProperty.RegisterReadOnly() メソッドが無いんですね。
うーむ。
探してみたら
Sometimes you just gotta do the best you can [Tip: Read-only custom DependencyProperties don't exist in Silverlight, but can be closely approximated]
こんな記事はありましたが。。。
SetValue されたときに元の値に戻して例外を発生させるという力業。。。つか、ちっとも ReadOnly じゃないじゃん。
RegisterReadOnly() メソッドくらい用意しておいてくれてもよかったような。