Visual Studio for Mac 2019 Preview 4がリリースされました。

Visual Studio 2019 for Mac version 8.0 Preview 4 がリリースされました。

visualstudio.microsoft.com

今回のリリースは、基本的にはバグフィックスで、新たな機能の追加はないようです。その中でも、インストーラーにはかなり修正が入りました。

インストーラー修正内容は以下の通りです。

• Visual Studio for Mac (10.12) に必要な最小バージョンの macOS のサポートを追加しました。 macOS のバージョンが 10.12 以上でない場合に、インストーラーが更新を求めるようになりました。
• 既定のインストーラーが、より小型でスマートなインストールを行うように変更しました。 既定ですべてを選択されるのではなく、すべてのユーザーには IDE と .NET Core を選択し、お使いのマシンにいずれかのバージョンの Xcode または Android SDK が検出された場合には追加で iOS または Android が選択されます。
• Xamarin.iOS または Xamarin.Mac アプリを開発している場合には、最も推奨されるバージョンの Xcode に更新するように求めます (まだインストールされていない場合)。
• Android SDK のダウンロードから、NDK を削除しました。
• Android のアクセス許可のダイアログに対し、UI の改善、ユーザーによる Xamarin.Android の選択解除の許可、ボイスオーバーの問題の修正など、多くの改善を行いました。
• Android のアクセス許可によってアプリケーションがハングしていた問題を修正しました。
• 個々のコンポーネントのエラー報告を改善し、すぐにはエラー ページが表示されなくなりました。

また、 Android Emulator に関する問題も修正されています。

その他、細かい修正内容につきましては公式サイトをご覧ください。

docs.microsoft.com

私も早速アップデートし、色々確認しています。

正式版のリリースが待ち遠しいですね！

Visual Studio 2019 for Mac version 8.0 Preview 3 がリリースされました。

Visual Studio for Mac をご愛用の皆さまお待たせしました！

Windows では、 Visual Studio 2019 RC がリリースされましたが、Mac でも Visual Studio 2019 for Mac version 8.0 Preview 3 がリリースされました。

visualstudio.microsoft.com

目玉機能は以下の通りです。

• Windows のソースコードエディターとコードを共有した新しいエディターがプレビューとして使えるようになりました。
• Getting started が新しくなりました。
• Visual Studio for Mac の複数インスタンスの立ち上げがサポートされました。
• .NET Core 3.0 がサポートされました。
• 複数プロジェクトの同時実行、デバッグがサポートされました。
• Azure Functions template のアップデートを検出できるようになりました。
• Unity デバッガーのコードが Windows と共有になりました。
• Visual Studio for Mac 2017 とのサイドバイサイドがサポートされました。ただし、Mono と Xamarin SDK は共有となります。

私も早速インストールし、色々機能を試しています。

今後、Visual Studio for Mac も Windows 版と機能差が少なくなっていくといいですね！

Xamarin.iOS Wrapper Types と User Types の補足

はじめに

前回の記事で、Wrapper Types と User Types について説明しましたが、言葉だけだとわかりにくいので、図を交えて補足したいと思います。


hiro128.hatenablog.jp

Wrapper Types と User Types

Wrapper types とは

Wrapper types は、UIView や UIButton のような Objective-C の組み込み型をラップしたもので、マネージドの世界では、ネイティブオブジェクトのインスタンスへのハンドルだけを持っています。

Wrapper types のインスタンス作成

var view = new UIView();

Wrapper types のイメージ

User types とは

User types は、UIView や UIButton のような Wrapper types を継承し派生した型で、Objective-C に対応する型が無いものを指し、ネイティブオブジェクトのインスタンスへのハンドルの他に、マネージドな世界だけで管理されている、フィールド、プロパティやメソッドを持っています。

User Types のインスタンス作成

public class MyView : UIView
{
    string myField;

    public string MyProperty { get; set; }

    public MyView(string fieldValue)
    {
        myField = fieldValue;
    }
}

var view = new MyView("fieldValue")
{
    MyProperty = "propertyValue"
};

User Types のイメージ

これで、Wrapper Types と User Types の違いがわかりやすくなりましたら幸いです。

今回は以上です。

Xamarin.iOS でメモリーリークをコントロールするために知っておきたいこと

はじめに

こんにちは、＠hiro128_777です。

この記事は「Xamarin その1 Advent Calendar 2018」の21日目になります。

Xamarin.iOS は基本的には、Objective-C の薄い Wrapper であることは間違いありませんが、オブジェクトがマネージドの世界とネイティブの世界でそれぞれに存在し、互いに関係性を持ちながら、インスタンスが生成・破棄されているので、GC の挙動を正しく理解しておかないとメモリリークをコントロールするのが難しくなる弱点があります。今回はそこについてのお話です。

この記事の内容については Xamarin.iOS のソースコードhttps://github.com/xamarin/xamarin-macios/blob/master/runtime/runtime.mに記載されています。

これは、Xamarin.iOS の GC の挙動について調べるために、Xamarin.iOS のソースコード を読んでいるときに偶然発見しました。これを読むと Xamarin.iOS の GC の挙動のクセがわかると思います。

このような超重要な事が、そんなところに書いてあってもなかなか皆さんが目にする機会はないと思い、今回日本語に翻訳し説明を追加しました。
※わかりやすくするために色々補完して翻訳していますので、原文に忠実な翻訳ではありません。



GC の挙動にかかわる iOS アプリののアーキテクチャーについてはこちらの公式ドキュメントもご参照いただくとより理解が深まります。
docs.microsoft.com



また、より詳しい記事を書き始めましたのでこちらもご覧ください。
hiro128.hatenablog.jp

参照カウンタについての注意点

Wrapper type と User type

Wrapper type は、UIView や UIButton のような Objective-C の組み込み型をラップしたもので、マネージドの世界では、ネイティブオブジェクトのインスタンスへのハンドルだけを持っています。

一方、User type は、UIView や UIButton のような Wrapper type を継承し派生した型で、Objective-C に対応する型が無いものを指し、ネイティブオブジェクトのインスタンスへのハンドルの他に、マネージドな世界だけで管理されている、フィールド、プロパティやメソッドを持っています。

Xamarin.iOS における GC の挙動を考える上で、この2つの型の区別はとても重要となります。

Wrapper type の寿命について

これはとても簡単です。

Wrapper type のインスタンスの寿命は、ネイティブオブジェクトの寿命とはリンクしてません。

Wrapper type のインスタンスは、マネージドな世界にネイティブオブジェクトへのハンドル以外には何も保持していませんので、GC の判断によっていつでも自由に解放できます。もし、後の段階で再びそのオブジェクトが必要になった場合には Wrapper type のインスタンスが再度作成されるだけです。

User type の寿命について

こちらは簡単ではありません。

User type のオブジェクトは マネージドな世界にユーザーが定義した状態を含む可能性があるため GC の判断によって自由に解放することはできません。
よって、User type のオブジェクトを必要な間はずっと生かし続けることを保証する必要があります（マネージオブジェクトは強力な GCHandle によって保持されます）。

この場合の問題は「どうやって不要になったタイミングを判断するのか」ということになります。
これには、歴史的に2つのケースが存在します。

ケース1

ユーザーが Dispose を呼び出すと、マネージオブジェクトの参照が解放され、ネイティブオブジェクトとマネージオブジェクトの間のリンクが切断され、GC がそのオブジェクトを解放できるようになります。（そのマネージオブジェクトを保持している他のオブジェクトが何もなければ）

ケース2

参照カウンタが1に達すると、マネージオブジェクトからの参照が唯一の参照であり、ネイティブコードは当該オブジェクトを再び使用しないと安全に仮定できます。よって、リンクを解除し、ネイティブオブジェクトを解放して、GC がマネージオブジェクトを解放できるようにします。

ケース1で、ユーザーが Dispose を呼び出した後、ネイティブコードが何らかの理由でそのオブジェクトを使用しようとすると、問題が発生します。 Xamarin.iOS は対応するマネージオブジェクトが存在しないことを検出し、それを（再）作成しようとします。ですが、これは失敗し、プロセスを終了させる例外がスローされます（この時、スタックにはマネージドフレーム/例外ハンドラが存在しない可能性があります）。

解決策としては、Disposeを呼び出すときに、次のことを行う必要があります。

• マネージオブジェクトの参照を解放する。
• ネイティブオブジェクトの参照カウンタが0に達するまで、ネイティブオブジェクトと管理オブジェクトの間のリンクを切断しない。

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

User type の挙動についての注意点

User type のオブジェクトは、次のいずれかの条件が発生したときにネイティブオブジェクトへの参照を解放するようになっています。

• Dispose がオブジェクトに対して（手動で）呼び出されたとき。
• マネージオブジェクトの Handle プロパティが変更されたとき。
• GC がオブジェクトを解放したとき。これは、参照カウンタが1でその参照がマネージオブジェクトによる参照である場合にのみ発生します。

（それ以外の時は、マネージオブジェクトに強力な GCHandle があるため、GC の解放処理はブロックされます。）

User type のオブジェクトは、次のいずれかの条件が発生すると、ネイティブ <-> マネージオブジェクトのディクショナリーからオブジェクトが削除されます。

• ネイティブオブジェクトが dealloc されたとき（参照カウンタは0になります）。
• マネージオブジェクトの Handle プロパティが変更されたとき（変更前の Handle 値とマネージオブジェクトの間のリンクがディクショナリーから削除されます）。

User type のオブジェクトは、ネイティブの世界の2つの情報を追跡し続けています。

• マネージオブジェクトへの GCHandle。
• マネージオブジェクトのインスタンスが存在するかどうか。

User type のオブジェクトはすでに GCHandle を保存する Objective-C インスタンス変数を持っているので、別のインスタンス変数を作成しません。
User type のオブジェクトはマネージオブジェクトへの参照（MANAGED_REF_BIT）があるかどうかを GCHandle の1ビットで保存します。

まとめ

Wrapper type は単に、ラッパーですので難しいことは何もありません。
問題は、User type です。こちらは、マネージドな世界とネイティブの世界にそれぞれ状態を持つことになるので、GC の挙動が複雑になっています。

オブジェクトの解放がうまく行われない時には、今回の内容を確認してたいただくとヒントになると思います。実際私もこれを理解してからは、解放できなくて困ったり、強引な Dispose で Exception に悩まされることが無くなりました。

以上です。

とっても簡単なので、Microsoft Docs にプルリクエスト を送ってみませんか。

はじめに

みなさま、Microsoft Docs はご活用されていますでしょうか。

aka.ms

Microsoft Docs はマイクロソフトが提供している各技術カテゴリごとのドキュメントです。それぞれのカテゴリについて充実した詳しいドキュメントが提供されています。

Xamarin につきましても Xamarin.Forms, Xamarin.iOS, Xamarin.Android, Xamarin.Mac, クロスプラットフォームと、５カテゴリについてそれぞれ詳しいドキュメントが提供されています。

その内容ですが、各カテゴリごとに環境のセットアップから、最初のアプリを作成するまでといったチュートリアル的なものから、それぞれのライブラリの API 設計の概念といった高度な内容までしっかりドキュメントが存在します。

よって、ドキュメントを熟読すれば、未経験でも Xamarin を始められるようなドキュメントになっています。

ですが、このドキュメントにはひとつ残念な問題があります。それは、基本的に「機械翻訳である」という事です。もちろん機械翻訳いってもひと昔のものとは違い、AIなどの活用でかなり精度は上がっており、不自然ながらも意味は読み取れるような文章にはなっていますが、読みにくいのは事実です。

もちろん、読みやすい日本語で読めるならそれに越したことはありません。そうであれば、自分の手で読みやすい日本語に修正してしまえばいいと言うのが本日のお話です。

いやいや、私は英語に自信がないので日本語へのローカライズにコントリビュートするとか無理なんですけど・・・

そんなことありません、英語が苦手でも大丈夫です。日本語の知識だけでも何とかなる部分もたくさんあります。

例えば　「章 1 です」-> 「第1章」などの修正であれば、英語力など関係なく修正可能です。このような不自然な表現が少しでも減るだけで、ドキュメントはグッと読みやすくなります。

今後、自分が読むときのストレスを軽減する意味でもプルリクエストを送る意味があると思っています。

間違った翻訳を送ってしまうのが怖いので、ちょっと無理かな・・・

そのような心配も無用です。プルリクエストを受け付ける側の担当の方がきちんと修正した日本語をチェックしてくれて、「適切」と思われる部分且つ、マイクロソフトの表現規約に沿ったものだけを取り込んでくれます。

ですので、間違った翻訳が取り込まれてしまう可能性は稀です。もちろん、可能な限り正しい内容のプルリクエストを送る必要がありますが、間違いを過度に恐れる必要はありません。

気軽な気持ちでまずは一度プルリクエストを送って見てはいかがでしょうか。

Microsoft Docs にプルリクエスト を送るのはとても簡単です。

Xamarin のドキュメントの場合の例

1. https://github.com/MicrosoftDocs/xamarin-docs.ja-jp を自分のリポジトリに Fork します。
   
   
2. 修正用のトピックブランチを切ります。
   
   
3. 修正用のトピックブランチで修正し、自分のリポジトリにコミットします
   
   
4. Github のForkした自分のリポジトリにWebブラウザでアクセスすると、プルリクエストをオープンできるようになっているので、そのままプルリクエストをオープンします。
   
   コミットメッセージ、コメントともに、「fixed inappropriate Japanese」とでも書いておけば十分通じます。（正直この英語表現が正しいかはよくわかっていませんが・・・）
   
   
5. 数日でプルリクエストがレビューされてマージされ、さらにその数日後に共同作成者のアイコンにあなたのアイコンが追加されます！
   
   
   
   

おわりに

修正のプルリクエストは、心構えをしてわざわざ時間をとって取り組むと言うよりは、ちょっとした時間にササッと見て気になる1センテンスだけをプルリクエスト送る方が気楽に取り組めると思います。

基本は自分が読んで意味が分からなかった表現に対してプルリクエストを遅ればみんな幸せになれるのではないでしょうか！

というわけで、皆さんも是非 Microsoft Docs にプルリクエスト を送って、日本語ドキュメントの改善にチャレンジしてみてはいかがでしょうか。