X X
Thanks for your comments, see my replies inline On Wed, Jul 25, 2012 at 10:30 AM, Lisa Stroyan wrote: 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 <m...@grantsmiths.org> 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. I agree that you have defined and reproduced this, that it's a defect and that it plays a role in my issue. 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? I have not been paying attention to date/time of modification. Are you certain that a task is subject to synch if AND ONLY IF date/time of modification is sufficiently recent? Without thinking too much about it I had assumed that date/time of modification was a sufficient but not necessary condition, and that other factors could also trigger a task to be candidate for sync. I have not been able to reproduce this and am not 100% certain that it happens as I describe it, but I have a sense that completing a subtask of a recurring task that recurs based on subtask completion, would cause the parent to sync even if its modification date was unchanged. Here's a scenario that DOES NOT work to illustrate my point, but I think it's close to the situation I'm chasing: -define a repeating task that recurs when all subtasks are completed. Set daily repeat with start and due date = today. -fully synch between windows and android -complete one task on windows and sync to cloud. Sync cloud to phone -complete second task on phone and set the phone aside overnight without synching. Leave MLO running as foreground program. Phone will not synch overnight while Windows will synch hourly. -In the morning, Windows phone and cloud all show the repeating task set for yesterday. Windows and cloud show one subtask complete, phone shows two subtasks complete. -On the phone, complete the repeating task. It will reset to today with all subtasks incomplete. Do not sync. -On windows, manually complete the second task, the same one that was marked complete on the phone yesterday. -Sync windows to phone to cloud. I believe but cannot reproduce that sometimes the phone will show the repeating task uncompleted with yesterday's date, matching what's currently on Windows, with the second task completed and the first and third uncompleted. My conclusion is that marking the second task complete on Windows caused the parent status (incomplete, due yesterday) to be updated to Cloud. 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. I agree that if it were possible to force Android to always sync first the problem would be corrected or at a minimum massively reduced in impact. Scheduled sync on desktop, as you say, makes that difficult. The other thing that in my opinion makes it difficult is that changed tasks on Android can remain unsynched for hours, provided that MLO remains in the foreground on the phone for all of that time. In my case I don't think that wifi only is significant because I almost never use my computer outside of wifi range and my phone is generally there with me, so if my fingers are on the computer the phone has almost certainly been in wifi range for a few minutes. 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. If Android always synched first, and the other obvious bugs were fixed, I would be pretty happy. I don't know how either Windows or Android could know whether the other side has synched until it finds out by synching. I kind of feel like Heisenberg and Einstein discussing whether anything anywhere can ever be simultaneous, and how we could know. I suppose that Windows could refuse to synch if the last Android synch was more than ___ minutes ago? But that would mean that if you lost your phone and then sent tasks to the MLO/cloud's email address the new tasks would not show up on Windows until you find your phone. 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? I would synch on every change. If a wifi connection were available I would expect the synch to occur within a minute or so of the completion of the change. If a wifi connection were unavailable I would expect the synch to occur within a minute or so of the re-establishment of a wifi connection. There would be no problem unless I am using my laptop with an Ethernet connection somewhere without wifi, or if I left my phone in the car (outside wifi range from my house) and went inside to immediately start managing my tasks. I could live with all of that. 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 suppose that any architecture with data stores on synchronized but disconnected platforms will show data loss if pushed hard enough. My point was that Evernote synchs changes more-or-less as they occur without destroying the performance of either Windows or Android and without requiring such massive cloud servers as to bankrupt the Evernote developers. I have to run! Me too. Thanks. -Dwight. -- Lisa _____ Lisa Stroyan, mailto: lstro...@gmail.com <mailto:lstro...@gmail.com> -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to mylifeorganized@googlegroups.com. To unsubscribe from this group, send email to mylifeorganized+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en. -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to mylifeorganized@googlegroups.com. To unsubscribe from this group, send email to mylifeorganized+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
