You get one toast and one blocking loading modal:

Depending on your connection they stay pretty long (especially when offline) and are not cancellable. This makes the app seem slow and even a bit broken.
Funnily enough, files you did not download yet show instantly, as their previews are shown.
Instead, the file should immediately be shown with no modal or wait at all. The updated file could be fetched in the background, and if there is one indeed, only _then_ could a toast be shown saying "Newer version available" with action "Show".
This was actually a client requirement.
On Wed, 21 Feb 2018 at 15:51, Jan-Christoph Borchardt <
[email protected]> wrote:
>
- Download a file
- Go offline, or simply bad connection (or even normal connection)
- Open the file again
You get one toast and one blocking loading modal:
Depending on your connection they stay pretty long (especially when
offline) and are not cancellable. This makes the app seem slow and even a
bit broken.
Funnily enough, files you did not download yet show instantly, as their
previews are shown.Instead, the file should immediately be shown with no modal or wait at
all. The updated file could be fetched in the background, and if there
is one indeed, only then could a toast be shown saying "Newer version
available" with action "Show".—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/android/issues/2214, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWsn6Bguh18CwRnHFZcwiTmMuVqpuPks5tXC1kgaJpZM4SNw0B
.
Would my proposed solution interfere with that? Because this absolutely breaks the UX.
Would my proposed solution interfere with that? Because this absolutely breaks the UX.
It can't be solved this way actually :/ This could be done for Text files or Images/Videos because they get opened in-app while any other file type will be send to another, external app and we can't ping that one about an updated file thus if we need to enforce an up-to-date file then we need to check before opening :/
What I don't know is how the check is actually done. ETag? Because that should be fast.
This is done via SynchronizeFileOperation:
https://github.com/nextcloud/android/blob/a77c453941e640f4153193f4eb42a2e27c846a0a/src/main/java/com/owncloud/android/ui/helpers/FileOperationsHelper.java#L249-L269
So, let us think a bit about it:
On folder entry we do check for a changed etag, which then indicates that any of the folder content has changed. But we do not do anything with this information.
_This would be first enhancement:_
store the information that a file is out of sync and indicate this to the user.
On file click we then know that the file is out of sync and can sync it (either up- or download it).
@jancborchardt this is already used if a sync conflict occurs:

As we check on folder entry for changes, I would assume that for certain timespan nothing has changed. Maybe 30s just like the server? So within this timespan we simply open up the file.
After this we can use the blocking "check for changes" as it is now.
Offline support must be handled better across the whole app and is out of scope to keep this rather small.
Sounds very sane @tobiasKaminsky. Note that the desktop client does exactly the same. We check every 30 seconds. And only if we detect a change sync. So if a change happened a second later and you open it then you will read an out of date version.
Indicating a file is out of sync to the user is a good first step imo.
This has also been reported to the forums recently: https://help.nextcloud.com/t/getting-newest-version-of-file/28051
We could disable checking for updated file when offline. IHMO, that's the best solution.
We could disable checking for updated file when offline. IHMO, that's the best solution.
I second that, checks shouldn't happen when offline :+1:
Good point, but then we should also have a snackbar warning, that it is maybe an outdated file.
What about my other idea:
As we check on folder entry for changes, I would assume that for certain timespan nothing has changed. Maybe 30s just like the server? So within this timespan we simply open up the file.
After this we can use the blocking "check for changes" as it is now.
As @rullzer said, this is also done on desktop client.
Of course this is only meaningful with the other idea:
(on folder refresh/enter store the information that a file is out of sync and indicate this to the user.
On file click we then know that the file is out of sync and can sync it (either up- or download it).
What about my other idea
Also makes a lot of sense in my opinion and I think both solutions would work nicely being implemented
@mario please give a feedback regarding the two other ideas:
https://github.com/nextcloud/android/issues/2214#issuecomment-368797671
Then I can do this together with offline check.
ping @mario.
If possible I would like to have this in 3.1, but then I need some time to develop it ;-)
Since we use etags to check for changes, I don't see the benefit of 30 seconds except for the second it takes to check the etag, yet the benefit of a fresh, newest file are obvious.
As for showing the info that file is out of sync - do we really need another icon on top of the file? We already have a few, that NONE of our users understand.
I still agree we should show the warning that file you're opening might be outdated if the connection is down (e.g. offline or in walled garden), but that's about it I'm afraid :(
Since we use etags to check for changes, I don't see the benefit of 30 seconds except for the second it takes to check the etag, yet the benefit of a fresh, newest file are obvious.
As said, this is very bad UX, if you enter a folder (where we already refresh anything) and directly clicking on a file pops up this sync dialog.
Therefore I suggested 30s as a trade-off between UX and up-to-date file.
Even desktop is doing this...
As for showing the info that file is out of sync - do we really need another icon on top of the file? We already have a few, that NONE of our users understand.
If you know from any non-understandable icons, then please open up a new issue, ping designer group and then let us enhance this. But taking this as an argument to not use another icon (which in fact already exists), does not enhance the app.
Therefore I suggested 30s as a trade-off between UX and up-to-date file.
Even desktop is doing this...
I agree with this behavior since I also think this is a trade of sure but it'll help with UX.
Then do it.
On Wed, 14 Mar 2018 at 11:10, Andy Scherzinger notifications@github.com
wrote:
Therefore I suggested 30s as a trade-off between UX and up-to-date file.
Even desktop is doing this...I agree with this behavior since I also think this is a trade of sure but
it'll help with UX.—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/nextcloud/android/issues/2214#issuecomment-372968928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWsnqpJU83j1ItN860eT_kY1jtq-8Wks5teOypgaJpZM4SNw0B
.
@mario @tobiasKaminsky For just for my understanding is the behavior introduced by this PR then still better then the actual status quo and should be merged or does it need to be changed as discussed by the latest comments?
Edit: wrong ticket, sorry...please ignore
This is an issue and not a PR?
On Wed, 14 Mar 2018 at 11:29, Andy Scherzinger notifications@github.com
wrote:
@mario https://github.com/mario @tobiasKaminsky
https://github.com/tobiaskaminsky For just for my understanding is the
behavior introduced by this PR then still better then the actual status quo
and should be merged or does it need to be changed as discussed by the
latest comments?—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/nextcloud/android/issues/2214#issuecomment-372974211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWso68UReRuosJwK0LJyPUw5wbVzRQks5tePDygaJpZM4SNw0B
.
Yeah, wrong ticket, sorry ...
In addition to that the SynchronizeFileOperation is a bit too much, as we want first only check if etag is changed. But this SynchronizeFileOperation also updates Capabilities:
03-14 11:11:40.054 3104-3104/com.nextcloud.client D/FileActivity: show loading dialog
03-14 11:11:40.086 3104-4101/com.nextcloud.client D/OwnCloudClient #3: REQUEST PROPFIND /nc/remote.php/webdav/FewImages/1.jpg
03-14 11:11:40.186 3104-4101/com.nextcloud.client D/FileDataStorageManager: Number of files updated with CONFLICT: 1
03-14 11:11:40.186 3104-4101/com.nextcloud.client D/FileDataStorageManager: checking parents to remove conflict; STARTING with /FewImages/
03-14 11:11:40.188 3104-4101/com.nextcloud.client D/FileDataStorageManager: NO MORE conflicts in /FewImages/
03-14 11:11:40.224 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:40.227 3104-4101/com.nextcloud.client D/FileDataStorageManager: checking parents to remove conflict; NEXT /
03-14 11:11:40.233 3104-4101/com.nextcloud.client D/FileDataStorageManager: NO MORE conflicts in /
03-14 11:11:40.239 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:40.249 3104-3450/com.nextcloud.client I/chatty: uid=10094(com.nextcloud.client) RenderThread identical 1 line
03-14 11:11:40.255 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:40.267 3104-4101/com.nextcloud.client D/FileDataStorageManager: checking parents to remove conflict; NEXT
03-14 11:11:40.268 3104-4101/com.nextcloud.client I/SynchronizeFileOperation: Synchronizing [email protected]/nc, file /FewImages/1.jpg: Operation finished with HTTP status code -1 (success)
03-14 11:11:40.272 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:40.888 3104-3450/com.nextcloud.client I/chatty: uid=10094(com.nextcloud.client) RenderThread identical 61 lines
03-14 11:11:40.895 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:41.278 3104-4101/com.nextcloud.client D/FileActivity: dismiss loading dialog
03-14 11:11:41.287 3104-3104/com.nextcloud.client V/FileDisplayActivity: onPause() start
03-14 11:11:41.291 3104-3104/com.nextcloud.client D/FileDisplayActivity: onPause() ending
03-14 11:11:41.292 3104-3104/com.nextcloud.client V/FileDisplayActivity: onPause() end
03-14 11:11:41.331 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:41.367 3104-3104/com.nextcloud.client D/PreviewImageActivity: onCreate(Bundle) starting
03-14 11:11:41.395 3104-4104/com.nextcloud.client D/OwnCloudClient #3: REQUEST GET /nc/ocs/v1.php/cloud/capabilities
03-14 11:11:41.465 3104-3104/com.nextcloud.client I/AppCompatViewInflater: app:theme is now deprecated. Please move to using android:theme instead.
03-14 11:11:41.536 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: Successful response: {"ocs":{"meta":{"status":"ok","statuscode":100,"message":"OK","totalitems":"","itemsperpage":""},"data":{"version":{"major":14,"minor":0,"micro":0,"string":"14.0.0 alpha","edition":""},"capabilities":{"core":{"pollinterval":60,"webdav-root":"remote.php\/webdav"},"bruteforce":{"delay":0},"activity":{"apiv2":["filters","filters-api","previews","rich-strings"]},"dav":{"chunking":"1.0"},"files_sharing":{"api_enabled":true,"public":{"enabled":true,"password":{"enforced":false},"expire_date":{"enabled":false},"send_mail":false,"upload":true,"upload_files_drop":true},"resharing":true,"user":{"send_mail":false,"expire_date":{"enabled":true}},"group_sharing":true,"group":{"enabled":true,"expire_date":{"enabled":true}},"federation":{"outgoing":true,"incoming":true,"expire_date":{"enabled":true}},"sharebymail":{"enabled":true,"upload_files_drop":{"enabled":true},"password":{"enabled":true},"expire_date":{"enabled":true}}},"theming":{"name":"Nextcloud","url":"https:\/\/nextcloud.com","slogan":"a safe home for all your data","color":"#7809DE","color-text":"#ffffff","color-element":"#7809DE","logo":"http:\/\/10.0.2.2\/nc\/core\/img\/logo.svg?v=23","background":"http:\/\/10.0.2.2\/nc\/index.php\/apps\/theming\/loginbackground?v=23","background-plain":false,"background-default":false},"files":{"bigfilechunking":true,"blacklisted_files":[".htaccess"],"undelete":true,"versioning":true}}}}}
03-14 11:11:41.564 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Added version
03-14 11:11:41.564 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Added core
03-14 11:11:41.564 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Added files_sharing
03-14 11:11:41.564 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Added files
03-14 11:11:41.564 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Added theming
03-14 11:11:41.567 3104-4104/com.nextcloud.client D/GetRemoteCapabilitiesOperation: *** Get Capabilities completed
03-14 11:11:41.593 3104-4104/com.nextcloud.client W/AccountUtils: Update Capabilities: true
03-14 11:11:41.663 3104-3104/com.nextcloud.client D/PreviewImageActivity: onStart() starting
03-14 11:11:41.672 3104-3104/com.nextcloud.client D/OCFile: OCFile name changin from /FewImages/E/
03-14 11:11:41.672 3104-3104/com.nextcloud.client D/OCFile: OCFile name changed to /FewImages/E/
03-14 11:11:41.716 3104-4105/com.nextcloud.client D/ExternalLinks: links disabled
03-14 11:11:41.729 3104-3104/com.nextcloud.client D/cache_test_DISK_: image read from disk 1206033570
03-14 11:11:41.763 3104-3104/com.nextcloud.client D/PreviewImageActivity: onResume() starting
03-14 11:11:41.765 3104-4106/com.nextcloud.client D/OwnCloudClient #3: REQUEST GET /nc/ocs/v1.php/cloud/user
03-14 11:11:41.786 3104-3226/com.nextcloud.client D/Avatar: URI: http://10.0.2.2/nc/index.php/avatar/tobi/384
03-14 11:11:41.795 3104-3226/com.nextcloud.client D/OwnCloudClient #3: REQUEST GET /nc/index.php/avatar/tobi/384
03-14 11:11:41.905 3104-3104/com.nextcloud.client I/Choreographer: Skipped 34 frames! The application may be doing too much work on its main thread.
03-14 11:11:42.084 3104-3226/com.nextcloud.client D/cache_test_DISK_: image read from disk 1206033570
03-14 11:11:42.112 3104-3104/com.nextcloud.client D/cache_test_DISK_: image read from disk -1074286518
03-14 11:11:42.236 3104-3110/com.nextcloud.client I/zygote: Do partial code cache collection, code=991KB, data=633KB
03-14 11:11:42.246 3104-3110/com.nextcloud.client I/zygote: After code cache collection, code=991KB, data=634KB
03-14 11:11:42.246 3104-3110/com.nextcloud.client I/zygote: Increasing code cache capacity to 3MB
03-14 11:11:42.296 3104-3104/com.nextcloud.client D/FileActivity: Operations service connected
03-14 11:11:42.297 3104-3104/com.nextcloud.client D/PreviewImageActivity: Upload service connected
03-14 11:11:42.375 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:42.406 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:42.408 3104-3104/com.nextcloud.client D/PreviewImageFragment: Showing image with resolution 480x480
03-14 11:11:42.443 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:42.485 3104-3450/com.nextcloud.client I/chatty: uid=10094(com.nextcloud.client) RenderThread identical 2 lines
03-14 11:11:42.523 3104-3450/com.nextcloud.client D/EGL_emulation: eglMakeCurrent: 0xc70ffe80: ver 2 0 (tinfo 0xc816db80)
03-14 11:11:42.791 3104-3104/com.nextcloud.client V/FileDisplayActivity: onSaveInstanceState() start
03-14 11:11:42.793 3104-3104/com.nextcloud.client D/FileDisplayActivity: onSaveInstanceState(Bundle) starting
03-14 11:11:42.794 3104-3104/com.nextcloud.client D/ExtendedListFragment: onSaveInstanceState()
03-14 11:11:42.795 3104-3104/com.nextcloud.client V/FileDisplayActivity: onSaveInstanceState() end
03-14 11:11:42.796 3104-3104/com.nextcloud.client D/FileDisplayActivity: onStop() ending
ReadRemoteFileOperation is also doing too much as it requests the whole webdav infos.
A click on a downloaded, not changed file, takes 1.1-1.3s on emulator with local server, so nearly no delay to server side.
Call to server, even with RefreshCapabilities is taking 0.15-0.2s.
So 30s is not current anymore? Cause it's wayy to long for anything - people close the app or think something is broken after 10s.
This is the workflow after everything is implemented
Only if eTag is changed, a spinner will be shown, so this is very less intrusive and "hidden" for the user.
The only "problem" is, if you have a very very slow internet connection, than the eTag check might take some time, but this is the same for refreshing folder or anything other. If internet connection is dropped/stalled during requests we are out of luck.
While I agree with improving speed (yay), can we please not have a new or even an updated icon? Icons areeee bad.
(30 seconds I've already voiced my concern over)
Also, if you know the file is out of sync and user clicks on it, shouldn't it just download & open newest version?
(Maybe I'm missing the big picture here)
I think we don't need a new icon at all. If the sync fails we already have an icon referenced by Tobias for sync errors. If we can't sync a file because we are offline / don't have a server connection / server is in maintenance mode we should (as discussed in #989 including mock-up) show the "info bar" below the Toolbar that we don't have an internet connection or can reach the server since that should be "obvious enough"
Mock-ups for connectivity issues can be found here: https://github.com/nextcloud/android/issues/989#issuecomment-317275293 ff.
Also, if you know the file is out of sync and user clicks on it, shouldn't it just download & open newest version?
True, I missed this in the above list, but it was already implemented.
Icons areeee bad.
This then should be discussed separately, as we use icons very widely, e.g. as downloaded indicator, favorite, sync folder, ...
I think we don't need a new icon at all.
It is not a new icon at all. It is already used if a "keep available offline" file is out of sync. Now the same icon is used if we know that the file is out of sync.
(We could download the file when on wifi, but downloading the file on mobile data without user interaction is not an option imho).
If we can't sync a file because we are offline / don't have a server connection / server is in maintenance mode we should (as discussed in #989 including mock-up) show the "info bar" below the Toolbar that we don't have an internet connection or can reach the server since that should be "obvious enough"
This is a very good idea, but a bit out of scope for this PR. I think the current approach is working, but can be enhanced by #989.
Please see #2369 for the PR.
Just like in the desktop client: If we are offline, every file is »green check mark« unless modified locally. Offline is not an error state.
Correct. "real" offline visualization we can discuss in #989 as @AndyScherzinger poined out.
Fixed since the PR has been merged, thus shipping with 3.1.0