Symbian Developer Library

SYMBIAN OS V6.1 EDITION FOR C++

[Index] [Glossary] [Previous] [Next]



Storing and restoring

An object in its internal form may consist of just simple data types, for example, a TPoint, which just has two TInt values representing its X and Y co-ordinates, or a network of objects, for example, a CBufSeg. There are two ways of storing the external form of the object:

When externalizing an object to a stream, the stream is passed to the the ExternalizeL() function and, in general, an object has no knowledge of where, in the stream, the data is written.

When a whole network of objects is to be externalised it is useful to store an object in its own stream network. This is particularly important if other objects are to be restored without restoring this one. The main reason is that it is very difficult to read past an object's data in a single stream without knowing something about its internal form.


What to store?

You should store an object which you might not wish to load along with its containing object. The following are typical situations where storing is used:

In general, the decision to store rather than externalise is a fundamental characteristic of the object, and should be taken with care. A compound object, which contains stored component objects, must obey store-related protocols which are more complex than the simple stream-related ExternalizeL() and InternalizeL(). The decisions already taken by system components, such as rich text, and by the application architecture, influence the kinds of things you store in your own applications.