Adding Uno Support

[nickrandolph]

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

Feature - Adds support for Uno

⤵️ What is the current behavior?

No support for Uno

🆕 What is the new behavior (if this is a feature change)?

Additional libraries MvvmCross.Uno and MvvmCross.Uno.Plugins to support Uno

💥 Does this PR introduce a breaking change?

No

🐛 Recommendations for testing

Run the sample Uno projects

📝 Links to relevant issues/docs

🤔 Checklist before submitting

• [ X ] All projects build
• [ X ] Follows style guide lines (code style guide)
• Relevant documentation was updated (docs style guide)
• [ X ] Rebased onto current develop

[nickrandolph]

@Cheesebaron can you let me know what I need to do in order to generate nuget packages for MvvmCross.Uno and MvvmCross.Uno.Plugins?

[MartinZikmund]

Hi, what is the status of this PR? Anything I could help with to get it done 🙂 ?

[nickrandolph]

@MartinZikmund I just rebased the branch. I need to test it again to make sure it's all working and I need some guidance from @Cheesebaron as to what we need to do to generate nuget packages.

[Cheesebaron]

To generate NuGet packages, the only thing that should be necessary is to use MSBuild.Sdk.Extras for the project file.

<Project Sdk="MSBuild.Sdk.Extras">

Additionally it needs to fulfill these conditions:

<GeneratePackageOnBuild Condition=" '$(Configuration)' == 'Release' and '$(IsTestProject)' != 'true'">true</GeneratePackageOnBuild>

So built in Release mode and not have "Test" in the project name.

[MartinZikmund]

Hi, is this close to release 😊 ? I had several people asking about MvvmCross support 😉 . I am happy to help if something is missing/not working yet

[Cheesebaron]

@MartinZikmund Except for it not building, then I guess it is not far from it.

I will be working on MvvmCross this week. So I'll give this one a spin and perhaps fix it up so we can get it out with 7.0.0

[MartinZikmund]

Thanks a ton 👌👌👌

[MartinZikmund]

Update

Nevermind, after a looooong debugging session I uncovered the bug is in Uno and is in fact cause by using await in OnLaunched, so does not happen in general (unoplatform/uno#2872).

Original post

I am trying out the current version with Uno and found an unusual inconsistency with x:Bind. Consider the following code-behind:

    public MainView()
    {
        this.InitializeComponent();
        DataContextChanged += MainPage_DataContextChanged;
    }

    private void MainPage_DataContextChanged(DependencyObject sender, DataContextChangedEventArgs args)
    {
        Text = "In data context changed";
    }

    protected override void OnNavigatedTo(NavigationEventArgs e)
    {            
        base.OnNavigatedTo(e);            
        DataContext = "test";
    }

    public string Text { get; set; }

And following XAML:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
	<TextBlock Text="{x:Bind Text}" Margin="20" FontSize="30" />
</Grid>

In UWP this properly shows "In data context changed", but on Uno platforms it does not. It seems like the bind occurs before the DataContextChanged is processed or something similar. Weirdly enough, this does work with a plain Uno Platform project, only happens when the page derives from MvxWindowsPage.

Not entirely sure if this is a problem on Uno side or MvvmCross side

[Cheesebaron]

@nickrandolph I've tried to get Android to build today. I can't seem to get it to work, since it generates some code behind looking like this:

#if __ANDROID__
		/// <summary>
		/// Native constructor, do not use explicitly.
		/// </summary>
		/// <remarks>
		/// Used by the Xamarin Runtime to materialize native 
		/// objects that may have been collected in the managed world.
		/// </remarks>
		public SplitMasterView(IntPtr javaReference, global::Android.Runtime.JniHandleOwnership transfer) : base (javaReference, transfer) { }
#endif

The base class is MvxWindowsPage, it which inherits from Windows.UI.Xaml.Controls.Page, this type doesn't have that ctor.

The only thing I did was to bump uno to latest stable 2.4.0 and use Uno.Wasm.Bootstrap.DevServer instead of the CLI tool in the Wasm project, as it was throwing build errors.

[Cheesebaron]

Wasm seems to work OK.

[Cheesebaron]

Can't seem to get UWP running either.

4>"C:\git\MvvmCross\Projects\Playground\Playground.Uno\Playground.Uno.UWP\Playground.Uno.UWP.csproj" (Build;BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;DebugSymbolsProjectOutputGroup;DebugSymbolsProjectOutputGroupDependencies;DocumentationProjectOutputGroup;DocumentationProjectOutputGroupDependencies;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies;SGenFilesOutputGroup;SGenFilesOutputGroupDependencies target) (1) ->
4>(MarkupCompilePass1 target) -> 
4>  C:\git\MvvmCross\Projects\Playground\Playground.Uno\Playground.Uno.Shared\Views\SecondChildView.xaml : Xaml Internal Error error WMC9999: Type universe cannot resolve assembly: Uno.UI, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null.
4>  C:\git\MvvmCross\Projects\Playground\Playground.Uno\Playground.Uno.Shared\Views\SplitMasterView.xaml : Xaml Internal Error error WMC9999: Type universe cannot resolve assembly: Uno.UI, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null.
4>  C:\git\MvvmCross\Projects\Playground\Playground.Uno\Playground.Uno.Shared\Views\SplitRootView.xaml : Xaml Internal Error error WMC9999: Type universe cannot resolve assembly: Uno.UI, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null.

[nickrandolph]

Closing this PR and raising a new one that's got a clean commit history