Fix custom realities to have separate instances for each requestor

[blairmacintyre]

Each page that requests a custom reality should get their own copy.

Right now, they are shared if they have the same URL, but that has two problems:

• if the reality has state, the different pages may conflict in their usage
• when we close pages, we don't end up closing the realities

Each page that installs a custom reality should get their own copy. In the reality view, the title of the page should identify the page that requested it AND the type of reality.

We also need to use more descriptive text, not URLs, in this view.

[kimberlysiva]

@speigg and I were discussing whether this is the right approach. If many pages open a Street View, for instance, performance will degrade. We can stick with the current many-to-one approach and close the reality when there are no more consumers for it. See slack discussion here: https://argonjs.slack.com/archives/G3HN5EP9V/p1493922719880800

[kimberlysiva]

Another point against multiple instances of the same reality: We've said that when a page gains focus its reality should not automatically be switched in. I can see this causing some confusion though, If two instances of a reality (that look quite similar) are in play.

[blairmacintyre]

I think they should be separate (e.g., for multiple panos) and the Titles in the "select reality" screens should indicate both which reality and which app.

[speigg]

The idea is that a single reality can transparently behave like a one-to-one connection for each session, if it manages the state of connecting sessions individually. The manager just has to tell the reality which session is in control. This is basically the same logic that any other service in the manager has to implement (like the VuforiaServiceProvider). For the reality chooser UI, each connection to the reality can still be displayed as a separate link (saying which app created it), and the user effectively chooses which app is in control when they choose from the list.

[blairmacintyre]

If you can manage this, that's obviously a fine approach! I personally have two things I'd like to see:

• realities go away when all the apps that opened them closes. (E.g. We never have the case we do now where I am bouncing through apps in the same page and realities are accruing)
• the state of a reality and its relationship to an app is not lost

It sounds like your idea would solve both

[kimberlysiva]

So is this a long-term or short-term goal? If you want I can go ahead and ensure that a reality closes when its consumers close. I think Gheric is better suited to implement the strategy outlined above (I understand it and think it's a great idea, but it'll take me much longer to figure out the implementation!)

[blairmacintyre]

I think that is a good plan. For most people, that will be the biggest impact. Leave this open as a reminder to do the changes for managing multiple instances, but we should probably do that as part of rethinking realities anyway (so we can potentially have some of them render in webvr too)