Few questions/issues.

[andr3wmac]

1. Is the (i) icon in the bottom left hand corner intentional? Is there a way to get rid of it? Here's a screenshot to show what I'm talking about: http://i.imgur.com/vWBLMkw.jpg

2. Are there any functions/flags that I can set to switch to fullscreen/non-fullscreen and turn VR on/off other than the buttons included in the player which can be enabled/disabled? In other words, how can I implement a custom fullscreen and VR button? I haven't been able to find them but maybe I'm missing something?

3. Is there anyway to disable or implement a custom Insert Into Viewer screen? Also, what is the intended functionality to hide said screen when a user is presented with it? I've found sometimes it never goes away, sometimes it goes away rather quickly. Motion of the device seems to possibly impact it? Is it on a timer?

[nathanmartz]

Hi. The (i) is intentional and designed to let users and other developers
understand the feature. It links to a Google help center article. We do not
currently allow developers to disable it. Can you give more context on why
you want to disable it?

We do not currently expose these functions. More context on your use case
would help inform future API decisions.

We don't currently allow a custom transition screen but we have considered
it. The screen goes away when you turn the phone landscape or press back.

On Tue, Apr 12, 2016, 9:18 AM Andrew Mac notifications@github.com wrote:

1. Is the (i) icon in the bottom left hand corner intentional? Is there a
   way to get rid of it? Here's a screenshot to show what I'm talking about:
   http://i.imgur.com/vWBLMkw.jpg

2. Are there any functions/flags that I can set to switch to
   fullscreen/non-fullscreen and turn VR on/off other than the buttons
   included in the player which can be enabled/disabled? In other words, how
   can I implement a custom fullscreen and VR button? I haven't been able to
   find them but maybe I'm missing something?

3. Is there anyway to disable or implement a custom Insert Into Viewer
   screen? Also, what is the intended functionality to hide said screen when a
   user is presented with it? I've found sometimes it never goes away,
   sometimes it goes away rather quickly. Motion of the device seems to
   possibly impact it? Is it on a timer?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9

[andr3wmac]

We're developing a 360 degree video app. We use the cardboard SDK for Unity and have had great success with it and now we're trying a native iOS implementation. I initially got the impression from VRView that it was supposed to act like the SDK to get most of the VR work done for us and then we can build the rest of the app around it. The (i) is in the way of one of our buttons that comes up with on-screen playback controls. Additionally we don't need our users to go to the google VRView page, we provide our own instructions and help information.

I guess I'm a little confused why VRView for the web, and Cardboard SDK for unity provide such customization and unrestricted access (source code, etc) where as this VRView for iOS seems locked down and branded and not intended to be used by developers? Am I missing the intention of VRView? Perhaps I should skip over VRView and just use the Cardboard SDK for iOS by itself and develop my own video implementation? Just feels like reinventing the wheel..

[nathanmartz]

Thanks for the context. If you are using Unity already, have you considered using that for iOS? It actually sits on top of the native iOS SDK.

VR View is designed to make it really easy for people to add 360 content to traditional sites and apps. We've tried to emphasize simplicity over total customizability. I'll discuss this use case with the team.

Regarding VR View on the web, it's open source because there's not really any alternative on the web. It's also better to host it yourself. The CardboardSDK for Unity is actually a mix of open and closed source, with much of the actual guts in the closed source native SDK layer.

[andr3wmac]

The problem with using Unity to embed a 360 video player is that it inflates the size of the binary. Adding Unity to an iOS project adds an additional 20 MB of bloat to the binary. We need a thinner solution.

The mix of closed and open source is fine as long as adequate customization is available. The ability to control video playback and implement your own video playback UI is there, but then you can't even customize the fullscreen or VR mode switching.

In my opinion there is two main usage cases for a closed source lib like VRView:

1. For testing Google Cardboard across various devices with various videos. Then I'd ask why aren't playback controls implemented for us?
2. To give developers an easy start point for developing their own 360 video player implementations. Then I'd ask why its restricted for fullscreen, VR, and the (i) button.

It seems to miss the mark on either target. Anyway, I've began rolling our own 360 player implementation on top of CardboardSDK and it's working quite well. I'd normally close the issue at this point but I'll leave it up to you to close in case you want to keep it around to keep the discussion open.

[andr3wmac]

Ugh. Why does Android's CardboardView have setAlignmentMarkerEnabled, and setSettingsButtonEnabled, etc and iOS GCSCardboardView doesn't? The APIs don't even match between iOS and Android releases of the CardboardSDK. So what I can do on Android I can't do on iOS? That completely shoots me in the foot for trying to achieve visual parity between Android and iOS versions of my app.

This has been an extremely poor experience thus far :(

[nathanmartz]

We intentionally wanted to launch with a streamlined API for iOS and see which APIs people actually used. The Java SDK has become sprawling over time, which people also complain about. We plan to better align these APIs in our next release, and feedback like this is valuable.

Regarding disabling the alignment marker, settings button, etc. are you replacing them with your own equivalents or are you just removing them?

[andr3wmac]

Thanks for the reply, and sorry for my increasingly negative tone, I'm just getting frustrated. We use the alignment marker supplied by the SDK but disable the settings button and back button. We present the user with a choice of magic window, cardboard, etc before launching the video so having those controls present during playback is unnecessary for us.

So, on our unity and android players there is no back button or settings button visible. I'm a little stuck at the moment since I can't disable those on iOS. Do you have any kind of ballpark timeline for when a new iOS SDK could be released? If not I may have to look into using something like this: https://github.com/rsanchezsaez/CardboardSDK-iOS instead, though I'd really rather stick with the official up to date SDK.

[nathanmartz]

Frustration is understandable, and we genuinely appreciate your feedback. I can't give exact timings on the next SDK update but before the end of May is a reasonable ballpark.

Regarding the back button and the settings gear, we discourage devs from hiding them unless they are replacing them with equivalent functionality.

With the back button, we find that many users don't understand how to "get out of VR" if there isn't an on-screen affordance, especially in android where you may have to swipe down from the top to get a home or back button.

The settings button is the only way viewers can switch viewers or pair the right one (which they may not have done). Our help center articles refer to this affordance and it can give users a bad experience if they have the wrong viewer and can't change it.

Lastly, I do not recommend you use the non-official iOS SDK. Other developers have reported issues with memory leaks and we can't guarantee compatibility, usable features, etc.

[andr3wmac]

We have our own back button as part of the playback UI to exit the video. We don't currently allow transitioning from stereo to mono mid-video. Its expected instead that the choice was made and the device configuration loaded right before the video was launched. We've found this is a better experience than starting the video having made an assumption of either stereo or mono. We want the user to be settled and comfortable at the beginning of the video so they can enjoy the whole thing, not promote making adjustments mid-video.

Ideally the API would expose just about everything. I can't recall a time I've complained about an SDK having too many options, only too few. That is of course as long as they come with good default values so I don't have to touch them until I want to. The android and unity SDKs do a fine job of this in my opinion.

[markusekblad]

@nathanmartz
We're developing a VR video application using the Cardboard iOS SDK at the moment and in our case we would like to let the user choose to enable VR mode before launching the video player. A good example is this screenshot from the NYT VR app:

All the other points in this thread applies to our indended use case as well so I hope it's something that might make the next release.

[nathanmartz]

Thanks for all of the feedback. When building VR View, our goal was to make it easy for traditional app developers to embed these elements. For developers who want full control, there is the CardboardView, in which you can do anything you want (assuming you write the GL). What could we do to make that approach easier for the folks on this thread?