- From: Rick Waldron via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Jun 2015 20:07:56 +0000
- To: public-device-apis@w3.org
> If all you are doing is listening to a single sensor for the life of a program and taking no action beyond updating a variable, composition won't be very interesting to you. This is most real world use cases. These things are long running and serve only to update and inform some other operation: - Checking Proximity of face to device to automatically (so you don't cheek press) - Any environmental monitor that affects change via output to any kind of effectors (eg. smooth display updates based on any number of sensory inputs, eg. updating the screen brightness by monitoring ambient light) - Controlling the position of a drone by updating its PID controllers with data from a smart phone's gyro and accelerometer, which are being used as a virtual "joystick" in a remote control app (see: FreeFlight 3, or anyone that works on a modern farm) - Monitoring moisture in the surrounding environment (don't drop your phone in the toilet) - Controlling the volume of headphones based on ambient sound level (good for ignoring everyone on crowded noisy subways) - Monitoring heart rate via a built-in smartwatch sensor - Ambient temperature monitoring, coupled with an algorithm that uses Compass, Acceleration, GPS and GSM location data, which sends a message to central "smart home" system to adjust where you are to who you are, and readjust/balance to any other user of the same system. - GPS/Compass/GSM data to track person or vehicle while using turn-by-turn directions - GPS/Compass/GSM data is also used to make "traffic" display more accurate - ^^ + Accelerometer/Gyroscope for monitoring a bike ride, walk, jog, etc. - All of the above for any kind of game. Here's an example that the `sensor.takeWhile` form might be useful for: - Fingerprint validation. (but can still be done without it) > My suspicion is that there are many use cases for combining sensors into new more complex sensor streams. Yes, PID controllers, fusion algorithms, etc. but the API doesn't have to more than `object.value` for those to be easy and awesome to write. > sensor1.takeWhile(pos => pos.x - pos.y) > This creates an observable which ends when the condition is met. What is the condition? Truthy-ness/falsey-ness of the return value? > Without an explicit completion semantic in EventTarget, building either of these methods isn't possible. We'd have to add more semantics to EventTarget to make that happen. Or not at all because it's not immediately obvious (or even remotely evident) that this is a desirable semantic trait that befits a solution for the most common use cases. -- GitHub Notif of comment by rwaldron See https://github.com/w3c/sensors/issues/21#issuecomment-108081529
Received on Tuesday, 2 June 2015 20:07:57 UTC