- From: Rick Waldron via GitHub <sysbot+gh@w3.org>
- Date: Sun, 06 Mar 2016 23:56:02 +0000
- To: public-device-apis@w3.org
> Just for kicks changed your first example with a sensor born
deactivated
Yeah, I can see that it improves this example (one less call in the
code), but is this the most common case?
> On second thought I see now how activate/deactivate might sort of
imply hardware level actions, which isn't necessarily the case
I agree.
> start/stop
Meh.
......
Currently, when this code is written:
```js
window.addEventListener("devicemotion", event => {
// ... it just starts emitting events.
}, true);
```
...Nothing else tells it to start emitting those events
When a similar Android thing is made:
```java
public class Main extends Activity implements SensorEventListener {
private SensorManager manager;
private Sensor accelerometer;
@Override
public void onCreate(Bundle savedState) {
super.onCreate(savedState);
manager = (SensorManager)
getSystemService(Context.SENSOR_SERVICE);
accelerometer =
manager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
manager.registerListener(this, accelerometer,
SensorManager.SENSOR_DELAY_NORMAL);
}
@Override
public void onSensorChanged(SensorEvent event) {
// this will just start happening
}
}
```
...The author would have to write an explicit `onPause` and `onResume`
that actually unregistered and registered the _listener_ mechanism
(yeeeeesh).
Anyway, I just learned how to write a crappy accelerometer output app
with swift. Considering the amount of boilerplate crap involved in
both the Android version and iOS version, I think whatever we choose
will be better.
--
GitHub Notification of comment by rwaldron
Please view or discuss this issue at
https://github.com/w3c/sensors/issues/88#issuecomment-193018227 using
your GitHub account
Received on Sunday, 6 March 2016 23:56:04 UTC