You've got the idea.
When a state specific changed announcement is sent saying you've entered, say, the FETCHING state, have a command respond by invoking a proxy method to fetch.
When the data comes back, have the proxy send a note, say MyProxy.DATA_RETRIEVED, that triggers a command which generates a StateMachine.ACTION notification. If the Proxy passed a reference to the data then the command can include that in the body of the ACTION notification to pass it to the next state, say DISPLAYING.
A mediator interested in the state specific changed announcement for the DISPLAYING state would see the data the Proxy fetched in its note body, and could simply set it on its view component for display.
As for making the view non-interactive while the service is being called, it would be during the entirety of the FETCHING state. Resist the urge to use the state specific entering and exiting announcements, these are for guard logic only, not setup/teardown of UI
. Wait until the state specific changed announcement for the FETCHING state.
The command that we've described above as responding to that by making the proxy call could trigger the UI interaction guard (perhaps a partially opaque box or a modal popup) by sending a notification prior to its invoking the proxy method. And the command that responds to the DATA_RETRIEVED message could also trigger the removal of the UI interaction guard.
Check out the original Sea of Arrows code at http://seaofarrows.com/srcview
You can see data being passed from the STARTING state to the FAILING state in the com.seaofarrows.musicplayer.shell.controller.StartShellCommand and FailCommand classes. It wasn't asynchronously retrieved from a server, but that's irrelevant.