Pubcenter での自アプリ広告

この記事の要約

• Microsoft Pubcenter に、有料の広告が無い場合に自アプリの広告を表示する機能がついた
• 自分のアプリに自分のアプリ広告を載せる分にはタダ
• 広告料を払うことで、PubCenter を使っている他アプリに自分のアプリ広告を出す事も可能

Wheel World Clock の下部に
自アプリ(PICT8)広告が表示されている様子

要約でほぼ全て語りつくしているのですが…昨年10月、Microsoft Pubcenter に「広告が無い場合に自アプリの広告を出す」、という機能がつきました。

Announcing New Capabilities for Developers to Promote their Windows and Windows Phone Apps
http://advertising.microsoft.com/en/blogpost/129472/microsoft-advertising-blog/announcing-new-capabilities-for-developers-to-promote-their-windows-and-windows-phone-apps

先日リリースした Wheel World Clock で試しに使ってみています。
※上のblogでは英語圏のみサポートとなっています。が、現状日本でも広告が表示されるようです（販売が日本のみ…en-us用のストアURLが無い場合は無理かもしれない）。

広告の製作

Pubcenter Dashboard から行います。
https://pubcenter.microsoft.com/Dashboard

Dashboard 右側の「Ad Campaigns > Promote your app」をクリック

「Promote your app」をクリックすると、下の広告作成画面になります。
画面に従ってマウスで突っついていけば終わります。

広告を作成している様子

注意点としては…

• 最初にアプリのストアURLを入れるのですが、ここは英語圏用なので「en-usの」URLを入力します。ja-jpは通りません。
• ここのフォームの入力チェックは少し変わっていて、入力後フォーカスが外れた所で入力のValidationが行われます。
• 広告に使う画像は、ストアに登録しているストアアイコン(*1)・スクリーンショットの中から選びます。
• 使える広告サイズは、728x90, 160x600, 300x250 の三種類です。
• 一行、アプリの紹介を追加できます。ここも文字数・WordingのValidationがあります。

余談１
広告で使われるアイコンは、アプリのPackage.appxmanifest で指定する「ストアアイコン」です。
これは僕も含めてかなりの人がはまっている罠なのですが、
ストアアイコンは背景を透明にしてはいけません。
Windows ストア だけは背景色をManifestで設定した色で塗ってくれるのですが、それ以外…このPubCenterやWindows Phone ストア、又MS以外のストアのXMLをクロールするようなサービス…AppFedsやApp annie等は全て指定した背景色を無視し、ストアアイコンをそのまま表示します。

この為、背景が透明＋前景のアイコン図柄が白の場合はほぼ何も見えないという悲しい結果になります。

辛うじて灰色背景なので見えているアイコン

逆に、スタート画面等で使うタイル 画像については基本、背景は透明にしたほうが見栄えは良くなります。
ただ、デザイン上全部塗るスタイルもあるので…ここはアプリそれぞれです。

余談２
タイル画像・ストアアイコン、数が多いので人力で作るのは大変です。
自動生成してくれるサービスは幾つかありますが、僕が何度もお世話になっているのはここです。（ストアアイコンも背景透明で作ってくれてしまうので注意）

Windows Store Image Generator
http://wat-docs.azurewebsites.net/Tools

• Windows / Windows Phone 両対応
• Splash画像やPromotion画像も作ってくれる　（そのまま使う事はあまり無いですが、指定サイズの画像が作られるだけでも作業はかなり捗ります。数が多いので。）

Win10 TP build 9926, アプリ開発目線で見た感想

(画像を追加しました 1/25）
首記の通り、今回初めてタブレットでWin10の動作を確認することができました。
アプリ開発にあたって、これは影響あるなぁと思った事を書いたよ、という記事です。

ただ、今回まだTechnology Preview であるので、「Win10はこういう動きをするよ！さあ今すぐアプリを書き換えよう！」というつもりは全く無いです。

APIやDesignの詳細が出る4月の//Buildまではもう何がどう変わってもおかしく無いと考えるべきですし、それの前に作業するのは完全にDouble Effortになってしまいます。
が、
今後MSさんはどうするつもりなのかな、というのは判っとかないと結構怖い。今作ってるアプリが//buildでフタ開けてみたら全然デザインに合わなかった、というのはしんどいです。
そういう視点でチェックした確認と、その感想を思いつくままがーっと書いてみました。

（まだ使って1日目ですが、「1日目の感想」……まだ慣れる前に感じたことは後々はもう思い出せないので）

ファイルピッカーの動作

ストアアプリのFilePickerOpenCallで、FilePickerが出てこない。DesktopのCommonFileDialogが出てくる。
StoreAppから開く場合、CommonFileDialogのナビゲーションペイン内にFilePickerContractを提供するアプリが表示され、Contractはそこから使える。

感想　タッチ用にFilePickerは残しておいてよかった気がするが　Contractが使えるのは大きな進歩（以前のWin10 Buildでは使えなかった）

タブレットモードOn・Offの違い

（以降Tab On/Offと表記）

キー入力を食うコントロール（Textbox等）をタッチした場合

• Tab On　即ソフトキーボードが表示される。
• Tab Off　手でタスクバーのキーボードボタンを押し、呼び出す。

これはストアアプリ・デスクトップに関わらず共通。

感想　TabOnでデスクトップアプリはかなり使いやすくなったのでは。また、手に持ってピュアタブとして使う場合はTab On 必須になるのでは（いちいち手で押すのは苦痛）

アプリ領域の分割

• Tab On　できる
• Tab Off　できない

感想　これは使ってみると差がかなりあって、ピュアタブとして使う場合Tab Offは苦痛。

所謂Snap動作

これは動作がかなり変わっているようで、

• Win8.1 アプリによっては最少幅320px、の範囲である程度自由に配置
• Win10 どうも、4:6程度に寄るのが最大。最小幅320pxのアプリであっても、それのずっと以前の幅で最小化になる。

感想　Win8.1の時のように幅の定義が変わったのかもしれない。//build待ち。

アプリバーの冷遇されっぷり

今までは一番使いやすかったアプリバーがとにかく（UI操作上）遠い。
画面上スワイプ→左上のハンバーガーをタッチ→App Commands をタッチ、でやっと出てくる。

8.1で出てきた画面下部のアプリバーボタン（…）、使っているアプリもあるが、今の8.1ベースの高さであのボタンを押すのは困難。ウィンドウモードだとかなり困難。どうも、ウィンドウモード時はウィンドウのサイズ変更用にエッジの認識エリアをほぼ全部使っているような動作。なのでサイズ変更は指でも結構簡単。

感想
Win10アプリのおそらくお手本であろう「フォト」ではそもそもアプリバーを全く使っていない、現在の距離の偉い遠さからすると、現状のアプリバーUIは下位互換用に取り敢えずつけてるだけなのでは？という気がする。
//buildで新しいCommand UIのDesignとControlを出してくるのでは？//build待ち。
が、今までのようにアプリバーをFirst Class の便利なUIと考えてアプリ作るのは危険だぜ！！という気がビンビンします。

下のキャプチャ画像は、、同じFrameworkを使ってる？ような感じの「フォト」「マップ」です。
左上のハンバーガー「三」をクリックすると、画面左端からメニューがスライドします。
フォトの場合、右のメインコンテンツはそれに合わせて縮小。
マップの場合、Flyout的にマップの上に被さって表示。

「フォト」アプリ、左端のメニューが閉じている画面

左上のハンバーガーボタンを押し、左端のメニューが開いている画面
フォトでは開いた状態で右のコンテンツを操作可能

「マップ」アプリ　左端のメニューが閉じている状態

開いている状態
マップではここで右の地図を操作するとメニューが閉じる
Win8.1のFlyout的なModal動作

MS謹製ストアアプリ

Win10用に完全に作りなおしたように見えるのは

• フォト
• XBOX
• チュートリアルアプリ
• マップ
• Skype

の四つくらい。特にフォトとマップは同じ考え方でUIを作っているようで、これがこれからのデフォなのかな・・・と思わせる。
Skypeは元々勝手なUIなのであんまり参考にはならないかな。
他はまだWin8ものをそのまま持ってきてるように見える。

感想
この先、MSがアプリどうするつもりなのか見るには「フォト」「マップ」この二つを使うのが良いのでは。
アプリの標準テンプレートの見た目とか随分変わるのではないかなぁという気がする。//build待ち。

その他雑多なこと

• StoreAppからFolderPickerを使う場合、ライブラリのルートを選択できない。これ微妙にバグな気がするんだけどどうだろう。FolderPickerの呼び方で何か変わるのかもしれない。//build待ち。
• ストア版IEって無くなってるような？　これはTab Onだとタッチでも普通に使えるのでこれはこれでいいのかもだけど。

ONDA V891w への Windows10 TP build 9926 January のインストール

要約

1. 「オンラインインストール」又は「isoをDLし、USBメディア等にCopyし、その中のSetup.exeを起動(*1)」からでは、「OSが圧縮インストールされているためセットアップできない」とのエラーとなり、インストールできない。
2. isoをDLし、USBメモリに焼いてからブートする必要がある。
3. キーボードとUSBメモリが要るので、マイクロUSBからハブに繋げるアダプタが要る。
4. OSインストール後はChipsetDriverその他が何も入っておらず、無線LAN・タッチパネル等全部使えない。ドライバを入れる。

1. について

無理なものは無理。
(*1) MSのDocumentにはこれで行けると書いてあるんだけど。そんなやりかたあったっけ？とは思うんですが

2. インストールメディアの準備

isoをDLし、USBメモリ等に起動ディスクとして焼く。

isoのDLはこちら。
x64/x86があるけども、下で出てくるドライバ群は現状x86もののみなので…使えるのはx86だけですね。

Download Windows 10 Technical Preview ISO
http://windows.microsoft.com/en-us/windows/preview-iso

焼くツールはこれを使いました。

UltraISO
http://www.ezbsystems.com/ultraiso/

番外 リカバリー領域の退避

本式のアップデートが出た時どうなるかまだ良くわからんので、元のWin8.1 リカバリー領域のバックアップをとっておく。

Create a USB recovery drive
http://windows.microsoft.com/en-us/windows-8/create-usb-recovery-drive

3. インストールメディアからの起動

USBメモリから起動するには、起動時のONDAロゴでキーボードのEscキーを連打する。
このため、USBメモリとキーボードを同時に繋ぐためのハブ（マイクロUSBに繋がるやつ）が要る。

※MicroSDから起動するんならハブは要らないかも。でもキーボードは要ります。

起動したらボタンが８つ並んだメニュー画面が出てくるので、左下のBoot from Filesを選択。
起動デバイスのメニューが出てくるので、USBメモリの中のbootmgr.efi を選択して起動。

4. ドライバのインストール

起動後は画面に従ってインストール。
今回の場合、インストール中に無線LAN・タッチパネル等のデバイスは全部使えないので注意。（I2Cの下が全部使えないんじゃないかなと）

ドライバはここからDL。

Ondaforum Downloads > Onda v891w
http://www.ondaforum.com/files/category/24-onda-v891w/

の中の、Win8.1 x86 drivers の最新のものをDLしてくる。1月24日現在はこれ。
（他にV3 Driverというのがあるけど試してないです。これは手持ちので動いた。）

V891w Core4_Win8.1_x86_Drivers-2-10302014.rar
http://www.ondaforum.com/files/file/271-v891w-core4-win81-x86-drivers-2-10302014rar/

（V891wはこの時点ではネットに繋がらないので、別PCでDLして）コピーしてから、
展開したディレクトリの一番上にある[Power]Install_all.cmd を選択し、Shift+F10→PowerShellで起動、でInstall開始。

ちなみにエクスプローラーの起動はWin+E。

途中何度かInstallShieldのWizardに「再起動する？」と聞かれるけど、そこは全部No。

しばらくすると終わり、普通にWin10が使えるようになります。

MSCC : Windows Phone App の Store Icon URL を取得する方法

(1月21日追記：Windows Phone Store のアプリページが更新されない不具合は解消したようです。なので、今となってはこの記事はあまり意味が無いです。）


この記事、「おそらく」「多分」な所が多いですが、そろそろ〆切りということで速度優先で書きました。
別記事　「MSCC 登録 失敗 上手くいかない」も合わせて御参照下さい。
http://ddlgjp.blogspot.jp/2014/12/mscc.html

・・・・・

ここのところ、Windows Phone Store のWeb側のページ更新が遅れているようです。
Windows Phone 実機のストアではアプリが表示されていてもWeb側には見えていないという状態の人が多いのではと思います。

Wheel World ClockのStoreのWebページ
http://www.windowsphone.com/en-ie/store/app/wheel-world-clock/0c242c2c-5c7a-4498-9999-118b116b162a
中々アプリページが出来ません…

MSCC にアプリを登録する際、Web上に表示されるアプリのアイコンURLが必要であるため困ってしまうのですが、
App annie のような、ストアのXMLをそのまま取得しているサービス(*1)を使うと、アプリのアイコンURLが取得できる場合があります（できない場合もある）。

自分のアプリを例として説明しますと、
以下のURLにアクセスすると、アプリの統計ページが表示されます。

http://www.appannie.com/apps/windows-phone/app/wheel-world-clock/

拙作「Wheel World Clock」の統計ページ

また、パブリッシャー、アプリ発行者のページもあります。

http://www.appannie.com/apps/windows-phone/publisher/ddlg/

パブリッシャーのページ

この○で囲ってある画像は、Microsoft の Windows Phone Store （Web版）で使っている画像への直リンクです。Wheel World Clock の場合はこうなります。
http://cdn.marketplaceimages.windowsphone.com/v8/images/4c40de02-b350-4762-ab85-e734142064cf

このリンクを使ってMSCCに登録すれば（多分）OKでしょう。

つまり、上のURL例二つから、ご自分のアプリ・パブリッシャーのURLを推測してページを開くことでアイコンURLを取得可能、となる（かもしれない）、というお話でした。

注意点として、

• App Annie の検索フォームからだとアプリの統計ページに辿り着けない場合があります。URL直打ちを試してみたほうがいいです。
• 私の場合、1月20日 午前中に見た時はまだアプリはApp Annie 上に表示されておらず、今（1月20日夜）に見たらアプリのエントリができていました。Storeへの登録は1月18日深夜でしたので、ある程度日数が掛かるようです。

(*1) App Annie 以外にも、Appfeds.com や filedir.com 等、ストアのHTMLではなく、XMLを直接クロールしてアプリリストや統計サービスを提供しているサイトが幾つか存在します。

Wheel World Clock を公開しました

Wheel World Clock
Windows 8.1 / Windows Phone 8.1 で動作します

ストアアプリ「Wheel World Clock」を公開しました。
Windows 8.1 / Windows Phone 8.1 でお使い頂ける Universal Windows Appです。無料です。

Windows ストアからダウンロード

Windows Phone ストアからダウンロード

Google Play からダウンロード

※ May 2017: Android version へのリンクを追加


Wheel World Clock で できる事

世界時計です。

• 文字盤はタッチ・マウスでぐりぐりと回すことができ、回転に応じてその時間・日付が表示されます。「1月21日午前9時（米太平洋時間）にイベント開始！」と言われても日本時間にすぐ暗算できないんだよ！UTC で書けよ！という僕や貴方のための時計です。
• 表示するタイムゾーン・表示名は変更可能です。OSがサポートするタイムゾーンを全て使う事ができます。
• 夏時間、Daylight Standard Time に対応しています。OSが対応していれば、その季節になると自動的に夏時間のタイムゾーンに切り替わります。
• 時計の文字盤画像を貼り変えることができます。

米太平洋時間1月21日午前9時、は
Wheel Wold Clockでくるくる回せばすぐわかる！という作為的な例

注意

• タッチ・マウスでぐりぐり回す際に回転がスムーズに行かない場合、画面下部のアプリバー　→　「Settings」→ 「Show each time during rotation」のチェックを外すことで改善される場合があります。Tegra2 世代のWindows RT機や、初期のAtomタブレットではチェックを外したほうがいいかもしれません。
• アプリ実行中に標準時～夏時間を跨いだ場合、表示は自動的には変わりません。一度アプリを閉じ、再度起動する必要があります。
• 時計の文字盤画像を貼る場合、Windows 8.1 では左上から最大の正方形を取れる分を自動的に切り取り、表示します。Windows Phone 8.1 では画像の形に関わらず正方形に縮小して表示します。

余談

• 2006年くらいですか、WPF が入ってきた頃にこの手のサンプルアプリを良く見たような気がします。書いていて少し懐かしい感じがしました。
• このタイプの時計…というか変換板の元ネタは、大昔にどこかで貰った国際電話のプロモーション用の小さなカードです。カードの真ん中にくるくる回る円盤がはめ込まれていて、中に都市名が書いてあり、回すと各地の時間がわかるという。所謂「世界時計」…各地の現在時刻が並んでいるタイプは良く見かけますが、ニュースやWeb を見ていて「○○時間△時」を日本時間に直すにはあのカードが一番便利だったなーという記憶がずっとあったのでした。MSCC 向けに小ネタで何か作るには丁度良いかなとガーっと書いてみた感じです。

ScrollViewer で中心に向けてZoomIn

WinRT の ScrollViewer で、Codeから拡大率を増減する場合…

ChangeView( double horizontalOffset, double verticalOffset, float zoomFactor)

を使います。
horizontal/verticalOffsetをNullにするとOffsetは0、画像左上をScrollViewerの左上に合わせた状態、になりますよと。

では、所謂「普通の」拡大縮小…ScrollViewer で今見ている物の中心を維持したまま拡大縮小するには？というのがこの項の話です。
これが実は結構面倒でして。完成しているものがこちらになります。（PICT8 で使っています）

 

        private void changeViewWithKeepCurrentCenter(ScrollViewer currentSv, float newZoomFactor)
        {
            // SVのProperty解説
            // Viewport    SVのサイズ、表示エリア
            // Extent      表示されてるイメージサイズ（クリップされてるとこも含む,のでアスペクト比は一定）
            //             VPに対して余りがある場合そこは含まれない　あくまでイメージのサイズ 
            //             ZoomFactor1なら元画像サイズと同じになる .5なら半分、２なら倍
            // H/VOffset   Extentベースの表示オフセット値

            // つまり
            // 1) 今表示している部分の中心座標が、元画像の何処にあたるか算出して
            // 2) 新しい倍率から新しいExtentのサイズを出して
            // 3) 1)で出した元の中心とExtentから新しいOffsetを算出
            // 元画像サイズを算出
            double originalWidth = currentSv.ExtentWidth / currentSv.ZoomFactor;
            double originalHeight = currentSv.ExtentHeight / currentSv.ZoomFactor;

            // 元画像スケールでの現表示の中心位置を算出する
            double originalCenterX = 0;
            double originalCenterY = 0;
            
            if( currentSv.ViewportWidth < currentSv.ExtentWidth )
            {
                // 余りが無い状態
                // 「余り」とは、ExtentがViewportより小さくなっていて、SVが額縁をつけてる状態
                double eCenterX = currentSv.HorizontalOffset + currentSv.ViewportWidth / 2;
                // originalに変換
                originalCenterX = eCenterX / currentSv.ZoomFactor;
            }
            else
            {
                // 余りアリ
                double eCenterX = currentSv.HorizontalOffset + currentSv.ExtentWidth / 2;
                originalCenterX = eCenterX / currentSv.ZoomFactor;
            }

            if (currentSv.ViewportHeight < currentSv.ExtentHeight)
            {
                // 余りが無い状態
                double eCenterY = currentSv.VerticalOffset + currentSv.ViewportHeight / 2;
                originalCenterY = eCenterY / currentSv.ZoomFactor;
            }
            else
            {
                // 余りアリ
                double eCenterY = currentSv.VerticalOffset + currentSv.ExtentHeight / 2;
                originalCenterY = eCenterY / currentSv.ZoomFactor;
            }

            // ZoomFactor変更後の数値を出す

            // 新倍率ベースでの、位置の表示中心
            double newExtentCenterX = originalCenterX * newZoomFactor;
            double newExtentCenterY = originalCenterY * newZoomFactor;

            // 新倍率ベースでの、Extentのサイズ
            double newExtentWidth = originalWidth * newZoomFactor;
            double newExtentHeight = originalHeight * newZoomFactor;

            // 新倍率ベースでのオフセットは、中心 - Extentサイズの半分
            // （ここのOffset計算では余り、ExtentとViewportサイズの差は気にしなくてよい SVが勝手にやること）
            double newExtentOffsetX = newExtentCenterX - currentSv.ViewportWidth / 2;
            double newExtentOffsetY = newExtentCenterY - currentSv.ViewportHeight / 2;
            // ﾃﾞｷﾀｰ
            currentSv.ChangeView(newExtentOffsetX, newExtentOffsetY, newZoomFactor, false);

        }

出来上がってるのを見ると…当たり前じゃんかと言いたくなりますが…それはさておき。
これをコピペすれば動くはずです。

せっかくですので、以下はScrollViewer のプロパティについて簡単な説明です。

ScrollViewer の三つのプロパティ…Offset, ViewportWidth/Height, ExtentWidth/Height

ScrollViewer のProperties の内、数値として取れるスクロール・位置関連のプロパティは4つで、

• ViewportWidth/Height ... ScrollViewer が開けている口、表示領域のサイズ。拡大縮小やスクロールでこのサイズは変わりません。アプリ領域変更等では変わります。
• ExtentWidth/Height ... ScrollViewer に載せているContent の、「表示上の」サイズ。倍率に応じてこのサイズは変わります。倍率１なら元Content と同じサイズ、倍率２なら2倍。また、この値はScrollViewer のViewport で表示しきれない、Clip されている部分も含んだサイズです。
• Horizontal/Vertical Offset ... Extent の左上(0, 0)から数えた、現在Viewport 上に表示している領域のオフセット。ここでの単位は「Extent での」、つまり表示画面上での単位であることに注意してください（元画像の単位では無い）。
• ZoomFactor ... ScrollViewer の現在の倍率。ちなみにこれだけ何故かFloat なので注意（他は全部double ）。

上３つ、特にHorizontal /Vertical Offset については、常に画面表示上のスケールであることに注意してください。つまり、何か計算しないと元画像の幅・高さやOffset 値は出てこないよ、ということです。

また上のCode Snippetでも少し触れていますが、Viewport よりExtent が小さい場合には少し注意が必要です。

ViewportよりExtentが小さくなってる場合

この場合、Horizontal/Vertical Offset は両方常に0 です。この状態ではPhysicalにはOffsetあるように見えはしますが、Logicalには常に（0, 0)、左右・上下の枠は勝手にScrollViewer がつけるもので、Contentは常に画面中心に表示されます。このため、表示中の画面中心を算出するには場合分けが必要です。

以上です。
ではでは楽しいScrollViewer Lifeをお過ごしください。

あけましておめでとうございます

あけましておめでとうございます。

昨年中は PICT8 と ゴミ出しカレンダー、アプリ二つを公開する事ができました。
お使い頂いている方、お買い上げ頂いた方、ありがとうございます。

Windows ストアアプリを作り始めて2年目、自分の欲しかった機能を持ち、製品として通用するものを作ろうとしたのがPICT8 でした。未だ完全とは言えないですが、画像ブラウザ・自炊本リーダとしてお値段分の価値は出せたものと自負しています。

また去年は、個人でアプリ開発を回していく際のワークフローについて多く考えた年でもありました。基本的に平日数時間分しか費やせない条件下で品質を保ち、スケジュールに沿った開発を行えるフローについて今年も引き続いて考えていきたいです。

今年は Win10 のリリースが予定され、アプリケーション開発の様子も大きく変わる事と思います。新技術にCatch up していき、使っていて隣の人にねぇねぇこれいいでしょと自慢したくなるようなイカしたアプリを作っていきたい、というのが目標です。
宜しくお願い致します。

なお、新年セールとして PICT8 通常価格 500円 のところ、日本時間 1月「2日」0時～3日 24時の間は 350円 になっております。この機会にお試しいただければと。
（1月1日からにしたかったのですが申請が間に合わなかった…）

写真は川崎・生田緑地にある岡本太郎作「母の塔」です。
これを撮った頃は幾らか汚れていたのですが、去年末から掃除をしており今年の春にはピカピカになるそうです。