Why custom ObservableList?

[TimGameDev]

Hello,

Could you please explain why do you create custom 'ObservableList' and didn't use 'ObservableCollection' from System.Collections.ObjectModel?

This makes usage of UnityWeld very limited. You force users of UnityWeld to has tight coupling with it. Which provides limitations like: can't switch between mvvm frameworks, can't use different frameworks for different platforms/engines, can't have common UI code for view implementations, constantly has a ref to UnityWeld everywhere.

As far as I know .Net 3.5 is deprecated long time ago https://forum.unity.com/threads/net-3-5-runtime-has-been-deprecated-in-unity-2018-3.601384/

and .netstandard 2.0 and 4.x api (in Unity) perfectly support ObservableCollection.

Can we just get rid of .net 3.5 already and use standard ObservableCollection?

Thanks.

[TimGameDev]

I've made this change in my rep if you interested: https://github.com/TimGameDev/Unity-Weld/commit/b961d82f0ea609e8adf501ac3953e1fa3ba21d55

Also checked examples and if update this file with ObservableCollection everything works perfectly https://github.com/Real-Serious-Games/Unity-Weld-Examples/blob/master/Assets/Collection/MyUI3.cs

[MorganMoon]

I like the idea, however in Unity 2017.4 (LTS Release) .NET 3.5 is still supported and will be until 2020 from my understanding

[TimGameDev]

Thanks for the answer.

Good catch. According to official site

Each LTS stream will be supported for a period of two years.

2017 LTS was released in 20 March 2018. So yeah...until 2020.

I'm going to use my version (since I need abstract UI dll which is not relate to any plugins), so if you want I can keep my PR to discuss it later.

[RoryDungan]

Yeah I'd like to keep support for .NET 3.5 at least until the 2017.4 LTS is no longer officially supported. Would have to have another discussion to figure out if we still want to support .NET 3.5 for the duration of the 2018.4 LTS period too because that version does still support .NET 3.5, although I think it's marked as deprecated.

One way we could potentially make the transition smoother would be to refactor the existing ObservableList to match the API of ObservableCollection so that when it is time to switch over, we can seamlessly transition from the custom implementation to the built-in one. Would also require renaming our ObservableList "ObservableCollection" but since it isn't ever serialised to the Unity scene and the API isn't considered stable yet I think that breaking change would be worth it. If we did that we could even start conditionally compiling against .NET ObservableCollection for the .NET Standard build target right now.

[TimGameDev]

Thanks for your time.

I'm pretty sure that the number of .net3.5 users in 2018.4 LTS is very close to 0. It's marked as deprecated since 2018.3 (link in my original post). imho UnityWeld can safely omit .net3.5 support after 2020.

I think there is no reason to change current ObservableList at the moment because it implements IList and ObservableCollection has Collection as base class which also implements IList. In fact the whole transition will look like 'replace ObservableList with ObservableCollection in project' and fix namespaces.

I can easily keep my version up to date until 2020 (and I'm going to).

PS: UnityWeld is great idea. And the main reason of my question is help to improve this plugin.