API access for data in the LocalChangeEntity table

[ndegwamartin]

Is your feature request related to a problem? Please describe.
Currently there's no API to access data in the LocalChangeEntity table

Describe the solution you'd like
In the client app we'd like a way to obtain Read Only access to the LocalChangeEntity table data, specifically the SquashedLocalChanges.

We can add an interface in FhirEngine.kt and the corresponding implementation in FhirEngineImpl.kt

//FhirEngine.kt
suspend fun getUnsyncedLocalChanges(): List<SquashedLocalChange>

//FhirEngineImpl.kt
override suspend fun getUnsyncedLocalChanges() : List<SquashedLocalChange> = database.getAllLocalChanges()

Describe alternatives you've considered
Might be better to have an API that just returns the counts for the grouped changes per resource because if there's too much data in the LocalChangeEntity table it may lead performance issues since obtaining the counts with the above approach is an in memory operation.

Additional context
This will be useful when one wants have the visibility of the Synced/Unsynced resources on the device.

Here is a sample of what can be achieved by this:

Would you like to work on the issue?
Yes

[jingtang10]

Thanks for raising this. Haven't thought about this carefully, but is it possible at all to reuse the syncUpload API for this purpose? Maybe we could change the API so that if no result is returned from the lambda we do not delete the local changes from the local changes table - so that esesentially you're using that API to read local changes.

[ndegwamartin]

It is worth noting that the above functionality/implementation renders the dialog based on a user action rather than at the end of a Sync job

[ndegwamartin]

Additional note, we may need to refactor Database.getAllLocalChanges() API for optimisation since it reads all the records into memory before performing the squash operation and returning the results.

For a case where an application using the SDK is offline first, they might have collected a lot of data in the field and its months before they can get a working internet connection to sync upward to the server.

This might require a new ticket but is worth highlighting here cc @jingtang10

[jingtang10]

@anchita-g

[jingtang10]

as of the latest design changes in the sync module, we will be deprecating syncUpload and syncDownload methods. the normal sync APIs will still be functioning as usual but we have concluded the syncUpload and syndDownload APIs are not utilised by developers and are overly complex. this actually means we do need to provide sufficient capabilities to manage local changes. so we need to work on this more.