Bait and switch Plugins?

[Cheesebaron]

Would love to not have to have Bootstrap files for each plugins, in a similar fashion that Refit, Splat, ModernHttpClient does.

How to do this is described here:
http://log.paulbetts.org/the-bait-and-switch-pcl-trick/

In short it would mean that Assembly Name, Version and Method structure should be the same in the PCL part of the plugin and the platform part.

So as an example if we take the PictureChooser Plugin the structure would be something like:

PictureChooser.nuspec  
    portable-net45+win+wpa81+wp80/
        MvvmCross.PictureChooser.dll     // PCL Version
    net45/
        MvvmCross.PictureChooser.dll     // WPF Bitmap Loader
    Xamarin.iOS10/
        MvvmCross.PictureChooser.dll     // UIKit Bitmap Loader
    MonoAndroid/
        MvvmCross.PictureChooser.dll     // Android Bitmap Loader
    ... more here ...

So the PCL would contain a class like this:

public class Derp
{
    public void Herp(string derrr)
    {
        throw new NotImplementedException();
    }
}

And a Platform specific one:

public class Derp
{
    public void Herp(string derrr)
    {
        Console.WriteLine(derrr); // or maybe something more platform specific
    }
}

So the PCL version is just a stupid Facade for the platform specific one, then on invocation the correct one will be chosen.

Ideas, thoughts, yay or nay?

[martijn00]

Yes!!!

[Dexyon]

Agree!

[Cheesebaron]

Well, we would probably still need Bootstrap files if the Plugins need to be registered in the IoC for DI. But could also just be invoked directly if wanted.

[lothrop]

This would only make sense if the plugin doesn't have any code that belongs inside a PCL.

[Cheesebaron]

Care to elaborate @lothrop?

From my understanding any class that is not a facade inside of the PCL should still work just fine as long as there isn't an class and method named exactly the same in the platform specific dll.

[lothrop]

Ah, gotcha, I was thinking the PCL wouldn't be used at all and we'd have to link the common code in using a shared project.

[ggirard07]

If bait and switch is used then please try to not update/change assemblies versions for the rest of their lives otherwise it could become tricky to manage with NuGet adding some bindingredirect to the app.config file.
https://bugzilla.xamarin.com/show_bug.cgi?id=22670

[smstuebe]

So this is similar to the https://github.com/jamesmontemagno/Xamarin.Plugins. Does it make sense to maintain two different branches of plugins. Or would it make more sense to combine forces at least for trivial plugins that do not use mvx functionality?!

[Cheesebaron]

We have talked to @jamesmontemagno about this and I think moving forward we would contribute our plugins after they have been converted to match the template he uses. Then in MvvmCross just describe how to use those plugins with our IoC.

[smstuebe]

Ye that is exactly what I thought.Good to hear. With my Fingerprint- and our BLE plugin we are going the same way.