XamarinとXamarin.Formsはチョコレートサボテンです。 パート1

エルバはモバイルアプリケーションが大好きです。 iOS用のアプリケーションを作成した経験があり、Android用のアプリケーションを開発してさらにサポートしています 。 今年もiOS用のバージョンをリリースしましたが、今回はXamarinとXamarin.Formsに基づいており、経験を共有したいと考えています。 これまでのところ、iOSのみの開発を検討することができましたが、すでに多くの印象があり、Androidについて間違いなく言う言葉がいくつかあります。

Xamarinとは

.NET （より正確にはMonoの実装）に基づくモバイルアプリケーションのクロスプラットフォーム開発のフレームワークは、すべての主要なオペレーティングシステム（Android、iOS、Windows Phone）をサポートしています。 詳細については、Habréに繰り返し 記載されているため、繰り返す必要はありません。

Xamarin.Formsとは

上記のプラットフォームのいくつかについて、インターフェースの単一のレイアウトをすぐに開発できるフレームワーク。 アイデアは次のとおりです。Xamarinコンポーネントに基づいて一度レイアウトを行い、ターゲットプラットフォームでは、各コンポーネントに対してレンダラーが呼び出され、既にネイティブなコンポーネントが描画されます。 レイアウト自体は、コードとXAML形式の両方で準備できます。 1年前のような 、結果のインターフェイスのレイアウトとプレビュー用のUIユーティリティはまだないため、コードからUIを作成するオプションを選択しました。

なぜXamarin + Xamarin.Formsを選択したのですか？

いくつかの理由がありました。

1. サーバーでは.NETとC＃を使用しているため、3つのアプリケーション（サーバー、iOS、Android）に1つの言語とプラットフォームを使用するのは非常に便利です。ある言語から別の言語に切り替える必要はなく、使い慣れたパターンを使用する機能があり、ライブラリ内の共通のフラグメントを簡単に選択できます、など.p。
2. 利用可能なフレームワークの中で、Xamarinは最も開発されたものに見えました。
3. HTML5アプリケーションを作成するオプションについては考慮しませんでした。アプリケーションで多くのフォームが計画され、この点に関するネイティブコンポーネントは著しく予測可能かつ高速に動作します。 特に低コストのAndroidスマートフォンに適しています。
4. Xamarin.Formsは、最小限のドップルでAndroidとiOSの共通インターフェイスを作成できる可能性に加え、iOSの使い慣れたブロックレイアウトモデルなど、多くの利点を喜んでいます。

最初の血

有料版との通信の始まりはアクティベーションシステムの傾斜で始まりました：Xamarin Webサイトの個人アカウントで既に支払い（ MSDNサブスクライバーの場合は 999 ドルまたは799ドル ）が表示されていましたが、Xamarin.Studioは頑固にアプリケーションのビルドを拒否しました。 「有料版はアクティベートされていません。」 Xamarinテクニカルサポートによる支払いの手動アクティベーションのみが役立ちました。 彼らはすぐに答えましたが、いずれにせよ、これは素晴らしいスタートであり、その後のプロジェクト全体のトーンを設定します。



ところで、無料試用版では、コンパイルされたコード用にサイズが64キロバイトを超えるアプリケーションをビルドすることはできません。 つまり、たとえば、同じjson-serializer（Newtonsoft）を接続します。これで、アプリケーションをビルドできなくなります。 いいね

IDEの問題

Xamarinは、 MonoDevelopに基づいて独自のXamarin.Studio IDEを提供します。 残念ながら、このIDEにはいくつかの問題があります。

1. 不安定。 たとえば、アプリケーションのアセンブリを中断しようとすると、固くフリーズする可能性が非常に高くなります。
2. バックライトを定期的に中断するか、オートコンプリートします。
3. 自動補完は、現在のネームスペースにないクラスを探す方法を知りませんが、クラスへの完全に記述された呼び出しを使用して必要な使用環境を作成できます。
4. リファクタリングの機会は明らかに十分ではありません。彼女はこの点でResharperからはほど遠いです。
5. XIBエディター（iOSのレイアウトファイル）との統合は定期的に中断します。 XIBまたはストーリーボードを介してレイアウトを使用する場合、Xcodeは編集のために開き、閉じると、UIに関連付けられた自動生成されたクラスが更新されます。 しかし、常にではありません。 環境は、原則として、一部またはすべてのファイルのXcodeの呼び出しを停止する場合があります。 スタジオのキャッシュをクリアすることで処理されます（ 〜/ Library / Caches / XamarinStudio-5.0ディレクトリのコンテンツを削除します）。

しかし、良いニュースがあります！ ビジネス料金では、Visual Studioとの統合があり、そこでVisual Studioでコードを記述できます。 これは非常にうまく機能します。 たとえば 、いくつかの問題があります。 たとえば 、これまでAndroidやXAMLを使用していなかったため、 このような問題は発生していません。 しかし、彼らは他の人に出くわしました。



実際のところ、iOSアプリケーションを構築するには、Mac OS Xを搭載したコンピューターまたは仮想マシンが必要です。ここには2つのオプションがあります。

• Macで実行されているXamarin Studioからアプリケーションをビルドしてデバッグする
• Visual Studioとポピー（ビルドホスト）の統合にプラグインを使用すると、VSからシミュレータでビルドおよび実行プロセスを開始し、そこでデバッグできます。 ただし、アプリケーションを実行する場合、シミュレーターの画像はまだMac上でのみ描画されるため、2台のPCを同時に並べて、一方のアプリケーションをテストし、他方のデバッガーで作業する必要があります。

さらに、統合プラグインは長い間不安定でした。 この状況は定期的に発生しました。3人の開発者が全員、同じバージョンのOS、studio、Xamarinなどを使用しています。 それらは同じケシに順番に接続されます。 その結果、1つではすべてが正常に機能し、2つ目ではブレークポイントが無視され、3つ目ではまったく機能しません。



テクニカルサポートは、MacとWindows用の最新の4つのバージョンを試すようにアドバイスしました。「おそらくいくつかの組み合わせが機能するでしょう。」 インストールには20〜30分かかります。 インストーラーは、前回ダウンロードしたコンポーネント（Android SDKライブラリーなど）もダウンロードします。 だと思う...



ただし、プラグインが正常に機能する場合でも、次にVisual Studioでプロジェクトを開くと、ネットワークが切断されるか、たとえばMacがオフになります。プラグインは、ビルドホストの検索でハングする可能性があります。 そして、システムレジストリに移動して、そこにあるビルドホストの保存されたパラメーターを削除しなければならなかった場合、「キャンセル」が常に機能するとは限りません。



したがって、私たちは次のように長い間働いていました。

1. コードは、Macで使用可能なネットワークフォルダーと、その上で実行されているParallels Windows仮想マシンにあります。
2. ほとんどのコードは、この仮想マシン内のWindowsのVisual Studioで記述されています。
3. 最終バージョンのデバッグまたはアセンブリは、Mac OS XのXamarin.Studioで行われますが、プラグインではなく、共有フォルダーの同じコードを手動で開きます。

さて、小さなトラブルから：iOSでプロジェクトを開くたびに、プラグインはビルドホストへの接続を提案し、質問に答えるまでプロジェクトのさらなるロードをブロックします。











幸いなことに、何ヶ月も苦しんだ後、Xamarinチームは私たちに同情しました。 Xamarin.Studioの最新の更新プログラムはこの問題を解決しました-リモートポピーに接続するためのウィンドウに、「接続ウィンドウを表示しない」チェックマークが表示されました。



ああ、それはまた、独自のXamarinユーティリティではなく、Mac OS Xの通常のリモートユーザーを介して、リモートビルドを実行します。







その結果、接続は非常に安定し、10のうち8つのケースでデバッグが正常に開始されます。しかし、いずれにしても、シミュレーターは別のPCで実行されます。 デバッグはマシン上にあり、アプリケーションはそこで実行されており、PCに画像は表示されません。 リモートセッションを開くか、2台目のコンピューターを同じテーブルに保持できます。



ソリューションはまだややこしいままですが、Xamarin Studioの使用を完全に放棄することができます！ 信じてください、数ヶ月住んだ後、私たちは確かに言うことができます：それは価値があります。



プロファイリングに問題があります。 iOSアプリケーションのXamarin.Profiler （ Monoログプロファイラーの GUIラッパー）は、長い間、作成したクラスの名前を表示しませんでした。そのようなネイティブオブジェクトがプロセッサ時間とメモリを占有するという情報しかありませんでしたが、作成したクラスとそれらを比較する方法は少しではありません明らかではありません。 これで状況は改善されました-書かれたクラスがついにリストに登場しました。



また、プロファイラーの下では、アプリケーションの実行が非常に遅くなり、その結果、起動に割り当てられた時間内に最初の画面を表示する時間がない場合があり、iOSはそれを打ち負かします。 また、アプリケーションが起動した場合、プロファイラーの下のシミュレーターで作業中にクラッシュする可能性があります。 弱い言い訳として、プロファイラーが長い間アルファ版の段階にあり、過去1年間で少なくとも「安定したベータ版」の段階に到達していないことがわかります。

クロスプラットフォームの問題

次の2つの方法のいずれかでクロスプラットフォームコードを記述することができます。

1. 共有プロジェクト 。 このプロジェクトのコードは、個別のアセンブリにコンパイルされるのではなく、一度に複数のプロジェクトの一部として自分自身を単純にインクルードします。 一種のsimlinkプロジェクト。
2. PCLライブラリ 。 （Portable Class Library）クロスプラットフォームライブラリ。

理論的には、1つのことを選択するように求められます。 実際には、これらの方法の両方を使用しました。



PCLプロジェクトでは、データベース、ネットワークなどと連携して、すべてのビジネスロジックを作成しました。 主な利点は、PCLがプラットフォームの1つに実装されていないシステムクラスの使用を許可しないことです。 したがって、PCL内で記述およびアセンブルされたコードは、選択されたすべてのプラットフォームで実行されることが保証されています。



欠点は、PCLライブラリが、選択されたすべてのオペレーティングシステムの機能の共通部分に基づいて記述されているため、それらの1つに欠けているものを使用できないことです。 つまり、iOSとAndroidのみを使用する予定で、一部の必要な機能がWindows Phoneにない場合は使用できません。 同時に、サポートされるプラットフォームを定義するPCL用の「プロファイル」のセットがありますが、執筆時点では、「iOSとAndroidのみ、Windows PhoneとWindowsなし」を選択することは不可能です。







その結果、iOSとAndroidで動作することが保証されているが、PCLでビルドできない共有アセンブリコードを追加しました。 たとえば、gzipの回答や、ネットワークまたはデータベースでの作業に関するその他の詳細がサポートされています。



PCLでは、ファイルの操作など、些細なことはないかもしれません。 -この場合、PCLアセンブリにインターフェースが存在し、特定のOSの実装がすでにプロジェクトにあると想定されています。 私たちの場合、これらの実装の一部は、共有アセンブリになりました。



ところで、PCLのプロファイルを選択する場合は、259のプロファイルを選択することをお勧めします 。 利用可能なすべての機能に最適です。 たとえば、ミューテックスやスレッドセーフな辞書を含まない別のものから始めました-あなたは手で書くことができますが、なぜですか？ また、プロファイルの選択は、Visual StudioではなくXamarin.Studioの方がはるかに便利で明確であることに注意してください。







まず、PCLの別の機能：1つのPCLライブラリに応じて異なるプロファイルを持つ別のPCLライブラリを追加することはできません。 より正確に言えば、追加することはできますが、すべてのプロファイルがすべてのプロファイルに対応するとは限りません。 一般に、PCLの概念は一般的に使用可能ですが、特に白熱を引き起こす可能性があります。

ネイティブプラットフォーム機能へのバインドの問題

Xamarinの基本的な考え方は、ネイティブコードを記述するときに使用するのと同じクラス、メソッド、および構造を使用してコードを記述できるということです。これは、C＃で記述されたばかりです。 しかし、微妙な違いがあります...



iOSの場合、デリゲートにはかなり興味深いバグがあります。 これは、たとえば、 UIScrollViewコンポーネントです。 特定のイベントを処理するデリゲートを割り当てるか、これらのイベントを直接サブスクライブできます。

var scrollView = new UIScrollView(); // 1 class UIScrollViewDelegate1: UIScrollViewDelegate { public override void ScrollAnimationEnded(UIScrollView scrollView) { base.ScrollAnimationEnded(scrollView); Debug.WriteLine("Yes, animation ended"); } } scrollView.Delegate = new UIScrollViewDelegate1(); // 2 scrollView.ScrolledToTop += (_, __) => { Debug.WriteLine("Yes, scrolled to top"); }; scrollView.ScrollAnimationEnded += (_, __) => { Debug.WriteLine("Yes, animation ended"); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、 ScrollAnimationEndedイベントをサブスクライブすると、 デリゲートは自動的に内部Xamarinに置き換えられます。 また、 ScrolledToTopイベントのサブスクリプションは失われます。 どうやら-問題は何ですか？ イベントとデリゲートを1つのコードに混在させないでください！ しかし、時には問題の状況があります：

1. コンポーネントには目的のイベントがありませんが、デリゲートに存在します。
2. コンポーネントでは、いくつかのハンドラーを持つカスタムデリゲートをXamarin自体によって既に割り当てることができます。

または、たとえば、Xamarin.iOSでは、クラスは2つの iOSプロトコルUITableViewDataSourceおよびUITableViewDelegateを置き換える単一クラスUITableViewSourceを使用します 。 これはわかりにくいかもしれません。



メソッドとクラスのシグネチャも時々変更され、同じiOSコンストラクターfileURLWithPathがCreateFileUrlで Xamarinに変わりました。



Androidでも同様の状況が発生します。元のGONE定数はViewクラスにあり、Xamarinバージョンでは同じ目的で、値Goneを持つ列挙型ViewStatesがあります。 他のメソッドや定数にも同様の問題があり、ネイティブプラットフォームから切り替えるときに混乱が生じます。

プラットフォーム機能の抽象化の欠如

完全な幸福のために、フレームワークは特定のOSの機能の一部を隠しません。 たとえば、ネットワークでのバックグラウンド作業：

1. Androidでは、ネットワークまたはバックグラウンドネットワークサービスを操作するための新しいスレッドを簡単に作成できます。アプリケーションが最小化されている場合、または電話がロックされている場合、作業は停止しません。
2. iOSでは、最小化するとアプリケーションが停止します。ネットワークで何かをしたい場合は、最小化の数分後に停止するバックグラウンドセーフタスクなどの別のオプションを使用する必要があります。

あなたは言う-これらは特定のプラットフォームの単なる機能ですか？ まさに。 しかし、開発者の誰もこれらの機能を抽象化の下に隠していないので、繰り返しますが、各プラットフォームを調査する必要があります 。

サードパーティのコンポーネントの欠如

現時点では、 多くのコンポーネントがすでにXamarinで記述されていますが、iOSおよびAndroidではさらに多く記述されています。 必要に応じて、理論的にはObject-CまたはJavaで記述されたバイナリライブラリを接続できますが、ネイティブライブラリとXamarinアプリケーション間の通信用のプロジェクトバインディングを記述する必要があります。 iOSの場合、そのようなプロジェクトを個別に生成できるObjective Sharpieユーティリティは大いに役立ちますが、常に100％確実に機能するわけではなく、そのような生成の結果を手作業で編集しなければならないこともありますし、このライブラリが必要かどうかさえ疑問に思うことがあります。



さらに、作成者は、ライブラリのネイティブバージョンと比較して、そのようなコンポーネントを遅れて更新することがよくあります。 TestFairyプラグインがネイティブバージョンよりも数か月遅れているという状況に直面しました。 TestFairyの技術サポートから尋ねられたところ、彼らはすべてがうまくいっていると答えました。あなたはいくつかの小さな機能を除いて何も失うことはありません。 しかし、Xamarinの新しいバージョンがリリースされたとき、問題が発生しました。このバージョンのXamarinでコンパイルされたこのライブラリを持つアプリケーションは、リアルタイムでクラッシュし始めました。

結論

フレームワークの複雑さを研究した後、結論はそれ自身を示唆しています。

• Xamarinを使用すると、モバイルプラットフォームC＃および.NETの開発に便利に使用できます（いくつか注意点があります）。
• Xamarinは、その年齢にもかかわらず、かなり粗雑な製品です。
• Xamarinは、各モバイルプラットフォームの機能を慎重に検討する必要からあなたを救いません。

この記事ではXamarin.Formsに関するストーリーも計画しましたが、そのセクションは非常に拡張されていたため、別の記事に分けることにしました。 その中で、Xamarin.Forms UIフレームワークのさまざまな問題とその解決方法について説明します。 それまでの間、ブログを気に入って購読してください！ いいえ、スタンプはどうですか...



更新する 2番目の部分へのリンク。