Elliott Heath (Fall Team Lead)

School of Engineering Phone 503 943 7314 5000 N. Willamette Blvd. Fax 503 943 7316 University of Portland Portland, OR 97203-5798

Design

Project Gopher: LocatePortland

Team Members:

Nick Wales (Spring Team Lead)

Industry Representative:

Marcos Ortiz

Faculty Advisors:

Tanya Crenshaw

Andrew Nuxoll

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ELLIOTT HEATH DESIGN SPECIFICATIONS REV. 0.93 PAGE 2 PROJECT GOPHER

Revision History

Rev. Date Author Reason for Changes 0.1 12 Nov 2010 Elliott Heath Initial draft. Contains milestones, introduction, conclusion, and the test cases. 0.9 12 Nov 2010 Nick Wales First complete draft. 0.91 23 Nov 2010 All Put sections into design doc. template, qualified milestones, and clarified descriptions. 0.92 2 Dec 2010 All Revised grammatical errors, added pseudo code for activities, and added in the button prototype figure, added appendix, fixed figure references. 0.93 6 Dec 2010 All Fixed grammatical errors, introduction of the background, abbreviated MVC, changed font to monospaced font (courier new), fixed appendix, added design detail. 0.93 15 Dec 2010 All Fixed grammatical errors, added R.java explanation, added design detail, added to Appendix A.

Table of Contents

List of Figures

Figure 1: Model-View Controller...... 8

List of Tables

Introduction

At the moment, there are a few competing map applications available for smart phones. Currently, none of them are targeted specifically at the city of Portland. We propose the development of LocatePortland, an Android 2.1 application featuring popular landmarks and restaurants as well as guidance for finding such locations. This application caters to downtown Portland tourists, college students new to the city, or anyone wanting to know about downtown Portland.

6 DESIGN SPECIFICATIONS REV. 0.93 PAGE 7 PROJECT GOPHER

Design

The design document is comprised of three parts, Background, Architecture and the Software Components. The Background section addresses a few android programming basics. The Architecture section details the high-level design of LocatePortland, and the Software Components details the various parts discussed in the Architecture.

Background

The purpose for this Background section is to inform the reader about how our application equates to a MVC design pattern, the basics of an Activity, and about the Software Components of our application. The MVC shows how we are modeling our application, what will be provided for the user’s view and how we will be controlling the view and model via Android’s touch screen interface. An Activity is the basic class for android applications. The Software Components details the code that will be put into the Activities. The Button Prototype is our basic activity that shows a picture when a button is pressed. The Button Manifest is provided to show the reader what a basic manifest file looks like. Once there is a basic understanding of these topics, the reader will be more informed of the design that will be used to implement LocatePortland.

Model-View Controller

An Android application can be accurately described via a Model-View Controller (MVC) as shown on page 330, in Patterns of Enterprise Application Architecture (Fowler 330) or in Figure 2 below [1]. The basis for LocatePortland’s design is a MVC. DESIGN SPECIFICATIONS REV. 0.93 PAGE 8 PROJECT GOPHER

Figure 1: MVC.

There are 3 components in Figure 2. They are:

1. Model: The model manages the layout and behavior of the data. It is not visible to the user, however it is the basic framework for the data that is displayed to the user.

2. View: The view manages the display for the user.

3. Controller: The controller interprets all of the user interactions within the application via communication with the view and in turn tells the view and model to update accordingly.

An Android activity has three major parts that correspond to the three components listed above in the MVC. These parts are:

XML file (Model)

The model for an Android activity is its xml file. Each Android activity has its own unique xml file. The purpose for this file is to lay down the framework for the display. It controls which layouts and widgets will be displayed in the view for the user to see. In xml, the exact placement of every object is specified. Within the code, each widget’s properties are also stored. For example, a button can retain the properties of designated width and length within a layout. A button can also have

properties of visibility, texting style, left and right padding, background, color

Display (View)

The view for an Android activity is its display to the user. This is the actual user interface that the user sees while using the application. The user interface will be displayed on the phone’s touch screen. The view is the display of the interface. It is not the control of the interface.

Java Class (Controller)

The controller for an Android activity is the corresponding Java class. This class contains all the functionality of the activity. If a button is pressed, the Java class specifies which action the activity takes as a result of the button click. All of the widgets created in the xml for the view have to be programmed into the Java class as view objects. A view represents a widget that has an appearance on the screen. To load a button widget into a Java view object, the Android button library needs to be imported. By importing these Android libraries, all the necessary methods are inherited as well to modify all the widget properties in the xml file.

Manifest File

One of the main components in an Android application is its manifest xml file. The manifest is the central configuration file for the application. This file sets all the activities in the application, services to be set up in the application, and the permissions each activity needs to function properly.

Features within an Android phone are protected with permissions. The manifest file needs to specify which permissions that a particular activity needs, in order to access the phone’s features. A feature has a maximum of one permission relating to it.

Button Prototype

We created a button prototype to help us gain a better understanding of developing an Android application. By creating the button prototype, we now know the process of organizing the GUI layouts and its widgets. Behind the GUI display we also now know how to code widgets into Java objects and assign various actions to a button click. The button prototype has two buttons marked “Visible” and “Invisible”, with a picture of a gopher placed above them. The picture will appear and disappear according to which button is pushed. A picture of the button prototype can be seen below in Figure 1. Its manifest file contents will be posted below the figure to show how they relate. DESIGN SPECIFICATIONS REV. 0.93 PAGE 10 PROJECT GOPHER

Figure 2: Button Prototype.

Button Prototype Manifest File

Here is the button prototype’s manifest file:

Above is a small manifest file from the button prototype. The version name and application are lines that are never actually used by the application. They are for the program developers to edit and reference so they know which version of the code they are working on. The application line that follows specifies which image in the project folder will be the application’s icon image and what string will be listed under the image. One activity is listed because there is just one screen in the button prototype. This particular application does not need any special functionality from the Android phone so no permissions are listed in this manifest file.

R.java File

Another critical file in the Android application is the R.java file. This file auto generates as the project develops, and all that it contains is an organized list of all the application’s resource identification values. The identifications are organized into string, drawable, class, and layout groups. The controller Java classes can then access these resources by creating an instance of the desired resource object and assigning it to the R.java identification value. The R.java class is listed below for the button prototype we implemented.

public final class R { //These are the images in the button prototype. The //gopher picture public static final class drawable { public static final int gopher=0x7f020000; public static final int icon=0x7f020001; }

public static final class id { public static final int Gopher=0x7f050002; public static final int Invisible=0x7f050006; public static final int RelativeLayout01=0x7f050000; public static final int Visible=0x7f050007; }

public static final class layout { public static final int main=0x7f030000; }

//The button prototype on has string variables for the //two buttons and for the application name. DESIGN SPECIFICATIONS REV. 0.93 PAGE 12 PROJECT GOPHER

public static final class string { public static final int Invisible=0x7f040000; public static final int Visible=0x7f040001; public static final int app_name=0x7f040002; } }

The code below is then implemented in the button prototype’s Java controller class to access the application’s visible button object.

//This typecasts a view into a button object. Visible = (Button)findViewById(R.id.Visible);

Now that Visible is assigned to the object, various methods can called on it to control the functionality of the Visible button resource.

Activities

An Android application is comprised of one or more activities. These activities are placed on what is called the activity stack. On the top of the stack is the active activity in the application. Only one activity can be active at a given time. The other activities are not created yet or are in a paused or destroyed state. The lifecycle of an activity is comprised within the bounds of onCreate() and onDestroy().

An activity has four states. These states are active, paused, stopped, and killed. If an activity is active, the user is interacting with it. Its view is displayed on the screen while the controller is running. An example of this is a small dialog box popping up over the map. If its view is completely blocked by another activity, the activity with a blocked view is stopped.

Activities can only be killed when in a paused or stopped state. When the Android system runs low on memory, it will kill a paused or stopped activity within the application to free up memory. Below are the seven callbacks that are necessary for an Android activity to respond to the various state changes described above.

The seven following callback methods comprise the lifecycle of an activity:

onStart()

This method marks the beginning of an activity’s visible lifetime. Between the onStart() and onStop(), resources can be maintained that are needed to show the activity to the user.

onCreate()

This method is called every time the activity is started or restarted. This method will setup the global state of the activity. All of the static data will be initialized and all the remaining data/resources will be bound. For example, a button widget will be programmed into a view object in this method. The only parameter in this method is a Bundle object, which contains the activity’s previously frozen state if there was one prior.

onResume()

This method is called any time an activity is brought up to the foreground, or when the activity starts interacting with the user.

onPause()

This method marks the end of an activities lifetime in the foreground. Data is saved, and exclusive resources are released.

onStop()

This method marks the end of an activity’s visible lifetime. This happens if the user chooses to bring up another application without quitting LocatePortland.

onDestroy()

This method complements onCreate(). It is called when an application is shutting down. All the static data initialized is freed up and any resources created in onCreate() are released. Since the Android language is Java based, garbage collection is automatic. We do need to clear the session data when the application is closing down. The user will typically call this method when the user is done using the application.

onRestart()

This method is always called an activity has been stopped prior to it being started again.

These seven callbacks are all methods defined in the Activity class, which can be overridden to accomplish the appropriate changes to an activity as it changes states. All activities have to implement onCreate(Bundle) for their initial setup but do not have to override the other callback methods. Below in the Software Components, there will be a more detailed discussion of how each of LocatePortland’s activities will be coded with these callback methods. Architecture DESIGN SPECIFICATIONS REV. 0.93 PAGE 14 PROJECT GOPHER

The Architecture section describes the high-level design of LocatePortland. LocatePortland will have a total of five activities, each corresponding to a possible screen display the user can view. Each of these activities has several widgets in the display for the user. Each activity will also access shared application resources. Figure 3 below is a flow chart of LocatePortland’s screen displays for the user. Each box represents a screen the user will interact with while using LocatePortland. Each box also represents an activity.

Figure 3: Screen Display Flow Chart.

The user starts LocatePortland and the initial activity created is the map activity. The map is displayed for the user to see. This is the map activity’s view component in the MVC. If the user navigates to a different screen, a new activity is created after the map activity is put on pause. Below in Table 1 is the summary of each screen containing a small screenshot, description, and their method prototype. A more detailed description regarding these classes can be found in the software components below.

Table 1. Design Summary.

Class Description Image Map The Map class displays a Google Map interface import com.google.android.maps.MapActivity; within an Android public class Map extends MapActivity {} application. It overlays on the map the current location of the user and the particular landmark of interest.

LandmarkCategories LandmarkCategories displays all the public class LandmarkCategories extends Activity {} landmark categories available within LocatePortland.

SpecifiedLandmarks SpecifiedLandmarks displays all the specific public class SpecifiedLandmarks extends landmarks available Activity {} within LocatePortland.

DESIGN SPECIFICATIONS REV. 0.93 PAGE 16 PROJECT GOPHER

Favorites Favorites displays all of the user’s selected public class Favorites extends Activity {} favorites. A landmark can be listed as a favorite as well as a selected coordinate.

LandmarkDetails LandmarkDetails displays an image of the public class LandmarkDetails extends landmark along with a Activity {} brief description of the landmark.

Software Components

The Software Components offers more detail on each component listed in the Architecture section.

Widgets

Every activity in LocatePortland will implement several widgets in their display that the user can interact with. Each activity has varying layouts for which the widgets are placed. In order for LocatePortland to react to user interaction, instances of their view controls must be implemented in the controller portion of the activity. Buttons will be the most common widget amongst LocatePortland’s activities. Below is sample code taken from the button prototype. This code will be implemented in every activity’s Java controller class for their widgets.

public class Prototype extends Activity implements OnClickListener { //Declare the widgets. This is done within the scope of //the activity class. Button Invisible, Visible; ImageView Gopher;

/* Called when the activity is first created. Every activity will assign the application resources need for their specific view to Java objects. */ @Override public void onCreate(Bundle savedInstanceState)

{ super.onCreate(savedInstanceState); setContentView(R.layout.main);

//Assign the java objects to various application //resources. Invisible = (Button)findViewById(R.id.Invisible); Visible = (Button)findViewById(R.id.Visible); Gopher = (ImageView)findViewById(R.id.Gopher);

//Allows for the application to tell if either //button has been pressed by the user. Invisible.setOnClickListener(this); Visible.setOnClickListener(this); }//onCreate

Every activity will have button widgets for screen navigation.

public void onClick(View v) { switch(v.getId()) { case R.id.Invisible: Gopher.setVisibility(INVISIBLE); break; case R.id.Visible: Gopher.setVisibility(VISIBLE); break; } }//onClick }//Prototype

Application Resource Management

Multiple activities will need to share resource data of LocatePortland. New data will also have to be added to the application as the user adds new landmarks to LocatePortland.

These are the classes that will be implemented in LocatePortland. Each activity has its own class overriding the Activity class’ callback methods. There also is a Landmark class used by some of the activities. Here are the imports that will be in common amongst the classes listed below:

import android.view.View; import android.view.View.OnClickListener; DESIGN SPECIFICATIONS REV. 0.93 PAGE 18 PROJECT GOPHER

Allows a listener to be setup so that the application knows when a particular widget is being pressed. An appropriate action can then be executed as a result. For example, hitting the favorites button on the map screen tells the application to switch displays over to the favorites list.

import android.widget.Button; import android.widget.ImageView; Importing Buttons and ImageViews allows for specific widgets to be used in the code and assigned to objects. The button listener methods will be overwritten to allow varying functionality pertaining to the specific activity.

import com.google.android.maps.MapActivity; The map activity is the sole activity that imports the MapActivity. This imports the basic Google Maps functionality.

Landmark

The Landmark class represents every landmark in LocatePortland. Landmark will contain all the information about a landmark that LocatePortland’s activities will need to display their correct views. The map activity will need each landmark’s latitude and longitude. Landmark will have a GeoPoint object, which contains a longitude and latitude value. Each landmark will also have an image ID string and a description string, which is needed in the LandmarkDetails activity. The image string will specify which image in LocatePortland’s memory belongs to which landmark. Here are the helper methods that will be found in the Landmark class:

getLocation(); //Returns landmark //location (GeoPoint). getDescription(); //Returns landmark //description (String). getImageID(); //Returns landmark image //ID (String). getCategory(); //Returns landmark //category (String). isFavorited(); //Returns true if //landmark is in favorites. setLocation(GeoPoint); //Sets landmark //location. setToFavorites(); //Assigns landmark //Favorites boolean to true. saveLandmark(); //Saves custom landmark.

Instead of extending the Activity class, the map class extends MapActivity instead in order to use the Google maps functionality. Its display will be comprised of the Portland map, user/landmarks pins, and buttons for alternate screen navigation. The map activity needs to implement the Android phone’s GPS feature so the permission ACCESS_FINE_LOCATION is specified in the manifest file.

The Map activity has three tasks to perform. These are to display the buttons and listen for clicks, start connecting the GPS device to GPS satellites, and displaying the Map. The Map Activity has 3 buttons. When the buttons are pressed, they will change the view from the Map to the Landmarks or Favorites. The second task is to connect to GPS satellites. This starts with a call to get the system service. The listener to achieve this is called GpsStatus.Listener. The Map activity proceeds with a call to establish a provider for the user’s GPS. Then the Map activity will start requesting location updates. Displaying the Map is the third task of the Map Activity. Buttons, GPS, and Mapping are the basic functions of the Map Activity. This isn’t necessarily the particular order they appear in the code.

LandmarkCategories

This class displays a list for the user. Contrary to the name, it will not need to use the Landmark class. This activity will just list landmark categories for the user to select. These are nothing more than hard coded string values specified in this activity’s xml file. The widget for which these landmarks categories will be displayed is a list. The LandmarkCategories class is important because each individual landmark will be sorted into a category. This will allow the user to browse restaurants by the categories we choose to list. This class will have basic a get method that will get the vector of landmarks for the category selected.

Favorites

This class holds a vector of Landmark objects that the user has selected as their “favorite”. A user has the ability to add and remove landmarks from their favorites, which in turn adds and removes elements to this class’ vector. It won’t actually use any method functionality within the Landmark class; just store the objects for a list display. This list is initially empty and the only locations listed in it are custom landmarks that the user deems Favorite worthy. If the user chooses to save a custom location as a favorite, it will not have any details in the text box. Instead the save a custom location feature makes it a very easy operation to for the user store their current location.

LandmarkDetails DESIGN SPECIFICATIONS REV. 0.93 PAGE 20 PROJECT GOPHER

There are two different sections of the LandmarkDetails activity. The top half of the screen displays a picture that is based on the landmark currently selected. The bottom half of the screen shows a textbox. In the text box there are basic details like phone numbers, addresses, and websites. The data is hard coded into the application and this class is just reading it from the Landmark class. This class will need to get the strings and images from the Landmark class for the specific landmark. The LandmarkDetials class also relies on the SpecifiedLandmarks class.

SpecifiedLandmarks

This class holds a vector of Landmark objects just like the favorites activity does. The only difference is that this vector will not change in size. The original landmark objects will be permanently listed in the vector.

System Test Plan

The System Test Plan specifies how the user will specifically interact with the application to achieve the desired result. Follows are the five test plans that describe the applications operation. They range from launching the application to viewing locations on the LocatePortland map.

Test 1: Open Application

In this test, the user opens the application and views their location on the map.

Initial Condition:

1. The Android mobile phone is on and all components are present and properly connected. The user’s mobile phone has a touch screen component. LocatePortland is installed on the user’s device. 2. The screen is visible to the user.

Steps to run the test case: 1. The user presses on the LocatePortland icon in the menu or on their home screen. 2. The user waits for the application to load and display the map on the screen. 3. The user presses the button to activate GPS. 4. The user’s location is displayed on the map.

Expected behavior: The user observes the map and their specific location marked on the map.

Test 2: Finds landmark

In this test, the user finds a landmark on map and travels to it in real life. (ie. Pioneer square)

Initial Condition: 1. The user successfully completed test 1 before performing test 2.

Steps to run the test case: 1. The user presses the button labeled “landmarks” at the top of the screen to bring up the list for finding landmarks/restaurants. 2. The user then presses category of the desired destination. (i.e. public park) 3. The user presses the specific name of the landmark/restaurant (i.e. Pioneer Square). 4. The user selects the option for placing a balloon icon on the map at the destination location. 5. The user starts moving towards the destination based on their relative position to the landmark balloon. DESIGN SPECIFICATIONS REV. 0.93 PAGE 22 PROJECT GOPHER

6. The user reaches the landmark destination and the application alerts the user with a notification that the destination has been reached.

Expected behavior: The user receives notification when the landmark is reached.

Test 3: User saves landmark as favorite

In this test, the user saves a landmark to the favorites menu. The user saves a landmark as a favorite to locate the location on the map easier.

Initial Condition: 1. The user successfully completed test 1 before performing test 3.

Steps to run the test case: 1. The user presses the button labeled “favorites” on the top of the screen. The application then takes the user to a different screen with a list of (already saved) favorite locations. 2. The user then presses the button labeled “add a favorite”. 3. The user presses the button labeled “landmarks” on screen for finding landmarks/restaurants. 4. The user then presses the type of the desired destination. (i.e. public park) 5. The user then selects the specific landmark/restaurant (i.e. Pioneer Square).

Expected behavior: The landmark added as a favorite is appended to the favorites list.

Test 4: User saves current location on map as favorite

In this test, the user saves their current location into the application as a favorite landmark. This allows customized landmarks to be added by the user. (ie. where the user parked their car)

Initial Condition: 1. The user successfully completed test 1 before performing test 3. 2. The user is currently at the location they wish to save as a favorite.

Steps to run the test case: 1. The user presses the button labeled “favorites” on touch screen. The application then takes the user to the “favorites” activity. 2. The user then presses the button labeled “add a favorite”. 3. The user presses the button labeled “save current location” on screen for finding landmarks/restaurants.

4. The current location is saved. 5. The user has an opportunity to add a picture from the phone as the picture for the saved location (optional feature).

Expected behavior: The current location is saved to the favorites list.

Test 5: View information about location on map

In this test, the user views detailed information about a landmark. (ie. address of landmark, telephone number, picture)

Initial Condition: 1. The user successfully completed test 1 before performing test 3. 2. The user is currently at the location they wish to save as a favorite. 3. The location user will view information isn’t a custom saved landmark.

Steps to run the test case: 1. The user presses the button labeled “landmarks” on screen for finding landmarks/restaurants. 2. The user then selects the category of the desired destination. (i.e. public park) 3. The user then selects the specific name of the landmark/restaurant (i.e. Pioneer Square). 4. The application presents the user with two options, placing a balloon icon on the map at the destination location or viewing a page of information about the location. 5. The user selects the page of information and is then presented with the information about the location.

Expected behavior: The user is presented with the information about the selected location after choosing the location with the menu.

Development Plan DESIGN SPECIFICATIONS REV. 0.93 PAGE 24 PROJECT GOPHER

In Figure 3 above, the arrows indicate the direction of which screens are accessible given a certain state. For example: From the map screen, the user is able to access the favorites list, landmark detail screen, and landmark category screen. Once at the map, the user is also able to go back to the menu.

The first activity to be developed will most certainly be the map. This is because it is the central activity in our application. As the map develops, each remaining screen will develop as well. Before any activity is fully completed, it is important that their navigation, as shown in Figure 3, is completed. That is all the activities can be navigated to correctly via button and list clicks. It is important to do this first because as the activities develop more and more in their Java controller class, it may be hard to implement navigation after the fact.

Assumptions

There currently are no new additional assumptions for LocatePortland development and its use. Please refer to our Functional Specification document for development risks.

There currently are no new additional risks to the development of LocatePortland. Please refer to our Functional Specification document for development risks.

Milestones

Table 2 below lists the milestones for LocatePortland. These are listed from the beginning of the project to the end. Milestones for programming components are not solely based on, but also include a test-and-fix phase.

Table 2: Project Milestones.

Completio Number Description n Date 1 Functional Specification v0.90 9/29/10 2 Functional Specification v0.95 10/8/10 3 Functional Specification v1.00 10/25/10 4 Google Maps Implementation Decision 10/26/10 GPS Prototype 5 11/1/10 Buttons Prototype 6 Design Document v0.90 11/5/10

7 Design Document v0.95 12/9/10 8 Design Document v1.00 12/10/10 9 Map Activity 2/12/11 Landmark Activity 10 2/19/11 Favorites Activity 11 Landmark Detail Activity 2/26/11 12 Testing 3/10/11 Final Document 0.9 13 3/25/11 Testing Final Document 0.95 14 4/01/11 Testing Founder’s Day Presentation 15 4/12/11 Final Document 1.0

Functional Specification v0.90

This is the first draft of the functional specifications. Our faculty advisor edited this document. After our faculty advisor edited our functional specification v0.90, we made the revisions. Once our faculty advisor approved the revisions, the document turned into v0.95.

This is the first draft that was sent to our industry representative to be approved. Appropriate changes were made to our document based upon our industry representative’s comments. Once our industry representative approved this document, it became v1.00.

This is the final draft for our functional specification. Our industry representative and our faculty advisor approved it. All prior edits are completed.

Google Maps Implementation Decision DESIGN SPECIFICATIONS REV. 0.93 PAGE 26 PROJECT GOPHER

After hours of research, it was decided to implement Google’s own map functionality into our LocatePortland product. Our team decided to integrate Google Maps functionality into our application because this will allow us to implement additional functionality to the application.

GPS Simulator

This is an exercise to become familiar with Android’s GPS functionality. On both of the list screens, the map will be displayed showing a made up location of the landmark when a user selects a landmark. Random longitude and latitude values will be generated. The values generated will simulate a satellite feed to the phone. The GPS functionality and graphics will be used in the map activity

Buttons Prototype

This is an exercise to become familiar with Android’s buttons. The goal is to get comfortable with the button use, placement, graphics, and sizing. On both of the list screens, the map will be displayed showing a made up location of the landmark when a user selects a landmark. Buttons will be used to implement the map activity.

Design Document v0.90

The v0.90 design document is the first draft of our document that we submitted to our advisor for corrections. This document will go through the exact same editing and revision process as the functional specification does listed above. Our faculty advisor as well as our industry representative will approve the final document, v1.00, before it reaches its final documentation phase.

This is the first draft that was sent to our industry representative to be approved. Appropriate changes were made to our document based upon our industry representative’s comments. Once our industry representative approved our revisions to this document, it became v1.00.

This is the final draft for our design document. Our industry representative and our faculty advisor approved it and no more improvement is necessary. All prior edits are completed.

Map Activity

The Map Activity is a class that implements Google Maps functionality and pin points the user’s location on the map. It is completed when it correctly displays the map and the user’s location and destination.

Landmark Activity

The Landmark Activity is a class that lists the landmarks available to the user. The Landmark Activity is done when the user is able to select a landmark and it appears on the map.

Favorites Activity

The Favorites Activity is a class that allows the user to mark Landmarks as favorites. It also provides a list for quickly setting Landmarks as destinations. We know it is completed when the Favorites Activity passes the system tests.

Landmark Detail Activity

The Landmark Detail Activity is a class that displays the Landmark’s details to the user. We know it is completed when the Landmark Detail Activity passes the system tests.

Testing

It is important to plan time for testing the functionality of the application. We must plan time to run the test cases as listed above. Testing ensures that each activity of the program is bug free and that all activities interact with each other as described in the in this design document. We know it is completed when the system passes the system tests.

Final Documentation 0.9 DESIGN SPECIFICATIONS REV. 0.93 PAGE 28 PROJECT GOPHER

This version of the final documentation is the initial draft. It is to be completed when all sections of the final documentation document are filled out. It is to be approved by our advisors.

Final Budget

3 contains the budget for LocatePortland during the development phase:

Table 3: Final Budget.

Line Category Description Number Rate Amount Material 1 s # of parts Subtotal Android application development book. 1 $39.99 $39.99 2 Software $00.00 TOTAL $39.99

LocatePortland purchased a textbook to aid with developing code on the Android handset. This textbook aids in our android application development research. The textbook discusses a wide variety of android application functionality that will be implemented in LocatePortland. A major topic is the implementation of Google maps.

Conclusions

LocatePortland is a cell phone application developed with Android software. The primary goal of this application is to navigate its users throughout downtown Portland. It does this by displaying a map of Portland with the user’s current GPS location visible. The user can then decide from a list of landmarks what they would like to see and a marker of the landmarks location will be displayed. If a user has this application on their phone while in downtown Portland, they are less likely to get lost and be able to find various popular landmarks throughout Portland. DESIGN SPECIFICATIONS REV. 0.93 PAGE 30 PROJECT GOPHER

References

[1] Fowler, Martin. Patterns of Enterprise Application Architecture. Boston: Addison- Wesley, 2003. Print.

Appendix A.

This is a partial list of restaurants that will be implemented as landmarks in LocatePortland:

1 Voodoo Donuts 22 SW 3rd Ave Portland, OR 97204 Neighborhoods: Downtown, Old Town (503) 241-4704 Category: Donuts www.voodoodoughnut.com

2 Pioneer Courthouse Square 701 SW 6th Ave Portland, OR 97204 Neighborhoods: Southwest Portland, Downtown (503) 552-9890 Category: Landmark www.pioneercourthousesquare.org

3 Portland City Grill Category: American 111 SW 5th Ave Portland, OR 97204 Neighborhoods: Southwest Portland, Downtown (503) 450-0030 www.portlandcitygrill.com

4 Powell's City of Books Category: Landmark 1005 W Burnside St Portland, OR 97209 Neighborhood: Downtown (503) 228-4651 www.powells.com/info/places/burn...

5 Portland Farmers Market at Portland State University Category: Landmark /Fresh food SW Harrison and Montgomery South Park Blocks Portland, OR 97201 Neighborhoods: Southwest Portland, Downtown www.portlandfarmersmarket.org DESIGN SPECIFICATIONS REV. 0.93 PAGE 32 PROJECT GOPHER

6 Huber’s Café Category: American 411 SW 3rd Ave. Portland, OR 97204 503.228.5686 http://www.hubers.com/