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:

http://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html

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
meh...@icloud.com

[Jens Alfke]

On Sep 5, 2015, at 9:59 PM, Alex Hall <meh...@icloud.com> 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:

http://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html

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

[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.

[Jens Alfke]

On Sep 6, 2015, at 4:44 AM, Daniel T. <danie...@gmail.com> 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

[Alex Hall]

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

[Jens Alfke]

On Sep 6, 2015, at 8:02 PM, Alex Hall <meh...@icloud.com> 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

[Uli Kusterer]

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.

[Alex Hall]

> On Sep 7, 2015, at 05:34, Uli Kusterer <kust...@gmail.com> 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.

[Daniel T.]

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