Twitter iPhone Client
CS 430
Design Specification
March 15th, 2011
Sean Adam
Ryan Colosimo
Nathan Gladysz
James Smith
iPhone Twitter Client
Software Design Specification
Table of Contents
1.0 Introduction ..........................................................................................................4
1.1 Goals and objectives .....................................................................................................4
1.2 Statement of scope ......................................................................................................4
1.3 Software context ..........................................................................................................4
1.4 Major Constraints.........................................................................................................5
2.0 Data design ...........................................................................................................5
2.1 Internal Software Data Structure ..................................................................................5
2.2 Global Data Structure ...................................................................................................5
2.3 Temporary data structure .............................................................................................5
2.4 Database Description ...................................................................................................6
3.0 Architectural and component-level design .............................................................6
3.1 Program Structure ........................................................................................................6
3.1.1 Architecture diagram ..................................................................................................... 6
3.1.2 Alternatives .................................................................................................................... 7
3.2 Description for View .....................................................................................................7
3.2.1 Processing narrative (PSPEC) for View........................................................................... 7
3.2.2 View Interface Description ............................................................................................ 7
3.2.3 View Processing Detail ................................................................................................... 7
3.3 Description for Controller .............................................................................................8
3.3.1 Processing Narrative (PSPEC) for Controller .................................................................. 8
3.3.2 Controller interface description .................................................................................... 8
3.3.3 Controller Processing Detail .......................................................................................... 8
3.4 Description for Model...................................................................................................9
3.4.1 Processing narrative (PSPEC) for Model ........................................................................ 9
3.4.2 Model interface description .......................................................................................... 9
3.4.3 Model Processing Detail ................................................................................................ 9
3.4.3.4 Local Data Structures ................................................................................................ 10
3.4.3.5 Design Constraints .................................................................................................... 10
3.5 Software Interface Description ................................................................................... 10
3.5.1 External Machine Interfaces ........................................................................................ 10
3.5.2 External System Interfaces .......................................................................................... 10
3.5.3 Human Interface .......................................................................................................... 10
4.0 User Interface Design .......................................................................................... 11
4.1 Description of the User Interface ................................................................................ 11
4.1.1 Screen Images .............................................................................................................. 11
4.2 Interface Design Rules ................................................................................................ 14
4.3 UIDS Description ........................................................................................................ 14
5.0 Restrictions, limitations, and constraints ............................................................. 14
6.0 Testing Issues ...................................................................................................... 16
6.1 Classes of tests ........................................................................................................... 16
6.1.1 Incorrect Username ..................................................................................................... 16
6.1.2 Incorrect Password ...................................................................................................... 16
6.1.3 Invalid Tweet entered .................................................................................................. 16
2
iPhone Twitter Client
Software Design Specification
6.1.4 Invalid Search Entered ................................................................................................. 16
6.1.5 API Request Limit Reached .......................................................................................... 16
6.2 Expected software response ....................................................................................... 16
6.2.1 Incorrect Username/incorrect Password .................................................................... 16
6.2.2 Invalid Tweet Entered .................................................................................................. 16
6.2.3 Invalid Search Entered ................................................................................................. 17
6.2.4 API Request Limit Reached .......................................................................................... 17
6.3 Performance Bounds .................................................................................................. 17
6.4 Identification of Critical Components .......................................................................... 17
7.0 Gantt Chart ......................................................................................................... 18
8.0 Appendices ......................................................................................................... 20
8.1 Packaging and Installation Issues ................................................................................ 20
3
iPhone Twitter Client
Software Design Specification
SOFTWARE DESIGN SPECIFICATION
1.0 Introduction
This document is for the purpose of introducing and explaining the Twitter
Client for the iPhone. This application will provide the user with a way to use
their normal Twitter web interface from a dedicated iPhone application so that the
user can quickly and easily get up to date with their favorite social network.
Since every iPhone comes preinstalled with an app store application, we will
possibly be offering the app for download by its completion. The application will
be running on top of the iOS, which is run on every iPhone and will therefore
need to adhere to iOS specific environment capabilities and/or restrictions.
1.1 Goals and objectives
This iPhone application’s goal is to enable the user to be able to
quickly and easily check, write, and browse their personal Tweets from
their current Twitter user account. Not only do we want the application to
be a fully functional client but to also be visually appealing, intuitive, and
helpful.
1.2 Statement of scope
The scope of this project will mainly be within the realm of the
Twitter API that we will be using. The inputs for the application will
originate from both the user as they type in tweets and search engines
and also from the Twitter database as it sends the user their friends’
updates and other user specific information. Outputs will include the
application interface as it displays the information to the user and data
uploads generated by the user to the Twitter database. The majority of
the applications data processing will be text display, sending, and
receiving.
1.3 Software context
Ultimately this software project is in the context of a commercial
product even though it could have applications for business strategy and
marketing. With that in mind we must make it a priority to appeal to the
current culture’s tastes and needs. Even though there are no set
requirements from a stakeholder, if the application does not appeal to the
general iPhone owner browsing the app store then no one will buy it
making the app worthless.
4
iPhone Twitter Client
Software Design Specification
1.4 Major Constraints
Apple’s app store has some set requirements that any application
that is submitted to be sold must meet. This does put some restrictions on
what libraries of code we can use; however, any restrictions the app store
has will most likely not affect our final product. The only other possible
source of constraint would be the Twitter API; however, it is reportedly
very complete and functional so we should have no problem with providing
the services we want with it.
2.0 Data design
2.1 Internal Software Data Structure
The controller will pass data from the screen to the model. The
model will then return necessary data to the controller from the Twitter
servers. The data from the Twitter servers will then be displayed to the
user onto the screen based upon their initial request.
2.2 Global Data Structure
The data acquired by the application will be stored within iOS Core
Data. Core Data is available for use in this project because the
programming is being implemented using version of Xcode that is
compatible. The Core Data will allow us to save model objects to a file
and then retrieve those objects when we weed to use them again. Core
Data also automatically handles any changes that are made to a model,
which helps with versioning and editing. Since the user has the ability to
save his or her password and username, those variables will be stored
within Core Data as a token. As long as the token exists, the password
and username will be kept.
2.3 Temporary data structure
The main functionality of the application will be the ability to
compose a Tweet and view other Tweets. In order for these to function at
the best efficiency, the Tweet cache will the used to store user’s Tweets.
The Tweets in the Tweet cache will consist of the users own Tweets, the
Tweets composed by the users he or she is following. Upon the start up
of the application, the Tweet cache will fetch the most recent Tweets and
display them.
5
iPhone Twitter Client
Software Design Specification
2.4 Database Description
No database will be implemented for use in this application.
3.0 Architectural and component-level design
A description of the program architecture is presented.
3.1 Program Structure
IPhone apps are usually organized into three abstract groups: view,
controller, and model. The view holds what is displayed on the app
screen. These would be things like text boxes, grids, and buttons. The
controller is the mediator between the view and the model. The controller
handles events triggered by the view and will then make calls to functions
in the model and receive the data that is sent back. The model simply
holds the functions that the controller calls. The model does not directly
affect the view.
3.1.1 Architecture diagram
View
User Input
Controller
Receive Data
Model
Receive Data
Twitter
API
Send Request
Twitter DB
Send Request
6
iPhone Twitter Client
Software Design Specification
3.1.2 Alternatives
A data centric architecture has been chosen for this project.
The reason being is because the engine of the app is mainly only
making requests to the Twitter data base and then displaying
tweets and other information. We also considered an object
oriented architecture. We considered object oriented because
Tweets are conceptually an object and will need to be handled as
such; however, since this would be the only object we felt that the
app itself is more oriented to the getting and setting data feeds
rather than objects. The second architecture we considered was
service oriented. We considered this approach because we felt the
Twitter app would mostly be providing a service to Twitter users
specifically on the iPhone via the Twitter API. We abandoned this
idea as well for mostly the same reason we abandoned object
oriented.
3.2 Description for View
3.2.1 Processing narrative (PSPEC) for View
View
Touch screen event
Call controller event handler
3.2.2 View Interface Description
The input is in the form of a person touching the screen in a
certain area and the output is in the form of an IBAction data type.
3.2.3 View Processing Detail
3.2.3.1 Interface description
The interface for the view will be what the user will
see on every screen. When the user goes to the login
screen the view component will be displayed. The interface
for each view will be controlled mainly by the user except for
the occasional Tweet update that would bump the rest of the
Tweets on a timeline down.
7
iPhone Twitter Client
Software Design Specification
3.2.3.2 Algorithmic model (e.g., PDL)
The algorithm for the view is simple. When any action
has been triggered by the user the view sends the specific
action data to the controller.
3.2.3.3 Restrictions/limitations
The view cannot access model functions and data
directly. The view must go through the controller. The view
does not handle any data directly except for actions.
3.2.3.4 Local data structures
GUI display and IBAction data.
3.3 Description for Controller
3.3.1 Processing Narrative (PSPEC) for Controller
Controller
Call model function
View IBAction event
3.3.2 Controller interface description
The input is in the form of an IBAction from the view
component. The output is in the form of a function call to the
model.
3.3.3 Controller Processing Detail
3.3.3.1 Interface description
The interface for the controller is internal only. Only
the view and model can send the controller data, and the
controller can only send data to the model and the view.
3.3.3.2 Algorithmic model (e.g., PDL)
The algorithm for the controller is also simple. When
an event handler is called the function(s) in the model is
8
iPhone Twitter Client
Software Design Specification
called and then the returned data from the model is sent
back to the view to be displayed.
3.3.3.3 Design constraints
The controller cannot call other event handlers from
within itself or Twitter API functions.
3.4 Description for Model
3.4.1 Processing narrative (PSPEC) for Model
Model
Twitter API requests
Controller function calls
Other internal data processing
3.4.2 Model interface description
The input is in the form of a function call from the controller. The
output is in the form of a return statement to the controller (e.g.
Tweet text, Boolean value, etc…).
3.4.3 Model Processing Detail
3.4.3.1 Interface description
The interface for the model connected to the app and
the Twitter API.
3.4.3.2 Algorithmic model (e.g., PDL)
The algorithm for the model is also fairly simple. The
model waits for a function call. When a function is called the
code is executed (e.g. Twitter API request) and then the data
returned by the API request is in turn returned to the
controller.
3.4.3.3 Restrictions/limitations
The number of calls to the API is restricted. See
Section 5.0.
9
iPhone Twitter Client
Software Design Specification
3.4.3.4 Local Data Structures
Model stores any parameters passes to it and data returned
to it via the Twitter API.
3.4.3.5 Design Constraints
The model cannot display data directly.
3.5 Software Interface Description
The software's interface(s) to the outside world are described.
3.5.1 External Machine Interfaces
The app is ultimately receiving data from Twitter data base;
however, the app is not directly interfaced with the data base. The
data base is interfaced with the API.
3.5.2 External System Interfaces
The app interfaces with the internet to send requests to the
Twitter API which in turn sends and receives data from the Twitter
data base.
3.5.3 Human Interface
The iPhone is the main interface with the human operator.
The iPhone contains the touch screen to with events are received
and passed to the system.
10
iPhone Twitter Client
Software Design Specification
4.0 User Interface Design
The following section provides screen shots of the user Login screen and
the Timeline screen that the user will be presented with upon startup of the
application.
4.1 Description of the User Interface
4.1.1 Screen Images
4.1.1a Login Screen
11
iPhone Twitter Client
Software Design Specification
4.1.1b Objects and actions
The login screen consists of four primary elements. The
username and password fields are user editable and they will hold
the users Twitter username and password. The checkbox for
remember me will have two states, selected and unselected. When
selected, it will remember the users username and password upon
successful login. If the login was unsuccessful then the users
information will not be remembered. When the user opens the
program after a successful login he or she will not be required to reenter the information and the program will open to the timeline for
that specific user. Once the user has entered the necessary
information, he or she can click the login button which will then
verify the inputted credentials and continue onto the timeline
screen. The user may also click ‘Forgot my Password’ if he or she
cannot login successfully, this will open a web view which allows
the user to retrieve their password. The user can also click ‘Create
an Account’ which will also open a web view which will allow the
user to create a new Twitter account.
12
iPhone Twitter Client
Software Design Specification
4.1.1c Timeline Screen
4.1.1d Objects and Actions
The timeline screen is the home screen for the
application; it is the screen which first appears when the user
opens the application. This screen displays tweets in
chronological order of the individuals which the user is
following. Each tweet is formatted with the username of the
individual, his or her profile image and the date stamp of the
13
iPhone Twitter Client
Software Design Specification
tweet. The top navigation bar displays the username of the
current application user as well as a compose button on the
right and a refresh button on the left. The bottom tab bar
displays the various screens associated with the application.
The mentions button will display the tweet from any user
which uses the ‘@’ sign to direct a tweet at the current user.
The DMs button will display all of the users direct messages;
direct messages are essentially messages that are directed
to a single user and are private and can only be viewed by
the current user. The Search button will display a search
window which will allow the user to search a multitude of
items, such as Twitter users, tweets containing a word or
words, as well as other things. The more button will contain
information such as trending topics, the users profile, user
statistics, etc.
4.2 Interface Design Rules
The entire project is interface based, so the way the user interacts
with the interface governs the use of the application. The interface is
being developed using Xcode and Interface Builder. The team is limited to
functions that are provided by Xcode in ways the user is able to interact
with the interface.
4.3 UIDS Description
The user interface development system used is Interface Builder.
Interface Builder is a utility provided by Apple. It is made to be easy to
use by allowing the developer to simply drag and drop items onto the
interface platform. The developer may choose a series of objects from a
Library list. Each object can be dragged onto the platform and its
attributes can be manipulated and saved based on the developer’s
preferences. Each controller that the application uses can also be
implemented inside of Interface Builder. Interface Builder can only be
used to develop applications that will be used by Apple products.
5.0 Restrictions, limitations, and constraints
As developers of a Twitter client for an iPhone, we are restricted, limited
and constrained by Twitter’s “Developer Rules of the Road” – as well as Apple’s
iPhone development policies. Such limitations, restrictions and constraints can
be summarized as follows.
14
iPhone Twitter Client
Software Design Specification
“Using the Twitter API and Twitter Content are subject to certain
limitations on access, calls, and use of the Twitter API as set forth on
dev.twitter.com or as otherwise provided to us by Twitter. “
As a Twitter service our software must not “surprise users”, create or
distribute spam, protect and respect user privacy, and ” be a good partner to
twitter”. We must follow the display guidelines. As a part of complying with
Twitter’s principle of not creating or distributing spam we must abide by Twitter’s
spam and automation rules. Furthermore we must not enable or support the
publication of links to malicious content or pornography or other obscene images.
We must clearly disclose what we are doing with information collected from
users. Furthermore, we must not facilitate or encourage the publishing of private
or confidential information.
End users must log into Twitter using OAuth. New users, users without a
Twitter account, must have the opportunity to create a new account provided by
the twitter. We “must clearly display the end user's Twitter identity. Twitter identity
includes visible display of the end user's avatar, Twitter user name, and a Twitter
"t" mark.”
We must: “respect user content -- Tweets may be used in advertisements,
not as advertisements” and “respect user experience -- build your service around
the timeline, not in the timeline.” A user’s permission is required to use their
Tweet on a commercial durable good or product - or within an advertisement,
that implies the sponsorship or endorsement.
15
iPhone Twitter Client
Software Design Specification
6.0 Testing Issues
This section lists the various tests that will be conducted on the software. The
tests are done to ensure the software is working properly, and how it will handle
possible errors that may occur.
6.1 Classes of tests
6.1.1 Incorrect Username
This error occurs when the user inputs an incorrect
username when prompted.
6.1.2 Incorrect Password
This error occurs when the user input an incorrect password
when prompted.
6.1.3 Invalid Tweet entered
This error occurs when the user enters a blank Tweet or a
Tweet that contains too many characters.
6.1.4 Invalid Search Entered
This error occurs when the user incorrectly enters a search.
6.1.5 API Request Limit Reached
An IP address or account may be blocked by Twitter when more
than 20,000 requests an hour are called from that IP address or
account.
6.2 Expected software response
6.2.1 Incorrect Username/incorrect Password
If the user enters an incorrect username or password while
logging in, an error message will appear saying, “Incorrect login
information”, and the user will be prompted to enter them again.
6.2.2 Invalid Tweet Entered
If the user enters a null Tweet, an error message will appear
saying, “No text entered”, and the user will be asked to enter a
16
iPhone Twitter Client
Software Design Specification
Tweet. If the user enters a Tweet that contains too many
characters, an error message appear saying, “Too many characters
entered”, and the user will be asked to decrease the number of
characters in the Tweet.
6.2.3 Invalid Search Entered
If the user enters a search that produces no results, an error
message will appear saying “No results found”, and the user will be
prompted to search again.
6.2.4 API Request Limit Reached
The software should alert the user as they approach the limit
that the number of requests is approaching the limit and that they
should log off for a while in order to prevent potentially being
blocked. If the limit is reached the software should stop the
process and alert the user that they have been suspended for a
short time before they can use the app again.
6.3 Performance Bounds
A major bound on the performance of the Twitter client is speed of
the application. The speed of the application will depend on the network
that is available in the user’s location. There are areas that the user will
not be connected to a network, and when the user is in these certain
areas the application will not work at all. The performance of the
application is bounded by speed, and the performance will be better in
locations that have high speed network connection. Performance will be
subpar in locations with a low speed network connection.
6.4 Identification of Critical Components
The data cache and Twitter data base connection will be the most
critical components of this app. The data cache will allow the auto login
function to work and will keep the number of API requests below the limit.
The connection to the Twitter data base is the most essential to the whole
project. If connection is to be lost or interrupted the app needs to be able
to recover and handle any errors correctly.
17
iPhone Twitter Client
Software Design Specification
7.0 Gantt Chart
18
iPhone Twitter Client
Software Design Specification
19
iPhone Twitter Client
Software Design Specification
8.0 Appendices
8.1 Packaging and Installation Issues
The application will be available to user in the iTunes App Store. Each
user will be able to download the application directly. After being downloaded,
the app will automatically load on the user’s iPhone. The app is not being
developed to support Android phones, so only users with iPhones will be able to
use it.
20