ReactiveCocoa Tutorial – The Definitive Introduction: Part 1/2

Get to grips with ReactiveCocoa in this 2-part tutorial series. Put the paradigms to one-side, and understand the practical value with work-through examples. By Colin Eberhardt.

Leave a rating/review
Save for later
Share
You are currently viewing page 4 of 4 of this article. Click here to view the first page.

Adding side-effects

Replace the current pipeline with the following:

[[[[self.signInButton
   rac_signalForControlEvents:UIControlEventTouchUpInside]
   doNext:^(id x) {
     self.signInButton.enabled = NO;
     self.signInFailureText.hidden = YES;
   }]
   flattenMap:^id(id x) {
     return [self signInSignal];
   }]
   subscribeNext:^(NSNumber *signedIn) {
     self.signInButton.enabled = YES;
     BOOL success = [signedIn boolValue];
     self.signInFailureText.hidden = success;
     if (success) {
       [self performSegueWithIdentifier:@"signInSuccess" sender:self];
     }
   }];

You can see how the above adds a doNext: step to the pipeline immediately after button touch event creation. Notice that the doNext: block does not return a value, because it’s a side-effect; it leaves the event itself unchanged.

The doNext: block above sets the button enabled property to NO, and hides the failure text. Whilst the subscribeNext: block re-enables the button, and either displays or hides the failure text based on the result of the sign-in.

It’s time to update the pipeline diagram to include this side effect. Bask in all it’s glory:

SideEffects

Build and run the application to confirm the Sign In button enables and disables as expected.

And with that, your work is done – the application is now fully reactive. Woot!

If you got lost along the way, you can download the final project (complete with dependencies), or you can obtain the code from GitHub, where there is a commit to match each build and run step in this tutorial.

Note: Disabling buttons while some asynchronous activity is underway is a common problem, and once again ReactiveCocoa is all over this little snafu. The RACCommand encapsulates this concept, and has an enabled signal that allows you to wire up the enabled property of a button to a signal. You might want to give the class a try.

Conclusions

Hopefully this tutorial has given you a good foundation that will help you when starting to use ReactiveCocoa in your own applications. It can take a bit of practice to get used to the concepts, but like any language or program, once you get the hang of it it’s really quite simple. At the very core of ReactiveCocoa are signals, which are nothing more than streams of events. What could be simpler than that?

With ReactiveCocoa one of the interesting things I have found is there are numerous ways in which you can solve the same problem. You might want to experiment with this application, and adjust the signals and pipelines to change the way they split and combine.

It’s worth considering that the main goal of ReactiveCocoa is to make your code cleaner and easier to understand. Personally I find it easier to understand what an application does if its logic is represented as clear pipelines, using the fluent syntax.

In the second part of this tutorial series you’ll learn about more advanced subjects such as error handing and how to manage code that executes on different threads. Until then, have fun experimenting!

Colin Eberhardt

Contributors

Colin Eberhardt

Author

Over 300 content creators. Join our team.