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. On Sunday, October 18, 2015 at 6:46:40 PM UTC-4, Matt McCutchen wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "mobileorg-android" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mobileorg-android. For more options, visit https://groups.google.com/d/optout.
>From Mon Sep 17 00:00:00 2001 From: Matt McCutchen <[email protected]> Date: Tue, 20 Oct 2015 23:21:47 -0400 Ugly but workable solution for temporary loss of mobile edits. https://groups.google.com/d/topic/mobileorg-android/mSdtW_vqJgw/discussion --- .../mobileorg/Synchronizers/Synchronizer.java | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/MobileOrg/src/main/java/com/matburt/mobileorg/Synchronizers/Synchronizer.java b/MobileOrg/src/main/java/com/matburt/mobileorg/Synchronizers/Synchronizer.java index 8014d0f..a31cda1 100644 --- a/MobileOrg/src/main/java/com/matburt/mobileorg/Synchronizers/Synchronizer.java +++ b/MobileOrg/src/main/java/com/matburt/mobileorg/Synchronizers/Synchronizer.java @@ -80,6 +80,11 @@ public class Synchronizer { announceStartSync(); ArrayList<String> changedFiles = pull(parser); pushCaptures(); + if (changedFiles == null) + throw new Exception( + "Changes from the computer were not pulled to avoid " + + "temporarily losing mobile edits. Be sure to pull and " + + "push on the computer before synchronizing again."); announceSyncDone(); return changedFiles; } catch (Exception e) { @@ -137,13 +142,24 @@ public class Synchronizer { HashMap<String,String> remoteChecksums = getAndParseChecksumFile(); ArrayList<String> changedFiles = getFilesThatChangedRemotely(remoteChecksums); - if(changedFiles.size() == 0) - return changedFiles; - changedFiles.remove(INDEX_FILE); announceProgressDownload(INDEX_FILE, 0, changedFiles.size() + 2); HashMap<String,String> filenameMap = getAndParseIndexFile(); + if(changedFiles.size() == 0) + return changedFiles; + if(!OrgEdit.editsToString(resolver).equals("")) { + // Skip pull to avoid overwriting the pending mobile edits and + // temporarily losing them until they make it to the computer and + // back. This check will not trigger on the next sync, so we direct + // the user to pull and push from the computer before synchronizing + // again. The "null" is recognized by runSynchronizer. + // + // Ugly but workable solution to the problem described at: + // https://groups.google.com/d/topic/mobileorg-android/mSdtW_vqJgw/discussion + return null; + } + Collections.sort(changedFiles, new OrgUtils.SortIgnoreCase()); pull(parser, changedFiles, filenameMap, remoteChecksums);
