1. Reactive Android Development
CS T & CS T
Summer 2016
More Sodium FRP

2. More about merge Simultaneous Events! For streams S1 and S2
S1.orEsle(S2)
S1 takes precedence if S1 and S2 are simultaneous
S1.merge(s2,combining_function)
The stream produces an event with value combining_function(S1,S2)

3. Value Loops Sometimes a Value must be defined in terms of itself
An accumulator is a simple example
For(Integer change : changes) {
acc += change; }

4. Value Loops
This is a bit of a problem for Sodium (at least for reactive graphs built in Java)
Sodium Cells and Streams can only be defined once, but you need the before the definition in order to create the definition.

5. Value Loops To get around this, Sodium provides two 'placeholders'
CellLoop
StreamLoop
The constructor for each is just empty
It's just a promise that the loop will be closed in the future
The CellLoop or StreamLoop can then be used as an input to map, lift, snapshot, and merge as usual.
The final definition takes place in
<ValueLoopVar>.loop( <definition>)

6. Value Loop
Between the time that you start using the loop and the call to <Var>.loop(…) the reactive graph is in a precarious state.
The connections haven't really been made properly yet
To protect against this, all of those operations must take place within a single transaction
Sodium will throw an exception if you try to do otherwise.

7. Transaction
Every change to a sodium value (Cell or Stream) takes place within a transaction
Most of the time it is created automatically
Snapshots of Cells yield the value before the transaction.

8. Switch
One of the advantages that I claimed about FRP is that each cell or stream is declared only once.
This can greatly improve the clarity of the design.
My Claim: Once you are used to reading FRP code, understanding the behavior of someone else's code is simpler with FRP than is usually the case.

9. Switch However, this limits your program to having a fixed structure
Number of "objects"
Number of inputs
Etc.

10. Switch Provides a compromise
The definition of a cell can be changed by defining it as a switch on an input made up of cells
The cell is still defined only once and it is clear that its meaning can change
The code that can change its meaning is limited to that used in its definition

11. Inputs and Outputs
The FRP book waits until chapter eight to tell you how to send input into your sodium graph
This is because the author wants the reader to think declaratively
But interacting with the outside world requires us to lose some of that purity.

12. StreamSink/CellSink
Provide a way for imperative code to send events or values into the reactive graph.
Can not be called from within a transaction!
NO CHEATING!

13. Listen Cells and Streams can be "listened to"
You provide a handler and update the rest of your program with the results of your sodium calculation.