Chapter 1

void CGameAppUi::HandleCommandL(TInt aCommand)
{
switch (aCommand)
{
case EEikCmdExit:
SaveL();
Exit();
break;
...
}
}
This calls CEikAppUi::SaveL(), which ensures that the framework saves the document
data (by calling CGameDocument::StoreL()).
As we've seen, I implemented document restore by creating a new controller and deleting
the old one. This means that the app UI's pointer to the controller then becomes invalid. To
help the app UI cope with this type of circumstance, the framework defines a
HandleModelChangeL()function, which it calls when a new document is loaded. I
implement it here to get an up-to-date value for the pointer to the controller.
void CGameAppUi::HandleModelChangeL()
{
// Change pointers to new objects
iController = (STATIC_CAST(CGameDocument*, Document()))->
iController;
iAppView->SetController(iController);
}
First, I use the document to find out my new controller, and then I pass on this information to
the app view. Without this, you won't keep the app UI and app view up-to-date when the
model changes.
9.9 Two Player Battleships
You'll have gathered from the discussion so far that through the application, document, and
app UI frameworks the OS knows a lot about the running applications, and that it can have
quite fine control of their operations. The exception so far seems to have been the
application views: they've just been ordinary control objects, about which the operating
system has no special knowledge or control. To fill this gap, Symbian OS v6 introduced the
view architecture, which allows the operating system and other applications to
communicate directly with an application's views.
I'll demonstrate how to use the view architecture by extending Solo Ships into a two-player
game. In that version, there'll be two different views for each player, one that shows the
opposition fleet, and one that shows the player's own fleet. Along the way, I'll also briefly
look at making views more interesting by using bitmap graphics and sound.
9.9.1 View Architecture