Xamarin.Forms VS winforms

EDIT2: Yeah, https://github.com/xamarin/Xamarin.Forms/issues/2751

Example issue: https://github.com/xamarin/Xamarin.Forms/issues/8640 Its an issue reported by David O, its a 3 year old issue, there is limited communication from Microsoft on the issue, no plans, there are a couple of community discovered workarounds that got broken in later versions of Xamarin.Forms. I feel like its fairly common to come across an issue like this that can be a showstopper for a task. Do you come up with a workaround, do you wait for an official fix, do you use a third-party NuGet to accomplish the task?

The deploying is also very buggy in my project, see this post: https://github.com/xamarin/Xamarin.Forms/issues/15253

Xamarin, it is "cross-platform" in the sense that it makes cross-platform applications, for Android and IOS and Windows. There are some implementations of Xamarin for other platforms like Linux (GTK#) or MacOs, but they're not really mature and stable yet. See https://github.com/xamarin/Xamarin.Forms/wiki/Platform-Support for more details.

It appears there is no view binding for this function... I've been googling around and saw this post https://github.com/xamarin/Xamarin.Forms/issues/10254 , but I can't implement it properly. It fails out with a dictionary exception.

You asked a bunch of questions there, I will try to answer them separately. 1) I am a XN expert and have a ton of experience in it, and from my research, it’s extremely difficult to get an experienced xamarin native developer. Xamarin Native is amazing experience to have, but There’s literally NO WAY left for someone to train themselves in xamarin native and I wrote about that here https://blog.devgenius.io/usingxamarinuniversitytolearnmobiledevelopment-808b6dec3e8b?sk=1c196f32400196f14dff7359f8ee51c0 So yes, I highly recommend running away from using xamarin native apps. Companies are having such a hard time finding experienced devs at regular rates. So anything is better really. 2) As to what language to select, Cross Platform >> Swift/Kotlin, these are also specialized skills that are just as rare to find both of in one senior skilled developer. Microsoft is actually putting in a lot of effort into building out the new Maui platform which is a piece of cake for xamarin forms developers to learn. There’s several migration tools already built as well, and the advantage of using Xamarin for you would be that you can keep your ViewModel layer exactly the same, you just have to build your view layer (also pretty easy to do with hot reload). Finally, it is important to note that more than 50% of ALL new mobile app development is moving towards React Native. The ability to use typescript (TS) instead of JavaScript removed the biggest negative against RN. Also keep in mind there’s no easy way of migrating from Xamarin Native to Xamarin forms except for starting a Xamarin forms app from scratch because of This issue https://github.com/xamarin/Xamarin.Forms/issues/8153

BTW this is the reported issue, please comment to push xamarin team look over it and maybe fix the bug

I'm worried that I'm experiencing this unresolved issue on GitHub.

If you're using shell on Android, this is a prevelant problem as your binding count grows. There has been a bug open on the Xamarin team for two years that keeps getting pushed in favor of MAUI work. https://github.com/xamarin/Xamarin.Forms/issues/7521

Windows Forms[0] is still alive and will never die, and very low overhead to start with, and works on new and shiny .NET 8.

If Linux or macOS, you can use AvaloniaUI[1] instead which is sufficiently advanced but assumes some prior knowledge.

[0] https://github.com/dotnet/winforms/blob/main/docs/getting-st...

[1] https://docs.avaloniaui.net/docs/get-started/

Winforms: Licencia MIT.

3. Therefore reified generics are not possible to implement in a backwards compatible way.

Ok, sure, but if you instead a new generic collection types and leave the old ones alone, you don’t have to worry about breaking existing compiled code.

This comment about C# suggests a lack of familiarity with the approach C# took:

> C# made the opposite choice — to update their VM, and invalidate their existing libraries and all the user code that dependend on it.

All of the pre-generic C# libraries continue to exist to this day (ArrayList, HashTable, and the non-generic IEnumerable). Applications that used them never stopped working. New code uses the generic collections (List and Dictionary).

Anyways, I think the costs that Java is currently paying for non-reified generics (reflection, performance, and type safety mentioned in the article) is not worth the backwards comparability with the 20 year old J2SE 1.4. The price C# pays for making a backwards incompatible generics (mostly some minor annoyance when designing a collection class implementing IEnumerable) is worth it at this point.

P.S. ok, I do admit that C# forking the collection library is still causing ongoing maintenance work 18 years later: https://github.com/dotnet/winforms/pull/8673

No, it is fully supported and in active development. https://github.com/dotnet/winforms

No, it's still under active development/maintenance. https://github.com/dotnet/winforms/graphs/contributors

The image is kept in-memory— https://github.com/dotnet/winforms/blob/main/src/System.Windows.Forms/src/System/Windows/Forms/PictureBox.cs

Appears that this has been broken for a while. Seems it has something to do with the new designers being run out of process.

Also, the runtime that C# runs on, is also completely open source as well (https://github.com/dotnet/runtime); ASP.NET which is used to create web apps in C# is open as well (https://github.com/dotnet/aspnetcore). WinForms/WPF, used to make desktop apps in C# is also open source (https://github.com/dotnet/wpf, https://github.com/dotnet/winforms). All of the source code for these are on the dotnet Github page: https://github.com/dotnet and most are all MIT-licensed.

You'll likely have to open an issue against https://github.com/dotnet/winforms. If you've already opened an issue here, then feel free to link and I might be able to provide suggestions on how to improve the triage process.