MvvmCross vNext: Using System.IO.Compression in PCL

Question

I have some Model code that requires some methods from the System.IO.Compression namespace. However it is not present when using a PCL that targets VSMonoTouch and MonoAndroid as well. I see that some stuff is TypeForwarded in the MvvmCross solution, though when creating a similar project I can't seem to find out how to use it.

I created a MonoAndroid library project and added a Forward.cs class with the following content:

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))]

I have set the namespace of the project to System.IO.Compression. Trying to add it as a reference to the PCL project I have with my Model code which contains ViewModels, Services and what not it of course says that it can only reference other PCL projects and assemblies.

I especially need GZipStream and I cannot seem to find out how to add it to my project, so the question is how do I do that?

Only have a local copy, but basically I am using the Plugin route Stuart describes below. So I simply inject the platform specific GZip code. — Cheesebaron

Stuart Stuart · Accepted Answer · 2012-10-26T12:56:51

PCL Extension route

How to do this by extending PCL... I'm not entirely sure! One of the PCL guys might be able to assist with that.

Plugin route

The way I'd go about this is by defining the functionality I want in an interface and wrapping the code in a plugin.

For example in Cheesebaron.Plugins.Gzip.dll you could create an interface like:

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

This interface would then get plugged inside a PCL library that just contained this interface and the pluginmanager class.

Your PCL Core project can then reference this PCL plugin library and your ViewModel can use code like:

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

followed by

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

For each actual platform implementation, you then prepare a platform specific library, you implement the GZip factory interface, and you provide a simple Plugin class implementation.

For example, for Droid you might create Cheesebaron.Plugins.Gzip.Droid.dll:

 public class MyDroidGZipStreamFactory : IGZipStreamFactory
 {
      // the implementation
 }

And you'd then add:

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

Finally... to pull it all together, for MonoDroid you then reference both the PCL and the platform specific implementation in your UI project - and it should all work!

Note that there is a little convention based magic going on behind the scenes here - the framework loads the Assembly Cheesebaron.Plugins.Gzip.Droid.dll based on the PCL Plugin namespace being Cheesebaron.Plugins.Gzip

(For WP7 and other platforms, there's one additional step - there's a setup method to override which registers the plugin)

Note you can register as many services as you want to inside a single PlugIn, and you can perform extra common initialization/setup code too. This can help to reduce some project maintenance overhead: you can put your CheeseBaron IoC objects inside one single CheeseBaron.Plugins.Utils project if you like and then share just this one plugin across all your apps.

The DownloadCache Plugin provides a small sample of this - it registers all of IMvxHttpFileDownloader, IMvxImageCache and IMvxLocalFileImageLoader.

The downside with doing this is: eventual linked exe size - you're potentially adding unneeded code to each app.

Obviously this plugin approach has a little bit of a learning curve... and it does add a little project maintenance - but the good news is that these plugins can be used over and over again between projects - and can be shared between organisations (at least, that's my hope!)

Other routes

If you don't want to use Plugins - e.g. if you are ever in a hurry or if you are writing code for a module that you don't want to reuse, then there are alternatives:

You can define an interface like IGZipStreamFactory in your share Core PCL library. You can then provide a platform specific implementation of this interface within each UI project, and can then use normal IoC/DI in the ViewModel/Model/Service layer in order to locate the correct implementation at runtime.

Or...

You can just dump the shared PCL core library and create separate platform-specific DLLs into which you then manually link in platform-specific files (I try never to do this, but others like it)

MvvmCross vNext: Using System.IO.Compression in PCL

1 Answers

PCL Extension route

Plugin route

Other routes