VB開発者のためのWindowsストア・アプリをリリースするための13の極意
極意12： アプリは応答を停止したり、予期せず終了したり、プログラミング・エラーを含んでいてはならない
当然ながらアプリにバグがあれば申請はリジェクトされる。その実例と、Webカメラを使った際のある不具合の解消方法を紹介する。
前書き ―― 今回の極意について
「Windows 8 ストア 認定の要件」に次のように明記されている。
これは至極当然のことだ。
この要件の意味
この要件の意味は明白だ。読んだままの意味である。「アプリにバグがあればリジェクトになる」ということだ。当然のことだが、これを回避することが結構難しい。自分では完璧なアプリを作ったと思っていても、思わぬところにバグが潜んでいてリジェクトされる。筆者も何度痛い目に遭ったことだろう。
デバッグ時にアプリが一応正常に動作し、何かの特殊なアクションを起こさない限り発生しないようなバグは、「Windows App Certification Kit 2.2」の検証では見つけることができず「合格」となる。
潜んでいるバグを発見するには、開発者が何度もテストして、バグを発見し、つぶしていく以外に方法はない。筆者も最初のころは、後述するスナップ表示でのローカル画像選択時のエラーは知らなかった。もちろんその対策をしないで申請したものだから、見事にリジェクトされてしまった。
アプリによるプログラミング・エラー
今回はWindowsストアに公開している「仮面をかぶろう」を例に、プログラミング・エラーについて解説していく（次の画面を参照）。
このアプリは、ローカルにある画像を選択し、リストボックスに表示されるマスクを、読み込んだ画像の上に拡大・縮小して、任意の位置に配置して合成保存するアプリだ。
このアプリで注意すべき点
このアプリでは、ローカルの画像ファイルを選択させるために、FileOpenPickerクラス*1を使用している。FileOpenPickerクラスは、ユーザーがファイルを開いて選択できるようにするUI要素を表わすクラスだ。そのFileOpenPickerクラスが、画面がスナップ表示の際にはエラーが発生してしまう（次の画面を参照）。
- *1現在提供されているWindows 8.1 RTM上で動作するWindows 8.1アプリでは、スナップ状態がなくなり、画面が最小幅でもFileOpenPickerなどは使用できるようになっている。TryUnsnapメソッドなどを使う必要はない。
エラーが発生するVBコード
では、エラーが発生するVBコードを見てみよう。
|
Private Async Sub readButton1_Click(sender As Object, e As RoutedEventArgs) Handles readButton1.Click
' FileOpenPickerクラスの新しいインスタンスを作成する
Dim myFileOpenPicker As New FileOpenPicker
myFileOpenPicker.ViewMode = PickerViewMode.Thumbnail
myFileOpenPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary
myFileOpenPicker.FileTypeFilter.Add(".png")
myFileOpenPicker.FileTypeFilter.Add(".jpg")
' ユーザーが1つのファイルを選択できるようにするファイルピッカーを表示する
' ここでエラーが発生する
myFile = Await myFileOpenPicker.PickSingleFileAsync()
If myFile Is Nothing = False Then
Dim myBmp As New BitmapImage
myBmp.SetSource(Await myFile.OpenReadAsync)
If myBmp.PixelWidth <> 640 OrElse myBmp.PixelHeight <> 480 Then
Dim message As New MessageDialog("640×480サイズの画像を指定してください")
Await message.ShowAsync
Exit Sub
Else
resultImage.Source = myBmp
End If
ListBox1.IsEnabled = True
ListBox1.Focus(Xaml.FocusState.Keyboard)
Else
Canvas1.Children.Clear()
resultImage.Source = Nothing
makeButton.IsEnabled = False
ListBox1.IsEnabled = False
End If
End Su
|
上記のコードではエラー処理を行っていないので、［画像選択］ボタンをタップした際に、エラーが発生してプログラムが予期せず終了してしまう。もちろんこれでは完璧にリジェクトされる。
不合格認定レポート
スナップ表示でのエラーに気付かなかったり、忘れたりしていて、エラー処理を行わずに申請すると、当然ジェクトされる（次の画面を参照）。
上記の画面が「仮面をかぶろう」でもらったリジェクト内容だ。「お客様のアプリは、要件 3.2 を満たしていません。」と記載されているのが見える。「要件 3.2」というのが、今回の「認定の要件」に該当する。
エラーの回避方法
このエラーはVBコードで回避する必要がある。その回避コードが次のコードだ。前述のreadButton_Clickイベント・ハンドラー内の先頭に次のコードを追加する。画面がスナップ表示になったときの処理だ。
|
' 画面がスナップ表示だったときの処理
If Windows.UI.ViewManagement.ApplicationView.Value = ApplicationViewState.Snapped Then
Dim message As New MessageDialog("スナップモードでは使用できません。通常のモードに戻してください。")
Await message.ShowAsync()
Exit Sub
End If
|
実行すると次の画面のように、スナップ表示になっている状態で［画像選択］ボタンをタップすると警告ダイアログ・メッセージが表示される。
または、ApplicationView.TryUnsnapメソッドで、スナップ表示を解除する方法もある。どちらの方法でも認定はされる。
Webカメラの不具合
では次に、Webカメラを使った際の不具合を紹介する。
WebカメラのAPIには「バックエンドからフロントエンドに復帰した際に、Webカメラの映像が固まる」といった不具合がある。しかし、このことが理由で、今まで、リジェクトされた記憶はない。ただ、最近ではフロントエンドに復帰した際でも、Webカメラが正常に動作するよう、プログラムを書き換えているため、現在でも、この不具合のままで認定されるかどうかは確認できていない。Windowsストアに公開されている、アプリの中で、バックエンドからフロントエンドに復帰した際に、Webカメラの機能が停止するアプリは見受けられる。現時点では、この不具合は許容範囲に入っているのかもしれない。しかし、審査基準は日ごとに厳しくなっている。この不具合でも、必ずリジェクトされるようになるだろう。今から、その対処方法を知っておくことは、大切だ。
使用するサンプル
筆者は現在、Windowsストアに「おばけ写真」とういうアプリを公開している（次の画像を参照）。
Webカメラで写した写真に、リストボックスから「おばけ」の画像を選択して、写真のうえに拡大／縮小して、任意の位置に配置して合成保存するアプリだ。
Webカメラのエラー処理を行っていない場合は、このアプリを一度バックエンドに回し、ほかのアプリで作業などを行い、再度、このアプリをフロントエンドに復帰させると、Webカメラが固まり使用不可能となる。アプリを再起動させる以外にWebカメラが再度使えるようになる方法はない。
VBコードに復帰した際の処理を記述する
この不具合を解決するには、バックエンドから、フロントエンドに復帰した際にでもWebカメラを正常に動作させるVBコードを記述する。以下のコードになる。
|
Protected Overrides Async Sub OnNavigatedTo(e As Navigation.NavigationEventArgs)
' AddHandlerステートメントで、現在アクティブ化されているウィンドウのVisible
' プロパティの値が変更されたとき、Current_Changedイベント・ハンドラーを追加する
AddHandler Window.Current.VisibilityChanged, AddressOf Current_Changed
Await DataShow()
MyBase.OnNavigatedTo(e)
End Sub
Private Async Sub Current_Changed(sender As Object, e As VisibilityChangedEventArgs)
' ウィンドウが表示されている場合はCameraRestartタスクを実行する
If e.Visible = True Then
Await CameraRestart()
End If
End Sub
Private Async Function CameraRestart() As Task
' 新しいMediaCatureのインスタンスを作成して、取得したWebカメラのデバイス名で、
' MediaCaptureオブジェクトの初期化設定を行い、プレビューを開始する
myMediaCapture = New MediaCapture
Try
Await myMediaCapture.InitializeAsync(New MediaCaptureInitializationSettings With {.VideoDeviceId = myCamera(cameraComboBox.SelectedIndex).Id})
CaptureElement1.Source = myMediaCapture
Await myMediaCapture.StartPreviewAsync
Catch
Exit Function
End Try
End Function
|
以上のコードを記述しておくことでWebカメラの不具合は解消される。しかし、このコードを記述しないで、バックエンドからフロントエンドに復帰した際、Webカメラの画像が固まっても、必ずしもリジェクトされるとは言い切れないことを付け加えておく。
Windowsストア・アプリでは、お作法という言葉をよく耳にする。Windowsストアのお作法にのっとったアプリが質の良いアプリとされている。本当にそうなのだろうか。「質の良いアプリと質の悪いアプリ」に関して、筆者の独断と偏見に満ちた意見をコラムに書いた。年寄りの戯れ言だと思って読んでほしい。
【コラム】質の良いアプリ、質の悪いアプリとは
以前にも触れたが、筆者はWindowsストアの審査が1カ月以上されない状態が続いたことがあった。大量のアプリをWindowsストアに公開しているうえに、1つのアカウントに同時に69個ものアプリの申請を行ったのが原因のようだった。
ある関係者からは、Windowsストアに公開しているアプリの数が多い割に、「質が悪く」、そのうえ、大量のアプリを申請したから、一種のブラックリストに登録され、審査の優先順位が下がって、審査を後回しにされている可能性があると言われた。
「質の悪いアプリ」と言われて筆者は一時落ち込んだ。質の良いアプリ、質の悪いアプリとは、誰が、どこで判断するのだろうと考えた。当時筆者は、2つのアカウントを持ち、合計で140個以上のアプリを公開していた。そして、ダウンロード数もそれなりにあり、筆者自身は満足していた。
それなのに、アプリの質が悪いから審査の優先順位が下がっている、質の良い、ベストなアプリを1個だけ申請して様子を見てください、と言われた。その場では、「分かりました」と返事はしたものの、筆者自身は納得できなかった。
アプリの質の良い悪いは、審査員が決めるものではなく、ユーザー自身が決めるものだと思っている。必ずしも、質の良いアプリが、多くダウンロードされ、質の悪いアプリはダウンロードされない、という図式は成立しないと思っている。要は、そのアプリがユーザーにとって必要であるか、必要でないか、という1点に絞られる。
いくらUI（ユーザー・インターフェイス）／UX（ユーザー・エクスペリエンス）に優れ、これぞまさにWindowsストア・アプリの見本だ、というアプリであっても、そのアプリが、ユーザーが必要とするアプリでないなら、全くダウンロードはされないだろう。ダウンロードされないから、質が悪いのか、といえばそうではない。逆にUI／UXは特に優れてもおらず、Windowsストア・アプリのお作法から、遠くかけ離れたアプリであっても、ユーザーが求めていたアプリなら、当然、ダウンロード数が増える。だから質の良いアプリなのだ、とは言いにくい。
質の良いアプリ、Windowsストア・アプリのお作法にのっとったアプリを作って、Windowsストアに公開するのがベスト、というのは、筆者の考えとは異なっている。筆者はWindowsストアのお作法に、必ずしも従う必要はないと思っている。要は、ユーザーが求めているアプリが何であるのか、ユーザーの目線で、ユーザーに必要なアプリを提供すること、これが一番望まれることだと思う。そしてもう1点、操作の分かりやすさが重要だと思う。操作の複雑なアプリは、ユーザーから敬遠される。筆者はWindowsストアのお作法にのっとったアプリが、操作性に優れているとは思えないのだ。かえって操作性が煩雑なアプリに思える。
Windowsストア・アプリに関しては、「お作法がうんぬん」という言葉をよく耳にする。そんなことは二の次であると筆者は思う。ただし、この極意で紹介した、最低限のWindowsストア・アプリのお作法には、従った方がいいだろう。それ以上のこと細かいお作法には、必ずしも従う必要はない。それ以上に、ユーザーにダウンロードしていただくアプリを作ること、それが一番重要なことだ。要は何でもそうだが、結果が一番なのだ。結果の付いてこないアプリは、良いアプリとは言えない。UI／UXに優れ、Windowsストア・アプリのお作法にものっとり、ダウンロード数も多いアプリ、これが天下無敵の質の良いアプリである。
安易に、質の良いアプリ、質の悪いアプリと口に出して言うべきではない。ダウンロード数が多ければ、それはユーザーが必要とする価値あるアプリであるのだから。
後で判明したことだが、筆者のアカウントが審査されなくなった原因は、「アプリの質」には全く関係がなく、大量のアプリを申請し、アプリのキャンセル、再申請を繰り返したため、「グループ審査」なる審査対象になって、審査に時間がかかったのが原因のようだった。まぁー、今でも「グループ審査」という意味が理解はできていないが(-_-;)。
余談だが、筆者は2013年6月30日現在、ストアに255個のアプリを公開し、総ダウンロード数は10万8555に達している。1アプリ当たりのダウンロード数は425強となる。公開国は日本だけなので、この1個当たりのダウンロード数には、筆者は満足している。
筆者の独断と偏見に満ちた意見だと思われた方には、心からおわび申し上げる。
お知らせ
Windows 8の［検索］チャームで「ストア」を指定し、検索欄に、「kuniyasu」または「YakushijiKuniyasu」または「eightman」と入力すると、筆者の公開しているアプリの一覧を見ることができる。
■
今回はこれで終わりだ。そして今回で「Windows 8 ストア 認定の要件」に基づいた、筆者の経験による、Windowsストア・アプリの審査に通るノウハウの解説は終わりだ。ここまでの、ここで紹介したノウハウが、読者の皆様のお役に立つことを願ってやまない。
ここまでの連載で、内容についての、ご批判、ご不満は多々あると思う。しかし、前もって断わっておいたように、この極意は、筆者の実体験を基にした極意だ。その点を考慮して、ご批判、ご不満は、皆さまの腹の中に収めていただきたいと願う<m(__)m>。
最終回となる次回は、実際に作ったWindowsストア・アプリの、「アプリ・パッケージ」の作り方から、実際に申請する一連の流れを、順を追って解説していく予定だ。お楽しみに。
では、また次の記事でお会いしよう。
※以下では、本稿の前後を合わせて5回分（第9回～第13回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
9. 極意9： アプリで提供されるプライマリ・エクスペリエンスはアプリ内で行われなければならない
Windowsストア・アプリからWeb上の情報を表示するために、Webブラウザーを開くと申請時にリジェクトされる？！ その対象方法を紹介する。
10. 極意10： サポートしている全ての言語でアプリをローカライズしなければならない
日本語版のWindowsストア・アプリ上の表記に英単語があると申請時にリジェクトされる？！ その対象方法を紹介する。
11. 極意11： バージョンの一致と日本語OS
アプリの実バージョンと、表示しているバージョンが一致していない場合のリジェクト例。また、日本語版限定に用意した機能を申請する場合に注意するポイントを紹介する。
12. 【現在、表示中】≫ 極意12： アプリは応答を停止したり、予期せず終了したり、プログラミング・エラーを含んでいてはならない
当然ながらアプリにバグがあれば申請はリジェクトされる。その実例と、Webカメラを使った際のある不具合の解消方法を紹介する。
