For last week I have explored more ways how to drive UI state using core data. What I wanted to show some additional detail views based state in a hypothetical game. Game play can be in following states:
I needed to include opponent information to two screens. On map screen only in active mode. And on chat screen during matching and active play. Game status is updated using active network polling in background. All the game status updates are saved using core data.
In UI map and chat views are using stack views. Main view on top and accessory view in bottom. When accessory is not shown, main view will be full screen. There is additional catch - players can be in two modes. They can be either attackers or defenders. Both modes will use different accessory view. At launch we insert three views into stack view - main view, attacker view, defender view. Last two ones are hidden and only relevant one will be shown when needed. At most two views will be shown simultaneously.
Showing player status will be contained in AttackerStatusViewController and DefenderStatusViewController. When needed, views will be made visible. When not needed, views will be hidden. And stack views will do all the magic 😍
For monitoring database changes, we have a simple wrapper with callback around fetched results controller:
In AttackerStatusViewController/DefenderStatusViewController we instantiate the monitor:
When ever update callback is received, we can show/hide presenting view and fill in other details:
I’m still evaluating if this is a good idea. But I do like the decoupling here. Game status updates are monitored somewhere far away from UI and saved using core data. When something changes, this will be notified back to UI level where appropriate steps can be taken.
Tags: ios, ui, core data