2

System.IO.Compression 名前空間のメソッドを必要とするモデル コードがいくつかあります。ただし、VSMonoTouch と MonoAndroid も対象とする PCL を使用する場合は存在しません。MvvmCross ソリューションで TypeForwarded になっているものもありますが、同様のプロジェクトを作成するときに、その使用方法を見つけることができないようです。

MonoAndroid ライブラリ プロジェクトを作成し、次の内容の Forward.cs クラスを追加しました。

using System.Runtime.CompilerServices;

[assembly: TypeForwardedTo(typeof(System.IO.Compression.CompressionMode))]
[assembly: TypeForwardedTo(typeof(System.IO.Compression.DeflateStream))]
[assembly: TypeForwardedTo(typeof(System.IO.Compression.GZipStream))]

プロジェクトの名前空間を に設定しましたSystem.IO.Compression。ViewModels、Services、およびもちろん、他のPCLプロジェクトとアセンブリのみを参照できると言っているモデルコードを使用して、PCLプロジェクトへの参照として追加しようとしています。

私は特に必要GZipStreamであり、それをプロジェクトに追加する方法を見つけることができないようです。

4

1 に答える 1

2

PCL延長ルート

PCL を拡張してこれを行う方法...完全にはわかりません! PCL 担当者の 1 人がそれを手伝ってくれるかもしれません。

プラグインルート

私がこれに取り組む方法は、インターフェイスで必要な機能を定義し、プラグインでコードをラップすることです。

たとえば、Cheesebaron.Plugins.Gzip.dll次のようなインターフェイスを作成できます。

public interface IGZipStreamFactory
{
     Stream Decompress(Stream binaryStream);
}

このインターフェイスは、このインターフェイスと pluginmanager クラスを含む PCL ライブラリ内にプラグインされます。

PCL コア プロジェクトは、この PCL プラグイン ライブラリを参照でき、ViewModel は次のようなコードを使用できます。

 Cheesebaron.Plugins.GZip.PluginLoader.Instance.EnsureLoaded();

に続く

 var service = this.GetService<IGZipStreamFactory>();
 var unzipped = service.Decompress(inputStream);

次に、実際のプラットフォーム実装ごとに、プラットフォーム固有のライブラリを準備し、GZip ファクトリ インターフェイスを実装して、単純なPluginクラス実装を提供します。

たとえば、Droid の場合、以下を作成できますCheesebaron.Plugins.Gzip.Droid.dll。

 public class MyDroidGZipStreamFactory : IGZipStreamFactory
 {
      // the implementation
 }

そして、次を追加します。

public class Plugin
    : IMvxPlugin
    , IMvxServiceProducer
{
    public void Load()
    {
        this.RegisterServiceInstance<IGZipStreamFactory>(new MyDroidGZipStreamFactory));
    }
}

最後に... すべてをまとめるために、MonoDroid の場合、UI プロジェクトで PCL とプラットフォーム固有の実装の両方を参照すると、すべてが機能するはずです!

ここでは、舞台裏でちょっとした規約ベースのマジックが行われていることに注意してください。フレームワークはCheesebaron.Plugins.Gzip.Droid.dll、PCL プラグイン名前空間に基づいてアセンブリを読み込みます。Cheesebaron.Plugins.Gzip

(WP7 およびその他のプラットフォームの場合、追加の手順が 1 つあります。プラグインを登録するものをオーバーライドするためのセットアップ メソッドがあります)

1 つの PlugIn 内に必要な数のサービスを登録でき、追加の一般的な初期化/セットアップ コードも実行できることに注意してください。これにより、プロジェクトのメンテナンス オーバーヘッドを削減できます。必要に応じて、CheeseBaron IC オブジェクトを 1 つのCheeseBaron.Plugins.Utilsプロジェクト内に配置し、この 1 つのプラグインだけをすべてのアプリで共有できます。

DownloadCacheプラグインは、これの小さなサンプルを提供します。これは、 と のすべてを登録IMvxHttpFileDownloaderしIMvxImageCacheますIMvxLocalFileImageLoader。

これを行うことの欠点は、最終的にリンクされた exe サイズ - 各アプリに不要なコードを追加する可能性があることです。

明らかに、このプラグインのアプローチには学習曲線が少しあります...そして、プロジェクトのメンテナンスが少し追加されます-しかし、良いニュースは、これらのプラグインはプロジェクト間で何度も使用でき、組織間で共有できることです(少なくとも、それが私の希望です!)

プラグインの作成の詳細:

プラグインの例 (すべてのプラットフォームで利用できるわけではありません) については、https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Pluginsを参照してください。

その他のルート

プラグインを使用したくない場合 - 例えば、急いでいたり、再利用したくないモジュールのコードを書いている場合など、代替手段があります:

  • 共有コア PCL ライブラリで IGZipStreamFactory のようなインターフェイスを定義できます。次に、各 UI プロジェクト内でこのインターフェイスのプラットフォーム固有の実装を提供し、ViewModel/Model/Service レイヤーで通常の IoC/DI を使用して、実行時に正しい実装を見つけることができます。

または...

  • 共有 PCL コア ライブラリをダンプし、個別のプラットフォーム固有の DLL を作成して、プラットフォーム固有のファイルに手動でリンクすることができます (私は決してこれを行わないようにしていますが、他の人はそれを好みます)。
于 2012-10-26T12:56:51.173 に答える