CODEWITHSUNDEEP
dependenciesmvvmcrossportable-class-library
jeremy303
jeremy303

Reputation: 9241

Non-PCL dependencies w/ MvvmCross

Our application has several dependencies that are not available as PCL libraries (e.g. RestSharp, Websocket4Net, Reactive Extensions), but are available for each platform we plan to target. What's the best approach for handling this scenario in MvvmCross? What is the simplest?

Upvotes: 3

Views: 511

Answers (2)

Stuart
Stuart

Reputation: 66882

There are various ways to approach this.

  • if the problem is really large, you can abandon the PCL approach, and use multiple platforms specific class libraries. These libraries can reference the MvvmCross PCLs and the platform specific versions of RestSharp, etc. For discussions on the pro's and con's of this see - What is the advantage of using portable class libraries instead of using "Add as Link"?

    In general, I now only take this file-linking approach if I've got to include a very large Legacy library (e.g. one customer had a large business logic library that talked to 3 separate WCF services...)

  • some of the libraries you mention may already have PCL ports and/or alternatives - e.g.

    Many open source authors are now providing PCL versions - so check.

  • you can often abstract the native libraries away behind interfaces and you can then inject the correct version of that library at runtime. This is what plugins do within MvvmCross

    You can see how lots of plugins are built in https://github.com/slodge/MvvmCross/tree/v3/Plugins/

    There's a very simple plugin in this sample - https://github.com/slodge/MvvmCross-Tutorials/tree/master/GoodVibrations

  • another approach you can use is to provide 'reference assemblies' - these are PCL assemblies which contain the type and interface signatures only (i.e. they provide only NotImplementedException implementations). Your PCL projects link to these assemblies, while your UI projects link to the real assemblies. At build time, your PCL core will build against the signatures, but MSBuild/XBuild will ensure that the correct native library actually gets pulled in.

    I've not used this last technique in practice. I prefer the interface route as it leads to better architecture. However, this technique is used in the current MvvmCross Nuget packages - so I know it works.

Upvotes: 2

Immo Landwerth
Immo Landwerth

Reputation: 3249

Our tester Daniel has written a blog post on how you can solve this class of problems.

Upvotes: 1

Related Questions