Sync in background

I setup Joplin for Android for a new phone and a lot of data has to be synced, so ideally Joplin would to that in the background. When I click on "Battery Usage" it shows Screen time: 47 minutes for Joplin but no background time while it for example shows for Oura "Screen time: 11 minutes Background 25 min". To me that sounds like Joplin does not work in the background to do it's syncing.

Maybe, the sync work is not be doing in an Android Service (which can work in the background) but an Android Activity (which does nothing when it's not on the screen)?

3 Likes

Joplin mobile apps don't support background sync yet. If you want more info, I'd suggest finding the many background sync threads already on the forum. As far as workarounds go:

1 Like

That thread you linked suggests that the developers don't know what they are doing.

android - How to keep the application running in background react native - Stack Overflow gives various options of how you can do background tasks in Android in ReactNative.

I believe that none of those in the thread are Joplin contributors.

graphit0 seems to suggest that this is a priority issue which seems to be misinformation.

There's currently an open Github ticket which got relatively little attention and is not a high-priority ticket.

It's high priority, but the solutions we tried so far didn't work out unfortunately.

3 Likes

background sync on mobile devices · Issue #3872 · laurent22/joplin · GitHub did add background search and could have been integrated even if it's not perfect.

With that solution, you have two remaining issues:
(1) Doing the initial sync that might take hours in the background.
(2) Background tasks that are scheduled at a frequency of every 15 minutes are only allowed to run that often if the user opens the app.
(3) Handle the case of what the app does when a background sync is in progress when the user opens the app.

You can solve the first issue by putting up a notification on Android. As long as an app shows a notification to tell the user that it's doing work in the background it's allowed to run in the background.

On Android the second issue is a mix of informing the user, that Android might reduce the frequency of the syncs, and if the user wants to prevent that they can turn off battery optimization for Joplin.

The third issue is just a matter of writing code. No rocket science.

I'm an Android dev so I don't know about how far you could get on iOS but even if the feature isn't perfect on iOS it's likely still an improvement over the status quo.

As far as people complaining about sync not being perfect, they are already complaining about sync not being perfect and expect it to sync in the background whether or not rudimentary background sync is available.

If it's high-priority, what's stopping it from being implemented on Android?

Rephrasing point stated before

Why not just ship cheap and dirty flaky background sync on ReactNative?

Let me state clearly that I feel your pain and frustration. However, we must consider the open source nature of Joplin. All flakiness, user support and maintenance burden will lie entirely on maintainer and community. All lost data will be permanently tied to Joplin reputation, not the contributor who submitted the PR.

Once again I want to say that we, as a community, see and know the problem -- we respond to user support requests popping up weekly. This is unfortunate situation for both devs and users. However, this is the path Joplin team decided is best. As a fellow developer you, @ChristianKl, might have your own tough decisions made out of necessity which had to sticked to and I hope you could empathize with this one.

Leaving things on more productive note in my mind background sync could be best achieved by completing the prerequisite standalone sync API which was proposed in past GSoC

Additionally in this post I linked what implementations were already developed which hopefully could be of use to potential contributors


Yet another project of note is Joplin with background sync service by @Chen

P.S. if there's something in this post that seems misleading or false, please let me know

2 Likes

If you're an Android dev we would definitely welcome a pull request from you.

In fact I am not an Android developer but I saw the mess that React Native can be in some conditions. What I suspect is that with background sync we might end up with two instances of Joplin running in parallel and trying to sync at the same time which will result in data loss. Or maybe not, I'm not an Android developer after all. It seems there are lots of people who know a lot of things, but the problem is who has the time to write this code and maintain it - provide support, sometimes urgently, when it breaks and we need to release a new version.

2 Likes

I have done Android and Flutter but I have not worked with ReactNative before.

What I suspect is that with background sync we might end up with two instances of Joplin running in parallel and trying to sync at the same time which will result in data loss.

The word "instance" doesn't translate that well into Android. In Android, you have an app and within an app you have services and activities. Services are background processes and activities are foreground processes. In good old Android whenever the user switches the screen the user switches to a different Activity.

I would expect that if the user open Joplin (an Activity) while the background process (an Service) is going on both run in parallel but are one app.

To prevent conflicts with synchronization, there are two ways to deal with it. Joplin currently does sync-locks.The sync-lock could specify whether it's a background or foreground sync-lock. That way when a background sync process happens, Joplin does not start a foreground sync process in parallel.

The other more clean (and more Android specific) solution would be that the synchronization is always done by the Service and not by the Activity and when the Activity starts the Activity sends an message to the Service to start syncing and the Service just continues syncing when it already syncs.

It seems like @Chen already did some work, so maybe it will lead to a satisfactory solution.

1 Like

There's very little relation between the two, so don't get your hopes too high

1 Like