Integration with Unity / Blend Project

mandalorianbob · 31 Aug 2022, 23:03

For Unity, a really great way to represent data objects is ScriptableObject. This is especially true if the Data Objects aren't changing over the course of the runtime.

However, I've run into issues with the way that Noesis splits things up into the Blend project.

For the Blend project, none of the Unity references work. Is there a best practice here? Should I modify the Blend Project to reference Unity Engine, try to only use Interfaces, or should I give up on the Blend project all together?

01 Sep 2022, 00:03

Our Workflow tutorial may help here.

For Unity we don't recommend mixing Unity types with Blend (although a few of our clients are doing it in someway). We think the best way is following a pure MVVM approach and implement DataContexts separately:

For Unity, we recommend ScriptableObjects, like in our Buttons example.
For Blend, we recommend Design-Time DataContexts.

It is a complex topic, with many alternatives and approaches. Happy to discuss more.

PS: And we have been working on the alternative to Blend, implemented with Noesis and avoiding many of these issues. Please, stay tuned :)

mandalorianbob · 01 Sep 2022, 01:49

So I assume this means that you recommend not using x:Type information?

I mean, yes usually with a Model-View-ViewModel approach, the ViewModel can, technically, be swapped out for another at design time.

However, it's worth noting that in WPF/UWP style XAML, and especially in more modern XAML like MAUI, the idea of swapping out for an entirely different type isn't, generally speaking, the typical approach. It's also worth noting that your Buttons sample is MonoBehaviours, not ScriptableObjects. The difference I showcase below, because I can't just drop a SO onto a GameObject.

But overall, having two view models would be a very difficult to sustain approach. You'd have to make 2 classes for every VM, and you'd have to keep them in sync. And if you actually had a designer creating the UI, then the designer would have to create the DesignTime view model?

This was why I was asking about using Interfaces. Seems like you'd pretty much have to if for no other reason than to ensure synchronicity. However, I don't think Interfaces works with x:Type, right? Or at least, I wasn't able to get it to work.

01 Sep 2022, 13:11

Yeah, true, we are using MonoBehaviours, but at the end you need the ScriptableObject nested in a MonoBehaviour, so it is similar. But sorry for the confusion.

If you avoid using x:Type (for DataTemplates I assume), then it is possible to have Design-Time view models created by the designer in Blend. This is the approach followed in this tutorial:

I think if you don't share Unity types, it is a good idea to share DataContext types between Unity and Blend. And I agree with you this is the best solution for Blend.

In our new editor, you will be able to share everything (because in fact, the editor is running inside Unity) and we plan to support visual editing of Design-Time DataContexts.

PS: x:Type should work if you use the base class (not the interface)

01 Sep 2022, 15:17

You can reference, and use, ScriptableObject classes in Blend by creating some mock Unity classes for use in WPF/Blend. The conditional !UNITY_5_3_OR_NEWER compilation will mean that these mocks will not interfere with the Unity runtime.

#if !UNITY_5_3_OR_NEWER
using System;

namespace UnityEngine
{
    public class ScriptableObject
    {
    }

    public sealed class SerializeField : Attribute
    {
    }

    
    [AttributeUsage(AttributeTargets.Class, Inherited = false)]
    public sealed class CreateAssetMenuAttribute : Attribute
    {
        public string menuName { get; set; }
            
        public string fileName { get; set; }
            
        public int order { get; set; }
    }
}
#endif

And here is an example of a ScriptableObject view model, which can be created/edited in the Unity Editor and used in Noesis and Blend (with the above mock classes).

using System.ComponentModel;
using System.Runtime.CompilerServices;
using UnityEngine;

namespace ScriptableObjectViewModels
{
    [CreateAssetMenu(fileName = nameof(SampleViewModel), menuName = "ViewModels/" + nameof(SampleViewModel))]
    public class SampleViewModel : ScriptableObject, INotifyPropertyChanged
    {
        [SerializeField] private string _stringProperty;
        [SerializeField] private int _intProperty;

        public string StringProperty
        {
            get { return _stringProperty; }
            set
            {
                _stringProperty = value;
                OnPropertyChanged();
            }
        }
        public int IntProperty
        {
            get { return _intProperty; }
            set
            {
                _intProperty = value;
                OnPropertyChanged();
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;

        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }

    }
}

To reference these classes in the Blend project, I generally edit the .csproj file for the Blend project, and add a wildcard Compile entry to the Project element, pointing it to a folder which contains only the Blend compatible ViewModels (and related files, like the mocks):

<ItemGroup>
    <Compile Include="Assets\ViewModels\**\*.cs" />
<ItemGroup>

mandalorianbob · 03 Sep 2022, 01:14

I did eventually try something like

  <ItemGroup>
    <Compile Include="Assets\NoesisUI\**\*.cs" />
    <Compile Update="Assets\**\*.xaml.cs">
      <DependentUpon>%(Filename)</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <Page Include="Assets\**\*.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>

For the Blend project.

But now I'm running into Integration woes trying to extend your controls. I'm trying to add some AutomationPeer support, and so I've got a very simple button extension:

 public class PrototypeButton : Button, IAutomationElement
    {
        public PrototypeButton()
        {
            DefaultStyleKey = typeof(Button);
        }

        ButtonAutomationPeer _automationPeer;
        Semantics _semantics;

        public Semantics GetSemantics()
        {
            if (_semantics == null)
            {
                _semantics = new Semantics();
                string name = Name ?? string.Empty;
                _automationPeer = new ButtonAutomationPeer(name, _semantics);
                _automationPeer.InvokeEvent += AutomationInvoke;
            }
            return _semantics;
        }

        private void AutomationInvoke(object sender, EventArgs args)
        {
            Command.Execute(CommandParameter);
        }
    }

The problem is, it's throwing exceptions. I'd normally just hook a Debugger on to try to catch them but attaching a Unity debugger fails consistently.

Any thoughts on the Unity Managed Debugger failing to attach?

03 Sep 2022, 02:45

Automation is not currently supported in Noesis. It is a high priority, and is currently in the planning stages. Once we have an estimate for the work involved it will be added to the roadmap.

If you continue to have issues with the debugger, and believe it to be related to Noesis, please create an issue on the bug tracker and I will look into it.

Integration with Unity / Blend Project

Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Re: Integration with Unity / Blend Project

Who is online