Remember my iOS Model-View-Controller TDD screencast? Eric Baker took it a few extra steps with his own follow-up screencast, demonstrating:
- ReactiveCocoa to use functional reactive programming instead of having the Model post notifications which the Controller observes
- Kiwi as the unit testing framework
- AppCode as the IDE
There’s a lot of interesting stuff here. But I also want to acknowledge that this screencast changed my mind about dot notation. Yes, really!
What are your thoughts about ReactiveCocoa, Kiwi, or AppCode? Leave a comment below.
@jon: just started watching this. Very interested to see someone use ReactiveCocoa. Do offer your thoughts. Tool-talk is a kind of guilty pleasure for most devs, I think.
“I thought about posting my thoughts about the tools Eric demonstrates… but I didn’t want to dominate the conversation. What do you think?”
Of course you should post your thoughts. It’s always good to have more than one opinion.
Thanks for a great blog. You’ve really inspired me to down the TTD route!
/Mikael
Oh, and thanks to Eric Baker. Nice screencast. Will have to give Reactive Cocoa a try on a side project when time allows.
Thanks for sharing this. I also, for the first time, find the usage of dot-notation much simpler and cleaner than non-dot-notation. Looking forward to your post about this topic.
I’ve added the post about changing my mind about dot-notation — enjoy.
Good stuff.
I think what I’ve taken away from that video is that I want to use ReactiveCocoa.
I’ll not use it for my current app under work (which is going to be my first App Store submission).
But I plan on using it for my second.
Regarding the whole dot notation thing. I was already using it for properties getting/setting (guess it’s my Java background) as I found it personally more readable.
The direct ivar references were the most readable syntax, but given the lack of KVO there… dot notation is the way to go for me.
My last comment. I really want to like AppCode (I’m a user of IntelliJ and RubyMine), but I just keep going back to XCode. I think the problem is, AppCode seems to be playing catchup all the time whenever XCode changes, from a point of view of supporting stuff that Apple changes.
(IntelliJ and RubyMine is less affected my third party changes).
For example, how well is AppCode playing with XCode5/iOS7 at the moment?
Thanks Eric and Jon. Good stuff.
@Gavin: the current AppCode EAP works pretty well with Xcode 5. There are a few spurious error messages here and there, and simulator launching is intermittently a bit flaky. JetBrains’ openness about the problems that do exist is a very pleasant contrast to dealing with Apple.
When I first used AppCode I was concerned about exactly this problem, thinking that Apple would constantly shift the bar, and JetBrains would have trouble keeping up. But I haven’t really found that to be the case. They jump on incompatibilities, even with betas, remarkably quickly. About the longest lag I’ve noticed was with being about to use XCTest targets, and that was hardly a big problem (ie. because XCTest doesn’t add anything useful as yet).
OTOH, Xcode is playing catchup with AppCode as regards basic editing facilities, not always very convincingly. Its new test runner is getting there. Amazing though that its still as primitive as it is as regards refactoring, codebase navigating, code generation etc.