約1年前、Xamarin.Formsと呼ばれるクロスプラットフォームフレームワークが登場しました。 C＃と.NETを使用して、さまざまなプラットフォーム用のモバイルアプリケーションを作成できます。 実際、Xamarin.iOS、Xamarin.Android、およびXamarin.WinPhoneのアドオンは、それ以前に既に存在していました。 また、それらとは異なり、アプリケーションとそのUIのロジック全体を記述できるプロジェクトを1つだけ作成できます。 そして、異なるプラットフォームでコンパイルするだけです。 その結果、これらすべてが大幅に時間を節約します。

このプラットフォームには独自の見通しがあり、したがって、それを通り抜けることはできないと考えています。 従来、データグリッドコントロールの開発から始めました。 その作業中に、Xamarin.Formsの興味深い開発経験を積んでいます。それを皆さんと共有したいと思います。

この記事はDevCon 2015での私のレポートに基づいており、誰でもここでビデオバージョンを読むことができます 。

Xamarin.Formsの利点

まず、このプラットフォームの利点についてお話したいと思います。

• まず、これは私たち全員がC＃と.NETに精通していることです。 シャープで長い間書いているのであれば、いくつかの新しいフレームワークや言語を勉強するのに多くの時間を費やす必要はありません。 まあ、または少なくとも最初は必要ありません。現在の知識を使用して非常に迅速に開始できます。
• 第二に、ユーザーインターフェイスを作成して操作する方法は、Windowsでよく使用されている方法に近いものです。 Xamarin FormsはXAML、バインディング、テンプレート、スタイル、およびその他の楽しみの操作をサポートしているため、WPF開発者は特に喜んでいます。 それらがいくらか削減されていることは明らかだと思います。WPFのすべてのパワーを期待するべきではありませんが、それでも便利です。
• これはC＃であるため、次の利点は、既に記述されたコードを再利用できることです。 ほとんどの場合、正常に機能します。 プラットフォームには制限がありますが、それほど素晴らしいものではありません。 XtraGridControlから十分な大きさのピースを取得することができたので、非常に役立ちました。
• Xamarin.FormsがWPFに似ているという事実は、このプラットフォームの次のプラスを意味します：MVVM。 実際、Xamarin.FormsにはXAML、視覚要素にはBindingContext（WPFのDataContextのアナログ）、BindableProperty（DependencyPropertyのアナログ）があります。 したがって、WPFと同じ方法でViewをViewModelに関連付けることができます。
• このプラットフォームのもう1つの利点は、UIが1箇所でしか記述されていないため、異なるシステムのアプリケーションが非常によく似ていることです。 たとえば、企業の発展において重要なこと。

Xamarin.Formsの機能と欠点

ニュアンスとデメリットに移りましょう。

開始するには、小さな技術的な紹介。 次の図では、Xamarin.Formsがどのように機能するかを大まかに示しました。



回路の上部にはPCL部分があります。 これは基本的にXamarin.Formsです。 一般的には、エディター、ナビゲーションバー、レイアウトパネルなどのコレクションです。 UIを開発するとき、ほとんどの場合、UIを操作します。 ただし、これらのコントロールは、PCLパーツ内の単なる抽象化です。 何らかの方法でデバイスに表示できるように、いわゆるレンダラーがあります。 これらは、Xamarin Platformパーツの階層の次の段階にあります。

PCL部分の下に、Xamarin.iOS、Xamarin.Android、およびXamarin.WinPhoneがあります。 これは基本的に、Xamarin.Formsの前にすでに存在していたXamarinです。 そして、このXamarinとは何ですか？ これらは、各プラットフォームのネイティブクラスのC＃ラッパーです。 レンダラー-これらは、対応するビジュアルコンポーネントのラッパーですが、PCLオブジェクトへのリンクが内部に含まれているため、設定したプロパティを読み取り、自宅で適用できます。

将来、これらのレンダラーは既にネイティブコントロールにデプロイされています。 回路の下位レベルでそれらを見ることができます。

混乱を避けるために、例を挙げましょう。 PCL部分にはButtonクラスがあります。 各Xamarinプラットフォームパーツには、Buttonクラスのインスタンスを格納するButtonRendererクラスが含まれています。 一方、ButtonRendererは、iOSのUIButtonなど、各プラットフォームのボタンクラスのラッパーです。 このチェーン上で、PCLパーツからのコントロールが機能します。

このメカニズムには、このプラットフォームのほぼすべての問題が含まれています。

Xamarin.Formsで開発するときに発生する次のグループの問題は区別できます。

• WPF機能の不完全な実装
• プラットフォームによって異なる機能の実装における妥協ソリューション
• 異なるプラットフォームでの異なる動作
• 性能

次に、これらの問題を具体的な例で見てみましょう。

WPF機能の不完全な実装

これが私たちが最初に出会ったものです。 Xamarin.Formsには、開発でのテンプレートの使用に大きな制限があります。 WPFで長い間働いてきた人として、私はこのツールが本当に好きです。 テンプレートを単に重ねることでコントロールの外観を任意に変更できる場合に非常に便利です。 ただし、テンプレートがレンダラーの概念にうまく適合しないことは明らかです。これは、WinPhoneだけがエンドプラットフォームでこのような機能を備えているためです。

プラットフォームによって異なる機能の実装における妥協ソリューション

プラットフォームは異なる場合があり、レンダラーはこれらの違いをすべて単一の制御メカニズムに減らす必要があります。 したがって、いくつかの機能を犠牲にする必要があります。

• たとえば、Androidでは、テキストエディターで単一行モードと複数行モードの両方を有効にできます。 ただし、これはiOSでは実行できません。 これらの状況には2つの異なるコントロールがあります。 1つのPCLオブジェクトは1つのレンダラーにのみ関連付けられ、プラットフォーム上の1つのコントロールに関連付けられるため、Xamarin.Formsには1つの動作のみが残され、そのエディターは常に複数行になります。
• また、モバイルプラットフォームのマイルストーンでは、ジェスチャを操作するメカニズムが大きく異なります。 そして、それらを一般的な抽象化に減らすことは非常に困難です。 したがって、Xamarinは通常のタップのみをキャッチする機能を提供します（バグがないわけではありません）。 残りのジェスチャは、PCL部分からキャプチャできません。
• プラットフォームによっては、C＃または.NETでできることをイデオロギー的にできない場合があります。 これらの制限は、Xamarinのドキュメントに記載されています。 ただし、これに最初に遭遇したとき、移動に対処するのは簡単ではありません。
  
  たとえば、iOSでは、実行時にコードを生成できないという意味で、すべてのコードが静的である必要があります。 部分的には、System.Reflection.Emit名前空間を削除することで、すでに簡単になっています。 ただし、エミュレータで問題なくコンパイル、実行、動作するが、デバイスでクラッシュするコードを作成することもできます。 幸いなことに、すでに書いたように、考えられる問題はドキュメントに記載されています。
  

異なるプラットフォームでの異なる動作

コントロールの動作はプラットフォームによって異なる場合があります。 すでに見たように、Xamarin.Formsでは、ユーザーインターフェイスはすべてのプラットフォームの共通部分で説明されています。 そして、最終的にはすべてのシステムで同じように見えることが予想されます。 まあ、または少なくとも非常に近い。 しかし、これは常にそうではありません。 踏み込んだメインレーキを見てみましょう。

WinPhoneのマージン

WinPhoneでは、一部のコントロールに大きなマージンがありますが、これは他のプラットフォームでは使用できません（たとえば、スイッチコントロール）。 したがって、アプリケーションの外観は、完全に操作不能になるまで（要素が単に可視領域に収まらない場合）、AndroidおよびiOSのバージョンとは大きく異なる場合があります。

小さな例を示します。 同様のレイアウトでテストアプリケーションを作成する場合：

<Grid RowSpacing="0"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <Switch Grid.Row="0“ /> <Switch Grid.Row=“1“ /> </Grid> 

その後、iOSで実行すると、次のように表示されます。



Androidでも同じです。 しかし、WinPhoneで実行すると、次の結果が得られます。



ご覧のとおり、スイッチコントロールは互いに離れた場所にあります。 これは、WinPhoneのSwitchコントロール内に、サイズが大きすぎるグリッドパネルがあるためです。 この動作はWinPhoneに固有であるため、PCLレベルではなく、スイッチのレンダリングで解決する必要があります。 WinPhoneのネイティブソリューションは、スイッチコントロールのデフォルトスタイルをオーバーライドするか、必要なスイッチのスタイルのみをオーバーライドすることです。 PCL部分ではこれができないことは明らかであり、Xamarin.WinPhoneを1レベル下に下げる必要があります。

Xamarin.WinPhoneレベルでは、新しいデフォルトスタイルを設定できますが、必要なコントロールにのみスタイルを適用することはできません。 グリッド内にあるスイッチのみの外観を変更し、他のスイッチには触れないようにする必要があるため、この問題を解決しましょう。

前述したように、プラットフォームレベルでは、コントロールはレンダラーで表されます。 そのため、コントロールに変更を加えるには、そのレンダラーを編集する必要があります。 現在、私たちのタスクは他のスイッチに影響を与えずにスイッチの動作のみを修正することであるため、最も単純な解決策はスイッチの継承者を作成し（将来使用する）、その上にレンダラーを作成することです（標準のButtonRendererから継承されます）。 このレンダラーでは、視覚的なコントロールツリーを必要に応じて変更できます。 たとえば、次のように：

 Control switchControl = VisualTreeHelper.GetChild(Control, 0) as Control; Border border = VisualTreeHelper.GetChild(switchControl, 0) as Border; Grid grid = VisualTreeHelper.GetChild(border, 0) as Grid; grid.Height = 40; 

また、GetDesiredSizeメソッドで正しいサイズを返すことを忘れないでください：

 public override SizeRequest GetDesiredSize(double widthConstraint, double heightConstraint) { SizeRequest result = base.GetDesiredSize(widthConstraint, heightConstraint); result.Request = new Size(result.Request.Width, 40); return result; } 

その結果、次の結果が得られます。

ジェスチャー傍受

次の例では、新しいタスクがあると仮定します。画面のある領域ですべてのジェスチャーをロックする必要があります。 多くのコントロールがあり、それらの一部はそれ自体でジェスチャーをキャッチします（たとえば、エディターやボタン）。したがって、ロックするための単一のエントリポイントはありません。 この場合、簡単な解決策があります。目的の領域の上に透明なパネルを置き、InputTransparentプロパティをfalseに設定します。 このプロパティは、ジェスチャが要素のツリーに沿ってさらにスクロールするのを止めるという事実に正確に関与しています。 したがって、次のように記述した場合：

 <Grid> <Switch VerticalOptions="Center" HorizontalOptions="Center"/> <ContentView VerticalOptions="FillAndExpand" HorizontalOptions="FillAndExpand" InputTransparent="false"/> </Grid> 

動作するはずで、スイッチを押さないでください。 そして実際、これはまさにiOSで起こることです。 ただし、Androidでこれをチェックすると、スイッチが押されたままになります。 ご覧のとおり、AndroidはInputTransparentプロパティの設定を無視します。 これを修正するには、前の例のように行います-ContentViewの継承者を作成し、次のレンダラーを作成します。

 public class MyContentViewRenderer : Xamarin.Forms.Platform.Android.VisualElementRenderer<MyContentView> { public override bool DispatchTouchEvent(Android.Views.MotionEvent e) { return !Element.InputTransparent; } } 

DispatchTouchEventメソッドをオーバーライドします。このメソッドはジェスチャをスローするだけで、PCLオブジェクトの設定されたInputTransparentに応じて値を返します。 この問題も解決しました。

デフォルトのレイアウトの違い

要素は、プラットフォームごとにプロパティのデフォルト値が異なる場合があります。 たとえば、レイアウト。 このパネルでアプリケーションを実行しようとすると：

 <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="DefaultLayout.MyContentPage"> <Switch /> </ContentPage> 

次に、iOSおよびWinPhoneでこれらの結果を取得します。



Androidでは、WinPhoneと同じになります。 ご覧のとおり、画面上のさまざまな場所にコントロールが表示されています。 したがって、常にデフォルトのプロパティ値に依存する必要はありません。 このようなことが起こらないように、自分自身を保護し、それらの値を設定する方が良いです。

性能

また、PCLパーツの抽象化の追加レベルにより、アプリケーションに新しいブレーキが追加されます。 速度の点では、Xamarin.Forms上のアプリケーションは、ネイティブのものをかなり失う可能性があります。 特に、ビジュアルツリー全体を頻繁に再描画することを非常に好むことを考慮してください。

これでどうやって生きるの？

すでに示したように、このような問題を回避するためには、ネイティブモバイルパーツにクロールし、要素のレンダラーを作成する必要があり、どのデフォルトレンダラーが対処できないかを既に決定しています。

個人的には、PCLから任意のジェスチャーをサブスクライブできるようにするジェスチャーハンドラーを完全に作成し、すべてのエディターのレンダラーを作成して、そこに不足しているプロパティを引き出しました。 InputTransparentの問題は、Androidのレンダラーとそのジェスチャーのブロックによって再び解決されました。 さて、レンダラーに登るときは、レンダリングするシステムのネイティブAPIをすでに処理する必要があります。 そして、それはすでにこのAPIを学ぶ必要があります。 ですから、最初にそれを学ぶ必要はないと最初に述べたのは無駄ではありませんでした。

しかし、これらの問題はすべて何らかの形で回避されています。 そして、最終的にこのフレームワークでGridControlを作成することができました。 データを表示および操作するための十分に大きな機能を備えています。 次のようになります。



グリッドは非常に高速で機能が豊富であることが判明しました。 ただし、Xamarin.Formsに関する次の記事で、これについて詳しく説明します。

結論として、Xamarin.Formsは、一度に複数のプラットフォームでクイックスタートが必要な場合、パフォーマンスがそれほど重要ではない場合、または新しいアプリケーションで再利用したい古いコードがたくさんある場合に使用できると言いたいと思います。 また、最終的なアプリケーションの美しさよりも開発速度の方が重要であるため、企業のプログラマーにとっても非常に役立ちます。

もちろん、通常とは異なるデザインや作業の高速化が重要であり、店舗で販売するアプリケーションを作成する場合は、ネイティブモードまたはXamarin Mobileで作成した方がよい場合があります。 現在、Xamarinチームは積極的に製品を開発していますが、アップデートは頻繁にリリースされます。 したがって、Xamarin.Formsの範囲が拡大することが望まれます。

更新：
GridControlに関する詳細情報は、DevExpress からのXamarinの無料グリッドコントロールの記事をご覧ください。