i have this code. The circle is not centered. I assume because of the edgesIgnoring...and yes, if i comment it out, it is centered. But if i comment out the "scaledToFill" it is centered too, although the edgesIgnoring is in...is this a bug or am i misunderstanding something? I tested on an iPhoneX Preview...
struct ContentView: View {
var body: some View {
Circle()
.scaledToFill()
.edgesIgnoringSafeArea(.all)
}
}
I try to propose solution (one might say it is workaround - does not matter), for some cases it might be acceptable, because both centred properly, so worth posting:
Note: order of modifiers important!
1) approach 1
Ellipse()
.edgesIgnoringSafeArea(.all)
.scaledToFill()
2) approach 2
Circle()
.edgesIgnoringSafeArea(.all)
.scaledToFill()
Short answer, yes, it's a bug. The circle's size is being calculated including the safe area, but the circle's horizontal offset is being calculated to center it assuming the size it would have not including the safe area. Both circles have their left edge at approximately -204 pixels on an iPhone 11, which leaves the larger one uncentered.
Related
Example
I have tried playing with the padding but no success. Since the string is vertical when you use a larger string the vstack gets wider
var body: some View {
VStack(spacing: 0) {
Spacer()
Text(title.uppercased())
.font(.footnote)
.foregroundColor(.white)
.rotationEffect(Angle(degrees: rotateClockwise ? 90 : -90))
Spacer()
}//: VSTACK
.background(Color.gray.cornerRadius(12))
.frame(width: 85)
}
It's a little tricky to answer with certainty, as there is clearly a more complex layout around this element. So this answer may work or I may need to edit it as you give me a bit more info.
But my suggestion is this: because rotation is not part of SwiftUI's layout calculation, I would suggest using an HStack to wrap just the Text() elements and then rotating that entire stack. This of course then will require you to be more hands-on with the way you use the HStack in your overall layout, but will allow you to get regular stack layout dynamics for your Text elements. To get more control you could consider using the new layout protocol. These are two good tutorials.
I'm trying to work our if it's possible to display text in a Shape so that the text it not rectangular but the same as the shape it's self.
I have tried
Text(loremIpsum)
.font(Font.system(size: 14))
.clipShape(Circle())
which the result was that I'm not seeing new lines when text reaches the edge of the shape.
I then tried to use the circle first and add text to that but that resulted in text appearing outside the circle.
Circle()
.stroke(Color.black, lineWidth: 2)
.padding(6)
.overlay(
Text(loremIpsum)
.font(Font.system(size: 14))
)
I'm wanting to achieve Text that fits perfectly into whatever Shape I use. Is this possible?
The question suggested here does not answer my question sadly. hat just fits text into a Shape but still retains a rectangular frame. I'm trying to make text exactly match the shape I am placing it in.
I've had many similar issues to this when using ScrollViewand LazyVStack/ LazyHStack where the content of the lazy stack will stutter upon bouncing on the edge of the ScrollView.
First I thought it might be due to using complex Views on the lazy stack that would cause layout issues in SwiftUI but I've manage to come up with a MWE that uses a very simple view hierarchy and the issue is still there.
This causes a stutter when scrolling fast to the left and upon bouncing on the leading edge of the ScrollView:
ScrollView(.horizontal) {
LazyHStack {
Color.red.frame(width: 450)
Color.green.frame(width: 250)
Color.blue.frame(width: 250)
}
}
.frame(width: 350)
Decreasing the width of the first view makes the stutter go away
ScrollView(.horizontal) {
LazyHStack {
Color.red.frame(width: 400) //<- No stutter
Color.green.frame(width: 250)
Color.blue.frame(width: 250)
}
}
.frame(width: 350)
For this MWE the stutter only seems to happen on the device (maybe because I can't scroll fast enough in the simulator). However, I've had the same problem happen in the simulator with more complex views.
Any ideas if this is a bug in SwiftUI?
Tested on an iPhones Xs Max with Xcode 13 beta 1 and iOS 15.
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've encountered what I think is a bug, and I'm wondering if anyone else has encountered this, and/or has a work around for it.
I have images imported from the device's camera via the UIImagePickerController representable. Having imported this image, I then save it to the documents directory, and then display it using the following code:
Image(uiImage: image)
.resizable()
.frame(height: 300)
.scaledToFill()
This shouldn't cause the image to distort, as scaled to fill should simply enlarge the image until it fits the frame without distorting it. However, i'm getting a fair amount of horizontal stretching in the final image:
Has anyone encountered this problem? I don't think i'm missing anything obvious, as when I use it for images not taken with the camera then the code performs fine.
Try changing the order of the modifiers as below,
Image(uiImage: UIImage(named: "08-512")!)
.resizable()
.scaledToFill()
.frame(width: 50, height: 20)
//.clipped()
}