Visual Studio 2017 Update 3の個人的な目玉は何と言っても、.NET Standard 2.0対応です。
という訳で、早速Xamarinの共通部分を2.0にして試してみましょう！
入ってないのかよ(´・ω・｀)
しかも、「他のフレームワークをインストールする」のリンク先に無いし(´・ω・｀)
てことで、.NET Core SDK入れたら解決するんじゃね？ってことでここから入れてみました。
そして解決しました。
ちゃんちゃん！ってか、入れといてよ最初からさ(´・ω・｀)
Visual Studio 2017 Update 3では、デフォルトでAzure Functions and WebJobs Toolsがインストールされているのですが、おそらく？PreviewのUpdate3用の様で、デフォルトではAzure Functionsのプロジェクトテンプレートが有効になりません。
個別にUpdate 3を入れると、Azure Functions and WebJobs Toolsインストールされて、更新できる状態となっていますのでそれを更新かける必要があるようです。
Update掛けたら無事、Azure Functionsのプロジェクトテンプレートが表示されました。
それだけ！
普段Visual Studioの更新は、VSメニューバーの「ツール」＞「拡張機能と更新プログラム」から入れられた気がするのですが、どうも今回は2017.08.15時点ではそこから上げられないようです？
という訳で、Visual Studio Installerを手動で起動して（インストーラーはダウンロードしてもいいし、次のように検索しても出てくるはずです）更新すれば適用できるようです。
インストーラーを起動したら、あとは更新ボタンを押すだけで現時点ではそんなに待たずにアップデートできました。
それだけです。チャンチャン！
先日これまでのXamarin.Formsの経験や、PrismのPageNavigationServiceへの貢献を通して得たノウハウを整理して形にした、KAMISHIBAI for Xamarin.Formsをリリースしました。 前述のエントリーや、Github上のドキュメントでもKAMISHIBAIのメリットについては述べているのですが、少しずつ掘り下げて解説したいと思います。 まずは
について説明したいと思います。これはXamarin.Formsを素でつかっていると非常に面倒な領域です。つぎの図を見てください。
KAMISHIBAIではPageの状態遷移に伴ってつぎのようなイベントが発行されます。
| イベント | 想定する実装内容 | パラメーター |
|---|---|---|
| OnInitialize | リソースの初期化処理など | 〇 |
| OnLoaded | OnUnloadedで非活性化されるリソースの活性化 | × |
| OnUnloaded | リソースの非活性化 | × |
| OnClosed | リソースの解放 | × |
これらのイベント通知があらゆるPageの状態遷移で保たれていることが、KAMISHIBAIの強みの一つです。
どういう事かというと、通常だと実現困難な次のようなケースでも、一貫して振る舞うということです。
これらを見ると、画面遷移イベントだけではない（INavigationが絡まないものはNavigationじゃないという意見もあるので）ため、画面遷移イベントというよりは、Page状態変更イベントといった方が良いでしょう。
1.～3.については、PageをPushする際にBehaviorを外部からインジェクションするという、私が勝手に「Injection Behavior of outside」と呼んでいるパターンを利用して実現しています。このあたりのコードです。
NavigationPage、TabbedPage、CarouselPageにはそれぞれ専用のBehaviorをインジェクションしています。例えばNavigationPageではPoppedイベントをハンドルして適切に処理するNavigationPageBehaviorをインジェクションしています。
また4.については、ApplicationのPopModalイベントをここらへんでハンドルして処理しています。
これらはほぼXamarin.Forms.INavigationを薄くラップするNavigatorクラスを中心に実現していますので、MVVM系の機能を利用せずとも、Navigatorクラス（とApplicationService）だけ利用するという選択肢もありです。これら（と周辺クラス群）が
を実現しているので、KAMISHIBAIの実装技術的な方面ではほぼ全てと言って良いでしょう。
このあたりの強い一貫性を保ったイベント通知は、アプリケーション構築の強い味方になると信じています。
昨日、Xamarin.Forms.GoogleMaps.Bindings 2.1.0のリリースを告知しましたが、あれだけだと不親切なので使い方が少し癖のある部分の解説を追記しておきます。
追加した機能のうち、つぎの3つは少し使い方が特殊です。
とはいえ、どれか一つ覚えてしまえば基本的に他の機能も同じ方式に則っているので理解は容易でしょう。
というわけで、MoveCameraを例にとって説明します。
Mapの表示を位置や（三次元的な）角度を指定して、即座に変更するための機能がXamarin.Forms.GoogleMapsにはあります。
それをViewModelから利用するための機能を追加しました。
具体的にはViewModelに次のようなコードを追記します。
public MoveCameraRequest MoveCameraRequest { get; } = new MoveCameraRequest(); public Command MoveToTokyoCommand => new Command(() => { MoveCameraRequest.MoveCamera(CameraUpdateFactory.NewCameraPosition( new CameraPosition( new Position(35.681298, 139.766247), // Tokyo 17d, // zoom 45d, // bearing(rotation) 60d // tilt ))); ; });
MoveCameraRequestというプロパティを公開し、そのプロパティのMoveCameraメソッドを呼び出して利用します。
ちゃんと本家と同じく、Task<AnimationStatus>を返してくれます。
TakeSnapshotもちゃんとTask<Stream>を返してくれるため、投げっぱなしではなくちゃんとViewModel側で結果を受け取って処理できるようにしてあります。
もちろんこれだけではだめで、View側にBehaviorを追加して、このMoveCameraRequestからの要求を受け付けてMapへ伝達してあげる必要があります。
<googleMaps:Map> <googleMaps:Map.Behaviors> <bindings:MoveCameraBehavior Request="{Binding MoveCameraRequest}"/> </googleMaps:Map.Behaviors> </googleMaps:Map>
こんな感じです。
簡単ですね。
つぎの機能にも簡単に触れておきましょうか。
これらにはMapのイベントを監視し、イベント発生時にイベントパラメーターを渡してCommandを発行するBehaviorとして追加しました。
今までも類似のものはありましたので説明は不要かもしれませんが。
具体的にはViewで次のように記述します。
<googleMaps:Map> <googleMaps:Map.Behaviors> <bindings:InfoWindowClickedToCommandBehavior Command="{Binding InfoWindowClickedCommand}"/> <bindings:InfoWindowLongClickedToCommandBehavior Command="{Binding InfoWindowLongClickedCommand}"/> <bindings:MyLocationButtonClickedToCommandBehavior Command="{Binding MyLocationButtonClicked}"/> </googleMaps:Map.Behaviors> </googleMaps:Map>
特化型のEventToCommandBehaviorです。
てことで、簡単ですが今回はこれだけ。
それではまた！
ちょっと放置状態になってしまっていたXamarin.Forms.GoogleMaps.Bindingsを、「だいたい」Xamarin.Forms.GoogleMaps 2.1.0まで対応しました。
未対応機能があれば、良かったら教えてください。
とりあえず、対応内容は以下の通りです。
ServiceLocatorを追加して、Page生成のDependency Injection対応が可能となりました。
KAMISHIBAIをPrismと併用する記事を書かなきゃなと思っていたら、神のようなタイミングで記事化してくださった方がいらっしゃいまして。
かずきさん、ありがとうございました！
その中で2点、ご指摘いただきました。
どちらも仰る通りで、1.はすぐ対応できることなので、対応してリリースしました。
例えば、Prism.Autofac.Formsを利用される場合、App.csに次のように記述することでPage生成をDI Containerへ移譲することが可能になります。
public partial class App : PrismApplication { public App(IPlatformInitializer initializer = null) : base(initializer) { } protected override void OnInitialized() { InitializeComponent(); ServiceLocator.SetLocator(type => Container.Resolve(type)); ApplicationService.Initialize(this); ApplicationService.SetMainPage(new NavigationPage(new MainPage()), "Hello from Xamarin.Forms"); } protected override void RegisterTypes() { var builder = new ContainerBuilder(); builder.RegisterType<MainPage>(); builder.RegisterType<SecondPage>(); builder.Update(Container); } }
ServiceLocator.SetLocatorで、Containerから生成するようにデリゲートを渡してあげればOKです。
あと、ContainerへのType登録ですが、RegisterTypeForNavigationではなく、ContainerBuilderを利用してRegisterTypeで行っています。
RegisterTypeForNavigationはPrismのNavigationServiceを利用するための拡張メソッドですので。
ちなみにServiceLocatorの名前がPageResolverとかじゃないのは理由があります。今度ViewModeLocatorを作ってDIと仲良くする方法を記事化しますがそこでも利用したいためです。
なお、Prismとの併用サンプルを一応こちらのリポジトリに「LiveWithPrism」というプロジェクトで作成してありますので、よかったらご覧ください。
なお、DeepLinkについてですが、ちょっと考えがあって現時点ではKAMISHIBAIではサポートしていませんが、不可能なわけではありません。
URIベースの指定は無理ですけどね。
その辺は、書き出すと長くなるのでまた今度きちんと文書化しようと思います。
というわけで、今日はここまで！
