Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI in 2022

mjtsai.com

Post reply on HN
Print view View original

191–200 of 216 posts

Re: SwiftUI in 2022

#191

Post by saagarjha »

alexashka wrote: post #190
saagarjha wrote: post #155

Earlier quoted context omitted.

How's this? It's not quite "screen width" if you make the screen wider than it is tall, but I could make it stick to that if you really want I guess. struct ContentView: View { var body: some View { ZStack { Rectangle() .fill(Color.red) Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) HStack { VStack { Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) Spacer() } Spacer() } .padding(10) } .asp…

Your answer is wrong. You've failed the fizzbuzz :)

I generally expect interviewers to tell me what the problem is ;)

Re: SwiftUI in 2022

#192

Post by alexashka »

emehex wrote: post #160
alexashka wrote: post #121

Earlier quoted context omitted.

Your answer is wrong. You've failed the fizzbuzz :) Change frame (screen width) to 300, 500 to see why.

Good catch. Fixed with an extra ZStack.

GeometryReader was not part of fizzbuzz. Replace geo.size.width * 0.1 with 10 to see your code break.

Now tell me, why did it break? Do you even know? Because I don't.

I don't know why half the shit works as it does, and I've written non-trivial SwiftUI code for 6 months. I did not have this problem with UIKit and interface builder.

Re: SwiftUI in 2022

#193

Post by emehex »

bowsamic wrote: post #187
emehex wrote: post #171

Earlier quoted context omitted.

"tried" being the operative word. But you really shouldn't be persisting an ObservableObject. You should extract what you need into a model and use Codable...

Why shouldn't I try and persist an ObservableObject? Has some Apple guru given you this secret information in a WWDC, or personally? It seems totally reasonable to do so. Observability is something you bestow upon a model, it shouldn't exclude it from persistence. You are talking nonsense to defend Apple's lazy approach. They simply have not covered this base, that's the actual non-Apple-fanboy explanation. Get it to…

Observable/StateObjects help bridge between models and views... I'd recommend watching this WWDC session: https://developer.apple.com/videos/play/wwdc2020/10040/

Re: SwiftUI in 2022

#194

Post by emehex »

alexashka wrote: post #192
emehex wrote: post #160

Earlier quoted context omitted.

Good catch. Fixed with an extra ZStack.

GeometryReader was not part of fizzbuzz. Replace geo.size.width * 0.1 with 10 to see your code break. Now tell me, why did it break? Do you even know? Because I don't. I don't know why half the shit works as it does, and I've written non-trivial SwiftUI code for 6 months. I did not have this problem with UIKit and interface builder.

GeometryReader is a pretty critical part of the SwiftUI framework. I'd recommend getting familiar with it!

Saying "you can't use GeometryReader" would be like saying you can't use UIKit's Auto Layout...

Re: SwiftUI in 2022

#195

Post by emehex »

alexashka wrote: post #190
saagarjha wrote: post #155

Earlier quoted context omitted.

How's this? It's not quite "screen width" if you make the screen wider than it is tall, but I could make it stick to that if you really want I guess. struct ContentView: View { var body: some View { ZStack { Rectangle() .fill(Color.red) Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) HStack { VStack { Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) Spacer() } Spacer() } .padding(10) } .asp…

Your answer is wrong. You've failed the fizzbuzz :)

Perhaps you can post a photo of what you're looking for? Because your instructions aren't super clear :)

Re: SwiftUI in 2022

#196

Post by alexashka »

saagarjha wrote: post #191
alexashka wrote: post #190

Earlier quoted context omitted.

Your answer is wrong. You've failed the fizzbuzz :)

I generally expect interviewers to tell me what the problem is ;)

My apologies, you've successfully passed FizzBuzz, in a rather unwieldy way by relying on nesting vstacks, hstacks and adding spacers.

The larger point being - placing squares on a page went from drag and dropping and setting a few constraints, to now doing zstack/hstack/vstack/spacer wizardry.

Re: SwiftUI in 2022

#197

Post by [deleted] »

emehex wrote: post #194
alexashka wrote: post #192

Earlier quoted context omitted.

GeometryReader was not part of fizzbuzz. Replace geo.size.width * 0.1 with 10 to see your code break. Now tell me, why did it break? Do you even know? Because I don't. I don't know why half the shit works as it does, and I've written non-trivial SwiftUI code for 6 months. I did not have this problem with UIKit and interface builder.

GeometryReader is a pretty critical part of the SwiftUI framework. I'd recommend getting familiar with it! Saying "you can't use GeometryReader" would be like saying you can't use UIKit's Auto Layout...

[deleted]

Re: SwiftUI in 2022

#198

Post by ChrisMarshallNY »

JamesSwift wrote: post #143
ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril. I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the plat…

I liked the "cut with the grain" comment, someone made earlier.

The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers.

It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless.

I use the Storyboard Editor a lot. It is not my favorite editor, but it allows me to work incredibly quickly, and to make a really reflowable UI.

I know that the app I'm working on now, is larger than any I've seen from SwiftUI (around 40 screens, and communicating with three servers in realtime, using a couple of SDKs). I am able to make it all work.

I feel as if MVVM would make the parts of the app that link the UI to the servers a lot more graceful (it's a nasty state engine, right now -ick). I feel as if this kind of app is the kind of thing they had in mind, with SwiftUI.

I do know that it's really important to derive subclasses, and extend ObjC classes, when using UIKit/AppKit/WatchKit, and I feel sorry for folks that avoid inheritance like the plague. It must be a fair bit of work. Looks like SwiftUI doesn't really need that at all, but I haven't spent enough time with it, yet, to know for sure.

I have no doubt that I'll end up mastering it. I'm a quick study. I've spent 35 years, surfing the tech wave.

Re: SwiftUI in 2022

#199

Post by zethraeus »

ragnese wrote: post #9
dgellow wrote: post #2

I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?

> People seem to either love it or hate it. Or is that just an effect of people posting on Twitter? I'm sure that a big part of that is the effect of it being Twitter. How often do we feel the urge to post something online that we have no strong feelings about? More on topic, though: I'm a SwiftUI hater still. It's a cool concept, but there are two big problems with it, IMO: 1. It's totally out of place with the rest…

> It's totally out of place with the rest of the Swift programming language. They had to add new crap to the language to accommodate its declarative style, when Swift is (was) unapologetically imperative syntax-wise. It's an obvious bolt-on and leaves a really bad taste in my mouth.

Woah now, that's interesting! In my mind swift has had awesome support for functional programming paradigms since launch. I understand it to be leaning in about as far as it can given that it's built with first class support for Obj-c oriented frameworks.

What makes you feel like it's unapologetically imperative?

Re: SwiftUI in 2022

#200

Post by JamesSwift »

ChrisMarshallNY wrote: post #198
JamesSwift wrote: post #143

Earlier quoted context omitted.

> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril. I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the plat…

I liked the "cut with the grain" comment, someone made earlier. The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless. I use the Storyboard Editor a lot . It is not my fav…

> The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers.

I dont think you understand the point I'm making. Just because Apple has created a framework that has something called UIViewController which has child UIViews doesnt matter when using a pattern called MVVM. The V is just the _visual_ representation of the pattern. It could be a terminal console if you want, it doesn't have to be the "underlying" view of the platform! Don't fight the platform to align its idea of the view with a specific thing called a View in the pattern.

EDIT: and yes IB is an issue if you want to be programmatic. I do all my views in code.

Post reply on HN