I’ve created a new version of the Silk client which eases the installation process when opening the app for the first time.
Changelog:
Thanks! Installing it now. Should we report issues here Issues · OpenSilk/SyncthingAndroid · GitHub or somewhere else (or not report them at all 
)?
It doesn’t look like somebody is looking at those issues. Yours is already 5-days old, and my question is 9.
It would be fabulous if possible to merge the best of both worlds: Silk Client’s interface + official client’s inotify support.
just installed it and looks great! Especially that you can add remote devices as well
One little annoyance though : could you make the default setting to always run instead of inly when app is open? I was setting it up freshly and always got the message that syncthing was down after switching to my notepad to cut and paste remote id’s and switching back to syncthing. After switching to always run everything seems ok.
I sign underneath.
You can do that with the official client, too.
Collected top statistics with adb shell 'top | grep -i syncthing' | tee silk.log, and here are the results.
Thanks! Seems like this is the intended behaviour
@Zillode, do you know why the guys from OpenSilk don’t look at their issue tracker? It doesn’t make sense to file bug reports or suggestions if nobody will look at them. The ST team put a lot of traction on the issue trackers, which motivates us users to test stuff and report what we find. But the OpenSilk team doesn’t seem to care, they seem to have left the client hanging out to die, and are not interested in feedback.
@Zillode, an inevitable question: if the silk client can achieve such good CPU usage, what is the official client doing so different to get such bad CPU usage? The contrast is even sharper if we take into account that the official client relies on inotify, whereas the silk client has to rely on frequent rescanning: this alone would lead one to expect the silk client to eat up more CPU, but it doesn’t by very very far.
No idea, just be a bit patient. I think the open issue is solved with the updated version because it works for me. The guy is also updating Syncthing as new features arrive which is nice. I guess there is no time for support at the moment.
Syncthing-android asks Syncthing to compute the completion status every few seconds (Rest API). This requires Syncthing to loop (currently even multiple times) over the entire database to check if files are needed from other clients.
The Silk client uses a new Event API of Syncthing which broadcasts updates. This means that Syncthing announces the completion status as soon as files arrive. Syncthing-android could also use this API but it requires a little work.
Updated in the next version, which will also feature inotify (currently testing this)
great! inotify is most welcome too, since that was the major difference with the official version as i understood correctly
The guy is also updating Syncthing as new features arrive which is nice
This is great news! Long live the silk client!
Updated in the next version, which will also feature inotify (currently testing this)
The good news don’t stop coming! If you need beta testers, I’m up for it.
From what you explained, @Zillode, the CPU issue hinges on: REST API vs Events API. But then why 0.5.28 had similar CPU usage to the silk client?
It looks like the silk client will become the new official client. Is that the intention, to focus development on it?
From the good news you’ve been bringing, I’ll stick ti the silk client.
Because the new Syncthing-android app enforces TLS. This is necessary to protect Android’s sandboxing mechanism. The Silk client needs this as well, but the CPU impact will be smaller because the connection stays open.
So this confirms @calmh’s initial hypothesis on issue 362. Really good to know that the issue has been cornered.
@marcelpaulo and @Zillode: the output from top that @marcelpaulo showed also matches my nice experience with this client.
As for the bug report, I closed the original one I submitted since, as @Zillode says, it seems to be working just fine now. But I opened a new one . Anyway, regardless of whether or not OpenSilk has time to answer the issues (or address them) I guess that is the best place to report them. And, I should say, I am really happy with the app.
[Moved from https://github.com/OpenSilk/SyncthingAndroid/issues/3 ]
UI seems stuck after importing config file:
Using the version from http://wilma.vub.ac.be/~lhoste/syncthing/unofficial/silk-0.1.50.apk (2015-05-04; sources from https://github.com/Zillode/SyncthingAndroid).
I installed the apk in a device that did not have this client previously. It created keys, etc. Then I imported the config (a zip file containing the cert.pem, key.pem and config.xml files). The UI, however, seems forever stuck trying to start; it is still showing the device name pre-importation of config and giving the “Syncthing seems to be off or there is a problem with your internect connection”. The funny thing, though, is that it is really working just fine most of the time (it is syncing with other devices, the other devices see it with the right version, and I can operate from the Web GUI, changing folder settings, etc).
I turned off and on the phone, but it did not help.
Multiple androids: why is it working?
This is probably my ignorance showing, but here it goes. With the official ST android app I was keeping all the data under Android/data/com.nutomic.syncthingandroid. This, I understand, is about the easiest way to avoid the infamous mtimes issue ( https://github.com/syncthing/syncthing/issues/831). I am now running the Silk client in three Androids, but the data are still in the same place (Android/data/com.nutomic.syncthingandroid). And things keep working just fine.
A few questions then:
Android/data/com.nutomic.syncthingandroid would be removed. Or, for that matter, if someone were to install from the start only the Silk client, I guess that directory would not exist. Where should we place the data to circumvent the mtimes issue? /data/data/syncthing.android/ does not seem the right place (and cannot be modified unless one is rooted).