Design of OpenPlace
- One decider class that listens for messages.
-- This class receives messages about states.
--- e.g. WIFI on/off, location entered/exited, meeting started/ended etc.
-- This class checks whether a state (or combination thereof) is active
-- This class emits messages for the actor classes, to take action on changed states.
-- The instance of this class dies if there is nothing to do. All information is stored.
- Multiple passive receivers
-- These act on broadcast messages and report to the decider class.
-- If we do not allow extension of the input part, this allows us to have only one background thread running.
- Multiple active receivers
-- These receivers take action when they are told to by the decider class.
-- Examples are turning off/on WIFI, turning on/off sound etc.
-- These can also be supplied by other projects, since nothing needs to be running in the background. They only need to listen for things the decider broadcasts.
- One configuration UI class. This class allows users to create a combination of states and combine that with some action. We can send a message to all classes that are able to act on messages to report to us, so we can include them in a combobox.
- One background service to listen for stuff that needs a REGISTERED_
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Ok my thoughts.
In a very simple point of view we should have a thread (ref. passive receiver?) listening to broadcasts and/or polling for states (if needed?). We'll stick to broadcasts for now because that would be the best solution. When a broadcast is received a set of rules should be checked (ref decider?). And when a match is found (for instance place equals brussels or time equals 12:00) some activity should be triggered (for instance disable gps, enable wireless). Users can configure rules visually.
What I did find in this blueprint is
-------
- the passive receiver (why multiple?) and/or background service as this thread listening for broadcasts.
- The decider that triggers the changes based on some rules
- the gui to configure these rules.
I do have some questions with
-------
- the decider shutting down when it has nothing to do and therefor need to fecth the rules over and over again. Wouldn't it be better for performance if these rules were loaded all the time? For instance by the thread/background service?
- both multiple states and multiple actions can be configured in the gui. One or more, don't limit to one action.
- why do we have passive and active receivers? What I understand from this blueprint is that this has something to do with the possibility to add plugins? Isn't working with interfaces enough for plugins? Then the program can discover other intents (not sure about the android details on how to do this) and use these. If the thread, decider, etc is working on interfaces this should work. Example of interfaces:
public interface Event{
public boolean isActionTrigger
public Action getTriggeredAct
}
public interface Action{
public void performAction();
}
____WLigtenberg
What I mean with passive receivers are the BroadcastReceivers that can be declared in the Manifest. These do not require a running thread but will be called upon, when the Intent is received.
For some Intents the receiver cannot be declared in the Manifest. These can only be started from running code an example is:
http://
A receiver for ACTION_
Whereas a receiver for ACTION_BATTERY_LOW can be declared in the Manifest.
Receivers that can be declared in the Manifest do not need a separate thread. All others we will put into one background thread with high priority.
As to why the decider should stay active in memory, my reply is why should it?
In Android there are specific methods to pass information about the current state to a future instance of that class. These can be used for the rules. The decider doesn't do anything in between, so why should it take up memory? We might change this, if we run into performance problems, but I do not expect this.
