Peter Serwylo 10ccd5c503 Reimplement "peer finder" logic using funcitonal ReactiveX style.
The benefits of this are as follows:

No longer need to worry about how many types of `Peer`s exist.
There is a single publicly accessible `PeerFinder` which aggregates
the results of both the Bluetooth and Bonjour peer finders. In the
future if another is added, the consumer of the peer finder
(i.e. `StartSwapView`) doesn't need to be aware of this. Neither does
the `SwapService` or `SwapActivity` or any other code.

Never ask "Are we searching" but instead receive push notifications
from the peer finder when it stops searching.

Don't worry about receiving the same peer multiple times, it will
automatically get filtered out.

Less concern about doing things in `AsyncTasks` (and knowing what to
do in an `AsyncTask`). The RXJava + RXAndroid libraries deal with this
by allowing the client consuming the `PeerFinder` to specify which
thread to perform the background task on, and also that the found
`Peer`s should be emitted on the UI thread.

In the future, can play with caching the results of a particular
sequence of found peers. However right now using the `Observable.cache()`
method means we can no longer unsubscribe from the peer finders
and thus they run longer than they need to when we move on from
the initial swap screen.
2016-02-05 15:39:40 +11:00
..
2015-10-04 08:14:48 -07:00
2016-02-01 12:23:04 +00:00