いよいよアプリ作り本番！どこからはじめる？

課題の解決策を考えておく

企画の過程で実装する処理が明らかになるにつれ、課題も浮かび上がってきます。このアプリでは、次の3点を解決する必要がありそうです。

1. メインページ、入力ページ、表示ページという3つのページの実装方法
2. 3つのページ間の連携処理
3. データの保存先と構造

こういった課題の中には、テストしてみなければ分からないことや、知識を得なければ解決できないこともあるかもしれません。できるだけ事前に洗い出して、実開発を始める前に解決策を見いだしておきたいものですね。

複数ページの実装方法

このアプリは、「メインページ」「入力ページ」「表示ページ」といった複数のページから構成されるようになります。複数のページを扱うには、Panorama、Pivot、複数のPortrait Pageという3つの選択肢が考えられます。

しかし、それぞれ適用範囲は異なり、どれを使っても同じ処理で済むというわけではありません。

Panoramaは、Windows Phone 実機の1画面に収まらない1つのコンテンツを、複数のページに分けるために使うものです。ページが複数に分かれているだけで、内容はひとつながりです。そのため、「一日一句」には適しません。

また、Pivotは、互いに影響することのない複数の画面を乗せるコンテナのようなもので、連携し合う複数の機能を乗せることには適していません。また、Pivotでは、ユーザーは次のページにも、前のページにも進むことができます。それでは操作手順が分かりにくくなり、ユーザーが混乱するかもしれません。

このアプリでは、入力した結果を表示するというように、手順を追って処理を進めますから、「メインページ」と「入力ページ」にはPortrait Page、記録された俳句をフリックで一覧できるようにする「表示ページ」や、テキストの多い「ヘルプページ」にはPanoramaを使うことにします（図2）。

複数ページ間の連携処理

このアプリは、「一日一句」と銘打ってはいますが、その意図は「できるだけ一日に一句、詠んでみませんか」という呼びかけにすぎません。一日に何句も詠むユーザーもいるでしょうから、一日に一句しか記録できない処理であってはなりません。

それには、メインページから入力ページに移動して俳句を入力し、表示ページで入力結果を確認した後、また入力ページに戻って次の俳句を入力できるUI にする必要があります。3つのページ間を行き来しても、正しくデータが記録され、表示されなければなりません。

目的のページへの移動方法が分かりにくかったり、何度も同じ操作を繰り返さなければ目的のページにたどりつけないといった、ユーザーに手間を強要する設計は避けたいところです。また、複数のページを行き来した時、キャッシュをクリアしておかなければ、意図しない表示になる恐れがありますので、これも防がなければなりません。

そこで、このアプリでは、図3のように、3つの処理を記述することにします。

• 俳句入力ページには、メインページに戻る時に「ホームに戻ったことを示す値を渡す処理」を記述する。
• 俳句表示ページには、入力ページに戻る時に「最新のエントリに移動する処理」と、メインページに戻る時に「ホームに戻ったことを示す値を渡す処理」を記述する。
• メインページに戻った時は、「履歴をクリアする処理」を記述する。

データの保存先と構造

さて、もうひとつ、データの保存先と構造を検討する必要があります。

まず、保存先について考えてみると、いくつかの方法があることに気付きます。

1つ目は、Windows Phone実機の中です。Windows Phone実機の分離ストレージ コンテナ内に、アプリ側からローカル データ ストレージを作成し、これを指定してデータを蓄積します。この方法では、データの入出力処理は、アプリ内の分離ストレージに限定されるので安心です。また、キーと値の組み合わせで保存することもできます。

分離ストレージ コンテナ内のローカル データベースにRDBデータを格納して、LINQ to SQL で処理することもできます。

実機内保存では、画像の場合、PictureHubに保存させる方法もあります。

蓄積可能なデータのサイズは、実機の空き容量に依存するため、採用可否の判断基準になるでしょう。大容量になる場合は、次に紹介するWebサーバーへの蓄積が考えた方が良いでしょう。

データ保存先の2つ目は、Webサーバーです。Windows Phone アプリを、Webサーバーに配置したASP.NET Webサイトや、Azureサービスと連携させる方法が考えられます。

Windows Phone を入力専用デバイスとして扱う場合は、Windows Phoneアプリ側に、入力処理と、データ処理命令の送信処理を実装します。Webサーバー側から送信されたデータや処理要求を受け取って、データ処理を実行させることもできます。

また、すべての処理はサーバー側で行い、Windows Phone は表示専用デバイスとして扱う方法もあります。

通信が保証されるかどうかが、採用基準になります。通信が保証されない場所で使われる可能性があるなら、ローカル ストレージへの保存を採用するか、あるいは併用が望ましいと考えられます。

3つ目は、データの保存を、SkyDrive への保存や、facebook、twitterといったソーシャルメディアへの投稿で代替する方法です。ローカル ストレージやWebサーバーへの蓄積と並行して自動的に投稿を実行させたり、選択されたデータのみを手動で投稿できるようにする方法も考えられます。この方法を採用するには、認証をユーザーに煩わしく感じさせないUIデザインを考える必要があります。投稿の必要性が採用基準になるでしょう。

このアプリの場合は、「分け入っても分け入っても青い山」のような、ネットワークに接続できない環境で使われる可能性が考えるため、ローカルストレージへの保存を採用します。「DailyHaikuData」フォルダを生成し、その中に俳句ファイルを保存していきます。

そして、バージョンアップ時には、ローカルストレージへの保存だけでなく、facebookへの投稿にも対応することにします。

※データ処理については、これまでの連載を参照してください。

• Windows Phone Tips集　第3弾「第2回 撮影した動画を専用サーバーに保存し、再生する」
• Windows Phone Tips集　第3弾「第7回 撮影した写真を分離ストレージとPicturesHUBに保存する」
• これから始めるWindows Phone プログラミング（応用編）「第9回 ローカルデータベースの利用と郵便番号検索」

※データの扱い方については、Microsoft サイト内の次の記事や情報も参考になるでしょう。

• 「Windows Phone のローカル データ ストレージ」MSDN
• Code Recipe [C#] 分離ストレージに値を保存する
• 「Windows Azure アプリへの通知機能の実装」Windows Phone 開発者向け技術情報

データ形式と構造

データの蓄積場所が決まったところで、データの形式や構造を検討します。

このアプリでは、記録した俳句データを、句集編さんや応募作の選定の際に再利用できるようにしたいので、再利用に便利なXML形式を採用することにします。

Windows Phoneアプリでは、ハードウェアのスペックに上限がありますから、XMLの構造は、その範囲で処理できるものにする必要があります。

もっとも、XML黎明（れいめい）期には低スペックのPCで、しかも処理速度がメモリサイズに依存するDOMを使ってXMLデータを処理していたのですから、現在の高スペックなWindows PhoneでLINQを使って処理することを考えれば、さほどシビアになる必要はありません。

まず、最大予想ノード数（1俳句あたりのノード数×俳句数）と、処理速度（Windows Phoneのスペックでの読み込みや走査）を考慮したうえで、ファイルの分割方法を、次の3つのうちのどれにするのかを考えます。

• 全データを、1個のXMLファイルにまとめる。
• 選択した季節ごとに4つのファイルに分ける。
• 登録年月日によって、さらに細かく複数のファイルに分ける。

俳句はひらがなで詠んだとしても1句17文字であり、一日一句を詠んでタグを付けても、大したファイルサイズにはなりません。処理効率の問題は微々たるものですが、かといって全データを1個のXMLファイルにまとめて保存し、小さなWindows Phone の画面上にそれらすべてを表示したのでは、フリック操作して確認するのが面倒です。ユーザーにとって親切とは言えません。

そこで、季節別の4つのファイルに分けることにします。4つに分ければ、一日2句を詠んだとしても、1ファイルあたり200句程度です。1ページに6句を表示したとして30ページ強です。この程度であればフリックして確認するには問題ないでしょう。

そこで、登録されるデータは、spring.xml、summer.xml、autumn.xml、winter.xmlという、季節別の4つのファイルに保存することとします。

しかしながら、バージョンアップ版では、季節別という分け方は見直したいと思います。なぜなら、諸外国においては、日本の四季の感覚をそのまま持ち込むことが難しいからです。常夏の国もあれば白夜の国もあります。月別に分ける方が無難でしょう。

以上のような考えに基づいて、このアプリでは、リスト1のような構造のXMLドキュメントを生成して、保存することにします。

リスト1　「一日一句Ver.0.8」で生成保存するXMLドキュメントの構造

<?xml version="1.0" encoding="utf-8" ?>
<俳句集 季節="ユーザーが選択した季節名">
  <俳句 日時="年月日">
    <ルビ>ルビ欄に入力されたルビやコメントなど</ルビ>
    <句>俳句</句>
  </俳句>
  <俳句>要素、繰り返し
</俳句集>

さらに、この構造のデータをコピー＆ペーストして、365日分のダミーデータを作成してみます。ファイルサイズを確認すると、55KBです。これなら全く問題なく処理できます。