I have read countless articles and watched 10 hours of YouTube videos and still can't figure this out, maybe I'm just missing the term. I'm old school and still trying to learn this backwards swift stuff compared to vb or javascript.
I am using the default Mac OS document template in Xcode 13.1. it comes with a dialogue to open a file then dumps it into the TextEditor as utf8 string.
For my part I added another TextEditor and a button but keep getting error when I try to copy the text from the original texteditor to the new texteditor when button is pressed.
struct ContentView: View {
#Binding var document: test2Document
#State var newtexteditor: String = "press the button"
var body: some View {
VStack{
//main text editor
TextEditor(text: $document.text)
//divider
Divider()
//new text editor
TextEditor(text: $newtexteditor).padding()
//button
Button("test", action: dosomething)
}
}
func dosomething () {
$newtexteditor = $document
}
}
Also, is there any ways of giving objects a name or label and using that to say things like textbox1.text = textbox2.text like you could using storyboards. I obviously know that's not swift syntax but you get the point.
#State and #Binding vars are special kinds of variables. They actually contain 2 sub-variables: projectedValue and wrappedValue.
projectedValue is like a reference to the actual value, and allows the #State/#Binding to be modified from further down the view hierarchy.
You access this by saying $newTextEditor or $document.text.
This is only used for passing references down the view hierarchy, where you can later set the wrappedValue.
wrappedValue is the actual value — in your case, a String.
You access this by just saying newTextEditor or document.text. No $.
You're able to set this - for example, newTextEditor = "New text" or newTextEditor = document.text. The UI will automatically update to reflect the changes.
Here's an example:
struct ContentView: View {
#State var text = "Hello"
var body: some View {
VStack {
Text("The text is: \(text)") /// display the `wrappedValue`
SubView(text: $text) /// pass in the `projectedValue`
}
}
}
struct SubView: View {
#Binding var text: String
var body: some View {
Button("Click me to change text") {
text = "New text" /// set the `wrappedValue`
}
}
}
In your code, it would look something like this:
struct ContentView: View {
#Binding var document: Test2Document /// Side Note: structs like `Test2Document` should be Capitalized
#State var newTextEditor: String = "press the button" /// also use camel case
var body: some View {
VStack{
TextEditor(text: $document.text) /// pass in the `projectedValue`
Divider()
TextEditor(text: $newTextEditor) /// pass in the `projectedValue`
.padding()
Button("test", action: dosomething)
}
}
func dosomething() {
newTextEditor = document.text /// set the `wrappedValue`
}
}
Related
Here's what I want to do:
Have a SwiftUI view which changes a local State variable
On a button tap, pass that variable to some other part of my application
However, for some reason, even though I update the state variable, it doesn't get updated when it's passed to the next view.
Here's some sample code which shows the problem:
struct NumberView: View {
#State var number: Int = 1
#State private var showNumber = false
var body: some View {
NavigationStack {
VStack(spacing: 40) {
// Text("\(number)")
Button {
number = 99
print(number)
} label: {
Text("Change Number")
}
Button {
showNumber = true
} label: {
Text("Show Number")
}
}
.fullScreenCover(isPresented: $showNumber) {
SomeView(number: number)
}
}
}
}
struct SomeView: View {
let number: Int
var body: some View {
Text("\(number)")
}
}
If you tap on "Change Number", it updates the local state to 99. But when I create another view and pass this as a parameter, it shows 1 instead of 99. What's going on?
Some things to note:
If you uncomment Text("\(number)"), it works. But this shouldn't be necessary IMO.
It also works if you make SomeView use a binding. But for my app, this won't work. My actual use case is a 'select game options' view. Then, I will create a non-SwiftUI game view and I want to pass in these options as parameters. So, I can't have bindings all the way down my gaming code just because of this bug. I want to just capture what the user enters and create a Parameters object with that data.
It also works if you make it a navigationDestination instead of a fullScreenCover. ¯\(ツ)/¯ no idea on that one...
A View is a struct, therefore its properties are immutable, so the view can not change its own properties. This is why changing the property named number from inside the body of the view needs this property to be annotated with a #State property wrapper. Thanks to Swift and SwiftUI, transparent read and write callbacks let the value being seen changed. So you must not pass number as a parameter of SomeView() when calling fullScreenCover(), but pass a reference to number, for the callbacks to be systematically called: $number. Since you are not passing an integer anymore to construct struct SomeView, the type of the property named number in this struct can not any longer be an integer, but must be a reference to an integer (namely a binding): use the #Binding annotation for this.
So, replace SomeView(number: number) by SomeView(number: $number) and let number: Int by #Binding var number: Int to do the job.
Here is the correct source code:
import SwiftUI
struct NumberView: View {
#State var number: Int = 1
#State private var showNumber = false
var body: some View {
NavigationStack {
VStack(spacing: 40) {
// Text("\(number)")
Button {
number = 99
print(number)
} label: {
Text("Change Number")
}
Button {
showNumber = true
} label: {
Text("Show Number")
}
}
.fullScreenCover(isPresented: $showNumber) {
SomeView(number: $number)
}
}
}
}
struct SomeView: View {
#Binding var number: Int
var body: some View {
Text("\(number)")
}
}
After all that said to obtain a valid source code, their is a little trick that has not been explained up to now: if you simply replace in your source code Text("Change Number") by Text("Change Number \(number)"), without using $ reference nor #Binding keywords anywhere, you will see that the problem is also automatically solved! No need to use #binding in SomeView! This is because SwiftUI makes optimizations when building a tree of views. If it knows that the displayed view changed (not only its properties), it will compute the view with updated #State values. Adding number to the button label makes SwiftUI track changes of the number state property and it now updates its cached value to display the Text button label, therefore this new value will be correctly used to create SomeView. All of that may be considered as strange things, but is simply due to optimizations in SwiftUI. Apple does not fully explain how it implements optimizations building a tree of views, there are some informations given during WWDC events but the source code is not open. Therefore, you need to strictly follow the design pattern based on #State and #Binding to be sure that the whole thing works like it should.
All of that said again, one could argue that Apple says that you do not have to use #Binding to pass a value to a child view if this child view only wants to access the value: share the state with any child views that also need access, either directly for read-only access, or as a binding for read-write access (https://developer.apple.com/documentation/swiftui/state). This is right, but Apple says in the same article that you need to place [state] in the highest view in the view hierarchy that needs access to the value. With Apple, needing to access a value means that you need it to display the view, not only to do other computations that have no impact on the screen. This is this interpretation that lets Apple optimize the computation of the state property when it needs to update NumberView, for instance when computing the content of the Text("Change Number \(number)") line. You could find it really tricky. But there is a way to understand that: take the initial code you wrote, remove the #State in front of var number: Int = 1. To compile it, you need to move this line from inside the struct to outside, for instance at the very first line of your source file, just after the import declaration. And you will see that it works! This is because you do not need this value to display NumberView. And thus, it is perfectly legal to put the value higher, to build the view named SomeView. Be careful, here you do not want to update SomeView, so there is no border effects. But it would not work if you had to update SomeView.
Here is the code for this last trick:
import SwiftUI
// number is declared outside the views!
var number: Int = 1
struct NumberView: View {
// no more state variable named number!
// No more modification: the following code is exactly yours!
#State private var showNumber = false
var body: some View {
NavigationStack {
VStack(spacing: 40) {
// Text("\(number)")
Button {
number = 99
print(number)
} label: {
Text("Change Number")
}
Button {
showNumber = true
} label: {
Text("Show Number")
}
}
.fullScreenCover(isPresented: $showNumber) {
SomeView(number: number)
}
}
}
}
struct SomeView: View {
let number: Int
var body: some View {
Text("\(number)")
}
}
This is why you should definitely follow the #State and #Binding design pattern, taking into account that if you declare a state in a view that does not use it to display its content, you should declare this state as a #Binding in child views even if those children do not need to make changes to this state. The best way to use #State is to declare it in the highest view that needs it to display something: never forget that #State must be declared in the view that owns this variable; creating a view that owns a variable but that does not have to use it to display its content is an anti-pattern.
Since number isn't read in body, SwiftUI's dependency tracking detect it. You can give it a nudge like this:
.fullScreenCover(isPresented: $showNumber) { [number] in
Now a new closure will be created with the updated number value whenever number changes. Fyi the [number] in syntax is called a "capture list", read about it here.
Nathan Tannar gave me this explanation via another channel which I think gets to the crux of my problem. It does seem that this is a SwiftUI weirdness caused by knowing when and how it updates views based on state. Thanks Nathan!
It’s because the number isn’t “read” in the body of the view. SwiftUI is smart in that it only triggers view updates when a dependency of the view changes. Why this causes issues with the fullScreenCover modifier is because it captures an #escaping closure for the body. Which means it’s not read until the cover is presented. Since its not read the view body will not be re-evaluated when the #State changes, you can validate this by setting a breakpoint in the view body. Because the view body is not re-evaluated, the #escaping closure is never re-captured and thus it will hold a copy of the original value.
As a side note, you’ll find that once you present the cover for the first time and then dismiss, subsequent presentations will update correctly.
Arguably this seems like a SwiftUI bug, the fullScreenCover probably shouldn’t be #escaping. You can workaround by reading the number within the body, or wrapping the modifier with something like this, since here destination is not #escaping captured so the number will be read in the views body evaluation.
struct FullScreenModifier<Destination: View>: ViewModifier {
#Binding var isPresented: Bool
#ViewBuilder var destination: Destination
func body(content: Content) -> some View {
content
.fullScreenCover(isPresented: $isPresented) {
destination
}
}
}
I am executing a SwiftUI playground that contains 2 labels and 2 buttons that modified the value of these labels.
I've stored the value of these labels in a #ObservableObject. Whene I modify the value of any of these properties, both views CustomText2 and CustomText3 are reinitialized, even the one that his values has not changed.
Code:
final class ViewModel: ObservableObject {
#Published var title: Int
#Published var title2: Int
init(title: Int = 0, title2: Int = 0) {
self.title = title
self.title2 = title2
}
}
struct ContentView: View {
#StateObject var viewModel = ViewModel()
var body: some View {
VStack {
Button(
action: {
viewModel.title += 1
}, label: {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
}
)
CustomText1(
title: $viewModel.title
)
Button(
action: {
viewModel.title2 += 1
}, label: {
Image(systemName: "globe")
.imageScale(.large)
.foregroundColor(.accentColor)
}
)
CustomText2(
title: $viewModel.title2
)
}
.padding()
}
}
struct CustomText1: View {
#Binding var title: Int
init(
title: Binding<Int>
) {
self._title = title
}
var body: some View {
Text("\(title)")
.foregroundColor(.black)
}
}
However if I store both properties as #State in the view and I modify them, the CustomTexts are not reinitialized, they just update their value in the body without executing an init.
Why are they getting reinitialized when I store both properties in the ViewModel?
I've tried to make the views conforming Equatable but they're reinitialized.
Can be a performance problem if the views are initialized many times?
I am interested in not having the subviews reinitialized because I want to perform custom stuff in the init of some subviews.
When you have one StateObject that encompasses multiple State variables, change in one will redraw the entire view. In your case, any change in any variable in viewModel will trigger the publisher of viewModel and reload ContentView
Also we are not supposed to make any assumptions on when a View will be redrawn, as this might change with different versions of SwiftUI. Its better to move this custom stuff you are doing in the init of views to some other place(if it can be). Init should only do work needed to redraw the view with the new state parameters and nothing else.
#ObservableObject is for model data, not view data.
The reason is when using lets or #State vars, SwiftUI uses dependency tracking to decide if body needs to be called and in your case body doesn't use the values anywhere so there is no need to call it.
It can't track objects in the same way, if there is a #StateObject declared then body is called regardless if any properties are accessed, so it's best to start with #State value types and only change to #StateObject when you really need features of a reference type. Not very often now we have .task which is the place to put your custom async work.
I need to build a list of TextFields where each field is associated with focus id, so that I can auto scroll to such a text field when it receives focus. In reality the real app is a bit more complex which also includes TextEditors and many other controls.
Now, I found out that if my view defines #Environment(\.dismiss) private var dismiss then the list is rebuilding all the time during manual scrolling. If I just comment out the line #Environment(\.dismiss) private var dismiss then there is no rebuilding of the list when I scroll. Obviously, I want to be able to dismiss my view when user clicks some button. In the real app it's even worse: during scrolling everything is lagging, I cannot get smooth scrolling. And my list is not huge it's just 10 items or so.
Here is a demo example:
struct ContentView: View {
var body: some View {
NavigationView {
NavigationLink {
DismissListView()
} label: {
Text("Go to see the list")
}
}
}
}
struct DismissListView: View {
#Environment(\.dismiss) private var dismiss
enum Field: Hashable {
case line(Int)
}
#FocusState private var focus: Field?
#State private var text: String = ""
var body: some View {
ScrollViewReader { proxy in
List {
let _ = print("body is rebuilding")
Button("Dismiss me") {
dismiss()
}
Section("Section") {
ForEach((1...100), id: \.self) {num in
TextField("text", text: $text)
.id(Field.line(num))
.focused($focus, equals: .line(num))
}
}
}
.listStyle(.insetGrouped)
.onChange(of: focus) {_ in
withAnimation {
proxy.scrollTo(focus, anchor: .center)
}
}
}
}
}
The questions are:
Why is the list rebuilding during manual back and forth scrolling when #Environment(\.dismiss) private var dismiss is defined, and the same is NOT happening when dismiss is NOT defined?
Is there any workaround for this: I need to be able to use ScrollProxyReader to focus any text field when the focus changes, and I need to be able to dismiss the view, but in the same time I need to avoid constant rebuilds of the list during scrolling, because it drops app performance and scrolling becomes jagged...
P.S. Demo app constantly outputs "body is rebuilding" when dismiss is defined and the list is scrolled, but if any text field gets a focus manually, then the "body is rebuilding" is not printed anymore even if the dismiss is still defined.
I could make an assumption, but that would be really rather a guess (based on experience, observations, etc). In a fact, all WHYs like "why this sh... (bug) happens" should be asked on https://developer.apple.com/forums/ (there are Apple's engineers there) or reported to https://developer.apple.com/bug-reporting/
A solution is to separate dismiss depenent part into dedicated view, so hiding it from parent body (and so do not affect it)
struct DismissView: View {
// visible only for this view !!
#Environment(\.dismiss) private var dismiss
var body: some View {
Button("Dismiss me") {
// affects current context, so it does not matter
// in which sub-view is called
dismiss()
}
}
}
var body: some View {
ScrollViewReader { proxy in
List {
let _ = print("body is rebuilding")
DismissView() // << here !!
// ... other code
I am learning memory and ARC since a while and managed to use the Leaks instrument more often in order to produce quality code. Having that said, please consider my lack of experience in this zone.
Problem: I built a parent view A that presents a view B.
B contains a login form built using a TextField, a SecureField and a Button. I also have a #FocusState private var isFocused: Bool property that helps me hide the keyboard in order to bypass the "AttributeGraph: cycle detected" console error that shows up once I disable the textfield on button press having the keyboard on screen. (Get `AttributeGraph: cycle detected` error when changing disabled state of text field)
I noticed that when I use the #FocusState property, once I dismiss B, the Leaks instrument detects two "Malloc 32 Bytes" leaks just like in the picture below.
If I don't use the #FocusState property, the leaks will no longer show up. Am I doing something wrong or is this some kind of bug / false positive from Swift?
This view is partially extracted from my file so it doesn't have all it's properties and methods here.
struct AuthenticationLoginView: View {
#StateObject var viewModel = AuthenticationLoginViewModel()
#FocusState private var isFocused: Bool
var body: some View {
VStack {
TextField(text: $viewModel.username) {
Text("placeholder.")
}
.tag(AuthenticationLoginField.username)
.textInputAutocapitalization(.never)
.focused($isFocused)
.disabled(viewModel.isLoggingIn)
SecureField(text: $viewModel.password) {
Text("Password")
}
// .focused($isFocused)
.disabled(viewModel.isLoggingIn)
.tag(AuthenticationLoginField.password)
}
}
}
Without more code it is hard to tell what else you are doing that may have caused the leak.
My gut is that having a single focus boolean when you have two edit fields is an anti-pattern compared to Apple's way. When something is evolving like SwiftUI, try to follow their example styles more closely. Use a boolean only when there's just one focusable field.
This similar Hacking with Swift sample shows using an optional and changing the focus as fields submitted.
#FocusState private var focusedField: FocusedField?
#State private var username = "Anonymous"
#State private var password = "sekrit"
var body: some View {
VStack {
TextField("Enter your username", text: $username)
.focused($focusedField, equals: .username)
SecureField("Enter your password", text: $password)
.focused($focusedField, equals: .password)
}
.onSubmit {
if focusedField == .username {
focusedField = .password
} else {
focusedField = nil
}
}
I found this problem. In my case, it caused a massive retain loop which fed all the way back to coordinator with a bunch of objects.
Just showing a TextField with focus (either the bool way, or the enum way) caused a retain.
My fix was to use the introspect library and just set first responder manually
#State private var textField:UITextField?
#State private var secureTextField:UITextField?
var body: some View {
ZStack {
TextField(prompt, text: $text)
.opacity(isSecure ? 0 : 1)
.introspectTextField { field in
textField = field
}
SecureField(prompt,text: $text)
.opacity(isSecure ? 1 : 0)
.introspectTextField { field in
secureTextField = field
}
}
.animation(.easeInOut, value: isSecure)
.overlay(alignment: .trailing) {
Button {
isSecure.toggle()
setFocus()
} label: {
Image(isSecure ? "eyeClose" : "eyeOpen")
}
.opacity(canBeSecure ? 1 : 0)
}
.onAppear {
DispatchQueue.main.async {
setFocus()
}
}
}
func setFocus() {
if isSecure {
secureTextField?.becomeFirstResponder()
}
else {
textField?.becomeFirstResponder()
}
}
I'm trying to capture the text typed in a TextEditor, store it in a variable and update what is displayed on the TextEditor itself. I'm using the .onChange() to trigger and capture what is being typed, store it in a variable, and change the current text being displayed. But the problem is that, .onChange() is being called twice: First, when i type the text inside the TextEditor; and Second, when i try to set a different character for the view itself.
struct ChatView: View {
#State var chatTextInput: String = ""
#State var oldChatValue: String = ""
#State var newChatValue: String = ""
var body: some View {
VStack {
TextEditor(text: $chatTextInput)
.onChange(of: chatTextInput) { newValue in
oldChatValue += "a"
newChatValue += newValue.last.map{String($0)}!
chatTextInput = oldChatValue
}
}
}
}
For exemple, if i type qwerty, newChatValue is printed as Qawaearataya and chatTextInput receives aaaaaaaaaaaa
Any clues on how to prevent the .onChange to being triggered the second time, when i set the new character for the TextEditor text?
Thanks a lot!
Your issue is simply that .onChange(of:) isn't a responder to the TextEditor, it is a responder for the variable, in this case chatTextInput. Since chatTextInput is bound to the TextEditor, when you type a letter, chatTextInput is updated, and .onChange(of:) runs. However, as part of .onChange(of:) running, you change chatTextInput which calls .onChange(of:) again. You would have an infinite loop, except that .onChange(of:)` ends at this point. If anyone can explain that, I would love to hear it.
The fix, however is to simply put a flag in .onChange(of:) to only set the variables every other time like this:
struct ChatView: View {
#State var chatTextInput: String = ""
#State var oldChatValue: String = ""
#State var newChatValue: String = ""
#State var textEntryFlag = true
var body: some View {
VStack {
TextEditor(text: $chatTextInput)
.onChange(of: chatTextInput) { newValue in
if textEntryFlag {
oldChatValue += "a"
newChatValue += newValue.last.map{String($0)}!
chatTextInput = oldChatValue
}
textEntryFlag.toggle()
}
}
}
}