The native Android app does not sync when backgrounded, so you must leave the app open until syncing completes (this is the reason I added custom CSS to display the sync status on the main screen). This means you now have to wait 15s before you can close/switch apps after making changes in Dynalist, which is a major pain. If you background the app (e.g. switch apps), it will only sync after you reopen the app. If you use Dynalist in Android Chrome it will sync in the background, oddly enough. See this screen capture for a demonstration of this: https://streamable.com/2uwwzn
Why donāt you use Dynalist in Android Chrome rather than the native app, since that syncs in background?
I would prefer to use a dedicated native app
The native app seems to scroll smoother on large documents.
Thereās currently a major bug when using Dynalist in Android Chrome, where adding a new item causes Chrome to crash, making it completely unusable right now: Creating new item on Android Chrome crashes Chrome this has been resolved!
Is it still consistently happening? I feel like youāre running into one of those DB surges, since I donāt think weāve adjusted the sync algorithm recently.
Yeah this seems to be happening pretty consistently. Iāve timed it a few times throughout the day today and it always takes between 14-17 seconds to sync. ~15s seems like a pretty high request p50 latency (or even p90, p99) for a simple single character letter write request.
ā¦since I donāt think weāve adjusted the sync algorithm recently.
Just want to point out the last Android app version was from November 2020, so any changes to the syncing algorithm in the last six months would be new relative to the latest Android app.
I want to point out that I think Iām seeing something similar on the web client as well, but I might not have noticed it previously since Chrome tabs can sync when backgrounded. After I make an edit the sync status changes to Sync now and when I look at the dev tools network tab nothing is being sent by the client. Then after ~15 seconds update and bundle_binary requests go out and it moves to synced very quickly after that. However, since the network tab canāt monitor socket connections maybe thereās some other communication going on that I canāt see.
Iām curious how much of the latency is coming from the request itself and how much is from the client āwaitingā before sending out the update (maybe it has a periodic sync interval, or tries to optimistically wait to coalesce multiple writes into a single payload?).
Actually yeah youāre right, seems like I did touch a few timers when we had to optimize some of the sync issues about 2 months ago. The delay mostly come from the waiting on the client - the network side seems just fine. I can repro this delay on my dev setup as well.
I will try some tweaks to improve this, sorry about that!
Ok, I have an effective patch that reverts the sync timing back down to what it was before. Will be deployed in a few days with our end-of-month patches together.
Since this is really only a usability issue on the Android native app it would be great if the Google Play Store update for this version can be posted pretty quickly after release. Sometimes thereās a pretty long delay before the Android update goes out, so just want to make sure thatās on the radar for this particular release.