Event/Action Log about omnidroid HOT 17 CLOSED

I can look into this.

Created a patch: http://codereview.appspot.com/126087/show

Resetting to available due to prolonged inactivity. 

I'll see about continuing this work.

This issue was closed by revision r766.

This actually shouldn't get closed as it is lacking lots of functionality still:
  ActionLog:
    Core functionality
    Sortable
    Filterable
    Customize what is logged by user
    Clear logs
  EvenLog:
    Core functionality [DONE]
    Sortable by KEY_TIMESTAMP
    Sortable by KEY_APPNAME
    Sortable by KEY_EVENTNAME
    Sortable by KEY_EVENTPARAMETERS
    Filter by KEY_TIMESTAMP
    Filter by KEY_APPNAME
    Filter by KEY_EVENTNAME
    Filter by KEY_EVENTPARAMETERS
    Customize what is logged by user (e.g. "don't log TimeTick")
    Clear logs

Some good history and reference information/discussion for possible future 
changes here:
 http://groups.google.com/group/omnidroid-devel/browse_thread/thread/828b70947a5312eb/a149c5c78eb18819?lnk=gst&q=akshah123#a149c5c78eb18819

From Ankit:

Basically, at that time (more than a year ago), we went with a "flattened" 
approach with just one table: 

LogActionHistory(ID, timestamp, FK_EVENTID, rulename, user friendly message 
with event's parameters, FK_actionID, user friendly message with action's 
parameters) 

However, i do like having a more structured approach and keeping actions in a 
"child" table.

On the contrary, I am more in favor of the one table approach. Because I don't 
think the extra complexity is necessary, unless you would like to have a 
separate view for different types of logs, with each view corresponding to a 
specific table.

I was planning to provide an interface (coming soon) that a user can choose to 
view  event logs, action logs, general logs, or all the logs in the interface.  
I agree it would be simpler to have one table on the database side, but then 
we're rather limited to what we can do with the logs.

The original concept was to allow users a way to look at the logs and see:
1) why a saved rule wasn't activated (why the actions for that rule didn't 
activate)
2) why an action was taken (what event and rule triggered it).

In developing it, I think it may provide numerous other useful features for 
example:
3) users can see all the events that are occurring so they get a better 
understanding of what events are taking place and what events they may want to 
catch
4) As Ankit pointed out, usage statics may be an interesting thing to gather 
also

For the ability to show 1), we need to present the user with a way to view all 
the events that are occurred (my last commit did most of that).  For the 
ability to show 2) we need to display actions (and what rule/event caused 
that).  Sure we could add the rule and action data to each event log, but since 
every event can result in multiple rules being activated and every rule can 
have multiple actions it could become difficult to show which rule fired which 
action and display that effectively to the user (although it could be done).  
In addition since you have that one to many relationship, storage in the 
database would end up being rather ugly since you would probably just have to 
throw it all into a long string that isn't easily machine usable.  It seems 
like the one to many relationship lends itself to a multi-table approach.  In 
addition since most of our functionality is logically separated between events 
and actions having separate tables for each one makes sense to me.

I'm open to a single table approach, but unless it provides an advantage for 
users and/or what we can do with the data, I think the multi-table approach 
seems (although it is more code) more logically separated into the standard key 
components of the rest of the app (Events/Actions) which makes it easier to 
follow.

I was just a bit worried because we sometimes have a tendency to get 
overzealous and make things too complicated. If you think that the features you 
mentioned are essential, then I have no problems with the multi-table approach.

Essential probably not, but I think it will be useful and isn't that much more 
difficult to implement now that I've implemented one log type.  Give me a week 
to whip it together and if we don't like it then, we can ditch it in favor of 
something a bit more simplified.

BTW, I know right now the Event Logs load incredibly slow because of the way 
I'm pulling all the data from the DB and because there are so many TIME_TICK 
events stored.  I have a few ideas on fixing this and am working on addressing 
that as well.

Actually, we had a related discussion in the class regarding TIME_TICK. Prof. 
Schidlowsky mentioned about the Omnidroid drains the battery life of the device 
considerably and I suspected that TIME_TICK has to do with it (needs an actual 
device to prove it with experimentation) because it will be triggered every 
minute. Chris then suggested using 
http://developer.android.com/reference/android/os/Handler.html instead of 
listening for the system broadcast TIME_TICK intent if it is indeed an issue.

Here is one approach I can think of utilizing the Handler:
1. Replace TimeMonitoringService with something like ActionSchedulerService.
2. During startup, ActionSchedulerService will then query the rules table and 
look for time triggered events. Then it will schedule sending TIME_TICK* 
intents accordingly. Note that the key here is to schedule the sending of the 
intent instead of actually performing the action to prevent action misfires 
(The rule processor will decide if there is something to do or not). We could 
probably use a Set to keep track of the times to trigger during startup to 
avoid sending the TIME_TICK intent at the same time multiple times.
3. Whenever a time related rule is created or modified, we could then send the 
id of the rule or maybe even the new time itself to the ActionSchedulerService.

* The system broadcast intent is android.intent.action.TIME_TICK, which is 
different from Omnidroid's own TIME_TICK intent.

I opened a separate ticket about this (Issue #98) to avoid muddling this ticket.

Codereview: http://codereview.appspot.com/1678044/show

This issue was closed by revision r770.