Posts

Post marked as solved
6 Replies
I don't think you understand my question. I want the touch down effect, meaning I want the button to fire the moment my finger touches the button. What ButtonStyle does by default is like UIKit's touch up inside meaning the button fires when the user's finger LEAVES the button. As for PrimitiveButtonStyle, I know I have to implement gesture, it's what I did, I copied and pasted that blog post's code into Xcode, I did exactly what he did. And the problem is if I hold down the button for a few seconds, it actually reverts back to its original size and opacity while my finger is still pressing it.
Post marked as solved
6 Replies
Yes I am aware that ButtonStyle and PrimitiveButtonStyle don't share the same properties. Which is why I'm asking for a solution. I have read that SwiftUI Lab blog post you linked and I can't find the solution there either. Neither of the button styles he used in that blog post actually has the touch down effect. Also, the PrimitiveButtonStyle he created actually goes back to its original size and opacity before the user's finger leaves the button which is also not something I want.
Post not yet marked as solved
4 Replies
that's not very helpful, your reply seems pretty hostile and rude actually, I don't know why you felt the need to leave a snarky reply with no explanations as to why I'm wrong when you could've just ignored my question. Rude and disrespectful replies like yours is the reason why I stopped asking questions on Stack Overflow.
Post marked as solved
5 Replies
Ah I understand now. The doc isn't talking about literal deallocation.So in order to use the unowned keyword in a capture list to resolve a strong reference cycle between a closure and a class instance it captures, two conditions must be met 1) the closure and the instance it captures will always refer to each other. 2)In a hypothetical world where the closure and the instance can both be deallocated despite their strong reference cycle, the closure and the instance will always deallocate at the same time.
Post marked as solved
5 Replies
Thanks a lot for the answer but it's not really what I was asking. Let me try and ask my question in a different way.Apple says "define a capture in a closure as an unowned reference when the closure and the instance it captures will always refer to each other, and will always be deallocated at the same time"Now let me paraphrase that quote in my own words: "In order to use the unowned keyword in a capture list to resolve a strong reference cycle between a closure and a class instance, two conditions must be met. 1)the closure and the instance it captures will always refer to each other. 2)the closure and the instance it captures will always deallocate at the same time."But this is actually self-contradictory because if the 2nd condition can be met, that is, if the closure and the instance it captures can deallocate at the same time, a strong reference cycle between the closure and the instance wouldn't even exist. By definition, if there's a strong reference cycle between a closure and an instance, neither the closure nor the instance can deallocate. So if the closure and the instance it captures can deallocate at the same time (or can deallocate at all), it means that there's no strong reference cycle between them. And therefore there's no need for a capture list to resolve a strong reference cycle. And that quote from Apple's documentation is basically saying, in order to resolve a strong reference cycle between a closure and an instance by using "unowned" in a capture list, one of the conditions that has to be met is that there's no strong reference cycle between the closure and the instance. That's like saying, there's a solution to a problem, and in order to use that solution to solve the problem, one of the things you have to make sure is that you don't have that problem that the solution is designed to solve. Which makes absolutely no sense.My question is, how should I interpret and understand this seemingly self-contradictory quote by Apple? Am I misinterpreting the quote? or did Apple make a mistake when writing the documentation?Sorry, I know my question sounds extremely confusing but I hope you can understand what I'm asking here. Thanks in advance.