View

Concepts

  • The View that corresponds to the V in MVP.

  • Create only one on a single screen. (with exceptions).

Implementation policy

  • Implemented by inheriting from ScreenSystem's PageViewBase, ModalViewBase.

  • Receives a Model from the Lifecycle and builds the screen.

  • UI elements, such as each button, get a reference to a SerializeField.

  • Each button's event is exposed as an IObservable.

  • Dynamically growing parts of the View, such as lists, are created within this View.

    • This means that the View has the structure

    • Events also become bridges, but we allow them because they are easier to manage.

    • However, by limiting the role of the View to the following two roles, we can avoid the complexity of each processing.

      • Taking a Model and building the screen UI

      • Firing Events

  • UI Animation reduces the amount of scripting by relying on non-scripted data such as Animator and Timeline.

  • Use a UniTask to wait for the animation to finish.

  • 1Screen 1View is the principle

    • For the reasons above, it's not a big deal if a View gets bloated.

  • Depending on your project, you may want to interface the Model instead of passing it directly to the View. (We recommend interfacing in the following cases)

    • If a View or Model is reused across multiple screens

Example code

  • Event handling for buttons can also be implemented using IUniTaskAyncEnumerable and ForEachAwaitAsync in UniTask rather than UniRx.

    • When implemented with UniTask, it is easier to implement blocking-like processing, such as not performing the next processing until asynchronous processing such as communication processing is completed when a button is pressed.

    • UniTasks also make debugging easier with UniTask Tracker.

    • Whether to use UniRx or UniTask depends largely on the developer's skills and knowledge. (Choose whichever you are more comfortable with).

See also: Sample button processing with UniTask

Last updated