Moonmile Solutions Blog

Windows 8 Store apps Advent Calendar : ATND
http://atnd.org/events/33803

の 15 日目のネタですね。本当は「親馬鹿アプリ」のほうにする予定だったのですが、ずるずる状態になってしまったので、以前ブログに書こうと思っていたネタを掘り出してきました。

最初に言うと「書こうと思っていた」というのは、まだ調査途中で「本当にこれが効率的なのか？」、「定番なのか？」ってのがわからないので、保留にしていたわけで…ええ、忘れていたのもぽちぽちなのですが、まあ、年末だし蔵出しということで。

さて、パラパラアニメといえば「アニメgif」なのですが、いろいろ調べてみると、WPF でうまく表示する方法がありません。いや、探せば「MediaElement」を使う方法がでているので、Windows ストア アプリでも使えるのかもしれません（試しておりません）。ですが、今回はもうちょっと違った方法を取ります。

よくゲームアプリで使われている手法で、俗に「うなぎの画像」と呼ばれる…って呼びませんね、なんと言うのかわからないのですが、横に長い画像を使います。ひとつひとつのセルを横につなげて、表示したい位置をスライドさせるという手法ですね。実は、C++/CX のほうには、これが使える Bitmap オブジェクトがあってそれが「ウリ」だったりすのですが、果たして C# にはあるのか？って、のを夏のセッションを聞いたときに思ったのですが、そのところはちょっと不明です。

ちなみに C# で WritableBitmap を作る方法は、

byte配列からWriteableBitmapオブジェクトを作成する – 酢ろぐ
http://d.hatena.ne.jp/ch3cooh393/20120802/1343892131

を参照ということで。

この「うなぎ画像」を使うと便利なのは、

• それぞれのセルがひとつに連なっているので、管理が簡単？
• 複数のセルを読み込まないで済むので、ロード時間が少なくて済む。

ってところです。実際、やってみるとわかるのですが、60 枚近い画像を切り替えるのと、1枚の画像をクリップしながら表示するのでは、CPU への影響が格段に違い、アニメーションもスムースになります。

というわけで、ざっと作り方を紹介。

■うなぎ画像を作る。

適当に Form アプリで「うなぎ画像」を作るツールを作ります。

private void button1_Click(object sender, EventArgs e)
{
    int w = 46*60;
    int h = 46;

    for (int n = 1; n <= 6; n++)
    {
        Bitmap allBmp = new Bitmap(w, h);
        Graphics g = Graphics.FromImage(allBmp);
        for (int i = 1; i <= 60; i++)
        {
            string p = string.Format(@"\temp\balls\{0}\{1:00}.png", n,i);
            Bitmap bmp = new Bitmap(p);
            g.DrawImage(bmp, 46 * (i - 1), 0, 46, 46);
        }
        allBmp.Save(string.Format( @"\temp\ball{0}.png",n));
    }
}

画像自体は、とあるゲームからパクってきたものです。
画像サイズが、46×46 固定なのは、まあ、ツールなので。

■アニメ用のユーザーコントロールを作る

いくつか試したのですが、ユーザーコントロールを作るのが一番楽です。

<UserControl
    x:Class="AniBallControls.AniBall"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:AniBallControls"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="92"
    d:DesignWidth="92">
	<UserControl.Resources>
        <Storyboard x:Name="sbAnime" RepeatBehavior="Forever">
			<DoubleAnimationUsingKeyFrames x:Name="keyFrames1" 
				Storyboard.TargetProperty="(Canvas.Left)" 
				Storyboard.TargetName="img">
                <DiscreteDoubleKeyFrame KeyTime="0:0:0" Value="0"/>
            </DoubleAnimationUsingKeyFrames>
		</Storyboard>
	</UserControl.Resources>
    <Canvas>
        <Image x:Name="img" Source="ms-appx:///balls/ball1.png" 
			Width="5520" Height="92" 
			Canvas.Left="0" Canvas.Top="0"/>
        <Canvas.Clip>
            <RectangleGeometry Rect="0,0,92,92"></RectangleGeometry>
        </Canvas.Clip>
    </Canvas>
</UserControl>

46×46 では、デモ用には小さかったので、96×96 に拡大しています。
storyboard を使ってアニメーションさせていますが、中身は後からプログラムで書きます。最初はツールを使って XAML に書いていたのですが、プログラムで書けることが分かったので実行時に書き込みます。
Canvas の上に乗っけて、Canvas.Clip しているところがミソですね。たぶん、WPF とか Silverlight での定番の処理だと思うのですが、似たようなは見つかりませんでした。他にいい方法があるのかも？ この clip 位置を、スライドさせる（実際には Image オブジェクトの位置をずらす）ことで、アニメーションができます。

デザイナで見ると、うまくクリップされていることがわかります。本当は横に長い画像なのですが、一番左のセルだけがクリップされています。

で、実際にアニメーションさせるコードがこちら。

public sealed partial class AniBall : UserControl
{
    public AniBall()
    {
        this.InitializeComponent();
    }

    private Size _imageSize = new Size(92, 92);
    private int _curIndex = -1;
    private int _imageCount = 60;

    public ImageSource Source 
    {
        get { return this.img.Source; }
        set { this.img.Source = value; }
    }

    public void Start()
    {
        var kf = this.keyFrames1;
        kf.KeyFrames.Clear();
        for (int i = 0; i < _imageCount; i++)
        {
            var dd = new DiscreteDoubleKeyFrame();
            dd.Value = -_imageSize.Width * i;
            dd.KeyTime = new TimeSpan(10 * 1000 * i * (1000/60)); // 1/60 sec
            kf.KeyFrames.Add(dd);
        }
        this.sbAnime.Begin();
    }
    public void Stop()
    {
        this.sbAnime.Stop();
    }

    private void onTimer(object sender, object e)
    {
        _curIndex++;
        if (_curIndex >= _imageCount)
            _curIndex = 0;
        Canvas.SetLeft(this.img, - _imageSize.Width * _curIndex);
    }
}

普通の storyboard では、開始位置と終了位置を連続につなぎますが（直線とかスプラインとか）、ぱらぱらアニメの場合は、とびとびの値にします。この飛び飛びの値を作るのが DiscreteDoubleKeyFrame クラスですね。これは Blend の Storyboard でも変更できるので、ちまちま 60 フレーム作ることも可能なのですが…面倒なので、プログラムでやります。

この ontimer の負荷がどのくらいかというと、

なところで、3% 以下ですね。ひとつのアニメなので、複数配置したときはどうなるのかは検証していませんが、普通のアニメGIFっぽいことをしたいのであれば、これで　OK かと。
ちなに、60 枚の画像切り替えをすると、CPU は 3% 程度で同じなのですが、画面の駒落ちが発生します。どうやら、Image.Source に設定するときが重いらしく、そのあたりの負荷を減らすためにも、一枚のうなぎ画像を使ったほうがよいみたいです。

■メインページを作る

テスト用のメインページには、こんな風に貼り付けます。ユーザーコントロールはツールバーに出てくるので、普通にドラッグ＆ドロップすれば ok.

<local:AniBall x:Name="aniBall1" Source="ms-appx:///balls/ball1.png"
    HorizontalAlignment="Left" Height="100" 
                Margin="251,266,0,0" VerticalAlignment="Top" Width="100"/>

タップイベントを設定しておいて、開始と終了を制御します。

AniBall curBall = null;
private void aniBall_Tapped(object sender, TappedRoutedEventArgs e)
{
	if (curBall != null)
	{
		curBall.Stop();
		curBall = null;
	}
	else
	{
		curBall = sender as AniBall;
		curBall.Start();
	}
}

実は、Storyboard が実行中かどうかを取れるので、それをプロパティにすれば良いのですが…まあ、デモなので、これで。

■実行してみる

動かしてみると、結構スムースにくるくると回ります。これだったらゲームに使えるよねっていう感じで、これぐらいだったら、DirectX + C++/CX を使う必要はあるまい（本来はこれが目的）、っていう感じで動きます。

ちなみに、Image コントロールは、透過PNG を扱えるので、背景を付けることもできます。

これができると、パズルゲームぐらいならば、C# で書けそうですよね…って感じですかね。年末年始の休みを利用して、ひとついかがでしょうか？　ええ、私は、たぶんお仕事かと orz.

ふと、思いついたネタです…続くかどうかわかりませんが…ちなみに、アプリ自体はできています。

クリスマスに向けて、親馬鹿アプリを作ってクリスマスプレゼントの代わりにしよう企画～～～ぱぶぱふ～、ってことで、思いついたのでブログネタにしておきます。

絵本を読んでいて常々気になっていたのが、自分の娘や息子向けに作るというパターンです。絵の場合は、絵本を作ればいいけど、じゃあ、プログラマの親の場合はどうするのか？ってことで、じゃあ、自分の子供向けにアプリを作ればいいじゃないか？、ってところに至りました。

が、ノートパソコンは壊されると怖いし、デスクトップアプリだといまいち食いつきが悪いし、iPad のアプリでもいいんですが実機に乗せるには年会費が掛かるし（まあ、私の場合は払っているからいいんでけど）…ってことで、Windows 8 のタブレット PC の子供用アプリを作ります。

タブレット PC の値段が～、ってことなのですが、私の手元にあるのは acer w500。android のほうだと20,000円ってところなのですが、そこは windows 7 のほうの 40,000円のほうを買って、windows 8 に乗せ換えます。

[win8] Acer w500 に windows 8 cp をクリーンインストール（続き） | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/3304

なんかを参考にしてドライバーを入れ替えてください。

さて、どうせ家庭内で使うアプリ（しかも子供向け）なので、準備するものとしては、

• タブレット PC 実機（もちろん windows 8）
• Visual Studio 2012（Express でもok） + Widnows 8 マシン
• 子供の写真（デジカメとか）
• 子供の食いつきそうな版権もの（きかんしゃトーマスとかミッフィーとか）

ってところですかね。どこにも公開しないので、個人情報とか版権とか無視です。ええ、私家版ですから。

～

で、作ったアプリがこれ。スライドパズルです。

よく見ると、英語で「Shaffle」とか「Reset」とか書いてありますが、まあ、小２の娘はボタンを押せばなんとかわかるみたい。２歳児の息子は、16ピースだと難しいらしいのですが、ぽちぽちと正しい位置に置く（２つのピースをタップして、交換させます）をやろうとはしています。なので、４ピースぐらいにするのを計画中。

～

プログラム的には、MVVM っぽい形にしているのですが、失敗中。そのあたりも含めて、ソースコードを後日に公開します。プログラム自体は、C# で 300行弱といったところです。ピースと、ピースをまとめたボード、というユーザーコントロールを作っているので、画像の差し替えは比較的楽かな、とおもっているのですが…プログラム上

• 画像の大きさが固定になっている
• ピースの数が16ピース固定になっている

という問題があって（私家版なのでこれで良いのですが）、さきほどの２歳児用の４ピース版を作るためには…うーんと唸っている途中です。あと、画像自体はリソース組み込みなので、本当は SkyDrive に配置して、子供に選ばせたいですよね、とか考えてみたり。

と、サンデープログラマっぽいことができるのが、Windows ストア アプリの良いところかなあと気づいたりしております。

StorageFile の Open は、通常の Open/Close とちょっと違う | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/3880

の続きです。

Windows ストア アプリでは、fopen/fclose のようにファイル名を指定して、ファイルの読み書きができません。サンドボックス的なセキュリティを維持するために常に StorageFile クラスを使います。このクラスは、アプリ ローカルのフォルダから直接作るか、ピッカー（FileSavePicker など）を使って作ります。

ってのが前回の話で、FileSavePicker から戻ってきたときには、ファイルが既に作られています、ってのがちょっとした「落とし穴」なのです。

■ピッカーで保存先のファイルを選択

ピッカーを使って、デスクトップに保存するファイルを選んでね、ってのが次のコードです。

private StorageFile _file;
/// <summary>
/// ファイル選択のみ
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private async void Button_Click_0(object sender, RoutedEventArgs e)
{
	// FileSavePicker を用意する
	var picker = new FileSavePicker();
	picker.CommitButtonText = "データを保存する";
	picker.DefaultFileExtension = ".txt";
	picker.FileTypeChoices.Add("テキスト形式", new string[] { ".txt" });
	picker.SuggestedStartLocation = PickerLocationId.Desktop;
	picker.SuggestedFileName = "Sample.txt";
	// FileSavePicker を出して、ファイルを指定する。
	StorageFile file = await picker.PickSaveFileAsync();
	if (file == null)
	{
		// キャンセルされたときは何もしない
		return;
	}
	_file = file;
}

ピッカーの PickSaveFileAsync メソッドの戻り値は、StorageFile オブジェクトなので、キープしておくと、あとから利用できます。いわゆる２度目に「保存」ボタンを押したときには、ユーザーに問い合わせをしない、ことが可能です。上書き保存ってやつです。

ここで、保存先のファイルってのは新規ファイルとは限らなくて、存在するファイル（中身があるファイル）でも ok なわけです。まあ、そうですよね。なので PickSaveFileAsync メソッドからの戻りは、

1.PickSaveFileAsync が作った空ファイル（サイズ 0 のファイル）
2.元からある、いくらかのサイズのファイル。
3.元からある、サイズ 0 のファイル

ここで、1 と 3 の区別（新規ファイルなのか、既存ファイルなのか）がつかないのが問題…になるかもしれんッ!!! と思ったわけですが、これから上書きしようとするわけだし、どっちでも構わないんじゃない？というのが設計思想のようです。

■保存するモデル

アプリのデータを DataModel にしておきます。

public class DataModel : BindableBase
{
	private int _id;
	public int ID
	{
		get { return _id; }
		set { _id = value; this.SetProperty(ref this._id, value); }
	}
	private string _name;
	public string Name
	{
		get { return _name; }
		set { _name = value; this.SetProperty(ref this._name, value); }
	}
}

画面のほうには、適宜 Binding を書く、というパターンですね。
クラスにしておくとシリアライズが楽なので。Windows ストア アプリの場合は、DataContractSerializer を使うと便利です。

■DataContractSerializer を使う

モデルデータを、そのままシリアライズするのが一番楽です。既に用意されている DataContractSerializer を使って、WriteObject メソッドを使って XML 形式で書き込めば okですね。

private async void Button_Click_1(object sender, RoutedEventArgs e)
{
	StorageFile file = this._file;	// 選択済み
	var data = new DataModel()
	{
		ID = 10,
		Name = "masuda tomoaki"
	};
	// これは正常に動く
	using (var stream = await file.OpenStreamForWriteAsync())
	{
		var serializer = new DataContractSerializer(typeof(DataModel));
		serializer.WriteObject(stream, data);
	}
}

ただ、DataContractSerializer クラスで書き出す XML って、改行とかインデントがついていなくて、デバッグに不都合があるのです。
なので、XmlWriter を使えば整形できるのでは？と思ったのが、ハマリどころです。

■XmlWriter を使う

XmlWriter を使って整形（改行やインデント）を使いながら、書き出します。

private async void Button_Click_2(object sender, RoutedEventArgs e)
{
	StorageFile file = this._file;	// 選択済み

	var data = new DataModel()
	{
		ID = 10,
		Name = "masuda tomoaki"
	};
	// これは正常に動く
	using (var stream = await file.OpenStreamForWriteAsync())
	{
		var serializer = new DataContractSerializer(typeof(DataModel));
		// ストリームを切り詰める
		stream.SetLength(0);		// これが必須
		// インデント等を設定する
		var st = new XmlWriterSettings();
		st.Indent = true;
		st.IndentChars = "\t";
		st.Async = false;        // 書き込み時に async を使わない
		using (var xw = XmlWriter.Create(stream, st))
		{
			serializer.WriteObject(xw, data);
		}
	}
}

この中で「stream.SetLength(0)」ってのがあります。これ、ファイルは「新規だ」と思っていると、実は違っていて「既存のファイル」かもしれないのです。で、既存のファイルを OpenStreamForWriteAsync メソッドで開くと、中身はそのままオープンって具合なわけです。

なので、もし既存のファイルよりも短い XML を書き込んだ場合、最後の閉じタグの後ろにゴミが残るんですよね…これはかなりはまりました。
fopen 関数だと、新規オープンなのか、追加オープンなのかの選択があるのですが、実は OpenStreamForWriteAsync には、その選択肢がないのです。さらに、PickSaveFileAsync では、新規のファイルでも 0 バイトのファイルができるし。
OpenStreamForWriteAsync の場合は、ファイルをオープンすると、先頭にカーソル位置が置かれるのですが、これは既存ファイルをオープンしたときも先頭にカーソルがあります。ってのが落とし穴ですね。

なので、この変な状態を解決するために「新規ファイル」として扱うためには「stream.SetLength(0)」のように、ストリームの長さを 0 に初期化する必要があるのです。

■テキストファイルに保存

そんな訳で、メモ帳のようなテキストファイルを扱うアプリを作ると更にはまります。

private async void Button_Click_3(object sender, RoutedEventArgs e)
{
	StorageFile file = this._file;	// 選択済み
	// 実は上書きモードでオープンしている
	using (var stream = await file.OpenStreamForWriteAsync())
	{
		// 新規扱いの場合は、サイズを 0 にする必要あり
		stream.SetLength(0);

		using (var writer = new StreamWriter(stream))
		{
			// テキストをそのまま書き込み
			writer.Write(text1.Text);
		}
	}
}

毎回、全体を保存するから、StreamWriter クラスの Write メソッドで書き出せば ok … と思いきや、この「stream.SetLength(0)」を忘れると、もともとあったファイル長さよりも文章（text1.Text）の方が短い場合には、後ろにごみが残るのです。

■Stream にも StreamWriter にも Close がない

で、Stream も StreamWriter も Close がありません。Open したら Close したくなるものなのですが、まあ、開きっぱなしでいいみたいです。というか、using で範囲を決めないとダメかもしれませんね。
テキストの書き込みだと、StreamWriter クラスの using で抜けるときに、同時に Stream のほうも閉じてくれます…と云いますか、閉じてしまいます。これは、以前からの仕様だったような気がします。

なので、ファイルの後ろを切り詰めようとして次のように書くとエラーになります。

private async void Button_Click_3(object sender, RoutedEventArgs e)
{
	StorageFile file = this._file;	// 選択済み
	// 実は上書きモードでオープンしている
	using (var stream = await file.OpenStreamForWriteAsync())
	{
		using (var writer = new StreamWriter(stream))
		{
			// テキストをそのまま書き込み
			writer.Write(text1.Text);
		}
		// 現在位置で切り詰める
		stream.SetLength( stream.Position );	// ★
	}
}

★の位置では、stream が閉じられちゃっているので、SetLength できません。
下記のように、StreamWriter のブロックで SetLength するとうまく動きます。

private async void Button_Click_3(object sender, RoutedEventArgs e)
{
	StorageFile file = this._file;	// 選択済み
	// 実は上書きモードでオープンしている
	using (var stream = await file.OpenStreamForWriteAsync())
	{
		using (var writer = new StreamWriter(stream))
		{
			// テキストをそのまま書き込み
			writer.Write(text1.Text);
			// 現在位置で切り詰める
			stream.SetLength( stream.Position );	// ★
		}
	}
}

これもなんか変な仕様ですよね…と思いつつ、まぁ、いいかと。

OpenStreamForWriteAsync メソッドに、新規バージョンと追加バージョンがあればわかりやすいんですがね。

・OpenStreamForNewWriteAsync()
・OpenStreamForAppendWriteAsync()

のような名前にすればよかったのに。。。まあ、拡張メソッドを2,3行書けば、済むはなしなんですが。