Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
36 views60 pages

(M6-MAIN) MVC, Navigation and Table View

This document covers Module 6, focusing on the Model-View-Controller (MVC) design pattern and its application in navigation and table views. It explains the roles of the model, view, and controller, as well as how to implement table views with both static and dynamic content. Additionally, it discusses the use of tab bar controllers and navigation controllers for managing multiple view controllers within an application.

Uploaded by

Charles Uy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views60 pages

(M6-MAIN) MVC, Navigation and Table View

This document covers Module 6, focusing on the Model-View-Controller (MVC) design pattern and its application in navigation and table views. It explains the roles of the model, view, and controller, as well as how to implement table views with both static and dynamic content. Additionally, it discusses the use of tab bar controllers and navigation controllers for managing multiple view controllers within an application.

Uploaded by

Charles Uy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 60

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:

You might also like