FINAL PRESENTATION
SYDNEY TOUR
Divya Nalla 30107395
Raja Kandasamy 30102984
RajaShekar Donti 30106226
Ren Zhu 30115339
Sadah Omar Sulaiman 30086830
Raja Kandasamy – Team Leader, coding
Ren Zhu – coding, documentation
Divya Nalla – Documentation
Rajashekar Donti – poster, documentation
Sadah Omar Sulaiman – team website,
documentation
Develop a simple online digital tour guide on
Sydney city for the iOS mobile device
 iOS
application on exploring the city Sydney,
Australia
 Users
to explore the classical and traditional
places of the city
 Users
to deliver a tour plan accordingly on their
current locations

Navigates
comfortably
the
user
to
their
destination
 Basic
project plan
 Software
project management plan
 Software
requirement specification
 Software
architecture design document
 Software
testing plan
 User
documentation
 Content
 Data
for the application
required for the application
 Team
member designation
 Sketched
the story boards
 Compared
 Discussed
contents
the other applications
in
locating
the
buttons
and
Initial story board – Home page
Story board – search page
Story board – map view
 Intel-Based
Macintosh Computer with IOS
SDK (Software Developer Kit) Installed
 Applicable
 Devices
to All IOS Devices
includes mobile devices like iPad,
Iphone, iTouch & iPod
 Pattern
 Design/Code
Structure
 Implementation
 Handling
Events
 Displaying
Content on the Screen
 Interacting
with the rest of the System
 Run
the application on background
 Must
be Different in Background and
Foreground
 Runs
Simultaneously apps in the background
 Only
one foreground App but multiple apps
can run in the background
 For
iOS apps, performance means more than
just writing fast code
 App
does not degrade battery life
significantly
 The
types of changes that are likely to
provide the most benefit
Tools required
 Operating
 Software
 Database
system – Macintosh
– xcode 4.6.3 with simulator
– Google API
 Programming
language – Objective C
 Practical
aspects involved with implementing
your app

installed the iOS SDK and configured your
development environment
 App
Store
provides
information
for
Developing Environment on how to configure
the Development Process and an overview
Layers

Cocoa Touch

Media

Core Services

Core Operating System
 Dynamic
 Header
Shared Library
Files
 Images
 Helper
Apps
X-Code
Create
Test
Debug
Tune
This is to be done in an iOS Simulator
 Documentation
 Platform
 Objective
 Google
c
API
The great thing about these patterns is they
work well regardless of the tools you are
using—whether it’s Objective-C and iOS, Java
and Android, or C# and Windows Phone
 Not
just once or twice, but many times over—
and that’s even before you release it to the
App store for the first time
 After
it’s released, your App will change even
more as others use it, provide feedback and
suggest enhancements
 User
Interface(UI)
 Core
logic
 Data
 It
is a Monolithic architecture that is difficult to
change
 Creates
a situation where you can’t change one
part of the App without changing the other
A more formal way to look at the three main
parts of an App is by means of the ModelView-Controller design pattern
Model
View
→ Data
→ User Interface
Controller
→ Core Logic
 The
Model is your application’s data and, in
iOS, usually takes the form of entities. An
entity represents an object in the real world
 Customer
entity
entity, Order entity, and Product
Vision is the interaction between the user and
the systems directly.
The user interacts with objects like
Buttons
Slide
bar
Dropdown
Search
bar
boxes
The Controller acts as an intermediary between
the Model and the View. The Controller is
where your core logic goes
User interacts with

view
 Touch
 Tap

Pinch
In response, the View passes a call to the
Controller,
and
the
Controller
does
something related to the response based on
that interaction
 Sometimes
when saved, a Model entity, it
gets new or default values

For example, if you save a new location
entity,
it
may
be
assigned
an
location
number. So, the model can fire an event that
tells the controller

A view is typically bound to a single view
controller
 Ultimately,
the view controller is a user-interface
object. It’s not the tight coupling between the
view and the view controller that’s the problem—
that’s perfectly fine
 The
problem is the core logic code that’s in the
view controller
 Unfortunately,
because the core logic is
buried inside the view controller, there isn’t a
clean way to reuse this logic in another App.
It’s “stuck in the weeds” of the user interface
Put in the core logic in some other place where
you can access it from multiple Apps, or from
multiple view controllers in a single App
 http://weekendtechnologies.com/en/apps
 http://www.theinquirer.net/inquirer/feature/
2274104/ios-7-specs-and-featureseverything-you-need-to-know
 http://mobithinking.com/mobile-marketing-
tools/latest-mobile-stats
 http://9slides.com/
 http://writing.engr.psu.edu/models.html