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

SwiftUI

developer.apple.com

Post reply on HN
Print view View original

181–190 of 394 posts

Re: SwiftUI

#181

Post by tsomctl »

ng12 wrote: post #164
_bxg1 wrote: post #130

Earlier quoted context omitted.

useState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.

What's the difference between a class and a function with local state? (Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing – is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil – objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

Re: SwiftUI

#182

Post by jdhn »

eugeniub wrote: post #137
fphilipe wrote: post #7

Personally, as an iOS developer, this is by far the biggest announcement. Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising. The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 1…

Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago. [1]: https://iosref.com/ios/

>Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.

That really is a bummer, I have an iPhone 6 and it's still alive and kicking.

Re: SwiftUI

#184

Post by Hemospectrum »

hokkos wrote: post #81

So it look like react but it doesn't seems to be immediate mode GUI, still retained ? The body is a property not a function.

That's a "computed property," ie. a getter method pretending to be an instance variable.

Re: SwiftUI

#185

Post by stabbles »

aseipp wrote: post #65
jcelerier wrote: post #16

The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html ).

Depends on what you mean by "clean". I'd say it's pretty good from what I can see? The examples are also incomparable; the one you link to is nearly 20 lines of code to define nothing more than an embedded triangle image and single text embed with a few colors, while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode t…

> while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly)

I think you might check out more of QML / QtQuick 2 before drawing any conclusions.

    import QtQuick 2.12
    import QtQuick.Layouts 1.12

    ListView {
        model: Model.items
        delegate: RowLayout { 
            Image { source: image }
            Column {
                Text { text: title }
                Text {
                    text: subtitle
                    color: "gray"
                }
            }
        }
    }
This should be more or less the same. Fluid scrolling is backed by the underlying Flickable [1]. RTL support is available an can be changed in runtime [2]. Themes / colors can be changed in runtime as well [3].

Lastly, it runs on Windows, Linux and Android as well as OSX and iOS.

[1] https://doc.qt.io/qt-5/qml-qtquick-flickable.html

[2] https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html

[3] https://doc.qt.io/qt-5/qtquickcontrols2-styles.html

Re: SwiftUI

#186

Post by penagwin »

grey-area wrote: post #136
jaegerpicker wrote: post #100

Earlier quoted context omitted.

This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI.

This must be the .. fifth entirely new UI framework from Apple? This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI. They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished: QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI The constantly changing frameworks and languages…

I firmly don't believe they're changing frameworks to "provide platform lockin".

Development philosophies change over time, like the other's said, some of those UI frameworks you mentioned are 20+ years old.

It does suck that we can't use it on other platforms, and I'm sure they don't want to spend resources on doing so, but there's no way the main motivation is to keep people switching frameworks constantly.

Re: SwiftUI

#187

Post by teilo »

skohan wrote: post #9

I hope it still supports low-level control when you need it.

Looks like it shifts the focus toward developing more intelligent components. They mentioned custom SwiftUI components a few times in the demo.

This is one of the things I am eager to get a deep dive on in later session videos.

Re: SwiftUI

#188

Post by HillaryBriss »

pier25 wrote: post #183
mmargerum wrote: post #140

Earlier quoted context omitted.

Flutter doesn't use native controls . It draws everything. Just pointing out that difference.

Native controls aren't drawn too?

yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.

Re: SwiftUI

#190

Post by childintime »

I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer.

Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.

Post reply on HN