Thanks for the detailed explanation. I'm going to jump to the issues as you've gone above and beyond in your setup to get it the best it can be...no issues there. I'll put my replies inline:
On Tue, Jul 24, 2012 at 1:57 PM, Dwight Arthur <[email protected]> wrote: > A. I think that sometimes, every task in a project has been completed, and > some of them are completed on Android awaiting sync to Windows while others > are completed on Windows awaiting sync to Android. When the sync is > completed in both directions I would like to see everyone agree that all > tasks are completed and that therefore the project is completed for this > cycle and needs to be rolled to the next cycle. I do not think that > happens, at least I do not think it always happens. The results may vary > depending on whether the Windows side or the Android side was the first to > see the project with all tasks in completed state. > I have found at least one fully reproducible defect here which I submitted to the beta forum [I just saw your reply]. You are correct, not only does completing part of the tasks on one and part on another FAIL to cause a recurrence in the parent, it's even worse because completing yesterday's tasks on Android can cause today's versions of the tasks to be completed erroneously on the PC. > B. I think that at least sometimes, completing a task causes the parent to > sync. If I change the parent on Android and a minute later (before any > sync) change a subtask on Windows in a way that causes the parent to sync, > the (unchanged) windows parent will overwrite the changed Android parent > and the change from the Android side will be lost. > By "sync" do you mean "marked as modified"? If a single subtask is changed, I don't get the parent marked as modified. But if I change the note of "Testparent" on Android, then complete and auto-recur Testparent on the PC, sync PC, and sync Android, the changed note will be lost on Android. Is that what you mean? But you see it sometimes *without* the recurrence happening? > C. In these circumstances it can be devilishly hard to ensure that items > (especially project/parent items) are changed only on one side. If they get > changed on both sides and the version you want to keep is on Android, the > "both sides changed" setting to server guarantees that the desired change > on Android will be lost. (note, changing "both sides changed" to use the > local copy makes the problems worse, believe me). > What I do in this case is I always sync Android first. It seems to me that if there is a case where syncing Android first does not give a request for a sync conflict resolution, there is an obvious/reportable bug -- if we can find it. But if you are syncing "wi-fi only" then you can't always sync android first, and automatic desktop sync complicates it even more. > D. Lisa noted that in the event of a sync conflict, on the Windows side > you always get notified and can choose which version to keep. I think most > users with an opinion would agree, but it's not always true. Start with the > case described in (C) above. When Sync overwrites the good version on > Android with a bad version from Windows, the next sync sends the bad update > back to Windows. Since the update exactly matches the Windows version no > conflict is detected and the bad version is retained, with no notice or > choice on the Windows side. > Yes, I have replicated this just now. It happens when Android is not synced. The reason I don't see this is that for me Android syncs as soon as I go do something else on my phone, pretty much always since I'm almost always on a network, and if I'm not, my PC is at home and I'm not changing anything. In my test case that I reported a defect, I was also not asked, if I did the steps in the order I listed. > > E. Along the lines suggested by ctenorman I believe that frequent > background syncs on both Windows and Android would reduce (but not > eliminate) the window in which an error could occur. > But if Android is always synced first, and the obvious bugs fixed, is this true? Of course Android cannot always be synced first, if the scheduler happens to slip in right at that moment. Ideally, either side would sync whenever a change is saved to the profile, > or whenever unsynched cloud changes are detected. I had asked for this in > one of these forums long ago and was challenged by other readers who felt > that the storage and processing costs would be exorbitant, and that > windows/android performance would suffer. > But wait...aren't you being inconsistent here? If you only sync when on Wi-fi, you wouldn't use the "sync on every change" anyway, and you would still see this issue, correct? > Meanwhile there have been several successful implementations, such as > Google Drive and Evernote. I understand that Google can afford unlimited > storage and processing for a product with little if any revenue, but > Evernote needs revenue the same way MLO does and yet Evernote gets this > right. > Not always. I've had data loss with Evernote too though I have not tracked it down. I have to run! > -- Lisa ------------------------------ Lisa Stroyan, mailto: [email protected] <[email protected]> -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
