Chapter 1

aFleet, aP1);
CleanupStack::PushL(self);
self->ConstructL();
CleanupStack::Pop(self);
return self;
}
CMyFleetView::CMyFleetView(CFleetViewData& aFleetViewData,
TFleet& aFleet,
TBool aP1)
:CFleetView(aFleetViewData, aFleet)
{
if (aP1)
iViewUid = KP1MyViewUID;
else
iViewUid = KP2MyViewUID;
}
Note CMyFleetView has no functions to handle pointer or keyboard input: the only thing
that the user can do is to look at it.
COppFleetView, the opposition fleet class, is similar, but has the functions, as defined in
Solo Ships, to handle input events.
We now have two concrete view classes, each of which will be instantiated twice, making
four objects in all. These objects will need to share a significant amount of data: the zoom
factor, and all the data calculated from it, for border areas, tile size, and so on will be the
same. C++ would allow me to make these static (i.e. class) members, but Symbian OS does
not allow such writable static data. The alternative that I adopted was to encapsulate the
data in a class CFleetView-Data, and give each view a pointer to the same, single
instance of that class.
9.9.4 Hider View
The final view in the application is the hider view, which is displayed between turns. I thought
I'd display something prettier than a blank screen, and chose a bitmap of a real battleship in
action. The second- phase constructor creates a bitmap object (CFbsBitmap), and loads
the picture from the application's bitmap store (you'll see how to create such a store in
Chapter 14). The view's Draw() function simply bit-blit's the bitmap to the view.
Note
Thanks to the U.S. Navy's Naval Historical Center for the 1906 photograph of
the USS Connecticut.
void CHiderView::ConstructL(const TRect& aRect)
{
CreateWindowL();
SetRect(aRect);