My First “Real” Magic Leap Project: Part 3
Refactoring the previous example with Redux-like state management.
This article is part of a multi-part series starting with My First “Real” Magic Leap Project: Part 1.
The completed application for this article is available for download from the part3 branch of the bounce repository.
Redux-Like State Management
We go ahead and refactor the previous example using a state management strategy. Our application strongly draws from the following article.
The first step is to capture what we previously stored in the private field _state, i.e, positioning, scaling, meshing, etc, in the global state:
- Mode: An enum; one of Positioning, Scaling, or Meshing
Also, because the position and scale of the MeshingZone game object is required by the MLSpatialMapper game object, we expose them in the global state.
- MZPositionX: An int of the x position of the MeshingZone game object; multiply x by 100 and truncate
- MZPositionZ: An int of the z position of the MeshingZone game object; multiply z by 100 and truncate
- MZScaleX: An int of the x scale of the MeshingZone game object; multiply x by 100 and truncate
- MZScaleZ: An int of the z scale of the MeshingZone game object; multiply z by 100 and truncate
Finally, the MeshingZone game object requires the x and y positions of the touch pad on the controller.
- TouchX: An int of the x position of the touch pad on the controller; multiply x by 10 and truncate
- TouchY: An int of the y position of the touch pad on the controller; multiply y by 10 and truncate
Once we have defined the global state, we then wire-up game objects to observe for changes in the relevant parts of the state.
The Code
In order to provide the necessary structure there is a fair amount of boilerplate code added; for example the following file defines the global Mode state.
Assets/Ducks/Mode.cs
We then wire-up game objects to observe for changes in the state; e.g., MeshingZone observes Mode, TouchX, and TouchY.
Assets/Table/MeshingZone.cs
Unlike our previous example, we do not maintain references between game objects; rather we share information through the global state
With this approach, we spread out the code that was on a single game object into code on a number of focused game objects:
- InputHandler: Stores the controller’s touch x and y values into TouchX and TouchY
- KeyPoseHandler: Using Mode, updates Mode based on hand gestures
- MLSpatialMapper: Using Mode, PositionX, PositionZ, ScaleX, and ScaleZ, sets its position, scale, and enabled status. This is in addition to the mesh building functionality provided through the provided MLSpatialMapper script (from last article)
- MeshingZone: Using Mode, TouchX, and TouchY, updates its position, scale, and stores its position and scale into PositionX, PositionZ, ScaleX, and ScaleZ
Next Steps
In the next article My First “Real” Magic Leap Project: Part 4, we implement the feature allowing the user to identify a point on the mesh (to later place a ball).