Reactivecocoa Introduction (i)

Basic methods of Reactivecocoa use

Reactivecocoa is a project on GitHub that was open source last year and is the implementation of FRP on the iOS platform. The core of the FRP is the signal, which is represented by the racsignal in the Reactivecocoa (hereinafter referred to as RAC), which is a data stream that can be bound and passed. Can think of the signal as a faucet, but the inside is not water, but the glass ball (value), the diameter of the same as the water pipe, so that the glass ball is arranged in order, there will be no side of the situation (data are linear processing, there will be no concurrency). The tap switch is off by default and will not open unless the receiver (subscriber) is available. So as soon as a new glass ball comes in, it is automatically transmitted to the receiver. Can add a filter on the faucet, does not conform to pass, can also add a change device, the ball to meet their own needs (map). You can also combine multiple taps into a new faucet (combinelatest:reduce:) so as long as one of the taps has a glass ball coming out, this new combined faucet will get the ball.

First look at a small example

[Self.input.rac_textSignal subscribenext:^ (ID x) {  NSLog (@ "%@", x);}];

After this code, as long as the value in your TextField is changed. can be printed out. The ability to implement KVO has been reduced by countless code. Embodies the bindings and responses.

On the basis of this code we can also filter, the following is a second example:

[[Self.input.rac_textsignalfilter:^bool (id value) {   nsstring*text = value;   return text.length > 3;}] subscribenext:^ (id x) {   NSLog (@ "%@", x);  }];

Compile and run, you can only enter characters in TextField, you will find that the printout will only be available if the input is more than 3 characters.

Each operation of the racsignal will return a racsignal, which is called a coherent interface (fluent interface) in terms. This feature allows you to build pipelines directly without using local variables at every step.

In the above code, the comment section marks the implicit conversion of the ID to NSString, which does not look very good. Fortunately, the value of the incoming block is definitely a nsstring, so you can modify the parameter type directly:

[[Self.input.rac_textSignal  Filter:^bool (nsstring*text) {    return text.length > 3;  }]  subscribenext:^ (id x) {    NSLog (@ "%@", x);  }];

The first example is simply that all changes will respond to. But demand may only need to respond to some of the situation. Filter is used at this time. The case where the block of filter returns Yes is the one that needs to be triggered. Others will not return.

Combination

This is a picture of Leezhong.

After verifying that each value entered conforms to the criteria, the button is clicked.

RAC (self, self.btn.enabled) = [Racsignal combinelatest:@[self.usernametext.rac_textsignal, Self.passwordText.rac_ Textsignal]reduce:^id (NSString *username, NSString *password) {return @ (username.length >= 6 && Password.length >= 6);}];

This code binds usernametext and Passwordtext signals together for reduce processing, and returns a bool value to bind to self.btn.enabled.

Summarize

The above is only the simplest use of Reactivecocoa, their own understanding is not very deep, so I will always devote time to Reactivecocoa to learn and use.

Last quote Leezhong said a sentence

RAC unifies the processing of KVO, UI Event, Network request, and Async work because they are essentially changes in value (values over time).

Reactivecocoa Introduction (i)