Fix samples UI (StackPanels usage)

[xperiandri]

Usage of StackPanels in samples causes a lot of layout and render issues like disabled UI virtualization in ListView.
On the Android emulator, I thought that the app hang but it was rendering 1000 items twice 😂

If you are fine with what I did in https://github.com/xperiandri/Elmish.Uno/tree/uno/src/Samples/Samples.Shared I can backport that

[TysonMN]

Hello @xperiandri. Thanks for creating all these issues! :)

Yes, StackPanel can be a bit restrictive like that sometimes. Feel free to with something that makes the UI look or function better (as long as for XAML is still "simple").

[xperiandri]

If you agree to consolidate all samples in a single project it would be simpler for me

[xperiandri]

@TysonMN do you confirm that I can merge all samples into a single project and apply layout fixes?

[TysonMN]

I would like to try your samples first. How can I do that? Maybe you could update your README with instructions on how that is done.

[xperiandri]

Just clone and run UWP app. If Visual Studio asks to install components let it install.
For UWP you need Window 10 of 2019 year or newer and Visual Studio 16.7+ I suppose
For Android just Xamarin workload and creating and Android emulator

[xperiandri]

Navigation may not work on Android. As far as I remember there is an issue with NavigateToPageAction

[TysonMN]

What do you mean by "UWP app"? There is no project with that name. Can you adjust your solution file so that the project you typically want people to execute is listed first?

[xperiandri]

OK, I'll update

[xperiandri]

This one

[TysonMN]

Yes, this is nice. It reminds me of the WPF demo for Material Design in XAML.

What do you think @cmeeren? Can @xperiandri combine the samples into one executable?

I want the SingleCounter sample to remain separate. Then the combined sample can be about the different binding types.

[cmeeren]

Can @xperiandri combine the samples into one executable?

I haven't given this much thought yet, but this doesn't strike me as a good idea. Each sample consists of views and domain code, and is an easy-to-understand "vertical slice", so to speak. This makes it easy to get an overview of what this specific sample contains, from entry point to views, and makes it easy to test and experiment with. IMHO this becomes a lot harder, particularly for beginners, if the samples are merged (like in the MaterialDesignInXamlToolkit demo, which I found quite dizzying when trying to understand it).

Separate samples are also better for dependencies. We don't have to pollute all samples with dependencies on the behaviors nuget, etc.

I think the samples should stay separate, but I'm open to hearing good reasons to merge.

Also note that my capacity is very limited at the moment, so please help me help you by being completely clear about what exactly is being proposed.

[xperiandri]

They are separate. Just in a single project. Look at my solution

[cmeeren]

But each sample consists of two projetcs; one for the domain code and one for the views. There is no way around this. So with your suggestion then we'd need one project for all domain code, and one project for all views. We take vertical slices and "zip" them together horizontally on different vertical levels. This still has the drawbacks I mentioned above.

[xperiandri]

How do developers consume your samples in your opinion?

[xperiandri]

For me, it was very inconvenient to use samples because I have to run different apps which can take up to a minute on a real iOS device from pressing F5 till it appears on the screen.
And I have never needed the whole app, just to see an approach and grab some code.

[TysonMN]

I think it might be possible to do both:

1. Two projects for each sample
2. Two additional projects that combine all the samples into one executable.

[cmeeren]

How do developers consume your samples in your opinion?

Each sample demonstrates one thing. As a dev, I want to know what makes a particular sample tick. I think that insight is a lot easier to gain when I know exactly what code makes up the particular thing I am interested in - namely, all the code in the relevant project(s) (with all the code being fairly relevant).

And I have never needed the whole app, just to see an approach and grab some code.

Given this, may I ask why are you interested in running the samples, instead of just looking at the code? And, in particular, why you are interested in running multiple samples (which, as I understand it, is what's causing headaches for you, since the startup time is too long)?

I think it might be possible to do both:

1. Two projects for each sample
2. Two additional projects that combine all the samples into one executable.

I think I can live with this.

Note that I don't mean to put my foot down. If, given my arguments, both of you (particularly @TysonMN since he knows the library well) still think merging the samples are the best option, I'm willing to listen.

[TysonMN]

I don't feel strongly either way, but I am inclined to agree with @xperiandri since he wants to make other improvements as well.

[cmeeren]

I have changed my mind.

I still stand by my reasoning, but I realize that since I am not actively using Elmish.WPF, nor have been for some time, the reasoning may be flawed in ways that are hard for me to see.

I will trust @TysonMN's judgement in this matter. I am also unsubscribing from this issue. Feel free to ping me if you want opinion on something.

[TysonMN]

Ok @xperiandri, let's move ahead with this.

I am think it would be good to keep SingleCounter as is. Then you could create project called BindingsDemo and BindingsDemo.Core (since I think usings Bindings instead of BindingsDemo could cause naming issues). That demo have a screen for each type of binding.

As a step in that direction, you could start with something similar to what you did in your repository.

[TysonMN]

I created a sample called Capabilities that should eventually contain most (but not all) of the existing samples. The Single Counter sample will remain separate. I want this combined sample to have more of a use-case driven approach instead of a feature driven approach.