-
Notifications
You must be signed in to change notification settings - Fork 0
Migration
This page contains some important aspects for the migration of the framework to other systems:
The main functionality which requires platform-dependent changes is the authorization procedure:
The authorization uses the service by the Learning Layers. The application is registered at this service as a client. If the user authorization succeeds, the login website redirects to the custom URL-scheme gamr://. This URL-scheme has been defined as the redirect URL at the learning layers.
The app needs to react to this URL-scheme so that it automatically reopens after authorization.
This step is also important as it receives the access token from the parameters of the redirect URL.
Since this reaction behavior is platform-dependent, it needs to be defined individually for each platform.
Make sure that the platform-specific application can react on the URL-scheme
gamr://. For instance, on the Universal Windows Platform this has to be defined as a protocol in the manifest file.
Moreover, the final application also needs to contain platform specific code which can query whether the application was launched due to the URL-scheme.
It also needs to be able to query for the URL in order to store the access token which is included in the redirect URL of the Learning Layers authorization.
The extracted access token can be stored in the AuthorizationManager.
It the using statement using UnityEngine is added to the generated file, the game object which contains the AuthorizatonManager can be accessed the same way as in any other script by GameObject.Find().
Search for an event or a callback function in the generated app which is triggered if the application is (re-)opened due to the URL-scheme. Make sure that it is possible to query for the exact URL-address to get its parameters, i.e. the access token. Extract the access token and transfer it to the
AuthorizationManager.
Every platform has different input techniques, e.g. the tap gesture on the HoloLens and the tracked 6DoF motion controllers of the HTC Vive. Therefore, the input schema needs to be adapted for each platform individually. The goal is to re-use as much code as possible and - if possible - to build an additional adapter layer on top of the original framework's functionality. The framework's main target platform is the HoloLens and so all interaction is laid out in the way that is defined by the interaction interfaces of the MixedRealityToolkit: To make an object interactable, a script can implement one of the following interfaces (among others):
-
IFocusable: Can be used to implement focus behavior. On the HoloLens an object is focused if the user looks at the object and on the desktop an object is focused if the user hovers over it with the mouse. -
IInputHandler: Implements methods which are called if the object is clicked. On the HoloLens, this corresponds to a tap gesture on the object. On the desktop, this is a mouse click. -
IInputClickHandler: This interface implements methods for the events of pushing down the mouse or raising it again.
On the HoloLens, these interfaces are called by the input manager of the MixedRealityToolkit.
Input managers for other platforms need to imitate its behavior by determining when to raise the individual methods.
Methods can be raised using the following piece of code.
The example shows how to call all OnInputClicked methods on a target game object.
InputClickedEventData inputClickedEventData = new InputClickedEventData(EventSystem.current);
inputClickedEventData.Initialize(null, 0, 0, InteractionSourcePressInfo.Select);
ExecuteEvents.Execute<IInputClickHandler>(targetGameObject, null, (x, y) => x.OnInputClicked(inputClickedEventData));
The first two lines are only needed for methods which require additional input parameters. The focus behavior can be realized with the last line alone.
The last line is calling the function. In the < > the interface needs to be specified which defines the method to call. The first argument is the target game object. Typically, this should be the game object which is currently focused/selected by the user. The second argument is not needed. The third argument is a lambda function which takes two arguments as input. Only its first argument is relevant since it contains the object which implemented the interface. It is used to call the method.
On the universal windows platform, the URL-scheme is defined as a protocol in the app-manifest.
The code which stores the access token from the redirect URL can be found in the generated App.cs in the function ApplicationView_Activated.
The changes to the platform-specific application only need to be performed once after Unity generates the app for the first time. After this Unity will only update the created solution but the code is not regenerated. Thus, the changes for the custom redirect URL are preserved if the app is re-generated.
- Platform Organization: A guide and documentation how the code for the different platforms is managed.