Currently, attachment download behavior on mobile and desktop defaults to "always".
As such, users doing an initial sync with the default settings download all attachments. This can make initial sync very slow, particularly if end-to-end encryption is enabled and there are many/large attachments.
Would it make sense to make this setting default to "Automatic" instead of "Always" on mobile?
When setting up an initial sync on mobile, users are directed to "Configuration/Synchronisation". While "Attachment download behavior" is shown just below "Synchronisation target", there are also many other settings.
Possible issues with defaulting to "Always"
It makes initial sync slower and Joplin mobile has no background sync.
To my knowledge, there is no way to remove unnecessary attachments from the device without reinstalling the app (and choosing a separate download behavior). (Related forum post).
Possible issue(s) with defaulting to "Automatic"
A user may quickly set up sync on a new device (i.e. changing the minimum possible settings) and assume that all attachments are downloaded to the device. (And, for example, then try to use Joplin on a metered connection or without internet).
The root cause of this and many other problems, I'm afraid. I'm not a dev, but I wonder if every app built with React Native is absolutely unable to perform background syncing.
But does it really make sync slower? Because downloading resources happens in parallel to sync, from a separate service, and can continue once sync is finished.
If it really makes sync slower maybe we can throttle that service while sync is running.
Currently, decryption happens on the main thread. As such, downloading resources in parallel gives the DecryptionWorker more to decrypt (and thus decryption of everything may be slower).
I also suspect that downloading resources in parallel to notes/notebooks makes downloading sync slower because of rate limiting.
Another option would be to sync notes and notebooks first, then resources. (Though if a user opens a just-decrypted note, perhaps its resources could be downloaded sooner.)
But does it really make sync slower?
I'm currently testing this.
Without resources, a full sync (iOS/OneDrive/E2EE) takes roughly 6 minutes.
With resources, a sync of all notes takes roughly 8 minutes. Resources continue to download after that however (still downloading 25 minutes later).
So it seems that sync times are similar.
A note on background sync
There is at least one library available that may do background sync (or something similar):
I wasn't able to get it to start a background task though (perhaps the version of the library I was using wasn't compatible with the version of React Native Joplin uses?).
A while back, there was also a pull request that implemented background sync natively, though just for Android.
The difficulties here are:
Running a task in the background.
If background sync runs at the same time as the main application, it could cause data corruption (Joplin makes the assumption that only one instance of the application is running at a time).
Thus, also canceling the background sync task when Joplin comes to the foreground and resuming it/starting a new one when Joplin goes to the background.
There seems to be a library available from the same project that prevents the screen from sleeping:
Thus, a simpler alternative could be to have an "initial sync" screen that keeps the screen on.
A common complaint seems to be that notebooks/tags don't show up near the beginning of the sync process.
It might alternatively make sense to only download notebooks on an initial sync with default settings. Navigating to a notebook could then download notes within that notebook.
Thanks a lot for explaining the implications of mobile background sync within the given framework. For my use case, creating, fetching and decrypting is fast enough, even if OneDrive as a target is deemed to be slow according to most comments here.
It's the behaviour of the app (desktop and mobile alike) after start that's troubling me (on mobile only): The sync wheel symbol always keeps on spinning for 30 to 50 seconds before there's any indication such as "fetched" or something similar. That's a test of patience which background sync would help to alleviate.
Maybe it's just the OneDrive API that causes "acquiring locks" to take so long (if that's the correct term), so I'd be very interested to hear from users with other sync targets: Is a sync wheel spinning for 30 to 50 seconds right after starting the app (before any status message is displayed) expected behaviour?
I disabled delta sync for OneDrive at some point because Microsoft broke it (it was making many clients, not just Joplin, go into some kind of infinite sync loop). OneDrive seems to be more stable lately so maybe we can enable it again.
Without delta sync, the client is comparing all local items to all remote items to find the differences, so if you have many notes it can take a long time.
I've just tried setting up a new Android device and it looks like this sync change didn't help much in this case. The bottleneck is probably elsewhere in Android, it's just so slow to create notes.
Maybe E2EE running in parallel, or downloading the resources but I'm not sure. It would be good to investigate this and find out what makes it so slow
