Status of Cocoa Bindings in Swift?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Status of Cocoa Bindings in Swift?

Alex Hall
Hi list,

How does Swift handle bindings? Some things I've found suggest that there's no problem, so long as whatever you're observing inherits from NSObject. Others seem to have major problems with bindings as they stand now:

I'm very, very new to bindings (as in, just started reading today, and my head is still spinning), so I might be confusing bindings with the underlying mechanism of KVO; if I am, sorry to confuse the issue more. As I continue down this path, what gotchas might I expect if I'm using only Swift? Is there any reason to think that pausing and waiting for an incoming feature of Swift itself is worth while? What hidden tricks might I need to know to get bindings working correctly? Should I not use bindings at all in Swift? Anything anyone can think of would be appreciated. Thanks in advance.

--
Have a great day,
Alex Hall
[hidden email]

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/7DA3A9E2-33D5-4277-9E33-2A8748E91B13%40icloud.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Status of Cocoa Bindings in Swift?

Daniel T.
I avoid KVO in swift. The most popular alternative seems to be the use of RxSwift or ReactiveCocoa, both of which bind the observation behavior to the property, like the last example in the great article you posted.

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/4301bb6d-525a-4bc8-82e8-69510996b2b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Jens Alfke
In reply to this post by Alex Hall

On Sep 5, 2015, at 9:59 PM, Alex Hall <[hidden email]> wrote:

How does Swift handle bindings? Some things I've found suggest that there's no problem, so long as whatever you're observing inherits from NSObject. Others seem to have major problems with bindings as they stand now:

That blog post doesn’t seem to be talking about functional problems, just the fact that using KVO from Swift code is awkward.

As far as I know, it should be true that "there's no problem, so long as whatever you're observing inherits from NSObject”, and of course the properties being bound need to be marked @dynamic so they’re observable, and their types need to be representable in Obj-C.

—jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/991CEAF3-4032-46D6-AD1F-2C848EEDBCBC%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Jens Alfke
In reply to this post by Daniel T.

On Sep 6, 2015, at 4:44 AM, Daniel T. <[hidden email]> wrote:

I avoid KVO in swift. The most popular alternative seems to be the use of RxSwift or ReactiveCocoa, both of which bind the observation behavior to the property, like the last example in the great article you posted.

I wrote a bit of glue code that makes KVO more convenient — the observing class doesn’t have to inherit from NSObject, and it can put the observation code in a closure instead of having to override a method. As an example:

someCocoaObject.observe(keyPath: “color”, options: []) { print(“color changed”) }

KVO does some tricky things behind the scenes for efficiency, so I think it’s worth using. For instance, unlike the Swift alternatives I’ve seen, there’s zero overhead to setting an observable property, unless that property of that object is being observed.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/86E681F2-EE05-4D2F-8BE9-95F1D7CDAD42%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Alex Hall
In reply to this post by Jens Alfke

On Sep 6, 2015, at 22:44, Jens Alfke <[hidden email]> wrote:


On Sep 5, 2015, at 9:59 PM, Alex Hall <[hidden email]> wrote:

How does Swift handle bindings? Some things I've found suggest that there's no problem, so long as whatever you're observing inherits from NSObject. Others seem to have major problems with bindings as they stand now:

That blog post doesn’t seem to be talking about functional problems, just the fact that using KVO from Swift code is awkward.

As far as I know, it should be true that "there's no problem, so long as whatever you're observing inherits from NSObject”, and of course the properties being bound need to be marked @dynamic so they’re observable, and their types need to be representable in Obj-C.

Thanks; sounds like I'm good to move ahead. I've never touched this Bindings stuff before, so I didn't want to get partway in and find out that Swift doesn't really handle it yet. I'll forge ahead then!

—jens


--
Have a great day,
Alex Hall
[hidden email]

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/F2F0C42D-FF70-4207-A97D-8CB6BEDCD6D4%40icloud.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Jens Alfke

On Sep 6, 2015, at 8:02 PM, Alex Hall <[hidden email]> wrote:

Thanks; sounds like I'm good to move ahead. I've never touched this Bindings stuff before, so I didn't want to get partway in and find out that Swift doesn't really handle it yet. I'll forge ahead then!

Good luck, just be warned that bindings can be difficult to work with because it’s hard to see exactly what’s going on at runtime. I do use them, and they can be a big timesaver, but in some of my projects I suspect the hours spent troubleshooting canceled out the hours saved in coding.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/80940615-156C-4D5B-84BF-8C88835FBFAA%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Uli Kusterer
On 07 Sep 2015, at 05:18, Jens Alfke <[hidden email]> wrote:
>> On Sep 6, 2015, at 8:02 PM, Alex Hall <[hidden email]> wrote:
>>
>> Thanks; sounds like I'm good to move ahead. I've never touched this Bindings stuff before, so I didn't want to get partway in and find out that Swift doesn't really handle it yet. I'll forge ahead then!
>
> Good luck, just be warned that bindings can be difficult to work with because it’s hard to see exactly what’s going on at runtime. I do use them, and they can be a big timesaver, but in some of my projects I suspect the hours spent troubleshooting canceled out the hours saved in coding.

 My rule of thumb: If you're showing value1 or !value1 in the UI or need it synched up right away between 2 controllers, use bindings. As soon as you realize you need a delay, or other issues crop up, rewrite using manual code.

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/3F80CC24-2039-4802-A178-53C0DA71CC35%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Alex Hall

> On Sep 7, 2015, at 05:34, Uli Kusterer <[hidden email]> wrote:
> My rule of thumb: If you're showing value1 or !value1 in the UI or need it synched up right away between 2 controllers, use bindings. As soon as you realize you need a delay, or other issues crop up, rewrite using manual code.

Part of my problem is that the background task that updates my model is asynchronous. My view controller calls the update method (via a timer or a menu item), then immediately calls table.reloadData(). Since the update to the model is asynchronous, though, reloadData() runs before the model is actually updated. The async calls are buried inside a framework I'm using, so I'm not sure how to hook into them to know when the update is really done. Bindings should solve that; no matter when it is, as soon as a new item is downloaded, processed, and added to my model, it shows up in the table. I have no idea if bindings will end up being the best way to go, but if nothing else, I'll actually understand them by the time this is all over. :) Thanks again for the responses, everyone.


--
Have a great day,
Alex Hall
[hidden email]

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/606E4EC1-3058-4422-A50F-33FB70C3F822%40icloud.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Status of Cocoa Bindings in Swift?

Daniel T.
In reply to this post by Alex Hall
Making a KVO replacement that works better in the swift environment is really easy and I think a much more viable option. The thing is, adding Objective-C dynamic components is insidious. Once you connect one part of your model to the ObjC runtime, you find yourself having to connect other parts as well. The next thing you know, you have having to change structs to classes and loosing the benefits that value types give you.

Here is an example of a simple KVO replacement I cooked up last night. You're free to use it....

https://gist.github.com/dtartaglia/0a71423c578f2bf3b15c

On Sunday, September 6, 2015 at 11:02:47 PM UTC-4, Alex Hall wrote:
Thanks; sounds like I'm good to move ahead. I've never touched this Bindings stuff before, so I didn't want to get partway in and find out that Swift doesn't really handle it yet. I'll forge ahead then!
 

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/5ab7765a-3619-4e70-9ad9-6e3d34f12ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.