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.

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

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

@anchita-g

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.

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

@ndegwamartin

Could you provide more details on what information is expected in the SquashedLocalChange class?
We could consider including the following:

• Resource type
• resource ID
• The total count of local changes per resource
• A list of local change IDs for each resource
• The count of changes per operation type (e.g., Insert, Update, Delete)

Not sure if the following should be included :

• Local changes per resource type (which could be fetched separately by the application)
• Local changes per operation type and resource type (which can also be fetched separately using change IDs)

@santosh-pingle yeah I think we can enhance the returned results with all the above, but at the very basic level, at least for our use case we just needed the map of Resource type to the grouped(by resourced id) count of all local changes. That is for example, if the same Patient Resource has multiple updates it will show up as one unsynced Patient resource.