Table of Contents Executive Summary 2
Download 471.88 Kb.
|
- Navigate this page:
- 3.2.1 User Interface
- 3.2.1.3 The Add Player Screen
- 3.2.1.4 The Lineup Builder
- 3.2.1.5 At-Bat Interface
- 3.2.1.7 Fielding Interface
- 3.2.1.8 Post-Game Manager
- 3.2.2 Classes
3.2 Coach ApplicationThe coach application is the point in this system that drives all of the data input into the database. It consists of 3 main functions/interfaces: pre-game, in-game, and post-game. The main function of the pre-game manager is for the user to be able to view and manage the current roster to his team. It will contain a list of all of the players that are currently on his team (which is stored in both a local and on-line database) in addition to a button to add a new player to his roster. Pressing the new player button will bring up a prompt for the user to easily input all the needed player information, a photo, and to search the database and upload previously recorded statistics if they have previously played for a different team that used this system. Additionally, the pre-game manager will allow the user to create and save a batting lineup, and also to edit previously saved batting lineups. While creating or editing a batting lineup, the user can easily manipulate the current order through easily navigable buttons to rearrange players and remove them from the lineup. A batting lineup must first be created before a user can enter the in-game manager. Once a user has entered the in-game manager, the user (or both) must link up to the Bluetooth umpire device and indicate whether they are the home or away team before the game is initiated. Once the game has begun, the majority of the data entry will be done by the team that is currently at bat. Whenever a pitch is thrown, the resulting umpire ruling (Strike, Ball, Out) will be uploaded instantaneously to the coach application. Upon any change in state, the user will be allowed to make any changes to the players that are currently on base since a steal can occur after any pitch. However, only a change in state that resets the strike and ball count will instigate the user to input the type of play, which will be done through a series of intuitive list selections which can be restarted at any time and will read back a legible string to the user to confirm their entries before being uploaded to the database. Additionally, for each change in state in the umpire device, the fielding pitcher’s pitch count will increment, allowing the fielding coach to easily track the number of pitches thrown. On each increment of the pitch count field, the user will be allowed to select the type of pitch thrown which, although is not required, allows another factor to use in the post-game manager. Finally, the interface for both coaches will allow any legal player substitutions to be performed. A high level diagram of the data flow for this portion of the system can be seen below in 3.2 Figure 1. 
3.2 Figure 1: System diagram that shows the inputs and outputs of the coach application. The third major interface in this system, the post-game manager, despite its name, can be accessed at any point, but is mainly a center to review how previous games conspired. It will allow a user to review their own, in addition to other teams that use this system to gauge their performance by several metrics. For example, a coach may be able to view how well their players bat against a left-handed pitcher, or how well their fielders catch fly balls at night, etc. It will also allow the coaches to do a player search throughout the entire database to provide in depth statistics on players from other teams similar to those found in the pre-game manager. 3.2.1 User InterfaceAll of the major sections of the user interface and how they will be implemented and used are detailed below: 3.2.1.1 The Home ScreenThe Home Screen is what first boots up when the application begins. It has buttons to access each of the 3 major interfaces of the application, seen in 3.2.1.1 Figure 1 below. Clicking on any of the 3 icons on the home screen will bring the user to one of the 3 sections: the pre-game manager, the in-game manager, and the post-game manager. The icons will simply be PNG resources that will have an onClickListener, which upon being triggered will send an intent to the appropriate Activity to trigger the corresponding user interface screen to appear on the device. 
Figure 1: Home Screen of the coach application and the buttons to the 3 major sections of the application. 3.2.1.2 The Pre-Game Manager The pre-game manager is the interface through which the coach can manage their roster and batting lineups. The prototype is shown in 3.2.1.2 Figure 1 below. 
Figure 1: Prototype of the pre-game manager that shows the player list on the left side of the screen and the detailed view on the right. On the left side of the diagram above is the list of players currently in the roster for the user’s team. The player list only shows the bare minimum of data needed to differentiate between the players: name, number, and position. Each player is represented by a single item in a scrolling ListView, at the bottom of which is the Add Player button which when clicked will send an intent to open up the new player dialog shown in the following section. The right side of the interface is populated by a larger, detailed view that contains all of the selected player’s information. Once the detailed view of a player has been opened, the user can examine all the player’s basic information in addition to a user-uploaded picture on the top portion of the detailed view which are simple textViews that will be populated based on the player’s information in a local database. If the user has not uploaded a picture of the player, a default image will appear in the box. The bottom of the detailed view will contain the calculated statistics based on the data uploaded tot eh database from the in-game manager. The statistics on this view will be set to overall by default but can be changed to current season, or most recent game through the menu options, all of which will need an internet connection to be populated from the online database. Additionally, the options menu will give the user the option to edit the basic information in the case of a position or number change or to modify age or weight. When the Edit Player Information item is selected from the menu options, it will send an intent to open the Edit Player Activity which is essentially the same as the Create a New Player dialogue listed in the next section except that it simply changes the information currently stored in the local database rather than creating a new entry. At any time, the user can return to the Home Screen by clicking the back button on the device or bring up the menu options by clicking the menu button on their device. 3.2.1.3 The Add Player ScreenThe add player screen is the interface through which the user can add an addition o their team roster so that they can be added to lineups and their stats can be tracked by this system. 3.2.1.3 Figure 1 below shows the screen through which the coaches will input the most basic information the player to be added to their roster. The add player interface is very similar to most forms that are now very common both online and within applications. It consists mainly of a few labels and their associated text fields. The player’s first and last names and player number will have to be input by the on-screen keyboard, while the Position, Bats, and Throws fields will be chosen from a drop-down Spinner widget. The players age can be easily chosen and later changed through the age Picker widget which will simply increment or decrement the number as desired by pushing the associated + or – buttons 
3.2.1.3 Figure 1: The add player dialogue appears when the Add Player button is clicked on the player list from the pre-game manager. Additionally, if a player has previously played for a team that implemented this stat tracking system, they could click the “Played Previously On Another Team” button to inherit all of the previously earned statistics from their previous team. An image can be uploaded by the user for any player being added to the roster by clicking the large “Upload Photo” box on the right-hand side of the screen which will then instigate a fileChooser dialogue to either take the picture then on the user’s device or to upload the photo from a file that exists on the device’s hard drive or SD Card. Once the user is satisfied with all of the information they have added, they can click the “Finished” button to store the new player into the local database. At any point if the user decides they would like to cancel the input, they can push the “Cancel button at the bottom of the interface which will prompt a simple confirmation poop-up and then discard all of the input information if confirmed. Pushing the back button at any point of the input process will similarly bring up the prompt to cancel the input sequence. 3.2.1.4 The Lineup BuilderThe lineup builder is the interface through which the user can (and must) determine the batting order and starting field lineup for any upcoming games. These lineups can be edited at any point prior to a game beginning but once the game has begun can only be edited according to play rules by substitutions. The lineup builder interface must be brought up through the pre-game manager’s Roster Management screen by clicking the button at the top right of the screen that says “Build Lineup”. Once pushed, the user will be confronted with the interface shown below in 3.2.1.4 Figure 1. 
3.2.1.4 Figure 1: The Lineup builder, showing the players currently added to the lineup on the left side and the bank of players from the current roster on the right to choose from. On the left side of the screen will be a ListView similar to that on the Roster Management interface that will initially, upon opening up the lineup builder be empty. On the right-hand side of the screen will be a bank containing all of the players currently in the roster and their basic information as shown on the top half of the detailed view in the Roster Management interface. To add a player to the lineup the user need simply to click anywhere on the corresponding info view on the right side of the view, at which point a small ListItem similar to that on the left side of the Roster Management screen will appear on the ListView to the left and the button on the right will be grayed-out. If there is more than one player that has been added to the current lineup, they can be moved up or down in the lineup by clicking the corresponding green arrows on the ListItem on the left-hand side of the screen. Additionally, any player can be removed from the lineup by clicking the red “x” on the ListItem and their corresponding info view on the right will become available again. At any time in the lineup building process, the user can click the “Cancel” button at the bottom of the screen which after prompting the user to confirm, will discard all inputted information and return to the Roster Once a batting lineup as been created, the user must click the “Done” button on the bottom of the screen indicated by a green arrow. This will bring up the Create Starting Fielding Lineup interface which is very similar to the previous, batting lineup; however the ListView on the left will be populated with empty spots corresponding to the 9 different fielding positions and will be clearly labeled as such. This list will be populated very similarly to the previous one except that the user must first click on which position they are intending to fill before clicking on the corresponding player view on the right that they would like to fill it. At any time, the user can click the “Cancel” button on the bottom of the screen and after being prompted to confirm, they will be returned to the batting lineup creation screen. Once all 9 of the fielding positions have been filled, the user can click the “Finished” button at the bottom of the screen to complete the lineup and add it to the local database and return to the Roster Management screen. 3.2.1.5 At-Bat InterfaceThe in-game manager is the portion of the application that actually records in the game data in the dugout in real time. It will consist of two major interfaces, the first of which is the At-Bat Interface, shown in 3.2.1.5 Figure 1 below, and the fielding interface, shown later. 
3.2.1.5 Figure 1: The at-bat interface is where most of the data input occurs. The series of lists used to determine the play type is shown above. The at-bat interface is shown in the in-game manager for the half of the inning for which the user’s team is at bat. It consists of 3 major sections. On the left-hand side of the screen is a ListView that shows the batting lineup for the team currently batting, the very top player indicating who is currently at the plate. This list is straightforward and very similar to the list in the Roster Management interface that just show the player’s name and basic information. The second major section of the at-bat interface is the field view, which shows the current state of the diamond, in addition to inning information such as strike, ball, and out count. Any runners currently on base will be represented by a small icon that show’s their player number. The third major part of the interface is the ScrollView on the bottom of the screen hat will be used to input the play information for what is happening on the field. The two situations that are recorded in this simulator are either when the batter hits the ball and is caught or thrown out, or if the batter makes it onto the bases either by a hit or a walk. These two situations are prompted when either the strike and ball count is reset to zero (indicating that there is a new batter up to bat) or if the hit occurs on the first pitch, the prompt will be determined by if the pitcher’s pitch count increases and neither the ball nor strike count changes. On either of these two occasions the user will be able to input what exactly happened by using the ListViews at the bottom of the screen starting from the leftmost, which will have the most basic options to choose from (Hit, Out, Walk, Hit By Pitch) and then the second list will be populated based on what the choice of the of the one to the left of it was. For example, if the user chooses “Hit” on the leftmost menu, the menu to the right of it will be populated with the items: “Single”, “Double”, “Triple”, “Home Run” to clarify what type of hit it was. The consecutive lists will always populate appropriately based on what was chosen in the previous list until no more branching can be made, at which point a confirmation prompt will occur where the user can either accept their input or choose to clear it and start over. If the user accepts their input one of two things will happen. If there are base runners in the field when the hit is made, the interface will cycle through them to determine what their outcome was for the play being recorded, once done the interface will read back the play to the user in plain English (e.g. “Player 1 hit a Double and Player 2 and Player 3 both advanced one base”) to be confirmed or denied based on correctness. If there are no base runners, then the interface will skip that first step and just prompt the user to confirm or deny the read back. Once the play is confirmed, all the appropriately tracked statistics will be uploaded to the database. Additionally, there is one more feature than can tracked from the at-bat interface. If there are base runners, at each change in state of the umpire device, they will be given the option to steal bases. In order to accomplish this, the user must first click on the base runner who attempted to steal the base on the field view, then the list below will be populated with the appropriate courses of action (“Stolen Base”, “Caught Stealing”, etc). Similarly to how all batting plays prompt the user before being uploaded to the database, stolen base plays will do the same. 3.2.1.7 Fielding InterfaceThe Fielding interface is the second half of the in-game manager that is shown for the half of the inning for which the user’s team is fielding. The user is rather limited in their inputs while on this interface, only being allowed to substitute players, increment pitch count, and determine pitch type. The interface through which this is done is shown in 3.2.1.7 Figure 1 below. 
3.2.1.7 Figure 1: The fielding interface showing the options that occur when a player on the left is clicked. The fielding interface is very similar to the at-bat interface hold a few minute differences. First of all, the ListView on the left of the screen is arranged based on the different fielding positions and the ListItem for the pitcher will also display the number of pitches they’ve thrown for that game. The field view will appear the same as in the at-bat interface, however the base runners will not be clickable by the fielding team when in the fielding interface. The play lists down at the bottom of the interface will be limited to only two options. First, when a fielder is clicked on the ListView to the left, the action list down at the bottom will be populated by the other players on the team who can also play that position. If one of those players is chosen, after a prompt, the player on the left ListView will be replaced with the player chosen previously. When the pitcher is chosen, the same as above will occur, however there will be an additional option that will allow for the pitch count to be increased. This is necessary for the cases when the umpire may not make any changes to the strike/ball count even when a pitch occurs, such as when a ball is hit foul when there are already 2 strikes. 3.2.1.8 Post-Game ManagerThe post game manager is the final of the 3 major interfaces of the coach application. It allows the user to see the results of previous games that were recorded using this system in addition to a lookup feature that gives information on any player throughout the league. The interface itself is shown in 3.2.1.8 Figure 1 below: 
3.2.1.8 Figure 1: The post-game manager showing the team matchup tab. It shows a comparison of important team stats juxtaposed with each other. The post game manager will have a tabbed interface for each of its 3 major function. The first tab, Team Lookup, will give users vital information about a particular team that uses this system. For example, if a coach has a game next week against a rival team (that records their stats in this system), he or she would be able to go into this tab, select that team from the dropdown Spinner at the top of the screen, and look at their team-wide statistics. Having access to numbers such as ‘batting average against left-handed pitchers’ or ‘batting average at night games’ would help a coach better develop a more specialized strategy to play against such a team. The second tab of the post-game manager will allow for side by side comparison of any two teams that implement this stat tracking system. The TabView consists of 2 Views, side by side that are initially empty except for a dropdown Spinner at the top of each view. When the Spinner is clicked, it is populated with a list of all the teams that currently have recorded stats in the database. Once a team is selected, the view below the Spinner is filled with relevant team-wide statistics. Once a second team is chosen on the opposite Spinner, then the two lists of statistics are positioned next to each other for easy comparison. The two sides of the TabView operate in exactly the same way and completely independently of each other. So while technically this tab is meant for team comparison, a user could technically select only one team and view their statistics rather than 2 for comparison. The final Tab of the post-game manager is the player lookup tab. It operates very similarly to the Roster Management interface from the pre-game manager in that it provides detailed information on a specific player, but differs in that it can do so for the entire league. It will have a search bar with an auto-complete feature that once the user begins typing the name of the desired player, possible results will be displayed below the search bar for the user to click on, displaying the detailed view of that player’s information in the view below. If no player can be found that matches the typed name, then that will be indicated to the user.
|
|
Method |
Description |
|
onCreate() |
Called when the activity is first created. This is where all normal static set up is done: create views, bind data to lists, etc. This method also provides a Bundle containing the activity's previously frozen state, if there was one. *Always followed by onStart(). |
|
onRestart() |
Called after the activity has been stopped, prior to it being started again. *Always followed by onStart() |
|
onStart() |
Called when the activity is becoming visible to the user. *Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden. |
|
onResume() |
Called when the activity will start interacting with the user. At this point the activity is at the top of the activity stack, with user input going to it. *Always followed by onPause(). |
|
onPause() |
Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns. *Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user. |
|
onStop() |
Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed. *Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away. |
|
onDestroy() |
The final call received before an activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. Distinguishing between these two scenarios can be done with the isFinishing() method. |
3.2.2 Table 1: A list of methods supplied by the Android API for all activity classes.
Home Activity: The home activity has very few methods or fields since it is used simply as a navigation screen to the other areas of the application. The 2 methods used in this class are listed below in 3.2.2 Table 2.
|
Method |
Return Type |
Description |
|
onClickListener() |
onClickEvent |
These listeners will be applied to each of the navigation icons to supply an intent to switch to the other areas of the coach application upon the user’s clicking on them. |
|
checkForLineup() |
boolean |
Will be initiated upon the user clicking the In-Game Manager icon and will check to see whether they have a pre-made lineup stored in their local database before allowing the intent to be sent to switch to that portion of the application. |
3.2.2 Table 2: A list of methods for the Home Activity class.
Pre-Game Manager Activity: The methods in this Activity are mainly used as interface mechanisms through which the user can perform the functions of this interface as described in the previous section. All of the methods utilized by this class are listed below in 3.2.2 Table 3.
|
Method |
Return Type |
Description |
|
populateList() |
Void |
Will read in the entire roster from the local database where it is stored and populate the left-hand side ListView with the simple basic Player data. |
|
fetchDetailedView() |
Void |
Will fetch the more detailed player information and draw the view to which all of this information will be presented to the user. |
|
fetchPlayerData() |
int[] |
Will ping the online database and fill in the bottom part of the detailed player description that contains all of their overall statistics. |
|
updateView() |
Void |
Updates the entire user interface assuming some change in state of the device. |
|
onListItemClick() |
onClickEvent |
Method which will detect the clicking of one of the players on the left-hand side of the interface. |
|
onMenuItemClick() |
onClickEvent |
Method that will detect the opening and clicking of a menu item. |
3.2.2 Table 3: A list of all of the methods for the Pre-Game manager activity class.
Lineup Activity: The methods in this activity will allow the interface to build and edit the player lineups that are required in order to use the In-Game Manager portion of the application. A complete list of the methods used by this activity can be found below in 3.2.2 Table 4.
|
Method |
Return Type |
Description |
|
addToBatting() |
Void |
Adds a player to the current batting lineup and grays out their view on the GridView selector. |
|
addToField() |
Void |
Adds a player to the current fielding lineup and grays out their view on the GridView selector. |
|
moveUp() |
Void |
Upon clicking the green up arrow on each of the ListItems in the batting lineup, this method will swap the ListItem with the one located above it. |
|
moveDown() |
Void |
Upon clicking the green down arrow on each of the ListItems in the batting lineup, this method will swap the ListItem with the one located below it. |
|
remove() |
Void |
Upon clicking the red X on each of the ListItems in the batting lineup, this method will remove the selected player from the lineup and set their selector on the GridView back to normal. |
|
submit() |
Void |
Saves the current lineup to the local database for use in the In-Game Manager. |
|
nameLineup() |
Void |
Applies a desired name to the current lineup so that multiple can be made and differentiated from each other. |
|
startField() |
Void |
Advances the lineup editor from the batting lineup screen to the fielding lineup screen. |
3.2.2 Table 4: A complete list of methods for the lineup activity class.
Edit Player Activity: The methods in this activity will handle the creation and editing of Player objects (shown later in this section) in addition to their storage in the local database and access to their information from other classes. A complete list of methods can be found below in 3.2.2 Table 5
|
Method |
Return Type |
Description |
|
getText() |
String[] |
Returns an array of strings that give any other class access to all of the player information stored in the local database. |
|
setFName() |
Void |
Initiates the first name field to the string that is passed in. |
|
setLName() |
Void |
Initiates the last name field to the string that is passed in. |
|
setNum() |
Void |
Initiates the player number field to the integer that is passed in. |
|
setPos() |
Void |
Initiates the position field to the string that is passed in. |
|
setBats() |
Void |
Initiates the bats field to the string that is passed in. |
|
setThrows() |
Void |
Initiates the throws field to the string that is passed in. |
|
setAge() |
Void |
Initiates the age field to the integer that is passed in. |
|
setHeight() |
Void |
Initiates the height field to the integer that is passed in. |
|
getImageFromDev() |
Image URI |
Returns the location of the image selected by the user to represent the player from elsewhere on the device. |
3.2.2 Table 5: A complete list of methods for the edit player activity class.
At Bat Activity: The methods in this activity handle all of the user’s input of data and the update of current game information in the In-Game Manager while the user is batting for their half of the inning. A complete list of methods for this class can be found below in 3.2.2 Table 6
|
Method |
Return Type |
Description |
|
incOuts() |
Void |
Increments the number of outs for the current half of the inning. |
|
incBalls() |
Void |
Increments the number of balls for the current half of the inning. |
|
incStrikes() |
Void |
Increments the number of strikes for the current half of the inning. |
|
incScore() |
Void |
Increments the score of the team currently at bat. |
|
incInning() |
Void |
Switches the current team from batting to fielding and increments the inning number if necessary. |
|
populateLineup() |
Void |
Populates the ListView on the left-hand side of the screen with the batting lineup from its current position. |
|
incrementLineup() |
Void |
Removes the current batter from the “At bat” section, moves the next batter in line into that position, and moves all the other batter up in the list. |
|
reorganizePlayList() |
Void |
Updates the list selectors on the bottom of the screen to indicate either the refining of a currently selected play or to initiate play selection altogether. |
|
advanceRunner() |
Void |
Moves a base runner to the next base depending on what type of hit occurred or if the base is stolen. |
|
submit() |
Void |
Submits the selected play and displays the prompt to the user to confirm that the entered play Is correct. |
|
upload() |
Void |
Uploads the confirmed Play object to the online database. |
|
clear() |
Void |
Clears any data recorded for a particular play for re-entry to account for user error. |
|
confirm() |
Void |
Approve that the indicated play is correct and ready to be uploaded to the online database. |
3.2.2 Table 6: A complete list of methods for the At bat activity class.
Fielding Activity: The methods in this activity will provide the needed abilities to show the current field state, player substitution, and incrementing of pitch count as needed for when a team is currently fielding. A complete list of methods for this class can be found below in 3.2.2 Table 7.
|
Method |
Return Type |
Description |
|
incOuts() |
Void |
Increments the number of outs for the current half of the inning. |
|
incBalls() |
Void |
Increments the number of balls for the current half of the inning. |
|
incStrikes() |
Void |
Increments the number of strikes for the current half of the inning. |
|
incScore() |
Void |
Increments the score of the team currently at bat. |
|
incInning() |
Void |
Switches the current team from batting to fielding and increments the inning number if necessary. |
|
populateField() |
Void |
Populates the ListView on the left-hand side of the screen with the players that are currently filling each of the fielding positions. |
|
makeSub() |
Void |
Upon clicking the player that needs to be substituted from the list on the left, the ListView at the bottom will be filled with valid substitutions and once selected, the 2 players will be swapped. |
|
incPitchCount() |
Void |
Increments the pitch count of the current pitcher in the case that it is not automatically done by a change of state in the umpire indicator. |
3.2.2 Table 7: A complete list of methods for the Fielding Activity class.
Post Game Manager Activity: The methods in this class seen in 3.2.2 Table 8 will be responsible for displaying all of the team evaluation information that is required for the interface to work as specified in the specifications.
|
Method |
Return Type |
Description |
|
displayTeamStats() |
Void |
Once a team as been selected from the drop-down Spinner, this method will pull the information indicated in the specifications from the online database and populate them into the view on the tab indicated in the interface section. |
|
statsCompare() |
Void |
On the team comparison tab of the interface, this method will populate each of the views according to the selection on their respective drop-down Spinners. |
|
updateView() |
Void |
Updates the entire user interface assuming some change in state of the device. |
|
searchPlayers() |
Player |
Provides the user with a search feature of the entire online database for any particular player. Returns player to be displayed in the detailed view |
|
populateSpinner() |
Void |
Populates each of the drop-down Spinners with all of the applicable team selections from the online database. |
|
displayPlayerStats() |
Void |
Displays the information returned from the searchPlayers() method to show all of the statistics for the player given a valid return from that method. |
|
populateDetails() |
Void |
Refreshes the view with any change in statistic from a previously loaded team or player view. |
3.2.2 Table 8
In addition to the main activity classes that will represent the core functionality of the application, a few data classes for easy and intuitive storage of specialized data will be used as indicated as follows in 3.2.2 Figure 2. These classes will be part of a separate, data, package.
3.2.2 Figure 2: The data package and its contained classes, fields, and methods.
The following is a brief description of each of the data classes, their methods, and return types:
Game Class: The game class keeps track of the current status of a game in progress. Its fields keep track of vital information such as scores, balls, innings, etc. so that in the event of the application being closes or minimized, no game data will be lost in the process of bringing the In-Game manager back into focus. The following 3.2.2 Table 9 is a complete list of methods for the game class.
|
Method |
Return Type |
Description |
|
swapTeams() |
Void |
Swaps the current state of the two teams from batting to fielding and vice versa whenever the 3rd strike is reached in an inning. |
|
incHomeScore() |
Void |
Increments the home team’s score when a run is scored. |
|
incAwayScore() |
Void |
Increments the away team’s score when a run is scored. |
|
getScores() |
Int[] |
Returns an array of the scores of the two teams. The home team is in the first position and the away in the second. |
|
setStrikes() |
Void |
Either increments the strike count when a strike occurs or sets it to zero when an out occurs. |
|
getStrikes() |
Int |
Returns the integer value of the number of strikes for the current at bat. |
|
setBalls() |
Void |
Either increments the ball count when a ball occurs or sets it to zero when an out occurs. |
|
getBalls() |
Int |
Returns the integer value of the number of balls for the current at bat. |
|
setOuts() |
Void |
Either increments the out count when a batter is out or sets it to zero when a field change occurs. |
|
getOuts() |
Int |
Returns the integer value of the number of outs for the current half-inning. |
|
incInning() |
Void |
Increments the inning number. |
3.2.2 Table 9: A complete list of methods for the Game class.
Lineup Class: The lineup class is used to provide the in-game manager with a premade list of fielders and batters so that it can all be handled automatically to minimize complexity within the In-Game Manager. Seen below in 3.2.2 Table 10 is a complete list of methods for the lineup class.
|
Method |
Return Type |
Description |
|
getBatting() |
Player[] |
Returns an ArrayList of player objects that the In-Game Manager will use to populate the batting lineup ListView and to wrap it around once the list has been initially exhausted. |
|
getPitch() |
Player |
Returns the Player object that has been designated as the starting pitcher. |
|
getCatch() |
Player |
Returns the Player object that has been designated as the starting catcher. |
|
getFirst() |
Player |
Returns the Player object that has been designated as the starting first baseman. |
|
getgSecond() |
Player |
Returns the Player object that has been designated as the starting second baseman. |
|
getSS() |
Player |
Returns the Player object that has been designated as the starting short stop. |
|
getThird() |
Player |
Returns the Player object that has been designated as the starting third baseman. |
|
getCenter() |
Player |
Returns the Player object that has been designated as the starting center fielder. |
|
getLeft() |
Player |
Returns the Player object that has been designated as the starting left fielder. |
|
getRight() |
Player |
Returns the Player object that has been designated as the starting right fielder. |
3.2.2 Table 10: A complete list of methods for the Lineup class.
Player Class: The player class is a simple holding object to keep all of a player’s information easily accessible in a single location so that data transmission between classes is as simple as possible. It will simply have several data access and editing method for all of its fields. The following 3.2.2 Table 11 is a complete list of methods for the Player class.
|
Method |
Return Type |
Description |
|
getName() |
String |
Returns the String representing the player’s first name from the fName field. |
|
setName() |
Void |
Sets the player’s first name to the String passed in. |
|
getNum() |
Int |
Returns the integer value of the players number from the number field. |
|
setNum() |
Void |
Sets the player’s number to the integer passed in. |
|
getPos() |
String |
Returns the String that represents the player’s played position from the position field. |
|
setPos() |
Void |
Set’s the player’s position to the String passed in. |
|
getAge() |
Int |
Returns the integer value of the players age from the age field. |
|
setAge() |
Void |
Set’s the player’s age to the integer passed in. |
|
getThrows() |
String |
Returns the String that represents the player’s throwing arm from the throws field. |
|
setThrows() |
Void |
Sets the player’s throws field to the String passed in. |
|
getBats() |
String |
Returns the String that represents the player’s batting arm from the bats field. |
|
setBats() |
Void |
Sets the player’s bats field to the String passed in. |
|
getQuickInfo() |
String[] |
Returns a String array of the quick info that appears on each player’s ListItem in the In-game and Roster Management interfaces |
|
getDetailedInfo() |
String[] |
Returns a String array of the detailed info that appears on the player’s detailed info screen in the Roster Management interface. |
|
toString() |
String |
Returns a string that just lists all of the Player’s fields. |
3.2.2 Table 11: A complete list of methods for the Player class.
Directory: seniordesign -> fa2010sp2011
seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr
seniordesign -> Group 5 Spr-Sum 2011
seniordesign -> Senior Design II paper
seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11
seniordesign -> Flight Performance Data Logging System
seniordesign -> Amphibious vehicle
seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle)
seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler
seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr
seniordesign -> Group 5 Spr-Sum 2011
seniordesign -> Senior Design II paper
seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11
seniordesign -> Flight Performance Data Logging System
seniordesign -> Amphibious vehicle
seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle)
seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler
Download 471.88 Kb.
Share with your friends: