are you working on a V2 for Android ?

4 views
Skip to first unread message

robisme

unread,
Nov 13, 2013, 7:23:46 PM11/13/13
to MLO-A...@googlegroups.com
Hi,
All in the title, I can't wait to see a new version on Android.

Dwight Arthur

unread,
Nov 14, 2013, 6:49:52 PM11/14/13
to MLO-A...@googlegroups.com
Hi. I cannot tell you what may be going on inside the MLO Development labs, but I can tell you that there isn't any big ndroid release in beta testing right now. The mobile development team is dedicated to bringing out a new, redesigned-from-the-ground-up iPhone version, and it's my unoficial opinion that we will see it ported to Android after it's stable on iPhone.

Normally I don't pay much attention to iPhone releases but this time, it might be worth looking into it for a preview of what's to come on Android.
-Dwight

MRF

unread,
Nov 15, 2013, 6:08:32 AM11/15/13
to MLO-A...@googlegroups.com
My guess the iPad version will come 1st then....which I use, so that's ok..

I was hoping for a big update to the Android version though...which is my primary mobile device...

Nick Clark

unread,
Nov 16, 2013, 10:09:03 AM11/16/13
to MLO-A...@googlegroups.com
I'm interested to know what you hope a new Android version will bring. I think the current Android beta version is the most functional of all the mobile versions, including the iPad and iPhone2 versions. The main items I'd like to see added are the ability to add/edit dependencies and more recurrence options.

Nick

MRF

unread,
Nov 18, 2013, 12:26:43 AM11/18/13
to MLO-A...@googlegroups.com
Nick,

For me the main ones that come to mind are;

More recurrence + regenerate (I.e x time period after completion)
Dependencies, add and edit
Review add + edit
Custom views

MRF

unread,
Nov 18, 2013, 1:51:11 AM11/18/13
to MLO-A...@googlegroups.com
I forgot flags..... This would really make the mobile versions more useful for me..

MOK | MATSURU

unread,
Nov 20, 2013, 9:27:18 AM11/20/13
to MLO-A...@googlegroups.com

+1 for flags

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized for Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MLO-Android...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Message has been deleted

MOK | MATSURU

unread,
Nov 23, 2013, 4:45:46 AM11/23/13
to MLO-A...@googlegroups.com

Date picker like Google calendar style is also not bad.  :-)

On 22 Nov 2013 19:29, "robisme" <robillar...@gmail.com> wrote:
I'd like formating (colors, highlight, icons), and a view with the note section displaying on half the screen, with ability to navigate from task to task and viewing the relevant notes without having to actually enter the task preview.
more, I'd like auto sync like evernote does ; idealy, also when entering a new task from the shortcut "new task", without having to open MLO app.
finally, I'd like a new date and time picker, more like the Business Calendar app's one, which is, imho, the best of all the android market.

Olivier

Joel

unread,
Jan 6, 2014, 6:35:54 PM1/6/14
to MLO-A...@googlegroups.com
Since my iToy 4 broke I no longer have an apple device so can't try the v2 but there are certainly things to want for on the Android version, regardless of the state of affairs in iLand. 

Frankly at the top of my list would be feature parity with the desktop in terms of views configuration and not the hard-coded stuff we have now.  It doesn't work for every case and often there is no work around but to resort to the desktop. This is perhaps the single main thing that forced me to abandon MLO.   Call me nuts but I don't think it should be wishful thinking to have mobile versions that don't make me wish I'd brought my laptop.

Push notification to every platform/device and user -  Can we finally do away with archaic tradeoffs regarding battery-life vs how often to poll for changes?
Push notification has been in Android I believe since v2.2 or 2.3 and most certainly is in 4.0+.  This uses less battery and eliminates user having to BS with tracking or remembering to sync before checking/doing something, just in case someone else has gotten to it first.  iOS has ALWAYS been a push based eco-system relying on Apples servers. Why this isn't leveraged is at least a little puzzling to me.
Leaving only the Win/Wine desktop client...  I have little to no question that implementing a change-push functionality should be quite very possible on a full blown desktop OS.

Speaking of sync, how about a little trick called *merging* of changes instead of clobbering 1 side or the other when more than 1 device/user makes a change to a record?  Push may remedy much of this btw, by closing the "window" that 2 changes may collide but still, the merging thing has been a worked out commodity for more than a few years..  Why are we still using sync methods, and dealing with issues, left over from the Palm Pilot days?


Those 3 alone are huge.


And they apply to the iLand as well.

Utimately I'd request/expect feature parity across devices (I understand resources may be/are limited but figuring out how to develop all platforms in relative unison should be a high priority imho.)  I would expect that of any developer that has a multi-platform ware.
I believe its draining and difficult model to sustain development across 3 (+iPad - 4?) platforms when only 1 is ever progressing.  That means at any point in time, the other 3 are falling behind.  Further, developing features and rolling them out to just 1 subsector of your users, and especially when it's highly likely that a given user in that subsector also uses other versions simultaneously, is just a strategy for mediocrity at best imho.   Is it not understood that as a user, features and improvements to my workflow on one platform will most likely be wanted/needed on another platform I use as well?  And what of the unlucky MLO user that is vested in 3 or all 4 platforms?  How frustrating it must be that the user experience is never consistent.  How unfortunate to be the owner of 4 devices and be holding the wrong one for a given to-do list task - would that not frustrate you badly?

I realize that's part of why 'cloud services' have proliferated so sharply and I appreciate Andre's commitment to the fat client instead.
But all this stuff still has to get addressed and really, sooner rather than later.

IMHO.



J.

tg2k

unread,
Jan 11, 2014, 12:07:13 PM1/11/14
to MLO-A...@googlegroups.com
I don't use it myself, but MLO has a cloud sync option. It's a separate paid service (and rightly so as it costs money to maintain) and might address some of your concerns.

JAz

unread,
Feb 16, 2014, 1:39:44 AM2/16/14
to MLO-A...@googlegroups.com
On Saturday, January 11, 2014 12:07:13 PM UTC-5, tg2k wrote:
I don't use it myself, but MLO has a cloud sync option. It's a separate paid service (and rightly so as it costs money to maintain) and might address some of your concerns.


Is that directed towards me?  I'm curious what you believe MLO cloud sync would solve for me.  
My comments about sync clobbering rather than merging were about cloud sync in particular (though the previous wifi sync suffered the same) so I'm curious. 
If it wasn't directed at me just feel free to ignore.

Dwight Arthur

unread,
Feb 16, 2014, 10:01:09 AM2/16/14
to MLO-A...@googlegroups.com
Hi, Jaz. For the most part I agree with you, but I have a couple of comments.

I would also like to see (and have posted as much elsewhere) a grown-up fullfeatured mobile app that would free me from running back to my Windows system every time I want to set a flag, create a biweekly recurrence, etc. But in requesting this we need to recognize the the MLO organization derives a lot of its revenue from the Windows app. There are a lot of possible strategies for replacing the lost revenue - the best one is skillful marketing of the fullfeatured mobile app so that it becomes immensely popular. But if that doesnt work we would need to understand that other kinds of fees may be explored.

Also, about merge versus clobber - it's all about the granularity. MLO does a great job of merging changes as long as the changes on each side do not involve the same specific task. (well, almost. see footnote 1). In this, it is far superior to approaches like dropbox where the whole file from one side overwrites the whole file from the other side. In the event that updates within a single task collide, I agree that MLO/Android's handling is unacceptably simplistic (you have to pick whether the local copy always wins or the remote copy always wins and neither strategy is always right). The Windows system displays the differences between the two versions of the task and asks the user to pick which one to keep. I like that and I would be happy if the mobile versions did the same. It sounds like you are looking for a field-by-field merge within a record. I would oppose that: there are too many cases where the meaning of the fields depends on other fields, by merging you could create a meaningless result. see footnote 2. As you mentioned, near-instant push sync in both directions eliminates the need for clever merge logic. I have worked with clever merge logic on various platforms for about 20 years and I hate it. Sooner or later no matter how clever it always gets something wrong, and the more clever the logic the more difficult it is to deduce what exactly it did to destroy my data and the more difficult to find a way to restore the data.
-Dwight

footnote one: MLO is unable to figure out the following situation: a recurring task or project has two or more subtasks and is set to recur when all subtasks are complete. All subtasks are complete but some of them are marked complete on one platform and some on the other. Sync will create on both sides, an uncompleted parent with all subtasks complete but still no recurrence of the parent.

footnote two: the same recurring parent with subtasks, at least two subtasks incomplete, all with today's date. On one side I complete one of the open tasks, so now it is complete with today's date. On the other side, I decide that I am not going to work on this project anymore and will take care of the open tasks when I do tomorrow's instance of this project, so I mark the project complete, forcing recurrence of all subtasks. The task in question is now uncomplete with tomorrow's date. A field-by-field most-recent-update merge of this task across the two platforms will produce a completed copy with tomorrow's date, indicating that I have already completed this task for tomorrow, which is untrue. We could write exception logic to handle this case, as well as the many other cases that will emerge over time but that will be a long and expensive process and many exceptions once implemented will give rise to new exceptions leading the developers to tweak the tweak.

MRF

unread,
Feb 21, 2014, 2:01:31 AM2/21/14
to MLO-A...@googlegroups.com
I don't think they have too much to fear about loss of revenue, in my experience most users will want a full blown desktop app, even if its just for the convenience to crashing in a huge amount of tasks for a new project etc.  But MLO desktop also gives import capabilities, I personally use it to get in tasks from mindmaps, and Outlook etc.... for my part I would have always have both.  But like you Dwight, I would really like MLO Android or iOS to have most of the core capabilities, so when I am travelling I can enter things properly, not have to wait until I get back to home or the office to then have to re-visit things twice...

JAz

unread,
Feb 21, 2014, 10:58:11 PM2/21/14
to MLO-A...@googlegroups.com
Hey Dwight,

Sorry for the delayed reaction, time is in ever short supply the last few weeks..
See my replies in context


On Sunday, February 16, 2014 10:01:09 AM UTC-5, Dwight Arthur wrote:
Hi, Jaz. For the most part I agree with you, but I have a couple of comments.

I would also like to see (and have posted as much elsewhere) a grown-up fullfeatured mobile app that would free me from running back to my Windows system every time I want to set a flag, create a biweekly recurrence, etc. But in requesting this we need to recognize the the MLO organization derives a lot of its revenue from the Windows app. There are a lot of possible strategies for replacing the lost revenue - the best one is skillful marketing of the fullfeatured mobile app so that it becomes immensely popular. But if that doesnt work we would need to understand that other kinds of fees may be explored.

I believe we are more in agreement than not but I fear you've read too much into my request.  When I say full featured mobile and/or 'not force me to look for a laptop' I mean that I should be able to handle my daily affairs of collection and doing without needing anything more the the device in front of me.  That specifically implies certain parities like being able to sync [at least some] views between the platforms.  Most of my views are how I work (e.g. *doing*) and I need that consistent across all touch points with MLO.  Anything less should be continually improving.

As far as the lost revenue - hogwash.  MLO A cannot and should not ever replace the desktop*.  MLO A is a companion to the desktop, a part of a system which includes the desktop and should never pull any punches doing so.  And by that it is/becomes a conduit to the desktop system.
Now, that sales of the desktop are the main source of revenue is it's own issue. (I'm of the opinion that MLO could benefit substantially from a pricing/biz model change but let's leave that for another time.)
 

Also, about merge versus clobber - it's all about the granularity. MLO does a great job of merging changes as long as the changes on each side do not involve the same specific task (well, almost. see footnote 1). In this, it is far superior to approaches like dropbox where the whole file from one side overwrites the whole file from the other side.

While this might be true it's a straw-man argument imo.  
#1  Dropbox is a file sharing/availability platform.  It has no direct bearing on any kind of database sync discussion and is irrelevant (regardless of how many ppl insist on trying to share their MLO or other databases using it.)  

#2  We have had this same granularity of sync going back to 1994 (earlier even) on the Palm platform (1994 is 20 years ago for the mathematically challenged.)  How is it that we're still bumping up on remnants of 20 year old technology?   Coincidentally, by 2000-2002 or so, pretty much every Palm app I cared about had worked out the sync/clobber issue for themselves so in reality, this was solved already 10 years ago.  
But it's still part of my experience in MLO today and I feel like it never should have been.
Regardless, it's 2014.  It's more than past due to be addressed.


In the event that updates within a single task collide, I agree that MLO/Android's handling is unacceptably simplistic (you have to pick whether the local copy always wins or the remote copy always wins and neither strategy is always right). The Windows system displays the differences between the two versions of the task and asks the user to pick which one to keep. I like that and I would be happy if the mobile versions did the same. It sounds like you are looking for a field-by-field merge within a record.

No.  Let me correct you here:  not a 'field-by-field' merge a field-by-field comparison.  Quite often the changes on either side (at least in my experience and observation) are NOT to the same field (completion and maybe due date being marginal exceptions)
In these cases just sync the updated fields correctly and you've solved the problem to my satisfaction.

I agree trying to get tricky actually merging a field with changes on both sides is a losing battle and would not advocate.
Additionally, agree that MLO A should gain a mechanism similar to desktop for manually approving/managing sync conflicts.  (<== good example of the kind of 'parity' I was advocating in prior paragraph)

I would oppose that: there are too many cases where the meaning of the fields depends on other fields, by merging you could create a meaningless result. see footnote 2. As you mentioned, near-instant push sync in both directions eliminates the need for clever merge logic. I have worked with clever merge logic on various platforms for about 20 years and I hate it. Sooner or later no matter how clever it always gets something wrong, and the more clever the logic the more difficult it is to deduce what exactly it did to destroy my data and the more difficult to find a way to restore the data.
-Dwight

(just for the record, totally agree w/ you here.  I'm in home automation.  When programming ppls homes to match their lives, often have to be cautious/resist/steer away from what we call "over automating".  Exactly because the more 'clever' you think your programming is the more pain in the derriere it eventually becomes)
 

footnote one: MLO is unable to figure out the following situation: a recurring task or project has two or more subtasks and is set to recur when all subtasks are complete. All subtasks are complete but some of them are marked complete on one platform and some on the other. Sync will create on both sides, an uncompleted parent with all subtasks complete but still no recurrence of the parent.

This is a fairly detailed edge-case but it sounds more like a bug in sync logic rather than a fundamental flaw, no?
 

footnote two: the same recurring parent with subtasks, at least two subtasks incomplete, all with today's date. On one side I complete one of the open tasks, so now it is complete with today's date. On the other side, I decide that I am not going to work on this project anymore and will take care of the open tasks when I do tomorrow's instance of this project, so I mark the project complete, forcing recurrence of all subtasks. The task in question is now uncomplete with tomorrow's date. A field-by-field most-recent-update merge of this task across the two platforms will produce a completed copy with tomorrow's date, indicating that I have already completed this task for tomorrow, which is untrue. We could write exception logic to handle this case, as well as the many other cases that will emerge over time but that will be a long and expensive process and many exceptions once implemented will give rise to new exceptions leading the developers to tweak the tweak.

Again, very detailed case.  While I'm not sure what flaw in the existing sync logic leads to this set of circumstances I don't see it as a case of tweak-per-case-per-tweak as you do.  Obviously any discussion of this, here and now, is pure speculation on my part but from your description I would think this and similar types of anomalies could be fleshed out by an iterative process of sync.
Another possibility is that tasks not sync based on trivial datum like task name/description but rather maintain a Key field or G/UUID, for each record thereby addressing any and all change/sync oriented anomaly/duplication.
The second option of course requires major rework of the MLO DB schema so I wouldn't expect it any time soon.
I WOULD however, hope that this already on the radar and roadmap, perhaps for v5 branch.

robert roszak

unread,
Mar 10, 2014, 7:28:38 AM3/10/14
to MLO-A...@googlegroups.com
Can anyone from developer's side provide us with even very preliminary roll-up date? 
Reply all
Reply to author
Forward
0 new messages