I've recently developed a renewed interest in iOS development particularly because of ReactiveCocoa. The idea of declaratively describing the intent of an action, rather than how it should work, has helped things "click" for me and I'm looking forward to using FRP and ReactiveCocoa in building a few personal iOS projects. I'm continuing to read more about it and this post was very helpful, thanks for sharing. I have a couple additional questions for any seasoned iOS / ReactiveCocoa / FRP devs that would definitely help me along as I progress:
1) Are there any performance gotchas or things to look out for when embracing ReactiveCocoa? One thing thats stuck with me as I read is making sure to understand and keep and eye on memory management, even after embracing ARC. Is debugging ReactiveCocoa code any different than the normal imperative way?
2) What parts of an app shouldn't be handled with FRP? Should everything fit into the framework or is a code smell to handle things both ways?
3) I'm a Ruby Dev and I'm looking hard at RubyMotion as a good toolchain for iOS Dev. It looks like ReactiveCocoa and Rubymotion can play well together[1], but is this a hack? Is there any issue with using Rubymotion and ReactiveCocoa together. Seems like a great fit, but perhaps my inexperience isn't aware of a deeper issue.
I'm not crazy about referencing self within the block to create changes. On OS X, NSObject supports keypath-to-keypath bindings, which can be processed with NSValueTransformer (a relic of the pre-blocks era, I suppose). Something like that, using blocks instead of value transformers would keep the processing functions pure (transformation functions, then) would be ideal, I think.
I use ReactiveCocoa very heavily at work, and find it very useful. Just want to avoid confusing the terminology with an existing concept which is well-defined and totally different.
I'm a fan of having unit tests with apps (maybe not full-on TDD but still). How would you create a unit test for something like this? Got any examples?
1) Are there any performance gotchas or things to look out for when embracing ReactiveCocoa? One thing thats stuck with me as I read is making sure to understand and keep and eye on memory management, even after embracing ARC. Is debugging ReactiveCocoa code any different than the normal imperative way?
2) What parts of an app shouldn't be handled with FRP? Should everything fit into the framework or is a code smell to handle things both ways?
3) I'm a Ruby Dev and I'm looking hard at RubyMotion as a good toolchain for iOS Dev. It looks like ReactiveCocoa and Rubymotion can play well together[1], but is this a hack? Is there any issue with using Rubymotion and ReactiveCocoa together. Seems like a great fit, but perhaps my inexperience isn't aware of a deeper issue.
[1] http://spin.atomicobject.com/2013/06/18/reactivecocoa-rubymo...