TEAM 9 : JAILBREAKERS
RENDEZVOUS
Instructor: Dr . Perez Davila
Mentor: Mr. Todd Guillory
Members:
Twinkle Agarwal
Anjana Bhirde
Ravi Madaiah
David Hodgson
Why iPhone?
 Not desktop, not web app. Mobile development
not usually offered as a course.
 New programming language
 Learn about Mac OS
 Learn about Model-View-Controller (MVC)
pattern
 Resume building
Requirements
 Must call a web service
 Must perform basic database operations
 This had a huge influence on what we decided to
do
What is a web service?
 A method of machine-to-machine communication
 A way of calling a procedure/function/method on
another machine
 Interoperability: can use different languages,
different operating systems
Web services
 Two types: “Big web services” and RESTful
 Big web services use HTTP, and SOAP. Easier to
consume with proxy classes. Click here for
sample web service.
 RESTful services use existing HTTP operations of
GET, PUT. Really just parsing a well-formed web
page.
No
SOAP
involved.
http://www.geoplugin.net/extras/postalcode.gp?
lat=29.577637&long=-95.104244&format=xml
What does our application
do?
 Divided into three features, to satisfy different
requirements
 First feature: gets the weather.
 Second feature: invite friends to a restaurant.
 Third feature: find directions to a friend, using
Google Maps.
 All features assume that there is internet
connectivity.
Feature One: Weather
 The view that loads with the application launch is
the weather for the user’s present location
 It also comes with a search option to get weather
update for particular zip code
 It also has an image that depicts the weather
description (sunny, etc.)
 Uses response of one web service (zip code) as
input for another web service (weather ): like
function composition in math
Feature One: Weather
Sequence Diagram
Notes on feature one:
 The user does not need to know where he is
 Does not accept invalid input
 It consumes data from an existing web service
 Demonstrates interoperability (between Apple
OS and Microsoft OS, and objective c to C#).
Same is true for feature 2 and feature 3
Feature One: Weather
screenshots
Feature Two : Fix Meeting
 On launch of this feature displays a list of
restaurants for present location
 Also has a search option for getting restaurants
for a particular zip code
 Shows list with 10-12 restaurants with respect to
user’s present location (limitation of XML?). This
might be because users give long reviews of
restaurants, so the service chops off the results.
Feature Two : Fix Meeting
 Uses two web services
Consume existing web service for getting list of
restaurants (Yahoo! API)
II. Create a web service for sending invitation
message via email. Deployed on DCM web
server.
I.
Feature Two : Fix Meeting
Sequence Diagram
Notes on feature two:
 User does not need to know where he is
 User does not have to do any typing
 Does not accept invalid input
 Retains value when there are view switches
 User choices are stored in a singleton object
 Interoperability
Feature Two : Fix Meeting
screenshots
Feature Two : Fix Meeting
screenshots
Feature Two : Fix Meeting
screenshots
Feature Three : Get
directions
 On launch of this feature, displays a list of friends
and their respective distance from the user
 Also has update location option that updates
user’s location in database
 Created web service that calls a stored procedure
that return relative distance between user and
his friend
 Performs database operations (INSERT, UPDATE,
SELECT)
Feature Three : Get directions
Sequence Diagram
Notes on feature three
 Gives map as well as textual route
 Interoperability
 Illustrates web service performing database
operations
 Database is prepopulated with users’ locations.
 The application does assume that a group of
friends all have and use the application.
Feature Three : Get directions
screenshots
What is unique about our
application?
 Two people in a new city can find each other
without knowing each other’s current location.
 Inviting a friend to a restaurant does not need
any typing on the user’s part.
Ideas of how this can be
extended in future semesters
 On restaurant feature, can get results based on
current location and radius.
 Other types of events:
1. Movies
2. Concerts
3. Sporting events
More stuff to do
 Web service authentication and encryption
 HTTPS
 Token
More to do: privacy concerns
 Need to authorize friends to see where I am
(could stalk someone otherwise)
 Web service needs to check that they are actually
friends before sending results
More to do: Identity
 Using a phone number to represent identity,
which can change
 Need to have a way for users to update their
information (name, phone number, email
address)
Things we could have done
better
 Comment code as we go, instead of at end
 For commercial applications, if you don’t, it won’t get
done
 More time consuming otherwise
 Don’t use comments to comment out code, and
especially don’t commit it into source control
 Break down objects more
 View controllers were doing a lot of work. Could move
parsing XML and calling web services into another
class.
 Makes for more reusable code.
Conclusion
 The requirements that we had to meet for the
course are met by this application
 Successfully implemented the three features that
we intended to implement at the start of the
course
 Get legitimate outputs