Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sensor Type in SphericalSurfaceView class #5119

Closed
Sylvain-interactive opened this issue Nov 19, 2018 · 8 comments
Closed

Sensor Type in SphericalSurfaceView class #5119

Sylvain-interactive opened this issue Nov 19, 2018 · 8 comments
Assignees
Labels

Comments

@Sylvain-interactive
Copy link

Hi,
Would it be possible to choose the Sensor type between TYPE_GAME_ROTATION_VECTOR and TYPE_ROTATION_VECTOR or change the way it is selected in the SphericalSurfaceView class by checking if the TYPE_GAME_ROTATION_VECTOR is present in the device.

Because my device, a Samsung SM-T700 API 23 does not possess the TYPE_GAME_ROTATION_VECTOR but your check "Util.SDK_INT >= 18 ? Sensor.TYPE_GAME_ROTATION_VECTOR : Sensor.TYPE_ROTATION_VECTOR" return the TYPE_GAME_ROTATION_VECTOR so there is only the touch mode that is enabled but with the TYPE_ROTATION_VECTOR it works. So could it be possible to set to TYPE_ROTATION_VECTOR ?

Thank you for your concern.

@ojw28
Copy link
Contributor

ojw28 commented Nov 23, 2018

If TYPE_GAME_ROTATION_VECTOR is optional and we're not implementing a fallback, I'd consider this a bug?

@Sylvain-interactive
Copy link
Author

It is not a bug, I ask if it is possible to choose the type of sensor used by the SphericalSurfaceView, like choose the TYPE_ROTATION_VECTOR when the TYPE_GAME_ROTATION_VECTOR is not available in the device.

@ojw28
Copy link
Contributor

ojw28 commented Nov 26, 2018

Why shouldn't the code just automatically fall back to TYPE_ROTATION_VECTOR if TYPE_GAME_ROTATION_VECTOR is not available? I don't understand why application code should need (or want) to choose.

@NicoIM
Copy link

NicoIM commented Nov 26, 2018

TYPE_ROTATION_VECTOR is an exemple. On some of our devices the TYPE_GAME_ROTATION_VECTOR is not supported, we have to use another rotation vector.

We would like to be able to chose any type of rotation vector to use instead of the TYPE_GAME_ROTATION_VECTOR.

@ojw28
Copy link
Contributor

ojw28 commented Nov 26, 2018

I'm not convinced there's a good use case for choosing an arbitrary type. There's probably always a correct type to be using, and it's probably TYPE_GAME_ROTATION_VECTOR if it exists, and TYPE_ROTATION_VECTOR otherwise. In which case the library should just do that for you. In practice are you actually going to want to set it to a different value, and if so, what's the use case for doing so?

@NicoIM
Copy link

NicoIM commented Nov 26, 2018

Yes that would be perfect.

The fact is in the SphericalSurfaceView the code that chose the rotation vector is:
int type = Util.SDK_INT >= 18 ? Sensor.TYPE_GAME_ROTATION_VECTOR : Sensor.TYPE_ROTATION_VECTOR;

It doesn't check if device supports it or not. It only check it's sdk version.

@ojw28
Copy link
Contributor

ojw28 commented Nov 26, 2018

I assume orientationSensor ends up being null if the device doesn't support it?

@Sylvain-interactive
Copy link
Author

yes it's null

andrewlewis pushed a commit that referenced this issue Nov 27, 2018
@ojw28 ojw28 closed this as completed Nov 27, 2018
ojw28 added a commit that referenced this issue Nov 28, 2018
@google google locked and limited conversation to collaborators May 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants