![Xamarin.Forms で吸収できない機能の記述
[assembly: ExportRenderer(typeof(BottomBar), typeof(BottomBarRenderer))]
namespace XamarinSample.iOS.Views
{
public class BottomBarRenderer : ViewRenderer<BottomBar, UIToolBar>
{
protected override void OnElementChanged(ElementChangedEventArgs<BottomBar> e)
{
base.OnElementChange(e);
～UI が生成される際の処理を記述～
}
}
}
プラットフォーム固有ViewRenderer
共有View
iOS の場合の委譲先クラス
既定の初期処理が行われる](https://image.slidesharecdn.com/ss-001-141005014023-conversion-gate01/85/Xamarin-20-320.jpg)
Uploaded byTatsuji Kuroyanagi
かけ算で使いこなす Xamarin
「かけ算で使いこなす Xamarin」 ～Xamarin × XAML × iOS API × データバインディング～ 2014/10/18 わんくま勉強会 東京#92 の発表資料です
![[MW08] de:code イベントアプリの作り方 ～ Xamarin.Forms で開発しています ～](https://cdn.slidesharecdn.com/ss_thumbnails/mw08-170614050111-thumbnail.jpg?width=640&height=640&fit=bounds)
かけ算で使いこなす Xamarin
- 1. かけ算で使いこなすXamarin Xamarin ×XAML × iOS API × データバインディング 2014/10/18（土） わんくま勉強会東京#92 @matatabi-ux
- 2.
- 3. 自己紹介： 黒柳達士（@matatabi-ux） •お仕事 ⁃ 某第二工場でWindows ストアアプリ大量生産中 ⁃ 拝承系SIer → 安心簡単快適デザイン会社→ 現職 • 個人活動 ⁃ Blog： 「しっぽを追いかけて」http://matatabi-ux.hateblo.jp ⁃ facebook： https://www.facebook.com/tatsuj.kuroyanagi ⁃ 日本人間工学会認定人間工学専門家 あの！ザッカーバーグと同じ心理学専攻でした ⁃ 飼い猫写真も垂れ流し中 twitter: https://twitter.com/burst_cafemocha facebook: https://www.facebook.com/burst.cafemocha もふもふの自宅警備ネコ「モカ」
- 4. 今回の目標とおことわり • 目標 ⁃ 「プラットフォームごとにコード記述」という足し算的対応ではなく、共通部分はきちんと共通化して、 固有部分が冗長にならないようすみ分けた「かけ算的」なXamarin の生かし方の１つを共有 ⁃ UI を制するものはクロスプラットフォームを制す！iOS のUI の話題が中心です！・・・ Xamarin.Android 持ってないんで>< • 注意事項 ⁃ Xamarin は現在進行形で進化中なので仕様が大きく変わるかも ⁃ XAML をある程度知っているC# エンジニア視点でまとめました ⁃ XAML が全くわからないとついていけない部分があるかも （時間があったら質問どうぞ）
- 5. おしながき • Xamarinに注目すべき理由 • Xamarin によるXAML サポート • Xamarin.Forms で吸収できない機能の記述 • プラットフォームの壁を越えるデータバインディング • まとめ
- 6. 突然ですが アンケート！ みなさんがXamarinに興味を お持ちの理由は何ですか？
- 7. みなさんがXamarin に興味をお持ちの理由は何ですか？ 新しい技術を おさえたい クロスプラットフォーム 開発ができる 仕事で必要 スマホアプリを 作ってみたい
- 8. Xamarin に注目すべき理由 ITエンジニア不足が深刻になってきたから（実感） 「スマートフォン・タブレットアプリ開発」に 対する回答 人材の量・質が不足しそう 人材不足を感じている 今後サービス利用したい 19.26% 41.5% 35.6% IT企業におけるIT人材の不足感 大幅に不足 IT企業 N=790 ウェブビジネス 企業 N=123 ユーザー企業 N=345 やや不足 N=790 過不足なし やや過剰 19.0% 63.2% 16.1% 1.4% 独立行政法人情報処理推進機構（IPA）IT人材育成本部発行「IT 人材白書2014」より
- 9. Xamarin に注目すべき理由 人材・ノウハウはないが新規にスマホアプリを開発したい HTML5 で十分な性能・デバイス機能を確保できるか？ リリースプラットフォームを広げたらコストかかりそう デバイスの流行に応じて技術の勉強しなおしが必要？
- 10. Xamarin に注目すべき理由 人材・ノウハウはないが新規にスマホアプリを開発したい C# だけでiOS / Android 開発できます HTML5 で十分な性能・デバイス機能を確保できるか？ リリースプラットフォームを広げたらコストかかりそう デバイスの流行に応じて技術の勉強しなおしが必要？ そう、Xamarin ならね
- 11. Xamarin × XAML Xamarin による XAML のサポート
- 12. Xamarin によるXAML サポート • Xamarin 3.0 よりXAML によるUI 定義をサポート ⁃ クロスプラットフォームUI ライブラリXamarin.Forms により宣言的なUI 生成をするXAML 記述が可能 ⁃ iOS 6.1 以降、Android 4.0 以降、Windows Phone 8.0 対応（8.1 はまだ；） • UI のレンダリングは各プラットフォームに委譲 ⁃ XAML の記述にしたがい各プラットフォームごとに見た目や振る舞いが変わる 各デバイスユーザーが慣れて いるUI をそのまま使える ワンソースでは難しい長所！
- 13. Xamarin によるXAML サポート • 本家XAML とは非互換・・・まだ出たばっかりだから； 2014/10/05 現在の対応状況 WinRT XAML Xamarin.Forms XAML Visual Studio のUI デザイナ表示対応非対応 Visual Studio のインテリセンス対応非対応 カスタムスタイル＆テンプレート対応ListView / TableView への DataTemplate のみ Visual State & Storyboard アニメーション記述 対応非対応 アプリ内共有リソースの定義 ResourceDictionary や 文字列リソースをファイル定義可能 定数クラスをx:Static マークアップで参照可能 プラットフォーム別マークアップ切替非対応対応
- 14. Xamarin によるXAML サポート • Page / Layout / View / Cell ⁃ 本家XAML とは異なりPage / Layout / View / Cell の基本クラスを継承したUI で構築 ⁃ Page：画面、Layout：パネル、View：コントロール、Cell：ListViewItem のようなイメージ Page Layout View Cell DataTemplate が適用可能 NavigationPage StackLayout TableView ImageCell
- 15. Xamarin によるXAML サポート • x:Static による静的クラス参照 ⁃ リソースファイル（.resw）やResourceDictionary の代替となるXAML 拡張 ⁃ Static クラスにstatic な値として定義することでXAML から参照が可能 <Label Text="Hello, XAML!" TextColor="{x:Static local:AppConstants.BackgroundColor}" BackgroundColor="{x:Static local:AppConstants.ForegroundColor}" Font="{x:Static local:AppConstants.TitleFont}" HorizontalOptions="Center" /> AppConstants クラスの ForegroundColor の値を設定
- 16. Xamarin によるXAML サポート • プラットフォーム別マークアップ切替 ⁃ プラットフォームごとのデザインの違いをワンソースで吸収できる仕組みのひとつ ⁃ 各プラットフォームごとに適用するプロパティ値を個別に指定できる <ContentPage.Padding> <OnPlatform x:TypeArguments="Thickness“ iOS="0, 20, 0, 0“ Android="0, 0, 0, 0“ WinPhone="0, 0, 0, 0" /> </ContentPage.Padding> ステータスバーに画面が重ならないように、 iOS だけ上余白20px を指定
- 17. Xamarin × XAML × iOS API Xamarin.Forms で吸収 できない機能の記述
- 18. Xamarin.Forms で吸収できない機能の記述 •DependencyService ⁃ プラットフォーム固有の機能を共有コードから呼び出すための仕組み ⁃ PCL / Shared プロジェクト側でインターフェースを定義 ⁃ 各プラットフォーム側でインタフェース実装クラスを定義 ⁃ PCL / Shared プロジェクト側からDependensyService.Get<T> で呼び出し ⁃ ぶっちゃけPCL 化されたUnityContainer で代用できるしそっちの方が高機能 var storage = DependencyService.Get<ILocalStorage>(); If (storage != null) { await storage.SaveAsync(); } 共有コード側からインターフェースを通して 各プラットフォーム固有機能にアクセス Shared / PCL インター フェース プラットフォーム固有コード
- 19. Xamarin.Forms で吸収できない機能の記述 •ViewRenderer<View, NativeView> ⁃ Xamarin.Forms が委譲しているプラットフォーム固有のUI 処理を拡張する仕組み ⁃ ExportRenderer 属性でXamarin.Forms のUI とRenderer をひもづける ⁃ View にXamarin.Forms の抽象化されたView の型を記述 ⁃ NativeView に委譲先のプラットフォーム固有のView の型を記述 ⁃ 本家XAML のBehavior に近いイメージの仕組み（描画やイベントハンドラの処理を 拡張できる） ⁃ OnElementChanged（生成時）、Dispose（破棄時）など、UI のライフサイクル に応じた処理をoverride で拡張できる Xamarin Forms 委譲先の 振り分け プラットフォーム固有描画
- 20. Xamarin.Forms で吸収できない機能の記述 [assembly:ExportRenderer(typeof(BottomBar), typeof(BottomBarRenderer))] namespace XamarinSample.iOS.Views { public class BottomBarRenderer : ViewRenderer<BottomBar, UIToolBar> { protected override void OnElementChanged(ElementChangedEventArgs<BottomBar> e) { base.OnElementChange(e); ～UI が生成される際の処理を記述～ } } } プラットフォーム固有ViewRenderer 共有View iOS の場合の委譲先クラス 既定の初期処理が行われる
- 21. Xamarin.Forms で吸収できない機能の記述 •Xamarin.Forms にないBottomBar を固有UI で実装した例 Android は Xamarin ライセンス を持ってないので 作ってません>< iPhone 版Windows Phone 版 実体はUIToolBar 実体はApplicationBar 実体はActionBar ?
- 22. Xamarin × XAML × iOS API × データバインディング プラットフォームの壁を越える データバインディング
- 23. プラットフォームの壁を越えるデータバインディング • Xamarin.FormsでのXAML によるデータバインディング ⁃ プロパティをバインド可能にするためにはBindableProperty を定義する ⁃ BindableProperty は本家XAML の依存関係プロパティに酷似 ⁃ XAML 側ではバインド可能なプロパティにBinding キーワードでバインド可能 ⁃ データコンテキストはBindingContext というプロパティに指定する ⁃ バインド方向、ValueConverter、Command、StringFormat など利用可能！
- 24. プラットフォームの壁を越えるデータバインディング • Xamarin.FormsView 側のバインド可能プロパティの記述例 public static readonly BindableProperty IsEnableStartProperty = BindableProperty.Create(“IsEnableStart", typeof(bool), typeof(BottomBar), true, BindingMode.TwoWay, ValidateIsEnableStart, OnIsEnableStartChanged, OnIsEnableStartChanging); public bool IsEnableStart { get { return (bool)this.GetValue(IsEnableStartProperty); } set { this.SetValue(IsEnableStartProperty, value); } } プロパティ名+ Property の名前で定義 プロパティ名称、データの型、View の型、初期値、 バインド方向、入力チェックメソッド、 変更後イベントハンドラ、変更時イベントハンドラ の順に定義 ※バインド方向以降の指定は省略可 外部への公開プロパティも追加
- 25. プラットフォームの壁を越えるデータバインディング • Xamarin.FormsXAML 側のBinding 指定の記述例 <view:BottomBar StartCommand="{Binding StartCommand}" PauseCommand="{Binding PauseCommand}" StopCommand="{Binding StopCommand}" IsEnableStart="{Binding IsEnableStart}" IsEnablePause="{Binding IsEnablePause}" IsEnableStop="{Binding IsEnableStop}"> <view:BottomBar.BindingContext> <vm:TopPageViewModel/> </view:BottomBar.BindingContext> </view:BottomBar> Command のバインドも可能 BindingContext ≒ DataContext
- 26. プラットフォームの壁を越えるデータバインディング • iOS固有ロジックの中でデータバインドを利用したい ⁃ iOS の主流はMVC のためデータバインディングの機構は標準ではない ⁃ MVVMCross のフレームワークでiOS からバインド可能だがC# コードごりごり （Storyboard 上でのバインド指定はできない） ⁃ Xamarin でもStoryboard 上でのバインド指定はできない ？ Xamarin.Forms とViewRenderer を利用することで XAML 上でバインドしたデータ変更をiOS 固有ロジックに 通知・反映する方法があります！
- 27. プラットフォームの壁を越えるデータバインディング • BindablePropertyの変更を通知するOnElementPropertyChanged public class BottomBarRenderer : ViewRenderer<BottomBar, UIToolBar> { protected override void OnElementPropertyChanged(object sender, PropertyChangedEventArgs e) { switch (e.PropertyName) { case “IsEnableStart”: this.startButton.Enabled = this.Element.IsEnableStart; break; ～ 後略～ ViewRenderer はView のプロパティ 変更時のイベントハンドラをoverride 可能！ Xamarin.Forms のView はthis.Element で参照可能
- 28. プラットフォームの壁を越えるデータバインディング • iOS固有ロジックの中でデータバインドを利用したい ⁃ iOS のStoryboard を利用したバインドはできないが、BindableProperty を介して プロパティの変更を通知・反映することができる ⁃ 当面はこの方法でデータバインディングをするのが無難 BindingContext Xamarin.Forms BindableProperty ViewRenderer XAML Binding 記述 OnElementProperty Changed
- 29. DEMO 時間が余ったので デモアプリをお見せします ※このデモのソースコードはGitHub で公開中 https://github.com/matatabi-ux/XamarinTimer
- 30. まとめ • XamarinのXAML はまだ発展途上 ⁃ Visual Studio だとインテリセンスなし、UI デザイナーなし ⁃ スタイル・テンプレート・VisualState・アニメーションありません ⁃ Binding はそこそこいけるし、今後に期待はもてる・・・はず！ • ViewRenderer でUI 描画・振る舞いを拡張できる ⁃ 共通化できる場合はXamarin.Forms 無理な場合はRenderer にすみ分け ⁃ Renderer からはXamarin.Forms やNativeView と連携可能 ⁃ 当面はデータバインディングをXamarin.Forms に委譲するのがよさそう Xamarin Forms 委譲先の 振り分け プラットフォーム固有描画