FIT3178 Chap.3 Data Persistence and Offline State
Data Persistence and Offline State
Persistence begins with a product question: which state must survive process termination, reinstall, device change or temporary disconnection? Screen selection and scroll position may be transient; saved places, authored notes or account preferences may be durable.
Classify lifetime before choosing a storage API, because convenience storage can become a hidden database and a database can become needless complexity.
Serialization converts in-memory types into a representation such as property-list or JSON data. Decoding must treat stored bytes as fallible input. Files may be incomplete, old or incompatible with the current model.
A robust loader distinguishes no data from corrupt data, preserves recoverable fields and decides whether the user must be informed. Silent replacement with an empty collection can destroy the only remaining record.
A persistent store adds query, relationship and update semantics, but it does not remove the need for a domain boundary. Keep storage-specific objects from leaking into every view.
Map persisted fields into the state needed by the feature, and put save or transaction decisions at a layer that can report success and failure. An interface should not announce completion before durability is known.
Migration is a planned response to change. If a later app version adds a required category to saved places, old records do not magically acquire a valid meaning.
Choose an explicit default only if it is semantically safe; otherwise make the field optional during migration and request user confirmation. Preserve the original record until the new representation has been validated.
Worked case: saved places store an identifier, title and coordinate. A temporary map pin under consideration is held in screen state, not immediately persisted.
Pressing Save validates the title, writes one record and reports a recoverable error if storage fails. On launch, decoding reconstructs only valid records and quarantines a malformed record for diagnostic handling rather than discarding the entire collection.
Portfolio evidence should include the recovery path: terminate and relaunch, load a prior-version sample, interrupt a write, and show how UI state reflects failure.
Explain why each field is durable or transient. The competency is not demonstrated by calling save once; it is demonstrated by preserving meaning across lifetime and schema boundaries.
Persistence choices should also state atomicity and recovery. If a collection is encoded to a file, writing directly over the only valid copy can turn interruption into total loss.
A safer route writes a candidate, closes it, decodes it and replaces the prior representation only after validation. Database transactions express a similar all-or-nothing boundary. The specific API matters less than being able to state what remains valid after failure at each step.
Build a migration fixture set rather than testing only current data.
Include no store, an empty valid store, one version-one record, several records, a malformed record and a version newer than the app understands. For each fixture, define whether the result is normal, recoverable, quarantined or blocking. Confirm that diagnostics do not expose private content and that a failed load cannot be followed automatically by an empty save.
Those cases demonstrate preservation rather than serialization syntax.
Use vocabulary precisely during explanation: persistence is the broad survival requirement; serialization is one representation step; a transaction defines a commit boundary; migration transforms meaning across versions; recovery chooses what remains usable after failure.
Naming the exact operation prevents evidence such as it saved from standing in for a stronger claim. Every claimed guarantee should be paired with a relaunch fixture or forced interruption that could disprove it.
What this chapter covers
- 01
serialization
- 02
persistent store
- 03
migration
- 04
choose persistence according to data shape, lifetime, consistency and failure cost
- 05
Successful writing does not prove successful recovery; test termination, corruption, partial data and schema change.
Migrate saved places safely
- 1Classify the new field.
- 1Load a prior record.
- 1Choose migration semantics.
- 1Protect the original.
- 1Verify relaunch.
Key terms
- serialization
- Encoding structured state into a storable or transferable representation.
- persistent store
- Storage that survives process termination and supports later reconstruction of application state.
- migration
- A controlled transformation from one stored schema or representation to another.
Data Persistence and Offline State FAQ
What is the key decision in Data Persistence and Offline State?
Choose persistence according to data shape, lifetime, consistency and failure cost.
Which failure path matters most?
Successful writing does not prove successful recovery; test termination, corruption, partial data and schema change.
Are the worked cases official portfolio tasks?
No. They are AskSia-authored practice aligned to the current teaching sequence.
What should be shown in discussion?
Show the state or responsibility trace, the changed condition and evidence that the repair works.
Assessment move
Rebuild the state or dependency map from memory, run the worked change, then explain the first assumption that fails.
Working through Data Persistence and Offline State in FIT3178? Sia is AskSia’s AI Software Development tutor — ask any FIT3178 Data Persistence and Offline State question and get a clear, step-by-step explanation grounded in how FIT3178 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
