Closed GoogleCodeExporter closed 9 years ago
I can look into this.
Original comment by akshah...@gmail.com
on 9 Jun 2009 at 9:13
Original comment by akshah...@gmail.com
on 6 Aug 2009 at 9:10
Created a patch: http://codereview.appspot.com/126087/show
Original comment by akshah...@gmail.com
on 5 Oct 2009 at 3:33
Resetting to available due to prolonged inactivity.
Original comment by case.and...@gmail.com
on 6 Jun 2010 at 6:18
I'll see about continuing this work.
Original comment by case.and...@gmail.com
on 15 Jun 2010 at 10:36
This issue was closed by revision r766.
Original comment by case.and...@gmail.com
on 22 Jun 2010 at 7:04
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
Original comment by case.and...@gmail.com
on 22 Jun 2010 at 7:30
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.
Original comment by case.and...@gmail.com
on 22 Jun 2010 at 9:43
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.
Original comment by renc...@gmail.com
on 23 Jun 2010 at 4:02
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.
Original comment by case.and...@gmail.com
on 23 Jun 2010 at 5:11
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.
Original comment by renc...@gmail.com
on 24 Jun 2010 at 12:54
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.
Original comment by case.and...@gmail.com
on 24 Jun 2010 at 9:55
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.
Original comment by renc...@gmail.com
on 24 Jun 2010 at 1:30
I opened a separate ticket about this (Issue #98) to avoid muddling this ticket.
Original comment by case.and...@gmail.com
on 24 Jun 2010 at 2:38
Original comment by case.and...@gmail.com
on 25 Jun 2010 at 4:50
Codereview: http://codereview.appspot.com/1678044/show
Original comment by case.and...@gmail.com
on 28 Jun 2010 at 4:12
This issue was closed by revision r770.
Original comment by case.and...@gmail.com
on 29 Jun 2010 at 1:45
Original issue reported on code.google.com by
case.and...@gmail.com
on 5 Jun 2009 at 9:48