Article summary
Last year at around this time, “Github”:http://github.com announced “ReactiveCocoa”:http://github.com/ReactiveCocoa/ReactiveCocoa. I was excited to see a “Functional Reactive Programming”:http://en.wikipedia.org/wiki/Functional_reactive_programming framework made for Objective-C and found an immediate use for it in an iOS project. Since its release, there’s been a tremendous amount of “activity”:https://github.com/ReactiveCocoa/ReactiveCocoa/contributors, “documentation”:https://github.com/ReactiveCocoa/ReactiveCocoa/tree/master/Documentation, and “blog posts”:http://nshipster.com/reactivecocoa/ around it.
The point being, there isn’t an excuse not to use it anymore, and I’d argue that it is (excuse the reference) the _Rearden Metal_ of Objective-C frameworks. It will significantly improve the structure and reduce the complexity of your code. It removes the need for the delegate pattern, continuation-passing style programming, and (most importantly) keeping track of state.
A Quick Example
Below is a small example of how I have used ReactiveCocoa to _react_ to the change in the value of an object.
The code is waiting for the LED light property to _change_ in value, and when it does, it will need to change the LED brightness indicator in the UI. Note that it is using the distinctUntilChanged
modifier which ensures it won’t react unless the value has actually _changed_ as opposed to just being _set_.
Without ReactiveCocoa, the code would have to be restructured to use a delegate pattern or “KVO”:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html (which is very clumsy) to watch the value of the LEDBrightness
property. Worse, I would’ve had to create a variable to capture the prior state of the value to ensure that it wasn’t unnecessarily updating the UI.
h2. Resources
If you want to learn more about “ReactiveCocoa”:http://github.com/ReactiveCocoa/ReactiveCocoa here are list of resources I found helpful:
* “ReactiveCocoa Docs”:https://github.com/ReactiveCocoa/ReactiveCocoa/tree/master/Documentation
* “NSHipster blog post on ReactiveCocoa”:http://nshipster.com/reactivecocoa/
* “ReactiveCocoa GitHub page”:http://github.com/ReactiveCocoa/ReactiveCocoa
regarding this and KVO…
while KVO has many many issues, maintaining a separate variable to handle prior state is not one of them. You can pass old and new values to the observer… having access to both can enable complex processing not possible with the new value only… This is something that seems to be excluded by react which is a pity.