Volume Number: 19 (2003)
Issue Number: 1
Column Tag: Handheld Technologies

TicTacPalm 2

Saving Data in a Palm OS Application

by Danny Swarzman

In a previous article ("TicTacPalm: Getting Started with Palm OS" in MacTech April, 2002), I presented a basic Palm OS application for a person to play Tic-Tac-Toe against the handheld computer. That article presented the structure of an application and the elements of the user interface. Here, we'll go one step further, adding the ability to save and restore documents.

On the Palm OS, each application can have one or more databases associated with it. Our sample application has only one database. Each record in the database is a game record. The user can review and modify saved games. This article shows how to save and restore game records. A future article will show how the game data can be transferred to a desktop computer.

TicTacPalm has three forms, a main game board form, a game list form, and game info form. The main form of the application is used both to enter new moves into a game and to review a game record. We use tape-recorder style buttons to review a game, moving forward or backwards. They are visible or hidden as needed. Figure 1 shows the board when reviewing a game.

The game list form has a scrolling list of names of games. The user selects a game to open or taps the New button to start a fresh game. (See Figure 2.) As you can see, there are buttons to open a game and to delete a game.

When the user deletes a game, the record doesn't completely disappear from the database. Instead, the record is marked for deletion. The record is eliminated when the next Hot Sync occurs. (We'll discuss this in greater detail in another article -- about conduits.)

In the game info form, the user enters the name that is to be associated with the game. The name doesn't need to be unique. The program distinguishes between games according to a record number.

When the user taps OK in this form, control returns to the game board.

Figure 4 shows how the buttons can be used to navigate among the various forms. Menus could have been used instead of buttons. Menus require more effort to use, but they are needed when the application is more complex.

A database on the Palm OS is a set of records associated with a creator and type. A creator is the 32-bit code corresponding to the application. An application can have several databases. The type is another 32-bit code that an application can use to distinguish among its databases.

A record can be any size up to 64k bytes. Applications in which documents are larger must segment the documents. Palm OS does have a file system, which uses the Data Manager and is not particularly fast. Each record has flags that are maintained by the Data Manager and accessed through Data Manager functions.

• The delete flag indicates that the user has deleted a record on the Palm OS device. When Hot Sync is performed, the file will be deleted on the desktop machine and finally be eliminated from the Palm OS device.

• The dirty flag indicates that the record has been modified since the last Hot Sync.

• The busy flag locks a record for writing.

• The secret flag is cleared only when the user password has been entered.

A program can open a record for reading. It can access it directly, as if it was just another chunk of memory. To write to a record, the application opens the record for writing. To do the actual writing, it calls a Data Manager routine to copy from another memory chunk to the record.

In this application, when a record is read, its data are copied into a CTicTacGame object. Data are written copying from a CTicTacGame object. When a game is opened, the board is displayed with the position as it was when the game was last closed.

This class handles the database access for the application. The declaration appears in Listing 1. It handles only one database.

CTicTacDatabase
class   CTicTacDatabase
{
protected:
   class CTicTacGame *mGame;
   static DmOpenRef sOpenRef;
public:
      
   static Boolean Open();
   static void Close();
   static UInt16 Count();
   static void GetGame ( Int16 inRecordNumber,
            CTicTacGame *outGame);
   static void SetGame ( Int16 inRecordNumber,
            CTicTacGame *inGame);
   static Int16 Add ( CTicTacGame *inGame );
   static void Delete ( Int16 inRecordNumber );
   CTicTacDatabase ();
   virtual ~CTicTacDatabase ();
   
};

Listing 2 shows the functions to save and retrieve the current game.

Listing 2: Definition of ::GetGame and ::SetGame

void CTicTacDatabase :: GetGame ( Int16 inRecordNumber,
            CTicTacGame *outGame )
{
   // Open the database
   if ( Open() )
   {
      // Get the numbered record and lock it
      MemHandle dataHandle = DmGetRecord ( sOpenRef, 
            inRecordNumber );
      MemPtr dataPointer = MemHandleLock ( dataHandle );
      
      // Copy the data
      MemMove ( (void*)outGame, dataPointer, sizeof ( CTicTacGame ) );
      
      // Unlock release the record
      MemHandleUnlock ( dataHandle );
      DmReleaseRecord ( sOpenRef, inRecordNumber, false );
      // Close the database
      Close();
   }
   else
      outGame->Clear();
}
void CTicTacDatabase :: SetGame ( Int16 inRecordNumber,
   CTicTacGame *inGame )
{
   // Open the database
   if ( Open() )
   {
      // Get the numbered record and lock it
      MemHandle dataHandle = DmGetRecord ( sOpenRef, inRecordNumber );
      MemPtr dataPointer = MemHandleLock ( dataHandle );
      // Copy the data
      DmWrite ( dataPointer, 0, inGame, sizeof ( CTicTacGame ) );
      // Unlock release the record
      MemHandleUnlock ( dataHandle );
      DmReleaseRecord ( sOpenRef, inRecordNumber, true );
      Close();
   }
}

The word preferences is a little misleading. This means that the data that is used to store information that the application needs to restore its state. Each time the user switches to a new application, the newly opened application needs to start where it left off the last time the user switched out of it.

For example, suppose the user switches out of the application while the Game Info form is displayed. The user may have been in the process of entering a new name. This partially entered new game name needs to reappear when the application is opened again. The case is similar for a selection made in the scrolling list in the Game List form. Let's see how this occurs.

The state of the current game is preserved in the application database when the application is switched out. This includes the state of the game. Listing 3 shows the declaration for the application task to deal with preferences.

CTicTacPreferences
class   CTicTacPreferences 
{
protected:
   static CTicTacPreferences *sPreferences;
   struct PreferencesRecord
   {
      Int16 mCurrentRecord;
      Int16 mSelectedRecord;
      Int16 mLastFormID;
      GameNameType mUnconfirmedName;
   };
   PreferencesRecord mPreferencesRecord;
public:
   CTicTacPreferences();
   ~CTicTacPreferences();
   static Int16 GetCurrentRecord();
   static void SetCurrentRecord ( Int16 inRecord );
   static Int16 GetSelectedRecord();
   static void SetSelectedRecord ( Int16 inRecord );
   static Int16 GetLastForm();
   static void SetLastForm ( Int16 inFormID );
   static void GetUnconfirmedName ( GameNameType outGame );
   static void SetUnconfirmedName ( GameNameType inGame );   
};

When the user activates another application, the system sends an appStopEvent to the current application. The main event loop picks up the event and exits. Control goes back to TicTacPalmMain, which calls AppStop. AppStop closes the active forms. As each form is closed, a frmCloseEvent is sent to it.

AppStop is defined in Listing 4. The function first closes all forms and deletes the CTicTacPreferences object. Then it deletes the objects that handle user action. As each form is deleted, a frmCloseEvent is generated. The handler for the form saves the current state of the form in the preferences data. Then, when AppStop deletes the preferences, the preference data are written to disk.

AppStop
static void AppStop(void)
{
   // Make sure the fields in each form are saved.
   FrmCloseAllForms ();
   
   if ( fPreferences )
   {
      delete fPreferences;
   }
   
   // Destroy the wrapper objects for forms.
   if ( fGameBoardForm )
   {
      delete fGameBoardForm;
      fGameBoardForm = NULL;
   }
   if ( fGameInfoForm )
   {
      delete fGameInfoForm;
      fGameInfoForm = NULL;
   }
   if ( fGameListForm )
   {
      delete fGameListForm;
      fGameListForm = NULL;
   }
}

When the system executes FrmCloseAllForms, the system sends a close event to each form. This event will be processed by the Close function for the Game Info form. That function, shown in Listing 5, saves the partially entered game name in the preferences.

CGameInfoForm::Close
Boolean CGameInfoForm :: Close()
{
   GameNameType name;
   GetFieldText ( GameInfoNameFieldField, name );
   CTicTacPreferences :: SetUnconfirmedName ( name );
   // Return false to tell the OS to clean up the form
   // in the usual way after we have extracted the info.
   return false;
}

When the data in the CTicTacPreferences object are up-to-date, AppStop calls the destructor for the preferences object, which then stores its data, as shown in Listing 6.

CTicTacPreferences::~CTicTacPreferences
CTicTacPreferences ::   ~CTicTacPreferences( )
{
   Boolean saved = true; // To be backed up at HotSync
   void *data = (void*)&mPreferencesRecord;
   UInt16 dataSize = sizeof ( PreferencesRecord );
   PrefSetAppPreferences (appFileCreator, appPrefID, 
            appPrefVersionNum, data, dataSize, saved );
   sPreferences = NULL;
}

Storing application data is relatively easy on the Palm OS, as long as the data takes less than 64k. Restoring the state of the application using Preferences data requires some thought. Both would be easier if there were an application framework to handle the messy details.

The Palm web site contains tons of information and links to related sites: http://www.palmos.com/dev/.

Thanks to Victoria Leonard for graphic resources. Thanks to Bob Ackerman, Mark Terry and Victoria Leonard for reviewing the text.

Danny Swarzman writes programs in JavaScript, Java, C++, and other languages. He also plays Go and grows potatoes. You can contact him with comments and job offers at dannys@stowlake.com, or you can visit his web site at http://www.stowlake.com.