Clocking / Time Capture about orgzly-android

[aancel]

Hello,

@nevenz I would like to help implementing this feature (if you want and are not already working on this).
I've read the previous discussions, and notably your last one about searching/replacing the content when needed (#15 (comment)).

I have made some tests with the latest master version and I currently have a basic version that can insert a clock state within the LOGBOOK drawer of a note using quick bar buttons. I currently can handle clock-in, clock-out and clock-cancel (just simple insertions for now). The only thing that is missing is handling the clocking logic (Find the last clock-in to apply a clock-out, delete clock-in via clock-cancel ...), but it shouldn't be too difficult.

I can open a PR, once the clocking logic is setup !

[k0105]

OK, let us at least think about it.
We only need three options: Start (org-clock-in), stop (org-clock-out) and cancel (org-clock-cancel).
When you clock in, the time is encoded and inserted.
So all org-clock-in does is add a new line under the Task entry like this:

* TODO Test
  CLOCK: [1927-01-23 Tue 12:34]

When we clock out (org-clock-out) it finds this line and adds the current time in the same format after it, subtracts it from the first time and adds the time passed as well, e.g.

* TODO Test
  CLOCK: [1927-01-23 Tue 12:34]--[1927-01-23 Tue 12:39] =>  0:05

Note: Org only adds up the current line's time. If other lines exist, they will not be taken into consideration in what is written to the line. There are two ways Org delivers total time: a) It is shown in the status bar while you're clocked in. b) You can hit C-c C-x C-d (org-clock-display) to (temporarily) add the total time to the top task. When you clock in again, the total time will be removed. I think we should deviate from this and always indicate and update the total time. Cancel cancels clocking, i.e. removes an empty clock line if it exists.

Now, to be exact Org does another thing: It checks whether you are already clocked in. If you are (only indicated by the text - you could add the unclosed line manually and it would assume you're clocked in), it will offer you resolution options. For me it would be fine if we ignored this - if there's a CLOCK: line we overwrite it.

I'm a bit rusty in Android, but in standard Java the time should just be a matter of

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd EEE HH:mm");
LocalDateTime.now().format(formatter)

We should be able to directly subtract times and the resulting format has to be

  CLOCK: [firstTimestamp]--[secondTimestamp] =>  0:00

Additionally, MobileOrg created a notification when you clock in, which is a neat way to quickly see and stop (cancel or pause) the current task. This article should explain the basic way to do that: http://www.vogella.com/tutorials/AndroidNotifications/article.html

There is another killer extension: Estimates. With those you can define an estimate of how long you think this task will take and show your clocked time in reference to that, e.g. via column mode. See the documentation here: http://orgmode.org/manual/Effort-estimates.html#Effort-estimates Essentially, it adds a properties drawer with the effort value like this:

  :PROPERTIES:
  :Effort:   0:30
  :END:

So that's easy, the displaying part might be more involved, esp. in the agenda.

Unfortunately, I won't be able to contribute code over the next time, since we're still pulling 80 hour weeks, but maybe this post can still serve as a first step. Do my remarks make sense? Anything else we should look into / design / keep in mind?

PS:
This might solve the notification part: #26

PPS:
As far as I can tell, this is tied (with #58) for being the second most requested feature after #8 if thumbs ups are used as popularity metric.

PPPS:
Here is the Org mode reference if anyone needs to look up something: http://orgmode.org/manual/Clocking-commands.html

[nevenz]

FWIW, I've started working on drawer parsing for #88 and #307. They are scheduled for v1.6.4. Folding (with temporary unfolding) is pushed to master already.

Initially, it's going to be implemented by simply searching & replacing the content when needed. No org-java parsing, storing separately to DB and such.

I'm keeping clocking in mind and will try to work on it for v1.6.5 (with hopefuly more frequent releases -- this last one is taking way longer then I'd like).

[nevenz]

I'm not an android developer, so I may take a while to get accustomed to the code base. @nevenz it would be great if you could point me to commits where similar changes are made.

Parsing :LOGBOOK: and being able to easily access its entries would be a great start. This work would also benefit some other features (like recording state changes for habits).

You should probably check org-java first. No Android there, but needs some work to support this. OrgHead has both clock and logbook and neither of them are parsed. logbook is just List<String> now, that should probably be List<LogbookEntry>, clock being one of those LogbookEntry implementations... something along those lines.

As a first implementation, I'm thinking of having the clocking in and out handled completely internally: i.e. the entry is only written when both the clock in and out action is completed.

That makes sense. I don't even know if keeping the clock across devices would be useful?

You would need to store the clocked-in time somewhere though, but a simple preference would do (see AppPreferences#lastSuccessfulSyncTime for the closest thing).

After that, just storing complete clock entry in the content would be good enough for the first version (using improved OrgHead to parse, update and generate content).

Second pass would be keeping logbook entries and clock separately from the content, for easier/faster access, displaying them in the app, folding :LOGBOOK: etc.

Anyway, if there's anything that needs explaining, do ask. Thanks!

[codygman]

I'd be happy to sponsor this feature as well.

[gekaklam]

Hi, given that #76 (which I guess should be related) is now resolved, are there any plans for supporting this feature? I'm also using Emacs heavily for time-tracking my tasks, and I'd love to be able to track what I'm doing through a buffer in Orgzly, even when I don't have my laptop around.

[alphapapa]

This would be really great. I use Org for time-tracking too, but that means I have to have Emacs next to me. I'd love to be able to clock in and out with Orgzly. :)

[k0105]

It's been over a year. I have since given up on ever having time to participate, but still need this feature. Has this been added to any roadmap / is there an ETA? Also: If I can't contribute directly, is there a way to support the implementation of this feature financially? I would be interested in either buying a premium version of Orgzly (for $5 or so) or, even better, contributing money directly to get this particular feature implemented while keeping the software free, e.g. by paying $100 [I assume others would have to chime in as well - $100 is not much for developing an entire feature].

Would this help? If not, what is the fastest way to get this done, i.e. what are the exact steps to wrap up PR 4 and have a basic clocking feature without fluff like estimates or cross-device clocking? Could we get an updated Org todo list with the exact steps? What remains to be done after the progress in orgzly/org-java#4 ? And would it help if I implement anything in native Java [where I'm an order of magnitude faster than in the unfamiliar Android environment]?

Here is a naive todo list:

• TODO Time Tracking Feature
  ** TODO Parse :LOGBOOK: and be able to easily access its entries, i.e. add parsing of clock and logbook entries to OrgHead in org-java
  *** TODO Refactor logbook from List to List, clock being one of those LogbookEntry implementations
  ** TODO First implementation: Clock in and out handled completely internally, i.e. entry is only written when both the clock in and out action is completed, stored like AppPreferences#lastSuccessfulSyncTime, store complete clock entry in content using improved OrgHead to parse, update and generate content
  ** TODO Refactor: Keep logbook entries and clock separately from the content (for easier/faster access, displaying them in the app, folding :LOGBOOK: etc.)
  ** TODO Add "fluff" like effort estimates

[stfl]

+1

[Rbagman]

I second the clocking feature.

I'm also surprised this app is open. Thanks!

[jethrokuan]

I'm quite invested into the time-tracking feature provided by org-mode, and would like to help make this happen with orgzly. The above post is a good start, but I believe most of the clock entries goes into the :LOGBOOK: drawer, which is currently not parsed. That would be where I'd start looking into.

I'm not an android developer, so I may take a while to get accustomed to the code base. @nevenz it would be great if you could point me to commits where similar changes are made.

As a first implementation, I'm thinking of having the clocking in and out handled completely internally: i.e. the entry is only written when both the clock in and out action is completed.

[jethrokuan]

Thanks for the detailed walkthrough, I'll look into them in a week when my schedule clears!

[Chobbes]

This is something that I would love to have as well. Being able to clock time on my phone would vastly improve my time tracking.

One suggestion that I might have is the ability to make widgets or shortcuts for clocking in / out of specific tasks.

[gnusosa]

Could we utilize some of the approaches from the now defunct MobileOrg? matburt/mobileorg-android@a9441d9

[debanjum]

Could we utilize some of the approaches from the now defunct MobileOrg? matburt/mobileorg-android@a9441d9

The associated PR for a more complete reference: matburt/mobileorg-android#204

[xx299x]

I second the clocking feature too.

[michaelsjackson]

Just suggested another clocking related feature here #869 . Maybe also interesting for any of you? Thanks friends. Org power to the voice.