Extract session ordinal logic to preference service #81
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
Extracts the business logic for incrementing the session number to the preference service. This means
SessionHandler
no longer needs knowledge about how the ordinal is calculated.As far as the session number calculation goes, I think the implementation should be thread-safe. Starting a session is always synchronised with a lock, and that's the only place the function is called. Flushing the change to shared preferences is done using
apply()
which is async, but internally within the OS implementation the change is kept in an in-memory hashmap. The only two scenarios where the ordinal won't be incremented is if I/O fails before the process can terminate (e.g. due to a race), or if storage is wiped by a user (in which case a new device ID/ordinal is created).Testing
Updated unit test coverage.