blareweyrSoftware and s/w Development

Dec 13, 2013 (4 years and 5 months ago)


Daniel Kirschner

Pocket Karaoke

Revolutionizing Portable Entertainment

Written by:
Daniel Kirschner


tailed Project Overview

Throughout the specification documents we have detailed exactly what our project’s final state
will be. These specifications effectively answer the “what” questions of the design process.
document will discuss the more technical implementation details

of “how” the product will work. It will
also discuss the testing process and how each section of testing will be implemented by us.

Our project can be broken down into two subsections, namely the Server and Client. In addition
each of these can be broken
down into two further modules. This gives us a total of four separate
modules that our project will need to implement.
These are as follows

Server Side

SQLite database

Apache Server

Client Side


File Player


Apache Server

The server
will be where we will host all of the karaoke files that our app

will have access
to. Right now the server is located on Dan

s PC. Currently we are using Apache Server version 2.2.14
running on Windows 7. (This may change as we get closer to the

end of the semester.)

SQLite database

This database will hold the information required for the iPhone to both search and download
the correct file. A master copy will be stored on the server while each iPhone app will store its own local
Each time
the application begins it will check to see if there is an updated copy of the database on
the server. If there is a newer version

e application will update its version to reflect the changes

usage will begin as normal. Storing a local copy allows t
he application to take the heav
y loads when it
comes to the task of browsing the database. In the real world, the database would hold a non
amount of data (information about 50,000+ songs) so even simple searches by only a couple of users
would qui
ckly overwhelm
our basic server’s capabilities if it was required to handle the searching. Along
with this, we are attempting to keep the bandwidth constraints imposed on the server as low as
possible. Multiple searches with the server hosting would requir
e concurrent connections along with the
responsibility of uploading files to the users who have already selected a file.
Hosting the database on
the application itself does raise security concerns however. For the most part these

s there will be nothing else of interest stored on the server

besides the already available

The initial test database will be constructed by hand to allow us to manually verify the data is
correct. As we move forward we will explore other options
to populate the database to allow us to
stress test the application both in terms of per
formance and usability. T
he usage of the database will
be done with the following basic SQL commands:


This command starts a search query by
a set of

result data from the database.
What gets returned in this set is dictate
d by the commands located below


Where is a

used to filter out results that are not wanted.

A typical delimiter
used would be to filter the results by a sp
ecific column or to filter by the length of the value returned.
This will prove useful as we expand the capabilities of our search process

beyond simple text matching
and into the realm of relative value matches


This command is used to determine w
hich table/tables to pull data from. As the size of
our database grows, it may prove useful to combine multiples tables into one database instead of
creating one


that will store all of the data
. This will po

help us cut down on the

cost of searching. Whether or not we take this approach will depend on the results of the stress testing
we will perform at a later time.


The Use
r Interface will be the way for the user to control the SQLite database as well as handle
the file player.

To do this we will use the Xcode framework given to us in the iPhone SDK. This
framework takes a lot of the grunt work out of creating an UI. One of the

will do for us


all of the text input actions. This means that we can spend a minimum of time setting up
text parsers and more time improving the UI in other ways.

The main
view of the UI
will have a

UITextField, a drop down menu, and a button to control
these. T
he UITextField will allow the user to input the requested search items using the standard iPhone
Keyboard. The drop down menu will be created using a UITableView to list the separate categories to
search in. Examples of these will be Author, Title, or Genr
e. Once the UITextField is filled in and the
appropriate category is picked from the list, pressing the button will construct the appropriate SQLite
statement and query the database. As described above, the statement will have the following syntax
* FROM ‘database’ WHERE ‘category = UserText’. This method call will be displayed in a
UITableView for the user to scroll through.
Once the correct song is selected, we will display a simple
button that has the text “Download”. This button will contain cod
e that will contact the server and
download the file to a selected folder on the iPhone. Once the download is completed, the File Player
will automatically begin to play the file. The process to do this will be explained by David Pinho during
the next pre
sentation. Once the file is finished playing, another view will appear with two buttons, one
containing code to replay the song, and the other containing a pointer to refresh the view to that of the
main menu. This will allow the user to quit the applicati
on or to pick another song.

File Player

The File Player is the module that will handle both the audio (backing track to the song) and the
visual (lyrics of the song) portions of the file. Currently we are still planning on using the MP3+G file type
to pla
y the file. However, this file type is not natively supported by the iPhone. This means that we will
have to either write a codec for our personal use, or come u
p with another solution. As David

deeper into this we will append a revision appendi
x detailing the changes.

Detailed Testing Overview

Our project will be tested using 6 basic types of testing. These 6 types provide complete
coverage in testing from the smallest part (single methods) to overall project testing (Beta Tests). They
are list
ed below in order from smallest to largest.

Types of Testing

Unit testing

Unit Testing is the smallest standalone portion of testing. This will be conducted “in code”. What
this means is that it will be done either during or directly after a specific meth
od is written. This testing
is also method specific. For example if a method were to be written
that would q
uery the SQLite
database for a specified song, the first thing
that would be done upon completion of the method

be to give it a sample databas
e and try to query a known data value from it. This enables us to ensure
that although the overall
usage of such small methods

might be incorrect, the values they return are

Module Testing

Module Testing refers to the act of stress testing each ind
ividual module before the integration
process begins. Our project is, at its most basic, a series of interactions between four distinct modules.
Each of these modules needs to be tested independently to ensure that as we integrate them we
isolate error
s to a specific module or section of code before assuming the overall design is flawed. This
process of module testing can be broken down into two conflicting methods. The first of these is what is
known as “Black Box” testing. Black box testing involves a
bstracting the inner workings of a module and
exclusively passing the module test inputs while analyzing the output for errors. This technique will be
paired with its counterpart “Glass box” testing. Glass box testing uses the same process but constructs
ts inputs with a full knowledge of the implementation details of the module. This enables the tester to
pick specific inputs which will force the module into methods calls that would normally not be run (IE
error states or something of the like). It is ess
ential that both of these be run simultaneously at the
Module Level. Black Box testing detects missing functionality but can’t test every possible set of inputs
while Glass Box testing can’t detect
missing functionality

but can test every s
et of inputs thr
ough the use
of representative test cases.

System testing

System testing is the process by which we will test the system as a whole. The first way this will
be done is checking to ensure that the modules function together properly.
For example, h
aving a File
Player available to us is a good step but without a way to provide it with the requested file it is pointless.
The testing here is used as another way to ensure that the overall design is both correctly implemented
and also in accordance to th
e system specifications. One thing to ensure as we both work through this
phase of testing

is that a simple bug fix could have implications for the rest of the code. As an example,
if a certain piece of code was designed to return a value that was twice a
s large as needed and we scaled
this down to where it was intended to be, we would also have to ensure that any other functions that
depended on this value were being implemented correctly.

Schedule and Responsibilities

The schedule remains
untouched from previous reports aside from the MP3+G issue noted
above when discussing the File Player. The breakdown in responsibilities is simple because of the linear
nature of the code. Daniel Kirschner will be handling the Server side and the related
modules while
David Pinho will be handling the Client side as well as th

related modules. There will be some overlap
in responsibilities, particularly in how the UI connects to the SQLite database. Daniel will have to handle
the portion of the UI that a
ctually manipulates the database while David will write the wrappers to allow

In the testing portion of the responsibilities, we are having weekly meetings where we go over
what we have done and aggressively attempt to break the other developer’s c
ode. As these bugs are
found they become the responsibility of the person whose code is at a fault. For example if the database
is returning incorrect responses to queries Daniel would trace the bug while if the UI was displaying
wrong David would correct

This process of cross
testing allows us to familiarize ourselves with other
portions of the code as well as provide additional support to ensure that all errors are caught as soon as

Testing Equipment

The most important piece of testing equip
ment we will need is a simulated iPhone. This is a
version of the iPhone that is emulated on the Mac OS. It is provided along with the iPhone SDK and will
allow us to quickly test how an actual iPhone would function under our code without having to
lly test is on an iPhone.
Since the main drive of our project is to make this as portable as possible,
there is no outside equipment that will be needed. However, if the device is used heavily we will provide
ways to make this more feasible. This will come

in the form of video/audio out for the user to display
the iPhone screen on a TV and play the sound through a set of standalone speakers. In additio
n we will
provide a way for
a Microphone to be used as well.

These items will need to be tested to ensure t
they will work with our application. As this equipment is natively supported by the iPhone, hopefully we
will not have to extensively test them.