Proposal for context management
|Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.|
The Context section of the new framework could be used to choose between a number of profiles that determine which services are running, the settings for outputs and what events will interrupt the current in-focus application and deliver outputs. These profiles could be overridden by individual rules selected by the user.
If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required. All profiles can of course be edited by the user and new profiles defined. The profiles will have to be prioritised.
Each profile would have a defined set of criteria in which it will become active. The system checks through each set of criteria in priority order and assigns the first which matches.
Within X meters of GPS co-ordinates YY:ZZ.
Gesture or position reported by accelerometers
Current time and/or date
A particular application has focus
A profile can define:
Which services are active; GSM, BT, WiFi, GPS
What events will interrupt the current application; Call, Message, Alarm
Output settings; Volume, vibration, screen brightness
A "profile rule" can be set to override a particular aspect of the currently active profile.
If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on or another profile is selected.
Some examples of context choosing a profile:
Phone face down at rest for >5 seconds -> SLEEP
Battery power below 20% -> LOW-POWER
GPS registers position as within 100m of "home" -> HOME
GPS registers position as within 500m of "work" -> WORK
Time between 1900-2330 -> PUB
Time between 2330-0500 and within 5km of "city centre" -> CLUB
No context match -> DEFAULT
"home", "work" and "city centre" all defined by GPS co-ords by user.
These profiles are in priority order so if the phone is face down battery power, GPS position and time will make no difference. If you are at home the PUB and CLUB profiles will not be engaged.
Examples of profile definition
Interrupts= Call, Message, Alarm.
Outputs= Volume, Vibration and Screen Brightness.
SLEEP: All service off, call & message interupts off, volume & vibration normal, screen off
LOW-PWR: GSM on BT,WiFi,GPS off, all interupts on, volume & vibration normal, screen max 50%
HOME: All service on, call & message interupts on, volume & vibration normal, screen normal
WORK: All service on, call & message interupts on, volume silent, vibration normal, screen normal
PUB: All service on except BT, call & message interupts on, volume silent, vibration normal, screen normal
CLUB: GSM GPS on BT,WiFi off, call & message interupts on, volume loud, vibration normal, screen 50%
DEFAULT: All service on except BT, call & message interupts on, volume & vibration normal, screen normal
D.N.I.: All service on, call & message interupts off, volume & vibration normal, screen normal
D.N.I (do not interrupt) is an example of a non-context driven profile.
No context driven system will be fool-proof but I think in this way we can build a relatively simple system that can have quite complex behaviour and importantly can be overridden and turned off quite simply.
Profile selector with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.
Context editor to define events and match them to profiles
Also needed (will be needed for other apps too I think):
Method of defining and tagging gestures eg "face-down"
Method of tagging GPS co-ords to define "home" etc.
I hope that this makes some kind of sense.