add method getStream for StoreGetInterface

[ulx]

If you created method "login", use "final Observable networkRequestStatusObservable =
networkRequestStatusStore
.getOnceAndStream(GitHubRepositorySearchFetcher.getUniqueId(searchString).hashCode())
.filter(NetworkRequestStatus::isSome);"

Method "getOnceAndStream" return 200 with latest request.
It is wrong.
I think that " networkRequestStatusStore.getOnceAndStream" must replace for "networkRequestStatusStore.getStream"

[apoi]

I understand the problem, but I don't think this is the correct way to solve it: in case a second request for the same item would be made when the first one is still in progress, the second request would not receive the current state of the request. The state would be emitted only after the next status change.

Not sure yet what would be a good fix for this issue...

[ulx]

@apoi
2 request not send, until 1 request not complite(exist in map).
I recive state 1 request.
Can you show me test or example, if I am wrong?

[apoi]

@ulx, this is the scenario:

1. Subscribe to fetchAndGetGitHubRepositorySearch()
2. Wait until it emits NETWORK_STATUS_ONGOING
3. Subscribe to fetchAndGetGitHubRepositorySearch() a second time

The second call would never receive NETWORK_STATUS_ONGOING because getStream only emits future values. Currently we use getOnceAndStream, so the current value (NETWORK_STATUS_ONGOING) will be emitted immediately.

A good fix for this requires a bit more work, but I'll see to it.

[apoi]

First idea for this was to delete the network status entry from the store upon completion. This would mean that when starting a new request, the old status wouldn't be in the database any more and so the wrong status wouldn't be emitted. PR #155 is groundwork for this, as we didn't previously have a delete operation at all.

This has a potential for race condition on update/delete in case a new request manages to start just after the previous request was completed, and before the status row was deleted. I don't think this scenario too likely, but it could potentially lead to a duplicated request. Let's see how it turns out.

[ulx]

Ok