Sergey, I think you have it right: use the underlying Browser implementation if possible, or call fail() otherwise is the right solution for cordova-browser implementations.
Ripple will stub out its own implementation if it wants to control a fake data stream. Mixing fake data into cordova-browser implementations sometimes but not always will not help developers. I do not think this is inconsistent, cordova-browser can be used for simple development/debugging or production, and ripple can be used for more feature rich simulation. -Michal On Mon, Dec 22, 2014 at 4:29 AM, Sergey Shakhnazarov (Akvelon) < [email protected]> wrote: > Hello all, > > I wanted to discuss the way we should handle unsupported functionality > like plugin-device-motion[1] or plugin-device-orientation[2] in the desktop > browsers. > > Chrome fires the corresponding events with null data fields on the desktop > (Firefox and IE don't even fire them), > so the question is whether the Browser platform should rely on the real > browser implementation if it is supported and do something like fail('Not > supported ... [method signature details]') otherwise? > > In this particular case the Browser platform is being used as a testing > tool like Ripple, which is a bit inconsistent with the preceding assumption. > > Please let me know if you have any questions or considerations. > > [1]: > https://github.com/apache/cordova-plugin-device-motion/blob/master/src/browser/AccelerometerProxy.js#L26,L28 > [2]: > https://github.com/apache/cordova-plugin-device-orientation/blob/master/src/browser/CompassProxy.js#L26 > > Best regards, > Sergey Shakhnazarov. > >
