Comments (17)
I can look into this.
Original comment by [email protected]
on 9 Jun 2009 at 9:13
- Changed state: Started
from omnidroid.
Original comment by [email protected]
on 6 Aug 2009 at 9:10
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
from omnidroid.
Created a patch: http://codereview.appspot.com/126087/show
Original comment by [email protected]
on 5 Oct 2009 at 3:33
from omnidroid.
Resetting to available due to prolonged inactivity.
Original comment by [email protected]
on 6 Jun 2010 at 6:18
- Changed state: Accepted
from omnidroid.
I'll see about continuing this work.
Original comment by [email protected]
on 15 Jun 2010 at 10:36
- Changed state: Started
from omnidroid.
This issue was closed by revision r766.
Original comment by [email protected]
on 22 Jun 2010 at 7:04
- Changed state: Fixed
from omnidroid.
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 [email protected]
on 22 Jun 2010 at 7:30
- Changed state: Started
- Added labels: Priority-Low
- Removed labels: Priority-Medium
from omnidroid.
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 [email protected]
on 22 Jun 2010 at 9:43
from omnidroid.
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 [email protected]
on 23 Jun 2010 at 4:02
from omnidroid.
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 [email protected]
on 23 Jun 2010 at 5:11
from omnidroid.
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 [email protected]
on 24 Jun 2010 at 12:54
from omnidroid.
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 [email protected]
on 24 Jun 2010 at 9:55
from omnidroid.
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 [email protected]
on 24 Jun 2010 at 1:30
from omnidroid.
I opened a separate ticket about this (Issue #98) to avoid muddling this ticket.
Original comment by [email protected]
on 24 Jun 2010 at 2:38
from omnidroid.
Original comment by [email protected]
on 25 Jun 2010 at 4:50
- Added labels: Milestone-Release1.0
from omnidroid.
Codereview: http://codereview.appspot.com/1678044/show
Original comment by [email protected]
on 28 Jun 2010 at 4:12
from omnidroid.
This issue was closed by revision r770.
Original comment by [email protected]
on 29 Jun 2010 at 1:45
- Changed state: Fixed
from omnidroid.
Related Issues (20)
- Event Handler Limit Crash HOT 1
- Events not executing until lock/unlock performed HOT 12
- no market access HOT 2
- Adopt Guice
- Filter, between pre-midnight and post-midnight HOT 1
- contact groups/aliases for recipient/blacklists HOT 3
- decide whether to perform actions smartly
- An action to Enable/disable actions HOT 1
- Crash when using "Time is day of week" filter HOT 2
- Sensor data not fully utilized in some cases HOT 6
- Enhancement: Disable Data traffic on low battery HOT 2
- Trigger on Wi-Fi SSID HOT 1
- Performance improvement suggestion
- Slow operation in UI thread HOT 1
- Add phone filter : in contact / not in contact
- Enhancement request: action on enter/leave WiFi or mobile base station HOT 1
- Unlock attempt event
- Phone shut down action
- Feature request: event on wifi network available / unavailable
- wrong orders of longitude and latitude when constructing a new OmniArea object in the LocationMonitor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omnidroid.