App States

The first few parts of the user interaction is based on a state machine: there are different App States, and can switch among these states.

The App State Manager controls the state machine loop. There is a method Run() that would respond to different app states. Take a look at the methods to get an overall idea of what interaction is needed to switch states, and what is done while the between state changes.

After the user puts in the basic information about the avatar, the app is then dominated by user interactions (button clicks, etc.).

The manager script also handles the reset functionality in ResetAvatar() and ResetStage(). When you add new code to the app, consider carefully what you have changed, and what is needed to revert it. You probably need to write this into the Reset() of the corresponding manager, and update AppStateManager accordingly.

Potential refactoring plans

The biggest problem with the current approach is that user interactions are handled in different scripts and make the app hard to navigate. There are several ways to address this problem:

• An easy way is to map all user interactions to state changes for all interactions, and use the states to guide the entire app. Each interaction would trigger a state change, which would in turn trigger changes in the underlying systems.

• Another more complicated way is to rewrite the entire app using an Entity-Component-System pattern. Unity is implementing one library by themselves (https://docs.unity3d.com/Packages/com.unity.entities@0.17/manual/index.html), while there is already a very full-fledged third-party library called Entitas available (https://github.com/sschmid/Entitas-CSharp). ECS is a data-driven pattern, like React and Redux in front end engineering. Basically, it is the change in data that triggers changes in the systems, and since this app is all about health data, ECS is actually a very good design pattern.