orgzly-android
orgzly-android copied to clipboard
orgzly
Implement auto synchronization
Please, add auto synchronization for remote repositories. Manual synchronization isn't comfy. also sometimes it could be cause of synchronization conflicts.
If you have tasker and a rooted phone, try running this in tasker via a shell command (it'll force a sync): su-c 'am startservice com.orgzly/com.orgzly.android.sync.SyncService' To stop the service (may need to do this before starting again): su-c 'am stopservice com.orgzly/com.orgzly.android.sync.SyncService'
If you have tasker and a rooted phone, try running this in tasker via a shell command (it'll force a sync): su-c 'am startservice com.orgzly/com.orgzly.android.sync.SyncService'
Service can be made "exported", so it doesn't require root to start, if that would help, short(-ish)-term.
I'd like to provide my usecase and desired UX as an example
I run orgzly against a folder in local storage, which (without any orgzly integration) I have synced to my computer with Syncthing. I'm careful to not make conflicting updates - I have one org file which I update from my phone. The rest I update only on my computer, and orgzly is read-only for those files. So, I never get conflicts, but I do have to press the sync button every so often.
Ideally (for me) orgzly would just attempt a sync every so often (say hourly). If it works, great. If it would produce a conflict, skip the sync entirely (i.e. don't make the multiple conflicted versions), and just give a notification that says "automatic sync failed. push the sync button whenever you want and resolve your conflicts manually"
Anderspapitto, I am currently using tasker to do a periodic sync as you suggest and foldersync to handle the remote sync and file conflict resolution. So in at least 1 form, what you are asking for can be done already. :)
I've also added actions for better control, so what happens doesn't depend on current status:
am startservice -a com.orgzly.intent.action.SYNC_START com.orgzly/com.orgzly.android.sync.SyncService
am startservice -a com.orgzly.intent.action.SYNC_STOP com.orgzly/com.orgzly.android.sync.SyncService
If sync is already running, sending SYNC_START does nothing. If not, sending SYNC_STOP does nothing.
Toggling remains the default if no action is specified or recognized.
This is great! It is very useful to do this without needing root. Anyone having tasker that wants autosync should be very happy. Do you know when this may be released? Not pushing, just curious.
Would it be possible to implement a kind of on-demand auto-sync, so that when a file is loaded or when Orgzly regains focus, it would quickly check to see if the remote copy has been modified and sync that file if necessary?
As it is now, I have several Org files synced to Dropbox, and Orgzly takes a long time to sync all of them. If I have to wait 1-2 minutes for it to sync every file before I can load the one file I need, it means that there are lots of situations in which Orgzly simply isn't useful. But if it could just sync the one file I'm loading, it would be much faster.
Thanks.
I think the golden standard for autosync (for me anyway) is Simplenote. I never have to do anything, and everything stays in sync.
In fact, "getting out of people's way" is something Simplenote does really well. Notice the difference in workflows:
In Orgzly:
- Click Notebook
- Click Note
- Click "Edit Content" *
- Type
- Click "Close" (w/Save -- the checkmark) *
- Click Sync *
In SimpleNote:
- Click Note
- Type
Big difference!
* Why do I have to do this?
I wish Simplenote and Orgzly would have a baby. It would be the most beautiful child in the world to me, and it's uncle Emacs would definitely support it!
Click "Edit Content" * * Why do I have to do this?
For the same reason we have "Write" and "Preview" here (GitHub comments editor). 😄
Currently, only links are supported ([[link][description]]), but in the future, we'll have *bold*, /italic/, lists, etc.
"Write" mode is default when you're creating new note, "Preview" when editing the existing one, as a attempt to speedup things.
Suggestions for improving UX welcome. Perhaps the button can be renamed for start?
If we are not using a rooted phone, how can we run these commands?
am startservice -a com.orgzly.intent.action.SYNC_START com.orgzly/com.orgzly.android.sync.SyncService am startservice -a com.orgzly.intent.action.SYNC_STOP com.orgzly/com.orgzly.android.sync.SyncService
Use an automation tool like Tasker, you don't need root for these commands.
Be aware that it might complain about the user this runs on, so make it say: am startservice --user 0 -a ... and the same for stop.
Oh, thanks, @licaon-kter ! The user error was the issue I was having! (I was running this from termux.)
@nevenz After testing that in Termux (start and then stop), I've look at the app to see that it synced, it did, but after exiting the app I got 2 crashes: https://gist.github.com/licaon-kter/346c8f7012dc61b7db30f99401808e4e
I'll try to look at the bigger log soon, maybe see what happened before the actual crash.
I would prefer to offer a different strategy - Git branching. Whenever you make changes, it is committed to an orgzly branch, and visa versa. This implementation allows for more fun things, like having a limited subest of a larger git repo being under orgzly. Whenever there is a conflict, it can automatically create a new branch. Its then up to the repo-owner to tidy everything up.
If you were to use git as a backend, which is an idea I definitely like, it can probably solve a lot of conflicts itself.
I like the idea of git for merge conflict resolution.
I use termux. I have it running orgzly sync via cron (stop then start). I also have setup inotifyd to watch my repository directory, and when notes change, it runs a script that commits to git, which I also setup in that directory. I am using syncthing to sync the whole directory between my machines. Finally, I am using rclone via cron to 'backup' (end-to-end encrypted) the directory (actually the parent with lots of other non-note files in it) to gdrive, and, using a sneaky trick on my always-on desktop of sharing directories, duplicating that on yandesk.disk and mega.
Sorry. TMI, I guess.
Anyway, I want concurrency, privacy, security, redundancy, integrity, and as much automation as possible in my setup. So, automating sync would still help.
This discussion is becoming a little long, I'm not sure someone has mentioned Drive Sync already.
https://play.google.com/store/apps/details?id=com.ttxapps.drivesync
I like the way each folder can have its own strategy. More details here https://metactrl.com/userguide/?app=drivesync#folder-pair (all the options are detailed at the end).
This discussion is becoming a little long, I'm not sure someone has mentioned Drive Sync already.
https://play.google.com/store/apps/details?id=com.ttxapps.drivesync
Um, well...:
Contains ads · Offers in-app purchases
D:
Back to git - Why? The thing about it is that it can solve the merge problem without requiring that you to change your sync method. It is the git repository that is the important part, because it is designed from the ground up for distributed content management. With stash, branch and other git state storage, it has autosync etc handled, and has had for some time. it should be easy to help users maintain multiple syncable/mergable versions of the same org-document base with some hand holding and documentation. I would also suggest that you do not need to write the code yourself. You can leverage existing tools (via extents?) or use code from open android ports like https://github.com/maks/MGit or https://github.com/rtyley/agit.
@timoc Git can sometimes merge automatically, but in the case of conflicts, I can't imagine resolving them on a smartphone UI being practical.
it should be easy to help users maintain multiple syncable/mergable versions of the same org-document base with some hand holding and documentation.
I don't follow you here. I've become familiar with git via the command line and Magit, and I know how to merge branches, resolve conflicts, diff branches, etc--but it was not "easy" or quick to learn, and that was with the power of the CLI and Magit and copious documentation available to me on a desktop PC. Trying to do all that on a tiny touchscreen will surely be frustrating and error-prone, and it will surely by no means be easy to teach people who aren't familiar with git how to do that, especially on a little smartphone.
Have you actually maintained a set of large Org files in a git repo and tried to merge changes made across different systems? If you have, you know that it's easy to lose data by choosing the wrong hunk when resolving conflicts. You have to be slow and deliberate and careful, and you need to be able to see more than a smartphone can display on its small screen.
I just don't see how merging conflicts with git could be feasible here, other than a simple ours/theirs merge strategy choice--but that would not allow users to truly resolve conflicts and would surely result in data loss at times.
@alphapapa
"Have you actually maintained a set of large Org files in a git repo and tried to merge changes made across different systems?"
I realize this was not a question to me, but for me, Yes.
However, if this feature were to be implemented, I don't think it would be mandatory. If you don't like using git or dealing with merge conflicts in it, I'm sure that could be accommodated by either not using git as your repo type, or by disabling the use of git for automatically handling conflicts. Making that an optional preference would be a good thing.
Git's conflict resolution stuff is basically line-by-line, whereas orgzly's is file-by-file. It is nice to have something handle the easy merges for you, so I like the idea of using git for that especially.
I had an Orgzly conflict last week, and it was in different parts of my org file, but orgzly just refused to deal with it (write/read or mine/theirs were the only choices I was given). However, the external version was already in git (as I am using git and a script to do auto-commits for me), so I just forced the write from orgzly, then went to a shell and diffed the versions and manually applied the proper changes in a different editor. Luckily both versions were at that point already in git, so this was not too difficult. However, if I didn't have this ability (because I wasn't using git) how would I have been able to resolve this issue at all?
Ideally, if I were just adding this feature for myself, I wouldn't want to have to deal with merge conflicts in a separate editor, or another program, or by commandline. I wouldn't want to use mgit at all. Git would be built into Orgzly (by integrating the mgit library), and if enabled for a filesystem repository, would automatically "just work" -- no learning curve. However, the real gem for me would be if the git conflicts were left in the file itself, and the file is committed with them marked. The notebook would also be flagged as conflicted in Orgzly so that I would know I need to fix it. So, both versions are merged together in both Orgzly and git, and all I have to do is edit it in Orgzly to "fix" it and let autosync commit it again.
For example, say there is autosync enabled, and say that there is a git library enabled for my git repo. During a sync there is a conflict when git tries to merge it. If orgzly automatically just "committed" the conflict, as marked by git and mark the notebook as conflicted, I could open the notebook and would see it as (ignoring the fact that this is plain text):
...
* Another heading
<<<<<<< HEAD:something.org
This is my new line
=======
This is a new line from the other me
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:something.org
* My last heading
...
I could then edit the file in orgzly to fix it and the next autosync would commit it again.
I don't see why this would be so hard or painful?
(I realize this doesn't deal with push/pull, but in my case, I don't need a remote repo. At any rate, config for and usage of push/pull during autosync could be by preference, too.)
I realize this was not a question to me, but for me, Yes.
Thanks, I appreciate your insightful comments.
I don't see why this would be so hard or painful?
You're right that committing the unresolved conflicts would make it possible to resolve them later. But as far as resolving them in Orgzly, it just seems to me that that would be cumbersome. On the other hand, maybe Orgzly could support the syntax and making resolving conflicts as simple as choosing from A or B, rather than having to manually edit all the lines of text.
Git aside, most of my conflicts would be resolved by a 'sync' button in the incoming note dialog. You know, the one you get when 'sharing' something to orgzly.
Or (better), an option to sync before and after storing a new note.
Right now, when I want to store a note, I have to manually switch to orgzly, sync, switch back to wherever I was (and hope Android did not decide to clear the app's memory in the interim), store the note via 'share', switch back to orgzly again, and sync again.
I guess I've gotten used to fancy cloud apps where you don't even have to think about sync. Things just somehow stay in sync.
Right now, when I want to store a note, I have to manually switch to orgzly, sync, switch back to wherever I was (and hope Android did not decide to clear the app's memory in the interim), store the note via 'share', switch back to orgzly again, and sync again.
Yes, this is the crux of the issue.
Quoting alphapapa (2017-05-11 19:14:09)
Right now, when I want to store a note, I have to manually switch to orgzly, sync, switch back to wherever I was (and hope Android did not decide to clear the app's memory in the interim), store the note via 'share', switch back to orgzly again, and sync again.
Yes, this is the crux of the issue.
Well, as far as I'm concerned, anything that makes the above less painful would be very, very welcome.
If we could reach sync nirvana, and just forget sync even exists, while everything magically appears on all our devices, hey, that'd be effin great. But that's a pretty complicated proposition without a strict protocol and data schema. Org-mode doesn't really fit very well with strict anything.