Initial results have been quite promising - so I think it will happen for real at some point soon.
The basic approach I've taken is to create a "core" mvvmcross portable library:
This single project contains 90% of the mvx code.
The code that doesn't fit into this is all platform specific and interface driven - i.e. it's things like the platform specific views, navigation and container code; or platform specific services like file IO, GPS/location information, launchers and choosers, etc. This code is now moved to small platform specific library projects:
The Binding and Dialog projects for now remain untouched - that's OK because they were never shared by the "core" projects any way - so they are always platform specific and there's no advantage in making those portable.
Moving on the sample projects, well the core of these can now be made portable:
So there is only one "core" project shared between all three ui projects - which is NICE :)
However, there are some problems currently…
- I've not quite finished! I've got the tutorial sample up and running, but there are still a few platform specific injection objects to make before all the samples will run... and there's lots more testing needed:
- A Json object
- A Native Color object
- A Visibility Color object
- ObservableCollections are a bit unpleasant to use - INotifyCollectionChanged doesn't exist as a portable interface :/ Because of this any kind of observable collection will need to be wrapped for presentation on wp7
- ValueConverters are a bit unpleasant to use – IValueConverter doesn't exists as a portable interface :/ Because of this all value converters need to be wrapped before use on wp7
- I've no idea how this would work in WinRT yet – there will definitely be reflection and interface issues in .net 4.5
- I don't know what the next version (v2) of the portable class libraries will look like yet!
- The monotouch and monodroid visual studio tooling isn't working nicely yet – you can't yet reference a portable library project from mt and md, you can only reference a compiled assembly – which means you can't do multi-platform refactoring.
- Forcing the core projects to be portable may be too limiting... the list of assemblies you can now reference is small....
I need to think about this some more.... I think portable class libraries is probably the right direction moving forwards - in the long term! But it's not all upside....