IT0093
Module 6:
MVC, Navigation and
Table View
• To understand the Model-View-Controller
• To familiarize MVC flow and structure
• To design an application using table view with static and
dynamic content
• To design an application applying some tab bars
Module 6 : Sub-topic 1
MVC and Navigation
• To understand the Model-View-Controller
• To familiarize MVC flow and structure
• Contains or encapsulates the data that your app
uses
• Can be a simple property in the controller, an array
or other structure, a local file or database, or data
from an external source such as a web service
• The model provides ways to be accessed by the
controller, sometimes directly (like properties), or
through other API calls or objects
• What you create in interface builder
• The visible part of your app
• Interacts with the user
• Talks to the controller when things happen
• Gets and processes interactions from the view
• Updates the view based on what happens (in the
view, the model, or external factors)
• Retrieves and updates information in the model
• Updates the model based on what happens (in the
view, the model or external factors
• The model should be valid for multiple views for
things like adaptive layouts
• The view should be independent of the data stored
to allow for things like internationalization
• Each component should be updatable
independently
• The view elements are accessed by the controller
by name
• These are through things like identifiers, outlets,
actions
• Changing something in the controller may mean
the need to change something in the view
• Refers to a design pattern where a target object
and a method in that object is called in response to
specific events
• Example we've seen is in the storyboard IBAction
• Can also be defined in code
• Used to allow multiple objects to communicate
• Typically, a delegate is used to determine what to
do before, during, and after an event has occurred
• For example, in an MVC setup, the View objects
take care of the drawing, and displaying, but can
use a delegate to perform “behind the scenes”
actions, like updating the model or getting more
data.
• Sometimes, two controllers can communicate with
each other through delegation to update the view
or model of the other
• The delegate is usually expected to conform to a
specific protocol
• Recall that a protocol is a blueprint for a class, and
may specify methods and properties that the
delegate is expected to have
• With protocols, an object can reasonably expect its
delegate to be able to handle its requirements
• Used to specify code in response to changes to
properties
• This way an object can be made to do something
by simply updating a property
• Property observers can also be added after the fact
in code
• Notifications are announcements or broadcasts
that can be generated both internal and external to
the app
• Any object can register to be notified when a
specific broadcast is made from anywhere
Apps that implement certain things like push notifications
are effectively pre registered for these notifications (they
simply have to implement specific methods to respond
• You can define transitions in the storyboard by
using Segues
• Segues are triggered by UI events (e.g., a button
tap) or in code
• A segue can be of several types; for this topic we
will use the “show” segue type
• Segues are handled automatically, but the view
controller is given a chance to prepare before a
segue is called (i.e., to pass data to the next view
controller)
• To this, a segue must be given an identifier (in the
storyboard), and the view controller must
implement the prepareForSegue: method
• A navigation controller manages a stack of view
controllers, with only the top most visible
• It provides a way of “pushing” onto the stack (i.e.,
segue to another view controller) and a way of
going back (via a back button)
• It provides a title bar (to show the title and back
button)
• It has an initial view controller called the Root View
Controller which is the first view controller it
displays
• Uses the show segue to define next view controller
• A view controller shown using a Navigation
Controller can access the title bar through a
navigationItem property
• Here, the title can be changed. Also, one of two
buttons on either side of the title, can be set. These
are not standard buttons, but a special button type
called UIBarButtonItem. The left is typically
occupied by the back button
Module 6 : Sub-topic 2
Table View
• To design an application using table view
with static and dynamic content
• To design an application applying some tab
bars
• Presents data in a single-column list of scrollable
rows that may be divided into sections
• Each item in the list (a cell) may lead to a detail
view to present a hierarchy of information
• Two content types: Static and Dynamic
• Two styles: Plain or Grouped
• Each row in the table view is an instance of
UITableViewCell
• There are four built-in layouts, but custom layouts
can be created in storyboard
• Content is set at design time
• Useful for fixed content (i.e., settings), or for
navigation with a fixed set of items
• Useful for providing a scrollable input form
• Useful for displaying data from a database (for
example) and provide drill-down
• Uses delegation pattern to query what to display
(from its “datasource”) and to determine some
behaviour (from its “table view delegate”)
• Uses prototype cells to determine the layout of each cell
• Four built-in layouts but you can easily create more
• Reuses cells to conserve memory (i.e., it only retains the
visible cells in memory, and when it goes off-screen, the
memory occupied by that cell is reused for the incoming
visible cell)
• numberOfSectionsInTableview should return the
number of sections
• tableView:numberOfRowsInSection: should return
the number of rows for each section
• tableView:cellForRowAtIndexPath: should return
an instance of UITableViewCell to display at the
corresponding section/row (i.e., indexPath)
• Each prototype cell in the storyboard should have an identifier
• An IndexPath is a combined section + row
• When tableview tries to display a cell at an indexpath, it asks its
datasource to give it a UITableViewCell instance
• When asked for a UITableViewCell instance, the datasource asks the
tableview to “dequeue a reusable cell” with a given identifier
• Note that only visible cells are allocated in memory… when a cell
scrolls off screen, that cell is marked for reuse; when a cell is about
to become visible, the tableview reuses this cell.
• The tableview’s delegate provides behaviour when
certain events occur The tableview’s delegate
provides behaviour when certain events occur
• Some of these, such as selecting a cell, can also
be handled using segues
• Others, such as deleting a row, must be handled in
code
• All View Controllers can participate in the view life
cycle by overriding certain methods
• These methods are prefixed with will- and did-,
signifying code that will run before a transition in
the life cycle (will-), and after (did-)
Table Views are one column wide
Table Views do not store data
Each piece of data is one row
Each row contains one UITableViewCell
• Instantiation
• awakeFromNib - best not to use
• segue preparation happens
• outlets get set
• viewDidLoad - called once view is initialised and outlets
are set; best time to do updates BUT geometry is NOT
YET set (the layouts are not yet known, only the outlets!)
• viewWillAppear - called when the view is about to appear
on screen (so the geometry and layouts are already set)
• viewDidAppear - called after the view is shown
onscreen
• viewWill/DidDisappear
• viewWill/DidLayoutSubviews - called whenever there
are updates in the layout (these are called a lot!)
• didReceiveMemoryWarning - allows the view to clean
up before getting kicked out of memory
• To add the ordering capability, we’ll need to add a way to
store the order
• This can be done through a “cart”
• Cart can be an array of structs, but for the example we’ll
use a dictionary of String:Int
• Since cart stores data, it becomes part of the “model” of
the main menu.
• We’ll need to have some way of communicating the
“order” from the menu view controller back to the main
menu view controller.
• There are several ways of doing that…
• Pass a reference to the cart array so the menu view
controller can add to it
• Pass a reference to the main menu and allow others
access to the cart array (public property)
• Use protocols and delegates (this is what we’ll do in
the exercise)
• Use notifications
• A Tab Bar Controller is a way to show several view
controllers
• A tab bar is shown at the bottom, and depending on
which tab is selected will display the corresponding
view controller
• All the view controllers are in memory at the same
time
Is a container
Some properties
rootViewController – initial vc
viewControllers – all vc in the stack
topViewControllers – visible vc
• Manages the Navigation Bar
• Navigation bar has left and right buttons, and title view
• VCs in the stack access navigationItem property (to set title
button)
• Can be hidden (ex. Customized UIs)
• Automatic handling of back button
• Can have a toolbar associated with it
• VCs can show/hide toolbar as needed
• VCs can set toolbar items
• Is a container
• VCs are loaded concurrently
• Presented one at a time (viewWillAppear will be
called)
• Manages the switching of views
• VCs maintain state
• Manages the TabBar
• VCs access tabBarItem property (to set label, icon,
badge)
• Is a scroll view
• Contains UITableViewCell Objects
• Used to present hierarchical data (best used with navigation controller)
• Can be static or dynamic
• Uses a delegate performs actions (ex. When row is selected, deleted, etc)
• Concept of “reuse”
• Plain or Grouped style
• Has sections, with header and footer
• Table itself can have header and footer
• TableView needs datasource and delegate object
Datasource
tableView:numberOfSections:
tableView:numberOfRowsInSection:
tableView:cellForRowAtIndexPath:
An indexPath – contains section/row properties
optional: tableView:titleForHeaderInSection:
(among other things)
Delegate
tableView:didSelectRowAtIndexPath:
Tab Bar Controllers (UITabBars)
Navigation Controllers (UINavigationbar)
View Controllers (UIViews & UITableViews)
Using stacks, and their hierarchy:
