Soccer League - Final Capstone Report

Running head: REPORT FOR A SOCCER LEAGUE TRACKING APPLICATION 1
Capstone Project Report: Soccer League Tracking Application for Android/IOS
Client:
South County Soccer League
Course:
CST 499: Computer Science Capstone
California State University, Monterey Bay
Team Members:
William Barajas
Mercedes Garcia
Thomas Krause
Eric Ybarra
October 13, 2019

REPORT FOR A SOCCER LEAGUE TRACKING APPLICATION 2
Executive Summary
Managing a sports league of any kind is a time consuming task. In soccer, managers are
responsible for scheduling games, finding volunteer referees, and keeping track of scores. In
addition, managers are responsible for seeding playoff games accordingly and ensuring all teams
know their standings. Keeping referees and teams posted can be difficult when doing things by
paper or posting things through social media since not everyone is easy to contact or available at
specific times. Adding to that, not everyone uses social media. Parents and spectators who miss
any games, currently have no means of receiving a recap of the best plays of the game or what
the final score was at a moments notice. However, much of these tasks can be automated in this
day and age.
For this project, our main goal is to create a mobile application alongside a website that is
capable of providing users of this service the ability to track team statistics. There will be no
issues whether the end user has a smartphone that is either an Android or is an IOS device to the
extent that they will have access to an alternative. The website will have all of the applications
features and will be available via any computer or phone with internet access. Additionally,
league admins will be able to manage their own league by having access to different tools such
as being able to start multiple leagues, removing and adding teams, and assigning different roles.
The time frame for completing the project will span over an eight week period beginning
on August 28 and ending October 18.
The population that will be affected by this project will include league administrators,
coaches, players and any soccer interested in their local soccer league. The client that will help in
testing the application and website will be South County Soccer League. South County Soccer
League is a privately held organization dedicated to providing recreation for local boys, girls,
and adults.
The purpose of this project is to provide a means of simplicity and reliability in order to
have everyone involved in the organization as well as soccer enthusiasts solely focused in the
sport.
Table of Contents
Introduction 5
Problem/Issue in Technology 5
Solution to the Problem/Issue in Technology 6
Project Goals and Objectives 7
Stakeholders and Community 8
Evidence that the Project is Needed 9
Feasibility Discussion 10
Functional Decomposition 12
Selection of Design Criterion 14
Final Deliverables 15
Approach/Methodology 15
Ethical Considerations 16
Legal Considerations 16
Timeline/Budget 35
Resources Needed 18
Milestones 18
Usability Testing/Evaluation 35
Final Implementation 35
Discussion 35
Conclusion 35
References 36
Appendix 37
Appendix A 37
Appendix B 38
Appendix C 39
Introduction
South County Soccer League is one of many soccer leagues that have a problem. Being
able to track various items at once can be overwhelming. Managers are responsible for
scheduling games, finding volunteer referees, and keeping track of scores. Keeping referees,
managers, teams and players up to date can be a difficult task when it comes to doing things by
paper which in turn can become a time consuming assignment relatively quick. Our solution for
our client, South County Soccer League, is to create a mobile application alongside a website
that makes it easier to keep track of teams, games and players. Not only will this product benefit
managers, referees, and players but soccer enthusiasts who would like to follow their favorite
local soccer team’s performance. Some of our team members have been part of a local soccer
team and have experience first hand how difficult it can be when everything is done on paper or
over social media. Not all soccer players, staff, coaches have social media which causes a
problem to solely use the traditional method of pencil and paper. This led our team to come to
the conclusion that this is a problem that needs a solution which we can provide. This project is
sponsored by South County Soccer League but it can be used by any soccer league regardless of
their location.
Problem/Issue in Technology
Community sport leagues often struggle with keeping track of their schedules for practice
and games, in a manner in which all players can access it from one location with ease. These
leagues must also keep track of wins and losses as well as other statistics. Often, this information
is still being tracked by the manager of the league and schedules are being handout to players in
paper form. This can create a problem when schedule changes occur. Not being able to have one
location, either website or mobile app, where players and managers can easily access to find their
schedules and games stats, makes it difficult when there are inevitable changes to schedules or
game updates. For community leagues, there are few options to help with this issue of
scorekeeping and scheduling. Many community leagues still rely on Facebook or other social
media apps to update members about stats and scheduling. This proves to be unreliable given the
competing content in the social media platform, anything from ads to the ever changing feeds. In
this situation, a league member must look up their page and scroll to find any new postings or
changes. In addition, there is a possibility that not all league members have social media
accounts and this makes it even more difficult for members to have communication.
Solution to the Problem/Issue in Technology
Our solution to this problem is to create a mobile application where users will be able to
use for tracking various different statistics of their leagues, players, etc. Alongside the
application, there will be a website that will allow users that do not have access to an android
smartphone to use on any other smartphone or computer. Both the application and website will
provide valuable services that any community soccer league can find useful to their organization.
One major component to our application and website is a scorekeeping feature in which there is a
record of scores per team in any given game. Our goal is to have a simple and easy to use
application that serve the basic needs of a community soccer league. Users are able to compile
statistics from the data imputed after every game. Aside from scorekeeping, we will also deliver
an area for administrators to set up a schedule for games and practice times. This will make it
easy when changes or updates to the schedule occur. Players and other members will be notified
when possible changes occur, whether it’s canceled games or location changes. An essential part
of the application and website is that we will provide a record of all the players and their stats.
With all this we hope to turn in an application that is what the clients seek and is easy to use and
understand.
Project Goals and Objectives
I. Provide an app and website based on the same code base and API where leagues can keep
track of divisions, teams, games, and players.
A. REST API for the app built with Rails
B. NativeScript framework for Android / IOS for web deployment
II. Allow users to register and follow teams, create their own leagues and teams, assign
players to teams, and assign addition league admins.
A. Develop database schema and backend for mobile app
III. Provide ability to track teams in a league and their scores, games played, games in
progress, missed, won, lost, and tied. Team placement should be viewable in the App and
online.
IV. Provide ability to create divisions in each league and for referees to track all game events
such as yellow cards, red cards, score and by which player, halftime, substitutes, game
duration and start time.

V. League admin should be able to assign roles for different users and invite them to the
teams.
Stakeholders and Community
Our project of creating a mobile application, as well as a website, will serve community
sports leagues for small local sports teams. The stakeholders include the league’s coaches,
players, referee volunteers, and managers. Community leagues are often small and are made up
of volunteers who donate their spare time to the league. They are adults with full time jobs,
college students, and high school students who all have busy lives and responsibilities outside of
their work in the leagues. These members volunteer their time as players, coaches, or managers
because they are passionate about playing sports and enjoy investing their time in the community
leagues. They love being part of a team, and are pleased to be able to compete with other local
sports teams. Since members are donating their spare time to practices and games, there leaves
little time to invest in the organization of league logistics such as creating and distributing
schedules for practices and games, scorekeeping, and game stats. Often, these leagues have
Facebook pages where members can check for any updates in schedules or game stats. In some
cases, there are group text messages where members can be reached in case there have been
changes in scheduling or game stat information.
A few issues arise with the current organizational procedures for these leagues. Because
most members have full time jobs or are full time students, the need to have to go to the
member’s Facebook account to search for their team’s page is time consuming and would have
to dig through all the content on the Facebook page in order to gather basic information. Users
will benefit from our mobile app or website contains all pertinent information in one place
without competing with other content. They will be able to easily access information about their
team and players. This is beneficial because members do not waste time digging to find
information about their team or being distracted by other content. Members will also not be
bombarded by constant text messages when being contacted for updates. Leagues will have an
opportunity to organize their tasks with ease without wasting their time printing schedules or
updating their Facebook page. Our project will allow league members to have more time to do
what they love, play sports.
Evidence that the Project is Needed
Currently, there are very few mobile applications that offer services to assist community
sports leagues with their needs. The ones that are available are for other sports, such as
GameChanger, which is a very robust application but only supports baseball and softball. There
is one other application that we found which supports all sports however the free feature set is
very limited and only supports rostering. Thomas, a member of our team, has children in a local
soccer league in Menifee. As a parent, he has witnessed the lack of communication between
coaches and parents regarding various game events from scheduling to scoring. In order to help
leagues fill this gap, a software solution would be be suited as is part of the reason for this
project.
Feasibility Discussion
This feasibility discussion will focus more in depth on the results of the environmental
scan made on similar projects. One mobile application that offers such services to sports leagues
is “LeagueApps”, where users register on their website and pay to have access to the mobile app.
Users can choose the sport they want and are able to customize features. From their website,
LeagueApp describe themselves as “The LeagueApp platform sets you up for success by
tackling time-consuming tasks, which allows you to get back to what you love.” If a user is
interested in purchasing this service, the user must register for a demo and select pricing. The
actual features and services are not clear on their website, until the user has registered and
received a quote. This may deter a lot of potential users given the lack of clarity from
LeagueApp’s website. Since users have to register before being able to see what LeagueApp’s
features and services are, they have to wait until LeagueApp contacts them via email to get a
demo of their mobile app and later receive a pricing quote. For most community leagues, this
seems like a lot of unnecessary work just to have access to scorekeeping and scheduling services.
There are a few mobile apps that offer basic scorekeeping functions such as “Scoreboard-
On the Go”, “Score-Keeper”, and “Broad ScoreKeeper”. These apps do not have other features
other than simple scorekeeping which is not ideal for community leagues given that it lacks
scheduling and game stat information. Example of current scorekeeping applications offering
more features are “GameChanger Baseball Softball” and “Scoreboard”. These apps are user
friendly and do not require prior registration for users to see what they offer. However, these
apps lack features for scheduling and other services that community sports leagues need to
facilitate their tasks and keep track of updates on games stats and ever changing scheduling.
Although there are mobile apps that track team scores, there are few that offer more services that
are useful to community leagues. Of the few mobile apps that exist in the market, like
“LeagueApp”, make it difficult for potential users to learn about their services and features
without having to first register and hear back from them via email. There seems to be a place for
a useful mobile app or website that allows community sport leagues to easily keep track of
scores, scheduling, and other pertinent team information all in one place where users are updated
with changes without the hassle of registering to see a demo of the app first.
As the result of researching the few applications that are offered to users to manage a
sports league, the development team behind this project discussed and came to the conclusion
that a simple, straightforward approach would be the ideal solution. After comparing and
contrasting all of the various features or tasks one must go through to have access to such
service, it made sense to lean towards this proposal. Our soccer league tracking application will
consist of a user interface that’s easy to use and provide the features that many of the other sports
mobile applications lack in their implementation. Community sports leagues will not have to
worry about registering to try a demo of the mobile application since time is always an important
thing especially when it comes to managing a sports league. Additionally, our mobile application
will have features such as allow the user to create leagues and teams to which they can then
populate with player information which GameChanger has but only for the free version.
Furthermore, our soccer league application will have a tracking feature that shows valuable
information such as current table standings, games played, won, lost, etc. Mobile applications
already exist that have this feature like GameChanger and Scoreboard but have an absence of
one or more important features that leagues need in order to manage it with ease. This is the root
of the problem which we intend to provide a viable application that provides all the necessary
features in this project.
Functional Decomposition
The Soccer League mobile application has four basic functions: a roster page, schedule
page, scorekeeping page, and a settings page, these being our desired features for our application.
Our goal is for the Soccer League app to be available for both IOS and Android users. For this
reason, the design of the app is more complex than simply designing for either just Android or
IOS users. We started by creating a database diagram that lists tables of the data needed for the
mobile application. The tables include: leagues, ruleset, divisions, teams, users, team_users,
games, GameEvent, and games_events. We used this database design to begin setting up our
application’s backend functionality.

We began with creating a basic login and sign-up functionality for users to register and
create their login information. The roster page was the first primary function we tackled given
that it’s the basis for the other functions such as the schedule and scorekeeping pages. The
roster’s page takes in the users basic information such as player name, team name, and league
name. We will use this information in the second basic function, the schedule page. We designed
the schedule page to display the user’s upcoming events, which is either a “game”, or “other”. It
will display all events into a list starting with the most recent event coming up and ending with
the furthest event date. For each event, the day of the week, day of the month, and month are all
displayed as well as the type of event , a start time, the name of the opposing team, and the name
of the location. Our third basic function is the scorekeeping page, which will be under the home
or “overview” page. This function will keep track of a game’s final score, which is then used to
generate a stats report about a teams total number of wins and losses. Lastly, the fourth basic
function is the settings page. This page allows a user to see who they are logged in as. It also
shows the record of the team and team they are viewing. Finally, users can also use this menu to
log out of their account.
When the user logs into the app, the first thing they will see is the overview/homepage
that will display recent or current information, such as final game scores, league standing, past
events, and upcoming events. Collectively, these basic functions will help to serve the needs of a
community Soccer League, particularly the South County Soccer League.

Selection of Design Criterion
During the initial phase of the project, the development team determined a handful of
features that the end user would require. This included users having the ability to access various
amounts of information that would help keep them up to date with their league, team, etc. To
keep everything in order, we came to the conclusion that each user would need to have an
account to have access to this information. The next key feature talked about was to allow
admins to have special administrative privileges such as assigning roles to different users.
As the project has progressed, other features were added. The first one that was included
was having the user able to click on any one of the events listed to find further information about
the event, like the location’s address. Another functionality of the schedule page is an option for
the user to create an event, either a “game” or “other”. We purposely made an “other” option for
the create event page so that the user can input what the event is: a fundraiser event, a practice,
or even a celebration event, it is up to the user to input what the specific event is.
The final goal of this project is to have a fully functioning app capable of providing an
easier way to manage a soccer league. In order to keep the app working in any general area, the
application’s front-end and back-end are deployed on Heroku which is cloud based so all
database information will be protected and safe from any environmental factors in case of any
disaster. The cost of maintaining the application running is based on the usage on a monthly
basis. In addition to improve performance of the application Heroku offers various plans if there
are twenty concurrent connections it is a certain price. In this case, the more soccer players that
are registered with the league, the league would need a plan that would suit the amount of
players they currently have.

Final Deliverables
Final deliverables include a mobile application that Android and IOS users will be able to
use for tracking various different statistics of their leagues, players, etc. The application will
provide valuable services that any community soccer league can find useful to their organization.
One major component to our application is a scorekeeping feature in which there is a record of
scores per team in any given game. Users are able to compile statistics from the data imputed
after every game. Aside from scorekeeping, we will also deliver an area for administrators to set
up a schedule for games and practice times. This will make it easy when changes or updates to
the schedule occur. Players and other members will be notified when possible changes occur,
whether it’s canceled games or location changes. An essential part of the application is that we
will provide a record of all the players and their stats. With all this we hope to turn in an
application that is what the clients seek and is easy to use and understand.
Approach/Methodology
We will begin our approach by mapping out the layout of the app. As well as conducting
a meeting to see how the work will be split up amongst the group then each member of the team
will conduct relevant research that pertains to this project. This includes reading valuable
information from a credible source that will help with the creation and enhancement of the app’s
features. For our approach, we chose to use an agile methodology for our Soccer League app
capstone and each iteration lasted a week. Also, our group should keep remaining to brush up on
their skills and knowledge of NativeScript framework and REST APIs so that they may be
applied to the project.

Ethical Considerations
In the Soccer League app, there are current plans to show the team roster which could
potentially be accessible by anyone. As of yet, we have yet to discuss how to handle players and
children whose parents do not want them to be listed on the app. While this could just be there
name or initials and generally would be acceptable, we should consider options for parents who
want to keep their children’s information confidential. Going into the project, this will be one
ethical concern that we’ll need to be aware of. One possible solution is to allow the parent to list
an alternative display name for the player such as a first initial and last name or only first name.
Another solution could be to allow the parent to mark their player as private and only show the
player number without a name. The team will need to contact the league to see which option
would work best for them.
In addition, since the application will require technology to access, there is a chance some
underprivileged groups would not be able to interact with it. Unfortunately, we do not have the
means to provide access to technology for them. However, one possible way we could solve this
is to allow the league the ability to print out the scores and match history for these situations. The
league would then be able to handle any situations that arise and handle this as they see fit.
For this project, there will not be any human study research required.
Legal Considerations
There are similar services out there to what the Soccer League App will provide. As of
yet, we have not done any research on patents in this area. Likely there’s no patents that would
interfere with the development of the application. However, the team will need to do our do
diligence to ensure we’re not infringing on a patent that could result in legal trouble. In addition,
the application will need to have an End User agreement for each user and league that uses the
application. This should ensure that users are aware of what their data is used for what is allowed
on the application. The user agreement should help protect the team from any lawsuits against us
by a league.
However, we could also help circumvent issues by putting a disclaimer on the league
creation tool that leagues should have their own agreements with parents as most already have
for injuries due to an unforeseen accident in sports.
Lastly, any technologies and external services used in the application should be given
credit for their work. For example, we have plans to use NativeScript for the application which
has a license agreement that should be visible and credit given to them according to their license.
In the application, this should be clearly visible along with any other services or software we use
in the application.
Timeline/Budget
Module Task
1 Project Setup and Initial Schema
2 League and Team Creation / Management
3 Game and Player Management
4 Score Tracking and Team Stats

5 Finalize Application and Deploy
6 Testing
7 Bug Fixes and Refine
8 Presentation
Resources Needed
This project required various resources during the development and testing phase. The
integrated development environment that was used to write both server-side and client-side code
was JetBrain’s IntelliJ IDEA Ultimate. Languages used in this project included Ruby, JavaScript,
JSON, HTML, CSS, and SQL. Ruby on Rails framework was used for the server-side. VueJS
and the NativeScript framework were used for Android and IOS app development. Other
services included MySQL for the database and Heroku for cloud deployment. In order to work
collaboratively, our team used a version control system known as Git with a shared repository on
GitHub.
Milestones
The project consisted of many phases each having an achievable milestone. During the
first phase, the key milestone was to come up with the project setup and create initial schema.
Phase two consisted of the development stage that was composed of multiple parts. This
included designing a user interface, creation of teams and leagues, management of player and
games, score tracking, and team statistics. In the testing phase, it was composed of having
administrators from South County Soccer League testing the application in order to receive
constructive feedback about the following product. In the final phase, it was to refine any bugs
found during the testing phase in order to produce a bug-free final product.
During the initial phase of the project, we had issues setting up the necessary software
such as our emulators to test the app. Because of this minor setback we did not meet our goal to
create the login/logout pages in the intended second phase. Once we got over the initial phase of
getting our emulators to run, we were able to catch up to our timeline. During week three, we
discovered that were unable to deploy Nativescript to the web for our website, unless we created
additional projects in order for it to work. We decided that we would focus on the website after
the app is finished and if time permitted. Ultimately, we did not create a website due to lack of
time and decided to add a few more features to our app instead, such as adding a map and an
event detail page.
Usability Testing/Evaluation
To test the app, we had the users download the Nativescript preview app to their
smartphones. We didn’t need much to conduct the evaluation other than the Nativescript preview
app and Heroku which hosted the backend API to communicate with the app. We gave the
testers a few days to test the app with minimal instructions and then had them reach out to us in
case they encountered any issues. Luckily, there were very few tech issues. The only issue that
we discovered was that one of the testers does not speak English, so he had a hard time reading
the stats etc. However, he was able to follow most of the pages with the help of the image fonts
for “homepage”, “schedules”, and “roster.” We gave the two testers the review form and they
were able to get back to us fairly quickly.

For our usability testing phase, we created a Google Form for testers to review our app.
The questionnaire consisted of several questions in which the testers rated the app. Our
application was evaluated by members of the South County Soccer League, administrators Jose
Barajas and Benny Herrera. In the evaluation form, we focused on the usefulness of the
application. We want to verify that the application meets the soccer league’s needs. Our goal is
for the application to have all the components needed for a community soccer league to function
with ease. We had the testers rate the usefulness of the application and website, with a rating of
one to four, one being “Not useful” and four being “Very useful”. The average score for this
rating of usefulness was a rating of 4, “Very Useful”. This let us know that the app has all the
necessary and basic functions that South County League needs to run their organization.
Another area of interest is the ease of usability of the application and website. Users do not need
to have extensive knowledge in computers or complicated software in order to use the services
that we will provide. It is important that members of the South County League are able to use the
application to the fullest with little confusion. Usability of the application will also be evaluated
within our survey. We asked testers to rate the difficulty level of the application. Testers had the
option of choosing a rating from one to four, with one being “Difficult” and with four being
“Easy”. From their responses, they gave us an average rating of 4, “Easy”. This indicated that
despite one tester’s language barrier, the app was still easy to follow, with the help of the image
fonts throughout the app.
In addition to a series of rating questions, our survey also asked for tester/user input. We
asked the testers what they liked the most about the application. One of their responses was,
“The homepage was convenient because it lets us know the upcoming game and previous game’s
score”. This lets us know that we met the needs of a soccer league in order to function efficiently
with the use of our application. We also ask how the application can be improved. With this
information we can see where the application falls short, given that the testers suggest
improvements for it. This was the most valuable question for us because it forces the tester to be
honest about an area or aspect of the app in which they we were not happy with. This question
revealed if the function or usability is not working the way it is intended to. One of the testers
suggested we create a page with more detail of specific events or games. However, another tester
commented, “I don’t see where the app can be improved, it has everything we need right now.''
A piece of information that is also valuable to us is if the testers are likely to recommend
the services the application provides. We asked them how likely are they to recommend the
application or website with a range of one to four, with one being “Not Likely” and four being
“Very Likely”. If the testers are likely to recommend the app or website, then it is a good
indication that it useful to them and that they are happy with the final product. From their
responses, both testers gave a rating of 4, “Very Likely”. We end the survey with a “Comments”
section where testers are able to leave any comments about the app or website. One tester
commented, “Good job, look forward to using the app.” Getting feedback from users with basic
computing skills is essential, particularly from actual members of the South County Soccer
League. Overall, we are very happy with their feedback and suggestions.
Final Implementation
The final delivery of the mobile application involved a core of important features. It
involved four different pages that users would find most optimal. The elements included in the
final design are as follows - Overview page, Schedule, Roster and Settings page. These are the
main pages that are seen after a user has signed up.
When a user wants to have access to the app’s core features. It must first create an
account to gain access. By the user clicking “Sign Up” , they will be prompted to enter necessary
information such as full name, email, password and confirm password once more. This
validation used ensures correct user input is entered for the password.
The overview page is where it provides information about the selected team. The
statistics section lets users know off hand how their team is performing. Other stats information
that is listed on the app includes current team standing, team’s win loss record, team name, and
team number. In the same page, there is a last game section where it will always show the most
recent game. If the team has not played any games yet, this section will be hidden from view.
Another feature of the overview page, is the ability for administrators to enter the score of the
last game. This can be done by clicking the plus button and update the score. The last feature of
this page is direction and navigation to events. The main service used is Google Maps and can be
used by clicking on the location present on each card.
The schedule page allows the user to add events. The user gets two choices in this section
whether they want to pick between a game or an event in which the user can specify in detail if it
is a fundraiser or party. If the user chooses the game option, then they will be asked to add the
name of the opposing team and other important details such as time of game and location. There
are special features in this page as well. They include a pull to refresh of the screen when new
data is implemented. Another feature is the ability to swipe and delete an event from the
schedule page. To see more in depth details the user can tap a game and show more details of the
game.
Next, is the roster page. This core feature allows the user to see all of the players on a
given team. What the user is shown on this page is their name, role, and jersey number if they
have one given when adding the player. This page also has the same features as the previous one
in that it supports pull to refresh as well as swipe to delete. Following that, this page allows new
users to be added to the team, by clicking the plus button.

In this section, existing users can be added by searching for them. Additionally, new users can be
invited by typing an email. The app will then prompt for user’s name. If a mistake is made the
user can simply delete it with the swipe function. The code for accomplishing this is shown
below:
<template>
<Frame>
<Page class="page" actionBarHidden="true">
<RadListView
for="player in players"
ref="listView"
class="list-group body"
separatorColor="transparent"
swipeActions="true"
pullToRefresh="true"
@itemSwipeProgressStarted="onSwipeStarted"
@pullToRefreshInitiated="onPullAction">
<v-template>
<GridLayout class="list-group-item" rows="auto"

columns="auto, *">
<Label row="0" col="0" class="player-avatar"
:text="player | toAvatar"></Label>
<StackLayout row="0" col="1"

verticalAlignment="center">
<Label :text="player | name" />
<Label class="m-t-2 text-muted"

:text="player.role | wordcase"></Label>
</StackLayout>
</GridLayout>
</v-template>
<v-template name="itemswipe">
<GridLayout columns="*, auto"

backgroundColor="#B02F26">
<StackLayout id="delete-view"
col="1"
class="swipe-item right"
orientation="horizontal"
@tap="onPlayerSwipeClick">
<Label class="fa p-y-4 p-x-8"
color="#ffffff"
fontSize="16"
:text="'fa-trash-o' | fonticon"
verticalAlignment="center"
horizontalAlignment="center"></Label>
</StackLayout>
</GridLayout>
</v-template>
</RadListView>

</Page>
</Frame>
</template>
<script>
export default {
props: {
team: {
type: Object,
required: true,
},
data() {
return {
players: [],
loading: true,
},
methods: {
onSwipeStarted ({ data, object }) {
const swipeLimits = data.swipeLimits;
const right = object.getViewById('delete-view');
swipeLimits.right = right.getMeasuredWidth();
swipeLimits.threshold = right.getMeasuredWidth() / 2;
},
async onPlayerSwipeClick({ object }) {
let player = object.bindingContext
try {
// remove from the api, when succeeded delete

local object
await
this.$api.client.delete(`/teams/${this.team.id}/members/${player.id}`
)
this.removePlayer(player)
} catch (e) {
// if we found the object but had some other error
if (e.response.statusCode !== 404) {
alert(e.response.data.error)
} else {
// this is fine the player doesn't exist on

the server
this.removePlayer(player)
} finally {
// tell the listView it can swipe other items
this.$refs.listView.notifySwipeToExecuteFinished();
}
},
removePlayer(player) {
this.players.splice(this.players.indexOf(player), 1)
},
onPullAction({ object }) {
this.$nextTick(() => {
this.onLoaded().finally(() => {
object.notifyPullToRefreshFinished();
})
});
},
refresh() {
this.onLoaded()
},
async onLoaded() {
this.loading = true
try {
let {data: players} = await

this.$api.teamMembers(this.team.id)
this.players = players
} finally {
this.loading = false
},
created() {
this.onLoaded()
},
filters: {
name(v) {
return `${v.user.name}`
},
toAvatar(p) {
if (p.role === 'coach')
return 'C'
if (p.role === 'admin')
return 'A'
if (! p.jersey_number) {
// if it's a player and they don't have a number
// get their initials and display those
let matches = p.user.name.match(/\b(\w)/g);
return matches.slice(0,2).join('')
return p.jersey_number
},
</script>
<style scoped>
.player-avatar {
text-align: center;
font-size: 20;
font-weight: bold;
padding-top: 10;
border-radius: 8;
margin-right: 10;
width: 40;
height: 40;
background-color: #F2F3F4;
color: #283237;
</style>
The final element included in the Soccer League app was a settings page. This page
allows the user to see who they are logged in as. Also, it shows the record of the team and team
they are viewing. Lastly, the user can use this menu to logout of the app which returns them to
the login page.

Discussion
As this is a software project, it is inevitable to have no problems during development.
During the design phase of the capstone project, we were presented with only one. The main
thing that came up was designing how the user interface was going to look like. This was up to
personal preference but we opted to keep it simple as well as the color scheme.
The implementation phase was the one that gave quite a few problems. During the first
week, authentication was an issue. Using a users password and email in every request is both
slow and not secure. The solution to this was to use JSON Web Tokens generated from user
credentials and signed by the server. This makes it so that they can not be modified by the client
and they expire on a set timeframe. In turn, they provide a more secure and far faster way to
validate.
In the second week, we encountered an issue with HTTP traffic being blocked by default
in IOS and Android. This was only an issue in development since Heroku has HTTPS by default.
This was resolved by whitelisting our local Rails server endpoint.
During the third week, we were presented with a few issues. The major one included
running into a variety of issues with NativeScript and shipping to the web. None of the native
components would run in a web browser leading us to develop essentially three different
projects. In the given time frame, we needed to drop the web version of the project. In the same
week, we had issues with TabViewIcons and styling causing the body of the application to be
symbols instead of text. This issue was resolved by using an Icon font and specific CSS styling.
Another issue was that Rails was not respecting the as_json method on users causing password
hashes to be leaked in the team member endpoints. This was resolved by writing a custom
resource encoder that defers to the user as_json method for that resource type.
In the fourth week, the first problem presented was some issues with cross platform
dialogs. We were able to resolve this with a third party / plugin. In the same week, more
problems were introduced such as the FontAwesome icons changing size depending on the
platform. This issue was resolved by converting them to PNG images and putting them in
resources instead of using the icon font. To determine team score, we had to go through each of
the teams games and calculate it. This resulted in more API calls to gather this data. Instead, we
modified the API to compute these values whenever an event ended and stored them on the team
directly. The last issue for this week was with dialogs and date pickers. We created our own
abstraction that uses a third party library which allowed us to solve this issue and make it easier
to use at the same time.

In week five, there were fewer issues since we were reaching the final iterations of the
project. The main problem for this week was accessing nested data in the API. These were
addressed by making some API modifications to include this nested data.
Roll out of the project was in week six which involved sending the project to our client,
South County Soccer League, to test out the product. They tested the app’s functionality and
provided feedback through a Google survey. A bug was found during this iteration where it
consisted of adding a user to the roster wouldn’t update the roster page but it was resolved. The
last two weeks were used to resolve any other bugs happen to appear and polish it for final
deployment.
Conclusion
As technology keeps growing exponentially, some sports communities don’t necessarily
keep up with it. This comes into play when local sports communities try to manage a league but
lack the funds to have services that would help manage their league. They often use social media
as a means to update anyone who is part of the league. This creates another problem that many
don’t have a social media account which leads them to become lost of any given announcements
or team standings.
Our team began researching ways to solve the problem. After a few weeks of
contemplating ideas, we came to the conclusion that a mobile application was the ideal solution.
Having a mobile application that our client, South County Soccer League, can use would make it
so that anyone who has a smartphone that can either be an Android or IOS can have access to all
sorts of features that high end sports managing applications charge hundreds of dollars a month
for. Our Soccer League app was made for South County Soccer League but it can be used by any
other soccer league wanting to better manage their league.
The design of the mobile application was first talked about. We wanted to create an easy
and intuitive user interface so the basic smartphone users would find it a trouble free experience.
We used a wide range of technologies to complete this project. Languages used included Ruby,
JavaScript, JSON, HTML, CSS, and SQL. Frameworks used were VueJS, NativeScript and
Ruby on Rails. Other services included Heroku, MySQL, GitHub and IntelliJ IDEA.
For most of this project’s team members, it was the first time working on a professional
development project. As a team, we learned the process of going through all of the tasks that
comes with developing a mobile application. The capstone project taking fairly about eight
weeks to complete, it was critical to have efficient time management skills for the scope of this
project and setting milestones for each week was crucial to the success of the project. We
communicated often to see where everyone was at. Overall, we are satisfied with what the team
has created and had a first glimpse of what it really takes to work on a software project.
In the future, we plan to implement components that we initially talked about in the
proposal but were cut out due to time constraints. This includes incorporating live update feature
using Websockets on the game status. Include notifications for users that give a specific function
such as notifying users when a game goes live, which team has scored, end of match, etc.
Additionally, provide a website we had mentioned in the proposal so that there wouldn’t be any
limitations if users don’t have access to a smartphone.

References
About us. (2018, June 18). Retrieved August 6, 2019. Helping Make Sports Happen.
Retrieved from https://leagueapps.com/about/
(n.d.). Retrieved August 3, 2019. GameChanger Baseball, Softball. Retrieved from
https://gc.com/
Appendix
Appendix A
Usability / Evaluation Test Plan
Authors: William Barajas, Mercedes Garcia, Thomas Krause, Eric Ybarra
Contact Details: William: wbarajas@csumb.edu
Mercedes: mergarcia@csumb.edu
Thomas: tkrause@csumb.edu
Eric: erybarra@csumb
Product: Soccer League mobile application that allows users to easily track various statistics
listed of a given league.
Participants: Jose Barajas and Benny Herrera, administrators of South County Soccer League,
testing product for their league.
Equipment Used: Smartphone either Android or IOS
Tasks Tested: Sign up for a user account and log in. Go through each of the app’s tab pages and
see what they can access with user account.
Schedule: The South County Soccer League members had about a week to test the mobile
application which started at the start of module six and ended before the start of module seven.
During that week they needed to test the app’s functionality and core features. During this time,
our development team was open to answering any questions the participants would have. After
the testing phase was finished at the end of the week, the users filled out a survey of the app.
Appendix B
Team Member Roles
William Barajas
● Android application testing and support
● Overview / Home Page functionality
○ Show team placement and record in the league
○ Most recently completed game, who it was against, and who won
○ Upcoming event / game and it’s location and time.
● Login and Sign In functionality
○ Allow a user to log into the application
● Assist with any other development tasks where needed
Mercedes Garcia
● App Design
● Schedule / Event pages
○ Add Event / Game
○ Delete Event / Game
○ View Event / Game
○ Modify Event / Game
○ All other functionality for schedules and events
Thomas Krause
● Database Schema and Design
● RESTful API development and modifications where needed
○ All functionality
● Team Selection and Sign Up functionality
○ Allow user to register and accept invites to teams
○ Allow user to select a team to view its data and be used in other parts of the app
● Cross compiling mobile application to the web and ensure compatibility
Eric Ybarra
● iOS application testing and support
● Roster pages and functionality
○ Add member to team
○ Delete member from team
○ View team members
○ Invite team members
○ Allow only admins and coaches to make modifications to the team
○ All other roster and team role functionality

Appendix C
Soccer League App Survey

Soccer League - Final Capstone Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soccer League - Final Capstone Report

Uploaded by

Copyright:

Available Formats

Running head: REPORT FOR A SOCCER LEAGUE TRACKING APPLICATION 1

Capstone Project Report: Soccer League Tracking Application for Android/IOS

South County Soccer League

CST 499: Computer Science Capstone

California State University, Monterey Bay

October 13, 2019

day and age.

on August 28 and ending October 18.

Solution to the Problem/Issue in Technology 6

Project Goals and Objectives 7

Stakeholders and Community 8

Evidence that the Project is Needed 9

Selection of Design Criterion 14

Solution to the Problem/Issue in Technology

Project Goals and Objectives

track of divisions, teams, games, and players.

A. REST API for the app built with Rails

B. NativeScript framework for Android / IOS for web deployment

players to teams, and assign addition league admins.

A. Develop database schema and backend for mobile app

duration and start time.

Stakeholders and Community

changes in scheduling or game stat information.

what they love, play sports.

Evidence that the Project is Needed

features in this project.

application’s backend functionality.

log out of their account.

community Soccer League, particularly the South County Soccer League.

Selection of Design Criterion

players they currently have.

applied to the project.

would work best for them.

for injuries due to an unforeseen accident in sports.

1 Project Setup and Initial Schema

2 League and Team Creation / Management

3 Game and Player Management

4 Score Tracking and Team Stats

5 Finalize Application and Deploy

7 Bug Fixes and Refine

event detail page.

were able to get back to us fairly quickly.

fonts throughout the app.

used by clicking on the location present on each card.

users to be added to the team, by clicking the plus button.

<Page class="page" actionBarHidden="true">

<GridLayout class="list-group-item" rows="auto"

<StackLayout row="0" col="1"

<Label class="m-t-2 text-muted"

<GridLayout columns="*, auto"

<!-- <ActivityIndicator v-if="loading" busy="true"

onSwipeStarted ({ data, object }) {

const swipeLimits = data.swipeLimits;

const right = object.getViewById('delete-view');

async onPlayerSwipeClick({ object }) {

let player = object.bindingContext

// remove from the api, when succeeded delete

// if we found the object but had some other error

if (e.response.statusCode !== 404) {

// this is fine the player doesn't exist on

// tell the listView it can swipe other items

let {data: players} = await

if (p.role === 'coach')