Android: factor out backend storage/api implementation so the library allows you to use whatever backend you want
Closed this issue · 6 comments
I just looked through this code, and the library here does not have the storage built-in. Instead, it calls the visitor interface for every observed or generated CEN. This makes it pretty easy to support multiple possible storage interfaces - we just have to implement a bridge library that implements the visitor and writes to the appropriate datastore.
Concretely, in the covidwatch-android code, BluetoothManager implements visitor interfaces and saves to the CovidWatchDatabase.
https://github.com/covid19risk/covidwatch-android/blob/82d26d726c083cebcd0d7951f5c1b0febc4fd999/app/src/main/java/org/covidwatch/android/ble/BluetoothManager.kt#L146
@Apisov @zssz @tzachari @freyley I am tempted to just close this - any app implementation that wants to use this can implement the visitor pattern and write to their own database. The only enhancement might be to pull out the CovidWatchDatabase into its own library, but I am not sure that is worth it.
Thoughts?
@shankari That seems entirely reasonable - maybe worth a short addition to the README about how to do so?
The library should be agnostic to the storage. In the develop version we have the Visitor class but it might change in the future, nevertheless, it always will be some kind of API that will allow library's clients to implement their own storage.