DB Sync loading.

[Waleedasim]

Please read these guidelines before opening an issue.

Bug Description

I need to know, can we show loading while sync db in android? for example 10% 20% 30% etc. This feature already had in IOS but not in android, any ETA for this feature? or you can guide me so i can do it by myself?

1. Steps to reproduce and the simplest code sample possible to demonstrate the issue

There are no issues

2. What you expected to happen

3. What actually happened

Environment details

[ricellis]

can we show loading while sync db in android?

Not really. The changes are fetched in batches hence the number of further changes pending is unknown. Even if you knew how many changes there were in total, that number could change before the replication reached the last batch due to further changes on the server. So it's not really possible to calculate a percentage complete.

This feature already had in IOS but not in android, any ETA for this feature?

This isn't a feature of cloudant/CDTDatastore for iOS either, see:

• https://github.com/cloudant/CDTDatastore/issues/416
• https://github.com/cloudant/CDTDatastore/issues/446

The same limitation applies there - the only difference is that in CDTDatastore a delegate block can get a callback after each batch or so.

or you can guide me so i can do it by myself?

Are you looking for similar functionality to CDTDatastore's delegate block?

If so then I think the equivalent in sync-android would be creating a new event type e.g. ReplicationProgressed to get a callback after each batch was processed. That would need to be "mirrored" by an internal ReplicationStrategyProgressed type in a similar way to ReplicationCompleted/ReplicationStrategyCompleted. Let me know if you want to attempt a PR for that, otherwise we'll put this on our backlog and prioritise it in due course.

[Waleedasim]

Thank you for the detailed answer. i want to know can we detect changes from server like full batch need to update or not?

[ricellis]

can we detect changes from server like full batch need to update or not?

I'm not sure I fully understand the question. The process of replication identifies whether changes from the source already exist locally or not and hence what updates need to be made - this happens for each batch of changes. It's like this in the simplest form:

• Start a replication
• Get the last since value from the checkpoint
• Ask the source for batches of new changes since the last checkpoint
• For each batch of changes check if the revisions already exist in the local datastore
• If they don't then add them to a batch and fetch them from the source and insert them into the target
• Update the checkpoint
• Repeat until there are no more changes from the server or the replication is stopped

There are info level logging events from:

• the start of replication
• the start of each batch with the number of changes processed so far during the replication
• the number of changes in the batch
• the end of the batch with the time taken and the number of changes processed from the batch
• the end of replication with the total time taken and changes processed

Besides that logging the in-progress state of the replication is not exposed except via com.cloudant.sync.replication.Replicator#getState (PENDING, STARTED etc) and the events fired for ReplicationCompleted (which includes the total number of batches and documents replicated) and ReplicationErrored (which includes any error that occurred).

Are you asking for information at the level of how many missing revisions are going to be fetched per batch? If so I think that would need even more events than proposed above.

[Waleedasim]

Are you asking for information at the level of how many missing revisions are going to be fetched per batch? basically i am asking how many missing revisions are going to be fetched for all batches?

[ricellis]

how many missing revisions are going to be fetched for all batches?

It's not knowable in the current architecture because of the way the changes feed is processed in batches. The only way to know that would be to process the entire changes feed and calculate the revs_diff upfront, but that would be much more inefficient because:

1. the memory usage would be dramatically increased
2. reduced fault tolerance
3. resuming replications after errors would require re-doing a lot more work

Also replications would potentially complete without actually reaching the same state as the source (because more changes could be introduced in the source while all the processing and fetching was happening). If one were to account for that by looking for more changes then the original report of how many missing revisions would be fetched would be wrong anyway, which sort of defeats the purpose.

If we added additional events that provided the missing revs per batch, then you could potentially emulate the behaviour you desire by setting com.cloudant.sync.replication.ReplicatorBuilder.Pull#changeLimitPerBatch to some massive number such that you effectively do the entire replication in one large batch (assuming no source changes), but I would advise against it for the reasons outlined here.