ScrollView: StackPanel of elements with % height

[Mitnick]

I would like that the elements in my ScrollView take each 25% of the available space (so no fixed size).

So that it has for every screen dimensions the same proportions.

It should look like this, when you scroll:

I tried it with this code:

<App>
	<ScrollView>
		<StackPanel>
			<Panel Height="25%" Color="Black" />
			<Panel Height="25%" Color="Red" />
			<Panel Height="25%" Color="Black" />
			<Panel Height="25%" Color="Red" />
			<Panel Height="25%" Color="Black" />
			<Panel Height="25%" Color="Red" />
			<Panel Height="25%" Color="Black" />
		</StackPanel>
	</ScrollView>

</App>

But for me the screen keeps just all white.

Can you please help me?

[Mitnick]

Hey Bent thank you for your answer

But I want to display exactly 4 elements on every device and every screen dimensions.

So I think with a fixed size of 100, I cannot achieve this.

If I have a list of 42 items then again only 4 should be viewable at the begin.

So that it looks exactly like on the image I posted. There the 4 elements have the height which is 25% of
the viewable space.

I hope this can be done with Fuse.

[Fahad]

I think OP means he wants the Height of each Panel to be 25% of the device’s screen screen

[Bent]

I removed my answer because it wasn’t correct. I’m currently running a different version of Fuse and what I suggested doesn’t apply to what’s currently available in the beta, sorry. Someone with more relevant info will most likely help you guys out when it’s not Sunday

[edA-qa_mort-ora-y]

Sorry, there is no way to do this at the moment, though there a couple of pending feature requests that would make it possible (two different approaches).

The reason it doesn’t work now is due to how StackPanel works within the layout systme. In the direction of the layout (the Orientation) there is no actual size, thus the % is not relative to anything and ends up with a zero-sized.

[Mitnick]

Thank you for answering edA-qa mort-ora-y

And when can we expect these features? I really need it for my application

Next release, or the release after that? When is it planned to included these features you mentioned?

Thank you

[Bent]

Mitnick: there’s no public timeline for this, we’re still researching if and how it would make sense. As for your project, I’m fairly certain that it’s possibly a better approach to see if you can achieve something close to what you are looking to make rather than to wait for this implementation - as edA-qa says, there are two different approaches to something like this, and even if we prioritize making one of them, it might not match your use-case perfectly. As he also touches on, in the context of a ScrollPanel (which can contain X elements), using percentages to fill it doesn’t really make a lot of sense since the % won’t be relative to anything. If I was implementing this design, I’d do an evaluation for how important it would be to have exactly 4 pieces of content in the responsive viewpoint at any given time and at any given resolution.

[Mitnick]

Bent Stamnes wrote:

If I was implementing this design, I’d do an evaluation for how important it would be to have exactly 4 pieces of content in the responsive viewpoint at any given time and at any given resolution.

The problem is that for smaller or bigger screens the items will be cut off.

As this is the main page I really don’t like that the items are cut off and look on every device different It just doesn’t look right. Not like an unit.

Bent Stamnes wrote:

As he also touches on, in the context of a ScrollPanel (which can contain X elements), using percentages to fill it doesn’t really make a lot of sense since the % won’t be relative to anything.

I think I’ve chosen the wrong term. You are right that the available space is unlimited and speaking of % regarding the height doesn’t make sense there.

The right term would be viewable space. As you can see in the illustration above the viewable space is limited.

No matter how much items there are, the viewable space will stay the same and is in this case 260pt.

So speaking of % does make sense here because you are referring to a fixed size (the viewable space).

And I think it’s just the same as for a Circle where you can set the Width and Height to % values.

So right now I think this is a limitation because I cannot design the viewable space like I want.

[Mitnick]

Any updates to this? Or any thoughts to my last response?

[Bent]

Thanks for the illustrations, they were great to understand what you wanted to achieve. In short: the layout you’ve sketched out are perfectly possible to do today if you use a fixed amount of items (just use a Grid). The problem comes when scrolling of those items are introduced. For very good performance reasons, you don’t really want relative-sized items inside a ScrollView which can contain an unknown amount of items. All the recursive relative sizing becomes a terrible performance bottleneck.

There’s also very good UX reasons not to have the four items align themselves perfectly with the bottom of the screen, and that’s peakability. You really want the user to understand that what he/she is looking at is a list of times and that what’s visible is just the top of it. By showing a little piece of the fifth item in that list, you convey this in a way that the user doesn’t have to think about it. If you take a look at the way lists are used in apps (or on websites for that matter), I think you’ll have a hard time to come up with lists like these who stick perfectly to the size of the viewable space.

There are some cases where it would make sense to have relative-sized items in a list, and we are indeed kicking some ideas around (ideas that don’t kill performance, naturally), but we’re a small team and there are unfortunately no limit of ideas or things to be implemented, so priorities kick in.

That said, there are basically two ways you can work around this limitation of the current ScrollView:

1) If you are comfortable with more low-level code, you can fork the ScrollView-implementation and rewrite some of the underlying Uno code so that it fits with the layout logic you want, or

2) You can simply work around this by reading the screen size on run, and then populate a ScrollView with items of static Height depending on which device you’re running it on. Should be pretty painless, and you’d be able to cover most popular screen sizes with very little code.

[Mitnick]

Hey Bent, thank you for your long and great response!

You really have a good point regarding “peakability”, so the user should know that this list is scrollable.

I was considering leaving it like it is now with a fixed size, so it looks on every device a little different.

The only problem is when I have large screens like on an iPad. If I use a fixed size then it won’t look right on one of the devices (iPhone5 vs iPad).

So as a little exercise I will try your second approach and read the height of the device.

For iOS I found this code for getting the screen dimensions:

[[UIScreen mainScreen] bounds].size.height

[[UIScreen mainScreen] bounds].size.width

I hope it is really simple and I can just use this one line.

And of course I will be excited about updates and new solutions from you guys

[Bent]

Hope the approach worked out.