Saving is a vital component of many interactive apps you create. Understanding how saving works will allow you to create a much better experience for your users, and better projects overall.
This article briefly goes over the core concepts of saving, and how the save system works in hyperPad.
In hyperPad saving is pretty simple when you get a better understanding of what's happening behind the scenes.
Think of the save system like a spreadsheet or table with 2 columns. One column for your title/description (key) of what you're saving, and another column actually stores the saved value.
Any time the save behavior is triggered, you're actually adding a new entry in the table, or overwriting an existing one.
Existing VS Dynamic Keys
Existing Keys: These are keys that already exist in your table before your project starts. These are keys you manually added already (using the save behavior), or keys that have been added after a dynamic save has been triggered.
In most cases, you want to use existing keys, since you know ahead of time what you want to save. For example: have a key called “Score”. You know you’re going to use later on. Existing keys are also used for overwriting data that’s already saved. For example: if you have a score saved of 500 and want to change the score, you can then create a new save behaviour and select the existing SCORE key to overwrite it with any new number.
Dynamic Keys: Dynamic keys are things you want to save that don’t exist yet. This allows you to create a key while your project is already running.
For example: you want to create a list of students, and their favorite colour.
For a list of students, create a save behavior and set it to dynamic. When a user enters their name, make the name be the key for the save behavior. The favorite color would then be the saved value.
With saving dynamic keys, you're actually entering two entries into the table each time. It saves the name (key), and the color (value).
Once you have run your project, any executed dynamic save behavior will now show up in the list of pre-existing keys since they're now added to the save table.
Any time you want to retrieve data from your save table, you must use the "Load from File" behavior. The Load behavior will get the value from any previously saved key as soon as the Load from File behavior is executed. If there is nothing saved, it will return a blank value. ("").
Note: To actually use the value stored in the Load, you must output the value to another behavior. See "Sharing Values Between Behaviors" to learn how to output and use the loaded value.
Loading Existing & Dynamic Keys
Just like the Save behavior, there are two key types to load. Existing, and Dynamic.
Existing Keys: Like the save behavior, this allows you to select a specific key from the save table.
Dynamic Keys: Instead of selecting a key from the predefined list, you must enter the name for a key you know will exist later on. If you enter a key that doesn't exist when the load behavior is executed, it will return a blank value ("").
Dynamic keys are really powerful when used properly. Instead of entering the key from the behavior editor, you can use behaviors to enter a key that doesn't even exist yet. This allows you to save information that is created at the runtime of your project.