I’ve just completed end released on google play a new app for android. This app works more or less like the Dropbox app:
does NOT synchronize all your syncthing repository on your phone;
instead it connects to your pc/laptop/wathever via syncthing protocols, and allows you to synchronize the index, and download/upload files from your syncthing folders.
DISCLAMER: this work is indipendent from the official Syncthing apps, and still quite raw. It may or may not work, it may destroy your data, use at your own risk! (I use it, and for me it works okay).
If you’re interested in the project, have any suggestion or bug report, feel free to contact me!
thanks for the hints! The android app code is quite messy, I’m sorry (I’m a java developer, I work on android in my spare time only).
runtime permissions: I’ll fix this as soon as I can (my phone is 5.1, so I didn’t notice);
most core syncthing code is in a separate lib (a-sync-client.jar), the app contains only interface-related code. But yeah, the single-class app is quite bad, I’ll refactor it in many classes soon ;
implementing a Document Provider is on my list, but first I’ll need to refine the code a little (it’s still quite prone to errors).
Yes, I may be interested in integrating my code in the main Syncthing app; my app is based on a separate java library, where the main app is build around the go binary (if I am right)… what do you propose?
I thought we could run your library in parallel to the Go binary, on the same key (so same ID). That way, we could have the functionality of downloading files in the same app. However, Syncthing would probably be confused if two devices connect with the same address, right?
I think the point would be that porting the existing functionality is the wrong thing for Android. What people probably want on their phone is something that does more on demand syncing of files when pointed at, plus seamless uploads of things like photos and so on. Probably the gain is much larger to not do scans and stuff and instead hook into whatever event you get when a photo is taken, then queue that for upload and connect and so on as required.
I love the idea. At the moment I achieve the same by uploading files on one ‘central’ node to Mega, from the Android Mega app I can download any file on my syncthing network. This app would obviate the Mega connection, allowing direct connection to my RPI3 ‘central’ node.
Unfortunately, I’m not a coder but I have tested the app and, although buggy, the idea is great. Looking towards the next update. Thanks.
I love the concept behind this. I think, though, that rather than add this into the official Syncthing Android app, what would be more useful would be to refactor the official core Syncthing code to strongly separate syncing protocol from the filesystem-specific stuff. The fact that it all had to be re-implemented in Java to get this functionality suggests that the original code is structured in a way that limits its flexibility too much.
Here are some examples of other things that some users might want to do, that as far as I can see are currently hard/impossible given the way Syncthing is strutured:
Display a web interface allowing users to browse and download files in a repository, even though the web interface is running on a server that is not storing a copy of the files itself.
Store files in something other than a filesystem, like, say, Amazon’s S3 object store.
Store files in an encrypted format.
Taken to an extreme, Syncthing could be split (on all platforms) into two separate processes - one process is responsible for syncing the index, while the other handles the filesystem. Then, an Android app that works like Davide’s app could simply use the first process but not the second, rather than re-implementing so much of Syncthing’s core functionality.
The fact that it all had to be re-implemented in Java to get this functionality suggests that the original code is structured in a way that limits its flexibility too much.
That’s also due to the fact that original code and protocol is tailored around the original requirements (ie synchronization of entire folders between two or more devices).
To use it without a local folder require some hack and workaround, because of the difference in requirements and control flow in the app.
my test folder has 20kfile, 90GB… your folder is bigger, but it should work. I suggest you do the first synchronization from the same network (ex: home network, phone connected with wifi, pc with syncthing client and open port), cause an index of that size could use some hundred MBS. In my case synchronization via local network took around 5-15M (with a low-spec phone).
You should see a synchronization progress message with percentage of completion (such as “index update xx% completed”). Do you? Does it hangs somewhat? Do you get any error/app crash?
note: after the first heavy synchronization, the app uses delta-transfer, so it does not require heavy data transfer anymore.
Sorry, I should have provided more information. I am doing the initial sync over wi-fi on the same network; peers connect via local addresses. Phone provides a spinner with “index update…”, but no percentage. Desktop UI reports ~150 bytes transferred before connection is lost. Desktop console (Syncthing 0.14.19 via SyncTrayzor) reports the following:
[PRME3] 15:45:21 INFO: Peer 192.0.171.42:56250 did not negotiate bep/1.0
[PRME3] 15:45:21 INFO: Established secure connection to LRDLQDT at 192.168.0.2:22000-192.0.171.42:56250 (tcp-server) (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
[PRME3] 15:45:21 INFO: Device LRDLQDT client is "syncthing-client 0.0" named "OnePlus ONEPLUS A3000"
[PRME3] 15:45:21 INFO: Device LRDLQDT folder jquit-j4pxa has a new index ID (0x2F68295D2E5D097E)
[PRME3] 15:45:53 INFO: Connection to LRDLQDT closed: reading length: EOF
Wait, that’s not a local address. Maybe I should try specifying the address rather than using discovery?
;
).