個人的なメモ

Tomohiro Suzuki @hiro128_777 のブログです。Xamarin に関する事を中心に書いています。 Microsoft MVP for Development Technologies 2017- 本ブログと所属組織の公式見解は関係ございません。

Microsoft Docs 「Objective-C 開発者向けの C# 入門書」

はじめに

こんにちは、@hiro128_777です。
Microsoft Docs の Xamarin.iOS のカテゴリでぜひとも読んでいただきたい記事をご紹介します。

https://docs.microsoft.com/ja-jp/xamarin/ios/get-started/objective-c-developers/primer

この記事は、「Objective-C 開発者向けの C# 入門書」というタイトルですが、Xamarin.iOSObjective-C の関係性を理解するのにとても役立ちます。こちらを理解しておくことで、Xamarin.iOS でのハマりどころを理解することができるので、是非、一読していただきたいです。

その中でも、特に重要な部分をピックアップしました。


Objective-C との相互運用

https://docs.microsoft.com/ja-jp/xamarin/ios/get-started/objective-c-developers/primer#objective-c-interop

Xamarin.iOS は単なる、Objective-C の wrapper ではありません。お互いに相互運用できるようになっています。相互運用についての解説です。

プロトコルインターフェイス

https://docs.microsoft.com/ja-jp/xamarin/ios/get-started/objective-c-developers/primer#protocols-vs-interfaces

Objective-CプロトコルC#インターフェイスとの違いを説明しています。 どちらも目的は同じですが、微妙な違いがあります。違いについての解説です。この知識は、Objective-CC# に移植する時に特に重要です。


セレクターと名前付きパラメーター

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/#delegates

セレクターのエコシステムをどのように C# の世界で利用するかについて説明しています。Xamarin.iOS ではイベントの代わりにセレクターを使用することも多いので、とても重要な内容です。

本日は以上です。

Microsoft Docs 「Xamarin.iOS API の設計」

はじめに

こんにちは、@hiro128_777です。
Microsoft Docs の Xamarin.iOS のとても良い記事が Human translation されたのでご紹介します。
(この記事、ぜひ Human translation して欲しかったので issue 上げてましたが、それが採用されました。)

ちょっとまだ翻訳がイマイチな部分もありますが、この記事だけで、20くらい PR 上げておいたので、程なく改善されるはずです。

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/docs.microsoft.com


この記事では、Xamarin.iOSObjective-C の関連によって関して注意しなければならない点がほぼ網羅されています。
Xamarin.iOS でのハマりどころはかなりの部分で、この領域に集約されているので、是非、一読していただきたいです。

その中でも、特に重要な部分をピックアップしました。


NSObject と Dispose の関係とメモリ管理

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/#nsobjectdocs.microsoft.com

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/#nsobject-and-idisposabledocs.microsoft.com


Xamarin.iOS において、ネイティブのインスタンスとマネージドのインスタンスが相互運用される場合、必ずリソースの破棄、つまり Dispose() の問題がついて回りますが、適切に破棄するために理解すべき事項の説明です。


デリゲート

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/#delegatesdocs.microsoft.com


Xamarin.iOSObjective-C では、デリゲートという言葉は違う文脈で用いられます。
デリゲートを使用する目的は一緒ですが、実現方法が違います。
Objective-C では設計のデザインパターンであり、Xamarin.iOS では言語に組み込まれているメソッドを参照する型です。


イベント

https://docs.microsoft.com/ja-jp/xamarin/ios/internals/api-design/#mapping-delegates-to-cdocs.microsoft.com


Xamarin.iOS ではひとつのインスタンスで、Objective-C の selector ベースのイベントと、C#イベントハンドラーベースのイベントをを同時に利用すると、イベントが発火しなくなリますので、ご注意ください。


今回は以上です。

Xamarin.iOS, Xamarin.Android は クロスプラットフォーム開発ツールから C# 版の iOS SDK, Android SDK になりました。

はじめに

こんにちは、@hiro128_777です。
2年ちょっと前に、Xamarin 今そこにある危機という記事を書きましたが、それから2年とちょっとが経過し、Xamarin を取り巻く環境はどう変わったのか、果たして Xamarin は危機を脱したのか、という観点で見ていきたいと思います。

hiro128.hatenablog.jp


いつの間にか変わっていった Xamarin.iOS, Xamarin.Android の位置づけ


Xamarin はご存知の通り、まず、Xamarin.iOS, Xamarin.Android がリリースされ、その後、Xamarin.Forms がリリースされました。
その経緯もあり、ネイティブ iOS SDK や ネイティブ Android API の Wrapper である Xamarin.iOS, Xamarin.Android と、それらを抽象化した UI Toolkit である Xamarin.Forms という構造であるものの、ブランディングとしては別のプロダクトとしてアップデートされていきました。


また、Xamarin.iOS, Xamarin.Android は両者ともそれぞれ、iOS Runtime、Android Runtime と双方向の相互運用が可能です。さらに、iOSAndroidAPI のほとんどが使用できます。(最近サポートされていない機能も増えていますが…)その結果、Xamarin.iOS, Xamarin.Android は、それ単体で iOS, Andtroid のネイティブアプリを開発できる Toolkit であるのと同時に、リリース当初から C# 版の iOS SDK, Android SDK としても利用できるポテンシャルがありました。その結果として、Uno.Platformや、Mobile Blazor Bindings のような Xamarin.iOS, Xamarin.Android の上で稼働するフレームワークが登場してくるというなかなか面白い展開になっています。


これは iOSAndroidAPI を可能な限り全て C# のエコシステムから触れるようにするという Xamarin.iOS, Xamarin.Android のコンセプトが非常優れていたからこその結果だと思っています。正直、昨今 Xamarin.iOS, Xamarin.Android それ自体にスポットが当たることは少なくなってきましたが、Xamarin.Forms や Uno.Platform、Mobile Blazor Bindings の支える重要な API として Xamarin.iOS, Xamarin.Android は今後も生き残っていくことになりました。


というわけで、Xamarin はひとまず危機を脱したと考えています。Visual Studio for Mac も順調にバージョンアップしており、C# で当たり前に iOS API, Android API を触れるのは、私としては非常に嬉しい結果になったと言えます。


今年は Surface Duo も発売され、.NET 5 として Xamarin は統合され、「dotnet new XamarinForms」というコマンドも通るようになるらしいので、Xamarin の今後がとても楽しみです!

Mac Catalyst もサポートして欲しいですが…)

Xamarin.Forms, Uno Platform と Mobile Blazor Bindings の比較

はじめに


こんにちは、@hiro128_777です。

C# / .NET 系のクロスプラットフォームフレームワークもいつも間にか、Xamarin.Forms, Uno.Platform と Mobile Blazor Bindings(まだ Experimental ですが) と3種類も登場しています。「さあ、これから C#クロスプラットフォームやるぞ」という方は、いったいどれから始めればいいのか迷ってしまうと思いますので、それぞれ、どんな違いがあるのかを簡単に整理してみました。



Xamarin.Forms, Uno Platform と Mobile Blazor Bindings のアーキテクチャの比較


Xamarin.Forms

f:id:hiro128:20200224235858p:plain



Uno Platform

f:id:hiro128:20200224235914p:plain



Mobile Blazor Bindings (実験段階)

f:id:hiro128:20200224235926p:plain


Xamarin.Forms, Uno Platform と Mobile Blazor Bindings それぞれの特長

Xamarin.Forms Uno Platform Mobile Blazor Bindings (実験段階)
UI コントロール 各プラットフォーム独自UIを尊重 UWP UI の再現を重視 各プラットフォーム独自UIを尊重
DSL XAML (Xamarin.Fomrs独自) XAML (UWP Based) Razor
iOS
Android
UWP ×
Web × ×
カスタマイズ難易度 × ?(まだ不明)




まとめ


Mobile Blazor Bindings はまだ Experimental ですが、Xamarin.Forms と Uno Platform は問題なくアプリ開発ができます。

Xamarin.Forms の方が設計的に、iOS, Android の最終的なアプリのカスタマイズが考慮されており、iOS, Android らしさについて細かい調整ができます。

Uno Platform は、カスタマイズはあまり考慮されていませんが、各プラットフォームでの見た目の差異が少ないので、UI にこだわりがないツール的なアプリが本当に簡単に作成できます。

Mobile Blazor Bindings は、今の所、Razor で Xamarin.Forms のUI が書けるという感じです。

実際にサンプルアプリをビルドしてみるとその違いがよくわかりますので、ぜひ試してみてください。

Visual Studio for Mac が Install additional required components に対応していました

Visual Studio for Mac は裏で、Xcode を利用していますが、Xcode をインストールまたはアップデートして、一度も起動してないと、iOS, Mac アプリのビルド時にエラーを吐いてビルドできない問題がありました。


これは、Visual Studio for Mac が悪いのではなく、Xcode がインストールまたはアップデート時に、Xcode command-line tools をインストールしてくれず、Xcode の初回起動時にダイアログが出て、インストールを確認する仕様になっているためです。


これは、初学者は自分で気づくことがかなり難しく Xamarin.iOS を使うときの大きなハマりどころでした。


ですが、いつの間にか、Install additional required components が実行されていない場合、Visual Studio for Mac が教えてくれて、そのままインストールも可能なようになっていました。


インストールしていないと、下記のように教えてくれます。

f:id:hiro128:20200119213950p:plain


あとは、Install Xcode command-line tools ボタンを押すと下記のように、Xcode の初回起動時のインストールが始まります。

f:id:hiro128:20200119214052p:plain


これは、とても良い改善です!


マイクロソフトは、Visual Studio for Mac に本気で取り組んでくれています。ぜひ、まだ使っていない方は使ってみてください。

visualstudio.microsoft.com

Xamarin.iOS Deep Dive その5 User type のオブジェクトが破棄される状況を理解する

はじめに



こんにちは、@hiro128_777です。
iOSDC で 以下の通り Xamarin.iOS の仕組みについてお話させていただきました。


www.slideshare.net
www.youtube.com



ですが、時間が足りなくて話しきれなかったことが多いので、blog でもう少し詳しく説明していこうと思います。


前回のお話はこちらです。

hiro128.hatenablog.jp


前回は、Wrapper type と User type の話でした。今回は User type の挙動について深く見ていきます。

User type でマネージ側の参照が解放される状況


前回、User type のオブジェクトは GC の判断で自由に開放することはできないというお話をしました。では、User type オブジェクトはいつ解放されるのでしょうか。

解放される状況は実質以下の2つです。

  1. 他からの参照がない状況で Dispose が明示的に呼び出されたとき
  2. ネイティブオブジェクトへの参照が対応するマネージオブジェクトのみになり GC がオブジェクトを解放したとき


他からの参照がない状況で Dispose が明示的に呼び出されたとき

C#
var button = new MyButton();

button?.Dispose();


上記のように、buttonを保持している他のマネージオブジェクトが何もないときに、ユーザーが明示的にDisposeをコールすると、マネージオブジェクトの参照が外れ、ネイティブオブジェクトとマネージオブジェクトの間のリンクが切断されて、GC がそのオブジェクトを回収できるようになります。

この時、ユーザーがDisposeをコールした後、ネイティブコードが何らかの理由でそのオブジェクトを使用しようとすると、Xamarin.iOS は対応するマネージオブジェクトが存在しないことを検出し、それを再作成しようとします。ですがこれは失敗し、プロセスを終了させる例外がスローされてしまいます。

その問題を解決するため、ユーザーがDisposeを呼び出したとき、Xamarin.iOS は以下のような挙動をします。

  1. マネージオブジェクトの参照を外す。(まだGCに回収はされていない)
  2. ただし、ネイティブオブジェクトの参照カウンタが0に達するまで、ネイティブオブジェクトとマネージオブジェクトの間のリンクは切断しない。(よってGCは回収できない)

これにより、ネイティブオブジェクトが存続している限り、マネージオブジェクトを引き続き参照することができるようにしています


ネイティブオブジェクトへの参照が対応するマネージピアオブジェクトになり GC がオブジェクトを解放したとき

C#
UIButton button;

public override void ViewDidLoad()
{             
    base.ViewDidLoad(); 

    button = new MyButton();
    View.AddSubView(button);
}

public override void ViewDidDisappear(bool animated)
{             
    base.ViewDidDisappear(animated); 

    button?.RemoveFromSuperview();

    button?.Dispose();
}


上記のような場合、button?.RemoveFromSuperview()が実行されると、ネイティブオブジェクトの参照カウンタが1になります。さらに、マネージオブジェクトからの参照が唯一の参照であり、ネイティブコードは当該オブジェクトを再び使用しないと安全に仮定できます。よって、ネイティブオブジェクトとマネージオブジェクトの間のリンクを解除し、ネイティブオブジェクトを解放して、GC がマネージオブジェクトを回収できるようになります。


この2つの状態が発生した時、User type のオブジェクトは破棄されます。


今回は以上となります。


次回は、イベントのアタッチによってメモリーリークするメカニズムを手順を追ってご説明します。

iOS で Uno Platform と Xamarin.Forms の registar.m を比べてみました。

はじめに


こんにちは、@hiro128_777です。


この記事は「Xamarin Advent Calendar 2019」の22日目になります。

最近何かと話題の Uno Platform ですが、iOS, Android に関しましては内部的には Xamarin を利用していると言うことですので、気になっているのでちょっと触ってみました。

私は、Xamarin.iOS が大好きなので、Xamarin.iOS との関係、特に registar.m の生成が Xamarin.Forms の iOS アプリとどう違うかを調べてみました。


作ってみたアプリ


registar.m を調べるにはとにかく実機ビルドしなければいけませんので、超簡単なサンプルを作って早速ビルドしてみました。

f:id:hiro128:20191222174415p:plain

そして同じアプリを Xamarin.Forms でも作ってビルドしました。


registar.m の比較


Uno Platform と Xamarin.Forms で生成された registar.m を比較してみましょう。


registar.m についてはレジストラーを使えるようにするための仕組みですのでこちらの公式ドキュメントも是非ご参照ください。
docs.microsoft.com


起動時に読み込むアセンブリの比較


比較しやすいように実際の registar.m と順番を変えています。


Uno Platform

static const char *__xamarin_registration_assemblies []= {
    "UnoSampleApp", 
    "mscorlib", 
    "Uno",
    "Uno.Core", 
    "Uno.Foundation", 
    "Uno.UI",
    "Uno.UI.Toolkit"
    "Uno.Xaml", 
    "Xamarin.iOS", 
    "Mono.Security", 
    "System", 
    "System.Xml", 
    "System.Numerics", 
    "System.Core", 
    "System.Net.Http", 
    "System.Drawing.Common", 
    "System.Data", 
    "System.Runtime.Serialization", 
    "System.Runtime.CompilerServices.Unsafe", 
    "System.ServiceModel.Internals", 
    "System.Web.Services", 
    "System.Xml.Linq", 
    "System.Collections.Immutable", 
    "Microsoft.Practices.ServiceLocation", 
    "Microsoft.Extensions.Logging.Abstractions", 
    "Microsoft.Extensions.Logging", 
    "Microsoft.Extensions.DependencyInjection.Abstractions", 
    "Microsoft.Extensions.Logging.Filter", 
    "Microsoft.Extensions.Primitives", 
    "Microsoft.Extensions.Logging.Console", 
    "Microsoft.Extensions.Configuration.Abstractions", 
};


Xamarin.Forms

static const char *__xamarin_registration_assemblies []= {
    "XFSampleApp.iOS", 
    "XFSampleApp", 
    "mscorlib", 
    "Xamarin.Forms.Platform", 
    "Xamarin.Forms.Platform.iOS", 
    "Xamarin.Forms.Core",
    "Xamarin.Forms.Xaml"
    "Xamarin.iOS", 
    "Mono.Security", 
    "System", 
    "System.Xml", 
    "System.Numerics", 
    "System.Core", 
    "System.Net.Http", 
    "System.Drawing.Common", 
    "System.Data", 
    "System.Runtime.Serialization", 
    "System.ServiceModel.Internals", 
    "System.Web.Services", 
    "System.Xml.Linq"
};



比べてみると、Xamarin.Forms の方がだいぶ少ないですね。Uno Platform は、iOS の UI コンポーネントを UWP の UI コンポーネントAPI で利用できるように、かなりの量のコードを書いています。この部分が丸々乗っかって来てるので、起動時に必要なアセンブリが多くなっています。



トランポリンの数の比較


トランポリンは C# 側のハンドラーメソッドを、Objective-C のランタイム側から引数をマーシャリングして呼ぶ仕組みです。
詳しくはこちらをご覧ください。

また、こちらの公式ドキュメントも参考になります。
docs.microsoft.com



Uno Platform : 124
Xamarin.Forms : 163


Uno Platform がかなり少ないですね。トランポリンの分布は調べるのがかなりしんどいので調べていません。



Class Map の 登録


Class Map は C# 側のオブジェクトで、Objective-C のランタイム側からアクセスする必要があるものを起動時に Objective-C のランタイムに登録する仕組みです。


Uno Platform : 486
Xamarin.Forms : 340


Uno Platform がかなり多くなっています。これも、Uno が、iOS の UI コンポーネントを UWP の UI コンポーネントAPI で利用できるように、かなりコードを書いていることに起因しています。



サンプルアプリの ipa のサイズ


Uno Platform : 13.5MB
Xamarin.Forms : 8.7MB


f:id:hiro128:20191222231906p:plain


上記のようになりました。 Uno Platform の方がアセンブリの数が多いので、順当な結果です。実際に大きいアプリになればフレームワークの容量はあまり関係ないので、そこまで気にするほどではないと思います。


まとめ


Uno Platform と Xamarin.Forms を、registar.m から比較してみましたが、最終的にどちらも Xamarin.iOS を利用しているので、その観点からは大きな差はないことがわかりました。もう少し何か出るかと思って調べてみましたが、単に使っている UI コンポーネントのライブラリが違うだけと言うそのままの結果でした。


Xamarin.iOS の上に、Uno Platform または、 Xamarin.Forms が乗っているという構成は全く同じですので、UWP の XAML を使いたいのか Xamarin.Forms の XAML を使いたいのか、あとは SPA も一緒に生成したいかでどちらを使うか決めればよいと思います。


@tan-yさんも仰っていましたが、Uno Platform は、UI コンポーネントの定義とレンダリングが分離されていません。よってカスタムでレンダリングしたいときに Xamarin.Forms のように比較的戦略的に機能を追加するのは難しく、あまり自分でカスタマイズして使う前提ではないのかも知れません。Uno Platform の FAQ にも、 UWP で提供されている全ての API を 様々なプラットフォーム上に展開するのがゴールだとあるので、カスタマイズは方向性として違うのだと思います。


Uno Platform は、UWP の各デバイスへの展開
Xamarin.Forms は、各デバイスの UI コンポーネントを統合して抽象化
なので、同じ XAML を使っていても、そもそもの思想が違うようです。


ですが、Uno Platform が Xamarin.iOS, Xamarin.Android を使用しているのも、Xamarin.iOS, Xamarin.Android がプラットフォームのブリッジとして、とてもよくできているからだと思っています。Xamarin.Forms がそれ自体の実装に、iOS, Android のブリッジを持たず、Xamarin.iOS, Xamarin.Android の上に乗せる形になっているのも、とても素晴らしい設計です。


Uno Platform と Xamarin.Forms は方向性が違うので今後の発展がとても楽しみです。また時間をとって、もっと色々調べてみたいです。


今回生成した、registar.m こちらなのでよろしければご覧くださいませ。


Uno Platform
Xamarin.Forms


以上です。