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.
You can find the app on play store: https://play.google.com/store/apps/details?id=it.anyplace.syncbrowser .
For developers: the app is all java, released on github: https://github.com/davide-imbriaco/a-sync-browser ; it is based on an indipendent java implementation of syncthing protocols, also available on github: https://github.com/davide-imbriaco/a-sync .
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!
That’s very cool, especially the Java implementation of BEP!
thank you; as now it lacks documentation… if anyone want to reuse it, just ask and I’ll make an effort to provide howtos and javadocs for the library.
Awesome! I tried it, but its still quite buggy. Some things I noticed:
- you need to request runtime permissions to access storage on Android 6+
- all the syncing code should be in a Service, (and you should split up your activity into smaller classes)
- think about implementing a Document Provider via the Storage Access Framework. That way, other apps can directly access files from Syncthing
Also, if you’re interested, we could think about integrating this in the main Syncthing app somehow.
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?
It would not allow connecting twice, it’s better just to implement scanner and the whole lot on android.
Yeah that would be ideal. But also a lot of effort to get all the existing functionality ported to Java.
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.
Yeah that makes sense. We could develop both apps in parallel, with different functionality.
thumb up! I’m going to test it deeply, thanks
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.
I’d like to see this feature on desktop app as well! Bravo!
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.
Anyway: I’ve just released a new version of my app: https://play.google.com/store/apps/details?id=it.anyplace.syncbrowser ; fixed a couple of bugs, added a couple of functions… its still beta-ish, but usable (or, at least, i use it ).
Feel free to report bugs!
I’m trying to sync with a 700GB folder with some 30,000 files, and I can’t. A folder between the same peers with just a couple of files works fine.
Would it be expected for such a large folder not to work? If not, what can I do to help you narrow down the cause?
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.
This is a side track, but how do you know how much index information to expect? Or do I misunderstand?
Edit: Oh, you’re estimating it based on the max local version in the cluster config, I guess? Clever!
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 126.96.36.199:56250 did not negotiate bep/1.0
[PRME3] 15:45:21 INFO: Established secure connection to LRDLQDT at 192.168.0.2:22000-188.8.131.52: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?