App.csのコンストラクタで、Xamarin.Forms.Application.Current.Resourcesの初期状態が、Xamarin.Forms 2.xとXamarin.Forms 3.0では異なっていました。
2.x:null
3.0:not null
そのため、nullだったらCurrent.Resourcesに項目をAddするようなロジックにした場合、2.xでは正常に動作し、3.0ではAddしないため、XAMLで
BackgroundColor="{StaticResource BorderBrush}"
のような参照をしていると、そこで実行時エラーになってしまいました。
if (Xamarin.Forms.Application.Current.Resources == null || Xamarin.Forms.Application.Current.Resources.Count == 0)
のようにCount判定も追加する。
Xamarin.Formsも3.0となり、魅力的な機能がさらに追加されました。
主な新規のは次のようなものがあります。
Microsoft XAMLではおなじみの「ResourceDictionary」や「Visual State Manager」のサポートもうれしいですが、「FlexLayout」と「CSS StyleSheet」のサポートも魅力的ですね。
例えば、FlexLayoutはコンテンツを折り返しならが横方向に並べてくれるレイアウトで、Gridのようにあらかじめ縦横のマス数を指定しなくてもいいので、可変数のコンテンツを効率よく表示するのに適しています。従来であれば、ListViewのように横幅が一定の１列リストなどしか方法がありませんでしたが、タイル状に表示することが可能になりました。
Visual Studio 2017 (15.7.2)で新規に作成したプロジェクトでXamarin.Forms 3.0を使う方法を紹介します。Xamarin.AndroidとXamarin.iOSに共通のロジックは.NET Standard 2.0でDLL化して共有するのではなく、共有プロジェクトでソースコードレベルで共有するスタイルにします。
そのためには、CrossPlatform - Xamarin.Formsテンプレートを選択して、空のアプリで「共有プロジェクト」を選択します。
この方法で作成したプロジェクトでは、Xamarin.Formsは最初から3.0が設定されています。Xamarin.Formsもnugetパッケージとして提供されていますから、ソリューションエクスプローラーでAndroidのプロジェクトの[参照]フォルダを右クリックして[Nugetパッケージの管理]メニューを選択して、使用されているnugetパッケージのバージョン確認してみましょう。
テンプレートのXamarin.Forms 3.0は3.0.0.482510ですので、その後に新しいものがでている場合があります。今回も、2018/06/05に3.0.0.530893がでているので、必要に応じてnugetパッケージん更新をしましょう。更新していいかどうかの判断基準は一概にはありませんが、リリースノートなどで判断するのがいいでしょう。
https://developer.xamarin.com/releases/xamarin-forms/xamarin-forms-3.0/3.0.0/
Xamarin.Androidの場合、さらにXamarin.Android.* (サポートライブラリ)のnugetパッケージのバージョンをどうするかも考える必要があります。
テンプレートで指定されてるサポートライブラリのバージョンは、25.4.0.1となっており、この時の依存関係にあるMonoAndroidバージョンはv7.0となっております。
2018/6/6現在に対応している最新MonoAndroidバージョンはv8.1ですので、最新のものを使うなら、サポートライブラリを最新のv27.0.2にします。
サポートライブラリのバージョンを更新してMonoAndroidのバージョンが変更されたときは、該当するAndroid SDKがイントールされている必要があります。
たとえば、サポートライブラリをv27.0.2にしたいのであれば、事前にAndroid SDK ManagerでSDK 8.1がインストールされていることを確認してください。
該当するSDKバージョンがないとnugetでサポートライブラリのバージョンを更新するときにエラーとなります。
Android SDK v8.1がインストール出来たらプロジェクトのターゲットフレームワークもAndroid 8.1にします。
こちらターゲットAndroidバージョンとは別となります。もし（そんなタイミングはすくないでしょうけれど）、ターゲットを最新OSにするのを待ちたいときは、ターゲットAndroidバージョンを明示的に指定することも可能です。
２つ指定するのが面倒であれば、SDKのバージョン＝ターゲットAndroidバージョンにする「SDKバージョンを使用したコンパイルの使用」という指定もあります。
それでは試しにFlexLayoutを使った画面を定義してみましょう。
画面定義は、AndoridとiOSで共通化できるところは共有プロジェクト側に記載します。
Modelなどのロジック部分も完成して実行すればタイル状に画像が表示されるアプリの完成となります。
ところでFlexLayoutでViewModelとBindingするのはどうするだろう。
build 2017も残すところあと１日となりました。
1日目、2日目のキーノートとセッションに参加して感じたことは、AI - Cognitive、HoloLens、Xamarinということでしょう。
そしてすべてのセッションには英語字幕がついている（これ、音声認識なのか、どこかに会場音声を飛ばしてキー入力している人がいるのか不明。後者なのかな）点も見逃せませんでした。
今回の会場は道路を挟んで２つの建物で行われていました。キーノートや展示会場もあるWCC側のセッションでは手話通訳者の人がスピーカーの話す内容を手話にしていました。もちろん、キーノートでも。
画像認識を使って危険予知や体調を推測するなど、Cognitive Serviceで提供されている機能を使うことで、人の気配りを機械にさせることができるようになるかもしれません。
疲れることも気分にも左右されない機械がいろいろなところに入ってきて、それによって生まれた余裕を使って臨機応変の部分で人が対応できるような未来が感じられるのが今年のbuildの特徴の１つでしょう。
そしてもう一つの未来がキーノートで紹介されたマイクロソフトリサーチの研究
パーキンソン病の症状の１つである手の震えを二軸のモーターで相殺する腕時計デバイスです。動画中にもあるような小型化できたのも、機械学習による成果と言えるでしょう。
今までは文字通り箱入り娘のようだったHoloLensですが、今回のbuildの展示会場では、普通のブースにもHoloLensを展示している企業さんがいて、HTCやOculusのように気軽にかぶせて自分たちのアプリを体験させていました。
そして、Microsoft Mixed Realityに準拠したAcerのHMDの体験コーナーもありました。AcerのHMDですが、HoloLensのように単体動作ではなく、PCに接続して使う従来型のHMDです。ですからHoloLens向けに作成したアプリをローカルコンピュータで実行すればAcerのHMDに表示されるという寸法です。
Mixed Reality AcademyでもHoloLensとAcerの両方が試せました。同じアプリが両方で試せるのは素晴らしいですね。Acer HMDですが今までにない綺麗さでした。いわゆるフルダイブ型ですが装着感もいいし、これでVRコンテンツをプレイしたら楽しいかなと思いました。
Mixed Reality Academy #MSBuild pic.twitter.com/EusLWhZRgy
— はつね (@hatsune_) 2017年5月12日
そして今年もXamarin界隈は元気ですね。セッションもたくさんあるし。
Visual Studio for MacがGA（正式提供）されたり、Xamarin Live PlayerやXAML Standardなどのいままでかゆかったところに手が届くような発表もあり、今後もXamarin界隈は元気な感じですね。
■Xamarin Live Player
AndoridやiOSでの実行（画面表示？）をシミュレートしてくれるインタープリター環境です。VMのように重たくもないし、実機デプロイと違って、Visual Studio側での変更もリアルタイムに反映ができます。
もちろん、シミュレーターや実機のように厳密には動作が違う部分もあるかもしれませんし、（実はインタープリターなのでMacなくてもPCだけで）iOS画面が確認できるといっても、まだまだ基本的なXAMLページしか対応できていないし、実機デプロイやストアへの登録はMacが必須なのは変わりませんが、この方向が示されただけでも、また、初学者の人が入門記事を試すのにも最適化なんじゃないかな。
■XAML Standard
現状、Microsoft XAMLとXamarin XAMLは同じように書けそうで、コントロール名が違っていたり、プロパティが違っていたりします。そこで、XAML Standardという考え方を入れて共通化していきましょうというものです。
私としては、コントロール名やプロパティ名を共通化するときに、全部、Microsoft XAMLによせるのではなくて、例えば、VisibleプロパティなんかはIsVisibleプロパティのようにXamarin XAMLにしてもらった方がConverter書かなくていいのになーと思ったりするので考慮してほしいなぁーと思ったりもしています。
それ以上に期待するのが、各プラットフォームごとに動きの差異が最小になるようにしてほしいという点です。それができるならば、コントロール名やプロパティ名が違うくらい外側の話ですから使う側でいくらでも補完できます。
若干、今回のXAML Standardの発表を否定的にとらえているようなコメントもTwitter上で見かけますが、build現地の空気感や使う側の開発者にしてみれば、XamarinがMSに買収されたときから【長い間】「こうなるはずだよね？」と思っていたことが【やっと公式に表明】されたという点が大きいわけで、個人的にはそれこそ去年のbuildで表明されてもよかったくらいだと思うので、それは素直に評価して喜んでいいじゃないかって思うところです。
Visual StudioでXamarinを使ってAndroidアプリを作成してストア登録するときの手順が最近(2017年3月末)変わりました。
以前であれば、[ツール]-[Android]-[Publish Android Application]メニューでダイアログを立ち上げて、そこでKeystoreなどを選択してapkファイルを作成しました。
そして、apkファイルを手動でGoogle Play Developer Consoleにアップロードして公開していました。
新しい方法では、ソリューションエクスプローラーでAndroidアプリのプロジェクトを右クリックして、そこで[Archive]を選ぶ方法に変更されました。
[Archive]メニューを選ぶとArchive Managerが立ち上がり、該当プロジェクトのアーカイブが進行します。
この時、ソリューション構成は[Release]を選択しておきましょう。
ビルドがうまく通ればapkファイルが所定のフォルダに作成されます。
ただし、このapkファイルは未署名のものなので、そのままではGoogle Playストアに登録できません。
[Distribute]ボタンを押して署名を行いましょう。
Ad HocなのかGoogle Playなのか配布方法を選びます。Google Playストア経由で配布するので[Google Play]を選択します。
署名を行います。
Keystoreファイルがすでにあるならば[Import]ボタンをクリックしてファイルを取り込みます。
既存のKeystoreファイルがないのであれば[+]ボタンをクリックして、新規にKeystoreファイルを作成します。
Alias：別名など（プロジェクト名とか）
Password：パスワード
Validity：25以上の数字。1000とかでもOK。
Full Name：発行者のフルネーム
Organization Unit：部署名（個人なら入力しないでもOK）
Organization：会社名（個人なら入力しないでもOK）
City：市区町村区名
State：都道府県名
Country Code：JP
Google Playストアに登録するアカウントを指定します。
Google PlayストアにログインしているIDとパスワードではなく、Google API AccessのClient IDとClient Secretを指定します。
これにはGoogle Play Developer Consoleにログインして「APIアクセス」のところでOAuthクライアントを作成してその認証情報からコピペします。
ここまでできたら、アルファ版、ベータ版、段階的公開、製品版のどれで公開するかを指定します。
少し説明が必要そうなのは、段階的公開（Rollout）でしょうか。これはバージョンアップ版の公開を一度にすべてのユーザに対して公開するのではなく、徐々に公開していく方法です。
こうすることによって、致命的な障害があった場合に全台に影響がないようにします。また、新バージョンの最初の起動の時だけにアクセスするようなデータがあった場合の負荷分散にもなります。
段階的公開が必要なくらいの利用者数があるアプリとか夢のようですよね。
新しい公開方法は以上です。
以前に比べるとGoogle Play Developer Consoleへの配置までできるので便利ですね。
Androidのアプリなどでロックスクリーン状態でも画面表示されているやつがあると思います。あれをXamarin.Formsでやろうとしたらどうするのか。
Androidアプリの普通のノウハウがそのまま使えます。
Xamarin.Forms (Android) でスリープ状態にさせないためには
Xamarin.FormsがサポートしているAndroidのバージョンをおさらいしてみましょう。
https://developer.xamarin.com/guides/xamarin-forms/getting-started/installation/#android
公式ドキュメントによれば
Android 4.0.3、つまり、「Ice Creame Sandwitch」以降をサポートしています。4.0.3は2011年12月16日に提供開始されています。
4.0.3以降ということであれば、世の中にあるAndroidデバイスのほぼ100%(残念ながらそれ以前のバージョンも多少は存在する)をカバーできます。
日本でいえば、ドコモのGalaxy SII SC-02Cなどが4.0.3ですが、2016年時点でキャリア2年縛りはすでに超えていますから、ほぼカバーしていると言っていいでしょう。
ただし、素直に4.0.3かといえば、若干違和感があります。
その違和感はXamarin.FormsとXamarin.Android.SupportとAndroid SDKの関係を表にしてみるとはっきりしています。
| Xamarin.Forms | Xamarin.Android.Support | Android SDK | |
| プロジェクト作成時 | v1.3.3.6323 | v4.21.0.3 | 4.0.3 (API1 5) |
| nuget最新 | v2.2.0.31 | v4.23.3.0 | 5.0 (API 21) |
このように最新のXamarin.Forms v2.2が要求するXamarin.Android.Supportはv4.23.3.0であり、v4.23.3.0が要求するAndroid SDKは5.0になるのです。
それではなぜ、公式ドキュメントには「4.0.3」以上となっているのでしょうか。
答えは同様に公式ドキュメントにあります。
つまり、ターゲットは最新（または少なくともXamarin.Android.Support.v4.23.3.0が要求する5.0以上）として、Minimum Android versionとして「4.0.3」を指定できることが、Xamarin.Formsの要求仕様がAndroid v4.0.3以上という意味だということです。
※Visual Studioならプロジェクトのプロパティの[Application]-[Application properties]
違和感の原因は、4.0.3以上ということで、では自分たちの作ったアプリも4.0.3以上としようとしたときにターゲットフレームワークを「4.0.3」ではなく「5.0」としてMinimum Android versionで「4.0.3」としていいのかという点にあります。Visual StudioならTarget frameworkが「Complie using Android version」となっているのでさらに不安を感じます。
これらのバージョンはどのような意味があるのでしょうか。
注意しないといけないのは、これは、Xamarin固有の話ではなく、Android開発の基本的な話となります。Android StudioでJavaで作成したときもbuild.grableに同じように描くことになります。
結論を先に書けばWindowsアプリに比べたらかなりおおざっぱというか、これでいいの？という感じがAndroidアプリ開発なんだなぁと。
| Target framework (targetSdkVersion) |
|
| Minimum Android version (minSdkVersion) |
指定したバージョン以上にインストールできる宣言 |
これ、トラディショナルジャパニーズカンパニーで開発やっていると、Target framework = Minimum Android versionとして、アプリの動作要件の○○以上とする一番古いバージョンに合わせてコンパイルして、それより上位のOSでも下位互換性確認の意味で動作チェックしてって感覚だと思うのです。
Target frameworkは最新にして、Minimum Android versionにアプリ動作要件の○○以上とするというのがAndroidスタイルだって納得して、きちんとシステムテストで4.0.3 (Ice Cream Sandwich)/4.3 (Jelly bean)/4.4 (KitKat)/5.1 (Lollipop)/6.0 (Marshmallow)とテストするしかないのでしょう。このあたり、Androidで業務アプリを作っていたり、それよりもGoogle Playで人気アプリ配信している個人開発者さんあたりにお話をお聞きしたいですね。ほんと、どうしていらっしゃるのだろうか。
まあ、そんなときに心強い味方と言ったら、Xamarin Test Cloudですよね。
例えば、月額249$のBUILDなら、こんな感じにテストができます。
4.0.3 (Ice Cream Sandwich)/4.3 (Jelly bean)/4.4 (KitKat)/5.1 (Lollipop)/6.0 (Marshmallow)の５バージョンでそれぞれ代表的なデバイスを１つづつテストするのであれば、もう一つ安いSTARTプラン=月額$99でもテストできそうですね。
1日1回しかテストできないの？と思うかもしれませんが、手元の実機やエミュレータでテストしたあとの仕上げテストですから、毎日１回とかで十分と言えるでしょう。
そうそう、Visual Studio Enterpirse使っているなら上記の金額から25%引きで利用できますので、さらにお得ですね。
