My GeometryReader was working fine in iOS13 but now in iOS14 i get a thread issue.
"Invalid frame dimension (negative or non-finite)."
I printed the size that the reader should give back and it looked fine.
The app is still basically working, but looks a bit weird, because there is some padding introduced.
Does anyone have any ideas how to tackle this?
Related
I'm having an application in SwiftUI and I am using ZIPFoundation to uncompress an archive. This works fine. At the moment I am using native SwiftUI ProgressView(title) to display during the uncompress process, again working fine, anyway it only displays a rotating wheel and no progress scale.
I would like to change to ProgressView(title, value, total) to display the scale, anyway not sure how. I have found this example, but it uses UIKit and addObserver() and I am not sure how to adapt this to SwiftUI, or if there is better way with SwiftUI.
Can anyone please help.
I've been running into a pretty consistent problem with how views inside HStack work, with a simplified screenshot to exemplify the issue.
My expectation would be for the width of the green to basically be (expressed like an equation):
Section.width - Image.width
The section width is fluid, and the image width is explicit. Surely that means the green should be correctly calculated?
Any help with what seems to be a basic misunderstanding on my part would be hugely appreciated.
Actually you're right, but there are just default List/Form insets, which can be either changed or removed.
So all you need is
that gives on Xcode 13.4 / iOS 15.5
The height property in your frame for the image is messing with width dimensions. By setting the maxHeight to be infinity, the height property will expand the image to the max possible height, meaning the height of the section, even if it changes the width. You can think of it as, in a way, overriding the ability of the text to stretch its full width.
To fix this, consider changing the maxHeight property by adding a set height, or play around with different types of frames dimensions.
I know this doesn't talk about HStack's specifically, but feel free to check out this video to learn more about layout: https://www.youtube.com/watch?v=zczHBLtpRZo
If you want to launch an app on the app store, you may want to consider learning Geometry Reader to have dynamic dimensions across different screen sizes. This is a tutorial from a really good website, hacking with swift: https://www.youtube.com/watch?v=WNO1b58k7zg&t=505s
So I'm try to use ScrollViewReader to programmatically scroll a horizontal scroll view. I thought it would work like scrollToItem with .centeredHorizontally in UIKit, and for the most part it does, but the last few elements in the scroll view are being forcefully scrolled to the center of the screen, despite the fact that the scroll view isn't normally able to scroll that far over (without snapping back after releasing the drag, at least). This ends up creating white space across the trailing half of the screen.
I've seen some other questions about this and it seems like the general opinion is that it's not a bug? On the one hand I suppose we're telling the scroll view to center the item, and it's doing just that -- so, not a bug? On the other hand, that's not how similar functionality worked in UIKit. Also, this behavior is only happening on the trailing end of the scroll view! If it was the intended behavior I would expect that scrolling to the first element in the scroll view using .center anchor would force it into the center of the screen and leave leading white space, but this doesn't happen.
Is there an elegant solution to this? Or do we have to calculate the width of our elements + spacing and figure out based on the screen width whether we should anchor .center or just scroll to the last element with anchor .trailing in order to replicate the UIKit behavior?
I found a package (Amzd/ScrollViewProxy) that was made before ScrollViewReader was released that functions much the same as ScrollViewReader, but also seems to not have the bug (if it is a bug) detailed in the question.
Usage examples can be seen on the repository page, but here's a quick minimal example.
ScrollView(.horizontal) { scrollProxy in
ForEach(sections) { section in
Text(section.text)
.scrollId(section.id)
}
.onChange(of: index) {
scrollProxy.scrollTo(
sections[index].id,
alignment: .center
)
}
}
The package adds a convenience init to ScrollView to give access to the scrollProxy.
I can confirm this behavior and think it should be considered a bug. Especially since the scroll view will "jump" into position on the first touch event.
As of iOS 15.4 Beta 1 this is fixed for me. Maybe give it another try.
I have a client that doesn't like the bounce effect on the edge hit of the scrollview. So I'm looking to make the scrollview not bounce and act more 'normal'. In truth I'd really like it to bounce but only on the top.
From looking at the scrollview I've got no idea how to do this with a scrollview without heavily modifying it. At that point I'm not sure that using a scroller and a draggable wouldn't be a better solution.
Any thoughts?
Edit: why was this down-voted?
Note that on OS X or iOS this is not possible, as Apple likes the bounce of a page and it is native behaviour. Famous does add on top of that, however, and THAT can be turned off:
for a ScrollContainer:
new ScrollContainer({
scrollview : {
edgeGrip : 1
}
});
for a Scrollview:
new Scrollview({
edgeGrip : 1
});
It's as simple as that ;-)
The scrollview will not bounce anymore unless the operating system wants it to bounce.
I tried Stephan's suggestion to use edgeGrip and it doesn't stop the edge bouncing running under Chrome. The other edge parameters didn't improve the behavior either. However I did find that speedLimit helps to reduce the bounce. Not a perfect solution but it might be enough depending on your requirements.
new Scrollview({
speedLimit: 0.6
});
Update: This doesn't seem to help as much with mobile Chrome :-/
I have a scrollview and an image as a background in different surface with lower z-index. I want to scroll the image with half the speed of the scrollview.
Any ideas on how to implement it ?
I can't give you a COMPLETE solution, but this should take you down a decent path.
1) Famo.us has worked on multiple scrollViews. Each has a slightly different method to get the 'scrollTop' value from it.
The one created earlier only gives you the scrollTop value for the first visible element in the list. So, in this case you can get how many elements have been scrolled away and calculate the actual value yourself. OR if you have a small, and limited number of the elements in the scrollView you should wrap all the elements in a single view and pass a singleView to the scrollView. This way Famo.us has to do calculations for off-screen elements, but if the number of elements is small enough, it can make many animations/calculations much easier.
The second scrollView was call LimitedScrollView internally. I don't have much experience with it yet, but it should give you the correct values anyway.
2) ScrollView fires events on scroll. use that to update the value of a transitionable.
Pseudo Code:
scrollView.on('scroll', function(){
transitionable.set(scrollView.scrollTop)
});
3) You can now bind the transform value for the background to the transitionable.
Pseudo Code:
background.transformFrom(function(){
return Transform.translate(0, -transitionable.get()/2, 0);
});
Now, things should work correctly.
Hope that helps.