[mobileorg-android] Edits temporarily lost on sync if computer has already pushed other changes

[Matt McCutchen via mobileorg-android]

I'm seeing the following problem regularly with MobileOrg:

Starting with the computer and phone in sync:
1. Make a change on the computer. It is auto-pushed using the code from
the FAQ.
2. Make an unrelated change on the phone.
3. Press "Synchronize" on the phone. The phone adds the change of #2 to
mobileorg.org, but then it imports the file pushed in #1, replacing all
previous data from that file and temporarily losing the change of #2.
4. Once I realize what has happened, pull and push on the computer and
synchronize on the phone.

For example, yesterday I took my phone to the kitchen to make my grocery
list, synchronized, and went out to the store with only the phone, to find
the grocery list gone. Luckily I remembered what was on the list.

Should I be doing something differently? I would hate to have to remember
to always synchronize after making changes on the computer and before
making further changes on the phone; to me, that negates a lot of the value
of a synchronization system.

I understand that under the current design, the phone relies on the
computer to combine changes to a single org file. Perhaps the phone could
at least check, before importing a new file version, whether it claims to
incorporate all edits previously made by the phone to that filename. If
not, the phone would skip the import and warn the user, who can complete #4
immediately if desired or continue using the phone with the data it has and
complete #4 later.

Given that the synchronization currently imports before pushing edits, the
condition to import would be: there are no edits to the file waiting to be
pushed in the same synchronization, and the LAST_MOBILE_CHANGE field has
changed since the last time the phone pushed edits to the file. This
should solve the most common case of edits being silently (temporarily)
lost. Edits would still be lost if the computer pushes while they are
sitting conflicted in the mobile inbox, but the user will typically see
when that happens. Any suggestions before I submit a patch?

Thanks,
Matt

[Matt McCutchen via mobileorg-android]

I realized that checking LAST_MOBILE_CHANGE of the file that was originally
edited on the phone is an incomplete solution because the target node could
have been moved to another file on the computer or even deleted by the time
the edit is pushed.

For now, I'm using a simple patch (attached) that skips the entire pull
with a notification only if edits are being pushed on the same
synchronization. This should work as long as I see the notification before
synchronizing again. Since I don't know yet whether MobileOrg will meet my
needs for me to use it long-term and no one else has shown interest in the
issue, I'm not spending time on a better solution. I'm not sure if this
patch would be appropriate to take upstream, but at least anyone who has
the same problem and finds this thread can try it.

Post by Matt McCutchen via mobileorg-android
1. Make a change on the computer. It is auto-pushed using the code from
the FAQ.
2. Make an unrelated change on the phone.
3. Press "Synchronize" on the phone. The phone adds the change of #2 to
mobileorg.org, but then it imports the file pushed in #1, replacing all
previous data from that file and temporarily losing the change of #2.
4. Once I realize what has happened, pull and push on the computer and
synchronize on the phone.
For example, yesterday I took my phone to the kitchen to make my grocery
list, synchronized, and went out to the store with only the phone, to find
the grocery list gone. Luckily I remembered what was on the list.
Should I be doing something differently? I would hate to have to remember
to always synchronize after making changes on the computer and before
making further changes on the phone; to me, that negates a lot of the value
of a synchronization system.
I understand that under the current design, the phone relies on the
computer to combine changes to a single org file. Perhaps the phone could
at least check, before importing a new file version, whether it claims to
incorporate all edits previously made by the phone to that filename. If
not, the phone would skip the import and warn the user, who can complete #4
immediately if desired or continue using the phone with the data it has and
complete #4 later.
Given that the synchronization currently imports before pushing edits, the
condition to import would be: there are no edits to the file waiting to be
pushed in the same synchronization, and the LAST_MOBILE_CHANGE field has
changed since the last time the phone pushed edits to the file. This
should solve the most common case of edits being silently (temporarily)
lost. Edits would still be lost if the computer pushes while they are
sitting conflicted in the mobile inbox, but the user will typically see
when that happens. Any suggestions before I submit a patch?
Thanks,
Matt

[mobileorg-android]

On October 21, 2015 11:33:32 AM Matt McCutchen via mobileorg-android

Post by Matt McCutchen via mobileorg-android
For now, I'm using a simple patch (attached) that skips the entire pull
with a notification only if edits are being pushed on the same
synchronization. This should work as long as I see the notification before
synchronizing again.

I'm at some pains to imagine how to handle it better than this (not that it
matters, as I'm only a user, not a developer of this tool).

If it's a new node, it would be reasonable to keep it in the phone until
the node comes back in a sync operation after pushing on the computer --
that is:

1. Make a new node on the phone.
2. The computer has auto-synced some changes.
3. In mobileorg on the phone, do a sync. This brings in new stuff from the
computer. Currently this also deletes new stuff from the phone. For the
sake of argument, let's pretend that it leaves new content in the phone.
4. Further updates in the computer, then org-mobile-push (C-c C-x RET p).
5. Sync again on the phone.

Step 5 should remove the new content saved locally in the phone and replace
it with the pushed material from the computer. But how do you match it up?
The user may have made any change to the headline text, or moved the
headline elsewhere in the file (or even into another file), and mobileorg
on the phone has no knowledge of, or control over, it. I guess you could
add a MOBILEORG_ID property with a GUID in the phone, but you can't
guarantee that the user won't remove it or tamper with it on the computer.

This isn't an answer, but I hope at least an acknowledgment that
mobileorg's current behavior is because it's a Difficult Problem.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

[mobileorg-android on behalf of Matt McCutchen]

Post by mobileorg-android
I'm at some pains to imagine how to handle it better than this (not that it
matters, as I'm only a user, not a developer of this tool).

[...]

Post by mobileorg-android
This isn't an answer, but I hope at least an acknowledgment that
mobileorg's current behavior is because it's a Difficult Problem.

I wouldn't let ourselves off the hook so easily. There's a simple (in
principle), complete solution that's consistent with the existing
design, which I would consider implementing in the future if it seems
like the difference matters to me or other people:

0. The mobile inbox is included in org-mobile-files.

1. The phone assigns a timestamp to each edit, and the computer stores
the timestamp of the last edit it has pulled in a special field in the
mobile inbox. So when the phone pulls a data set, it can tell which
edits are reflected in that data set.

2. After pushing an edit, the phone keeps the edit in the database until
it pulls a data set reflecting the edit.

3. Each time the phone pulls a data set, it locally reapplies all edits
it has that are not already reflected in the data set. Any edits that
fail to apply are added locally to the mobile inbox. (This would
essentially require duplicating the logic from org-mobile-apply.) This
way, the bodies of all conflicted edits remain available on the phone in
the mobile inbox, whether or not the edits have made the round trip to
the computer yet.

Matt