As a part of my effort to learn new technologies, I'm trying to implement one of the screens of an app I'm working on in SwiftUI. I have this rough layout:
This element should stretch to accommodate the container size (devices of different widths) and will be used in a ScrollView.
Here's the preliminary solution I came up with after some stumbling around:
This works well enough for the first attempt but I want to refactor the View by moving all the relevant parts into a separate View. In addition to that, I want that new view to automatically account for paddings and other size modification I might add later.
So, here's a naive rewrite:
As you can readily spot, GeometryReader inside ScrollView assumed the size the parent provided it, effectively hiding most of the View.
There are several "dirty" solutions to this situation: set a fixed frame height to the View, set an aspect ratio that would approximate the correct size (a bit tricky given that there are Text views with fixed heights), keep GeometryReader as the outermost element of the main view and pass the width to the subview as an initialization parameter.
I'm looking for a "clean" solution for this particular layout and, perhaps, for a more general understanding about how Views is SwiftUI regulate their sizes – in WWDC videos it is said that parent View proposes a size but then child View returns it's own size; is there a way to interfere in that process somehow or is it all done through private APIs?
Thank you!
–Baglan
p.s. I thought code screenshot besides the UI preview would be the most illustrative but let me know if I should provide code snippets as well!