Reactive Android Development CS 4593-02T & CS 5463-01T Summer 2016 More Sodium FRP

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)

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

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.

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>)

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.

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.

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.

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

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

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.

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!

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.