On Wed, 2015-10-21 at 22:50 +0800, mobileorg-android wrote: > 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). [...] > 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 -- 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.
