FIT3178 Chap.2 Application Architecture, Navigation and Collections

Application Architecture, Navigation and Collections

Architecture in FIT3178 is the arrangement of responsibilities that keeps screens comprehensible as an app grows. Start from the model: data and rules that still make sense without a particular button, label or controller. A view presents state and captures interaction. A controller or coordinating layer binds those concerns to lifecycle and navigation.

The names matter less than whether each responsibility has one defensible home.

A view controller receives lifecycle events, but lifecycle ownership is not permission to own every model. Record what must survive dismissal, what is screen-local and what belongs to the application or service layer. Navigation should carry a stable identifier or prepared dependency, not invite the destination to reach into global state.

On return, commit a deliberate change or refresh from the shared source of truth; do not rely on whichever controller happens to still be in memory.

Table and collection views introduce reuse. A cell is a transient presentation object, not the record itself. During configuration, assign every visible property from the current item because a reused cell may retain appearance from a previous index path.

Store item identity in the model or diffable snapshot rather than treating the cell instance as durable. Actions should resolve the item that is current when the event occurs.

Collection changes also separate position from identity. Inserting an item can move every later index path while the underlying items remain the same.

If an asynchronous image completion writes to the cell that used to occupy an index, the wrong image can appear. Preserve item identity, cancel obsolete work and verify that a completion still belongs to the configured item before updating presentation.

Worked design: a catalogue screen opens a detail editor. The catalogue owns or observes a collection model.

Selection passes the chosen item identifier to a coordinator, which prepares the editor with a draft and a commit route. Cancelling discards the draft. Saving validates once, updates the model and lets the collection derive its new presentation. A second grid view can reuse the model and selection route without copying editing rules.

Test the design by changing one condition.

Ask what happens when an item disappears while its detail is open, the screen is reconstructed after memory pressure, or the catalogue gains a second presentation. If the answer requires reaching through controller hierarchies or assuming an index never changes, the dependency boundary is weak.

Portfolio discussion should show the responsibility map and one failure-path repair, not only the final animation.

Architecture can be tested without debating labels by applying a replacement test. Replace the collection view with a table, replace the navigation controller with a sheet, or replace the remote catalogue with a fixture.

Domain identity and editing rules should survive; presentation binding and route mechanics may change. If a replacement forces the same validation rule to be rewritten, that rule lives too close to the screen. If it requires global access to reconstruct state, the dependency was never explicit.

For a discussion-ready diagram, draw four columns: user event, presentation state, domain operation and route.

Follow Select B, Insert X, Save B and Delete B through those columns. Stable identity should cross the domain boundary; an index path should remain inside presentation. Mark the exact point where existence is checked and the result where the collection derives a fresh snapshot.

This exposes why controller hierarchy, cell instance and historic position cannot serve as application identity.

When reviewing a portfolio item, annotate every arrow in the responsibility map with the information it carries and the result it can return. An unlabeled arrow often hides global lookup, unchecked absence or a controller reaching into another controller's controls.

Replace those arrows with stable identity, immutable starting state, a commit result or a route outcome. The clearer map also suggests focused tests for insertion, deletion and reconstruction.

What this chapter covers

• 01

  model

• 02

  view controller

• 03

  reuse identifier

• 04

  separate model state, view presentation and navigation so screens remain testable

• 05

  A visual hierarchy does not establish data ownership; navigation code must not become the only place where model changes are stored.

Preserve catalogue identity across navigation

Key terms

model

The domain data and rules whose meaning does not depend on a particular screen.

view controller

A UIKit coordination object that connects a view lifecycle with application behaviour.

reuse identifier

A stable key used to dequeue reusable table or collection view cells.

Application Architecture, Navigation and Collections FAQ

Assessment move

Rebuild the state or dependency map from memory, run the worked change, then explain the first assumption that fails.

Working through Application Architecture, Navigation and Collections in FIT3178? Sia is AskSia’s AI Software Development tutor — ask any FIT3178 Application Architecture, Navigation and Collections 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.