Improve automatic synchronization process

[przybylski]

Currently time between synchronization is constant and is equal to 3h. Let's give users freedom to specify the time between synchronizations.

[tobiasKaminsky]

Great idea!
To avoid user complaining that syncing is too often we should limit to a minimum of 60 minutes?

[AndyScherzinger]

Also think this is a good idea and yes 60 minutes being the absolute lowest end configurable is the right thing to do.

What do you think @jancborchardt from a UX perspective. ATM the preference would end up in the Details section.

[przybylski]

Personally I wouldn't restrict users to set any non negative value they want. But if I get outvoted I'll change it

[tobiasKaminsky]

Or we could show a little warning/info that a value <60 could be battery consumption.

[jancborchardt]

Hm, a custom setting like that seems strange. Is there no more intelligent way to solve this without people needing to fiddle with settings. Cause if people change it and are still unhappy with the results, people will feel stupid or frustrated. If the setting is not there in the first place, that’s less likely.

[przybylski]

So, drop?

[tobiasKaminsky]

The more "intelligent" approach is maybe the best way to go?
So to get a better understanding: why is it fixed to 3h? A balance between battery consumption and update frequency?
Maybe something like:

• measure sync process
• if > x minutes then +1h pause otherwise decrease sync time

[b1ggjoe]

Is there a way to offer a choice? For Example:

Sync Frequency:

• Instant
• Every 5 Minutes
• Every 15 Minutes
• Every 30 Minutes
• Every Hour

With another option for 'Manual' sync on demand?

J.

On Tuesday, June 14, 2016, Tobias Kaminsky notifications@github.com wrote:

The more "intelligent" approach is maybe the best way to go?
So to get a better understanding: why is it fixed to 3h? A balance between
battery consumption and update frequency?
Maybe something like:

• measure sync process
• if > x minutes then +1h pause otherwise decrease sync time

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ALfB7z_b5TckoB5HMtQTxqZxOl_SM50yks5qLwbygaJpZM4IzfxQ
.

[przybylski]

Instant as in? generally modified files should be uploaded to server but I am not sure how this function evolved over the time.
For more intelligent way. there is a lot of approaches which can be taken, from probing, not syncing when user is sleeping, etc.
There are a lot of paths to explore.

Why it was 3hrs? Random number :P i didn't give too much thinking when setting the sync time gap for 3h.

[ghost]

The choice should be given imho.
A simple warning that setting it too low could cause battery drain should be enough, users will be smart enough not to set it too low.

[jancborchardt]

@tobiasKaminsky yes, I’d prefer we go for a more intelligent approach. This is exactly details that the app should take care of and no user should need to fiddle with. :)

[tobiasKaminsky]

But currently I am cluless how we can implement such an intelligent mechanism.

[AndyScherzinger]

There would have to be a more or less smart algorithm taking the files changed frequency into account. In case at least one files change is tracked within an hour the sync can happen every hour, if files change less frequently raise the time between detected changes. This needs quite some change occurrence tracking.

[jancborchardt]

Would really be cool if we can have something like that, at least step by step. Because introducing a setting for it results in the 2 big problems which are always there on introducing settings for every little thing:

1. They obscure the other, actually important settings.
2. They are very difficult to remove once introduced and people will complain even if the new solution is better and more automatic.

[AndyScherzinger]

That's true but we would also have to think this through a little more even if we start step by step. So we need to have an answer how such an algorithm would play nicely with other sync relevant things like WiFi and Charging because having features like that for instant upload but then ignoring this for sync might confuse users.

[tobiasKaminsky]

How to deal with this?
To summarize, we want to have a (smart) approach and not have the user customize it.

@mario @AndyScherzinger @przybylski

[jancborchardt]

What’s the current state of this then? It should definitely not be a setting, yes.

[mario]

@jancborchardt no state. We can talk about it for 2.0. The entire sync stuff needs to be changed anyway - let's first get proper auto upload (new files), then proper synchronization of files/folders inside our directory and then we'll talk all the other details.

[codecov]

Codecov Report

Merging #4 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##             master      #4      +/-   ##
===========================================
- Coverage      6.49%   6.47%   -0.02%     
  Complexity        1       1              
===========================================
  Files           307     307              
  Lines         30075   30105      +30     
  Branches       4314    4318       +4     
===========================================
- Hits           1952    1950       -2     
- Misses        27831   27862      +31     
- Partials        292     293       +1

Impacted Files	Coverage Δ	Complexity Δ
.../com/owncloud/android/ui/activity/Preferences.java	0% <0%> (ø)	0 <0> (ø)	⬇️
.../owncloud/android/syncadapter/FileSyncAdapter.java	0% <0%> (ø)	0 <0> (ø)	⬇️
...in/java/com/owncloud/android/datamodel/OCFile.java	63.03% <0%> (-0.78%)	0% <0%> (ø)

[AndyScherzinger]

I did a (quite complex and time consuming) rebase of this PR to have it up to date with the master again for our toolchain.

We should though decide on what to do, since keeping very long living PRs alive it close to impossible and adds no value, plus for housekeeping reasons I also vote to delete any branch that won't be used in the next month, same for PRs.

What do you think folks?

[jancborchardt]

From the user perspective it’s still the same situation, as mentioned above and @tobiasKaminsky also mentioned, there should be a more intelligent approach to this than a setting. It’s too technical and sync frequency is really not something any user (however technical) should need to fiddle with.

Basically, we need to have a proper discussion and specification about this before a pull request.

[mario]

This is related to sync adapter I guess. I've always planned on removing it and syncing on demand WHEN needed instead (either in-jobs or when you visit a directory).

Sure, pre-fetching is sometimes good, but at the current state it sometimes works and sometimes doesn't which is quite bad for the user experience too.

[nextcloud-android-bot]

Lint

Type	Master	PR
Warnings	113	113
Errors

FindBugs (new)

Warning Type	Number
Bad practice Warnings	35
Correctness Warnings	167
Internationalization Warnings	14
Malicious code vulnerability Warnings	10
Multithreaded correctness Warnings	9
Performance Warnings	124
Security Warnings	202
Dodgy code Warnings	139
Total	700

FindBugs (master)

Warning Type	Number
Bad practice Warnings	35
Correctness Warnings	167
Internationalization Warnings	14
Malicious code vulnerability Warnings	10
Multithreaded correctness Warnings	9
Performance Warnings	124
Security Warnings	202
Dodgy code Warnings	139
Total	700

[tobiasKaminsky]

With #2886 there is no real need of having an automated sync as we remove "keep available offline", so this can be closed.