West 1

Mobile Magic Collector

Jacob West

California State University, Monterey Bay

CST 499 Online Capstone

Capstone Advisors: Eric Tao, Brian Robertson, Cassandra Humphrey

October 13, 2019

 West 2

Executive Summary

Mobile Magic Collector is a mobile Android Application which looks to fill the empty
space in which there could be a visual deck builder for Magic the Gathering players. The goal of
this application is to create an application in which a user can save cards to a collection or deck
list, and have a visual representation of their deck along with statistics for their deck lists. The
purpose of this project is to help the players of Magic the Gathering that are visual learners and
receive help from visualization of their lists rather than a text-based list. The population affected
by this project will consist of any Magic the Gathering players who have access to an Android
phone, as the application will only be currently available for Android phones. The anticipated
outcome of the project will be the full production and release of Mobile Magic Collector as an
application onto the Google Play Store so that any user will be able to use the application to store
their collection information or information about their deck lists.
 West 3

Table of Contents

Executive Summary 2

Project Name & Description 4

Problem and/or Issue in Technology 4

Solution to the Problem 4

Project Goals & Objectives 5

Stakeholders & Community 6

Evidence the Project is Needed 7

Feasibility Discussion 8

Functional Decomposition 9

Selection of Design Criterion 10

Final Deliverables 10

Approach/Methodology 10

Ethical Considerations 12

Legal Considerations 12

Timeline/Budget 14

Usability Testing/Evaluation 15

Final Implementation 19

Discussion 21

Conclusion 22

References 23
 West 4

Project Name & Description

Mobile Magic Collector, also known as MMCollector, is a mobile application working

off of Scryfall.com’s API that is used to create a list of your own Magic the Gathering collection

and create decks from that collection. Magic the Gathering is a trading card game that has been

around for over 25 years, and to this day, holds a massive playerbase. With an ever-expanding

list of over 20,000 different cards, there are many variations and different ways to go about

putting together a decklist for the game.

Problem and/or Issue in Technology

Card collections are something now that are commonspace for each player to have, but

sometimes can get out of control and are hard to keep track of. The initial idea for MMCollector

sparked from a lack of an application which features deck building with an interface that has the

card images to represent the cards, rather than just reading a card name from a list.

Solution to the Problem

What this project looks to do is solve the issue of not having a more visual-based deck

builder or collection recorder by creating an application where any Magic the Gathering players

can record their collection, build their decks, and get a good visual representation of what they

might have laying around in their collection. This product benefits the community of Magic the

Gathering players by giving them something that can be used in order to create a visual

representation of not only a collection, but their decklists as well. People who lean on a more

creative side or a visual way of learning benefit strongly from being able to look at all of their

options and be able to visualize everything in front of them, and that’s what I intend

MMCollector to address the most.

 West 5

Project Goals & Objectives

There are several goals and objectives that I am looking to fulfill by the time

MMCollector is completely finished. First, and most important, is adding a person’s cards to a

collection list. This is the first step in being able to get anywhere with the application, and from

there many more things can be added. The reason why this is the most important thing is that

collection lists can be longer lists than decklists, which will currently be set to have a limit on the

amount of cards that can be included. Once this is finished it makes implementing decklists

much easier as they essentially would just be small versions of the collection lists. With adding

decklists, instead of simply keeping track of what cards are in a collection, the idea is to pull

cards from the collections to put into decks. If a user wants to create a decklist with cards that are

not in their collection though, this opens up the decklist to manual entry for cards and the number

of cards they wish to add. This gives an opportunity to add in new dialogs in order to show what

a person might need (in terms of card quantities) to get to finish their lists. With Scryfall’s API,

this opens up the opportunity to even show expenses for how much it might cost for someone to

finish the deck list with average card prices, and potentially even link to outside vendors who

could sell those cards. After the decklists portion is created, the next goal would be to create a

statistical tracker for the decklists. Statistics tracking is very commonplace in deck building in

order to keep track of your average cost, colors, card types, and any other statistics that might be

helpful to the deck builders. Using these numbers, the application would create updating graphs

to represent each of the different statistics. This means that a user might be able to keep track of

how much of something they would like to add into the deck if they feel an average might be too

low in certain areas, or if they are unhappy with any other portion of the list statistically. Once all
 West 6

of the statistics portion is done, there is a final piece that builds off of it that could be added as an

additional feature, which would be land recommendation. In Magic the Gathering, in order to

play your cards from your hand, you need specific cards called land cards in order to be able to

play them. There are averages that are well known and used by the community created by Frank

Karsten of the company Channel Fireball, based off of your average color counts and average

card costs that can lead to a rough idea of how many lands should be in your deck (Karsten,

2018). This would be a feature that isn’t entirely necessary, but could be good for people who are

not used to deck building extensively and need that extra bit of help in order to get a good

recommendation for their deck. Finally, once all of these things are finished, the last goals for

MMCollector would be to be able to duplicate collections or decks and to be able to share or

export collection lists or deck lists to text files, or even copy them to your phone’s clipboard to

be able to paste them into web forums, or to share with friends. With this feature, there could be

a potential to create an import function as well so that someone might be able to share their

decklist with a friend and immediately have it load within the application.

Stakeholders & Community

The stakeholders and community in this project are primarily the Magic the Gathering

community as a whole. The community has a lot of different options currently for deck building

through applications or web pages, but nothing with a good visual representation for those who

might need it to help imagine their ideas in a more concise way. What they gain from

MMCollector as an application is not only something they can use in order to track their Magic

collections, but also use to create their own decklists with a good visual representation of what

the deck looks like. Another thing that is lacking from a lot of deck building applications out on
 West 7

the market currently is a form of statistics tracking built into the deck list maker. Most deck

building applications that are currently on the market keep track of simple things like what colors

are featured in the deck, but only a few are able to provide statistics alongside the deck.

MMCollector looks to include these features in order to give the community an application

where they can easily keep track of this information for the people who really wish to grind the

numbers of where their deck list might need work. Outside of these features - another massive

thing would be the sharing of decklists. This is sometimes easily done through screenshots of a

page with your list on it, but MMCollector looks to solve that as well by being able to copy and

paste your deck list so that it can be easily shared with friends or other members of the

community.

Evidence the Project is Needed

Currently on the Google Play Store alone, there are somewhere over 100+ different

applications that are related to Magic the Gathering in some way. Not all of these applications

are deck building applications or collection tracking applications, but those that are the highest

rated among the applications tend to have multiple features that make some of the other

applications obsolete. Among those that are deck building or collection tracking applications,

there are many that are blocked behind optional paywalls and several that lack a non-text based

representation of the user’s collection or decklist. Creating MMCollector would fill this role in

being a non-paywalled collection tracker and deck builder for users who possibly wish to have a

better visual representation of their card lists as they expand their collection and build new decks

to try out.
 West 8

Feasibility Discussion

With creating MMCollector, the first applications that really come to mind as a direct

competitor to the application idea would be the application Delver Lens, created by Delver Lab.

Delver Lens is an application that does a lot of what I set out to create with MMCollector, and

also features a card scanner with your phone in order to scan directly into a collection just by

reading the card information with the camera. The application also features a locally stored

database which is pulled regularly upon opening the application if there were any changes since

you last opened the application. This allows users to use this application while they are offline,

which is a large difference from my own application which requires an internet connection in

order to pull the card details from Scryfall’s API. This application has some of the features that I

wish to implement in MMCollector and could be used as a great research tool in order to

potentially build off of what I like from their application and maybe take a variation of it when

creating MMCollector.

Another application that is very highly rated in the Magic the Gathering community is

MTG Familiar, made by gelakinetic. This application is not nearly as in depth with their deck

building or collection tracking section as Delver Lens, but has a large community and is

something I personally have used for several years. It does have an extremely in depth searching

function, similar to that of Delver Lens, and has a deck builder also as part of the application but

is nowhere near the main feature of the application. The main use of the deck builder or

collection tracker for MTG Familiar also is blocked after a certain point by a paywall in which

you would have to create an account with them and spend money in order to continue to use the

application for that purpose after creating a certain number of decks. MTG Familiar has a lot of
 West 9

features that if I were to be able to meet deadlines quickly, would be tempting to also integrate

into MMCollector to make it a more well-rounded and general use application for Magic the

Gathering, and not just for collection and deck list tracking. This application, similar to Delver

Lens, also features a small local database that is downloaded to the phone in order to keep track

of all card information while your phone is offline.

Outside of these similarities in design, I feel as though MMCollector could be a great

addition to the application community for Magic the Gathering and still would have it’s own

unique feel in comparison to the other applications. Both of these applications differ from what I

intend to create with MMCollector in that my design for the application will be predominantly

image-based, while most of these applications continue to use text-based lists, with Delver Lens

giving you the option of either. MMCollector also will search for live-data and has the potential

to be updated near instantaneously alongside the Scryfall API, which is updated daily rather than

only pulling a database change when there is a new set that has been released, which usually

occurs every two to three months. I believe these differences help the creation of MMCollector

stand-out from the other applications in the Magic the Gathering community and potentially give

the community a new and unique way of collection tracking or deck building.

Functional Decomposition

The major functions required by my design are as follows:

● Search engine with prediction

● Deck design page with active statistics reading

● Deck sharing
 West 10

Most of the design for the application is built off of these 3 main features, as they are able to be

built off of to create separate parts of the application.

Selection of Design Criterion

Performance - ​Fast with next to no delay, there are requirements for the API calls but the

performance is still overall very quick.

Reliability - ​Extremely reliable as most API calls are instantaneous and are updated daily.

Cost - ​$25 to cover the registration fee to put the application onto the Google Play Store

Code Size - ​Long, even with API calls there are a lot of calculations and other functions that

have to be done on the application’s side after the API is called and information is pulled.

Final Deliverables

The final deliverables for the capstone project will be a mobile application that is

available on Android. When finished, the application will be able to be downloaded from the

Google Play Store and will be available for anyone to use. There are no plans for a webpage or

any other additional deliverables besides the application in the project’s current state, but if the

application will not be ready enough to put onto the Google Play Store, a website may be created

in order to push out a download for testing or downloading the application to anyone’s mobile

Android phone that would like to use it.

Approach/Methodology

In creating MMCollector, I intend to follow a waterfall model for the design process. My

research for starting the program is going to be done by reading up on Scryfall’s API in addition

to doing research on Android development through web forums such as stackoverflow and other

miscellaneous sites. A lot of what I plan to create has been implemented in similar ways but for
 West 11

other applications, so bringing them together in the manner I would like to will likely be

something that is very easily possible for me to accomplish.

My first process that I will need to go through in order to get the application started will

be creating a way to access Scryfall’s API within the application. Once that is created, I’ll need

to decide on a rough count for how many unique cards might be able to be added to a collection

list, and then move from there to creating the deck list portion of the application. When creating

the deck list portion, I will need to do some in-depth reading into Scryfall’s API to make sure I

can keep track of the different statistics I want to track for later in the project. Creating a fast and

simple way of getting these averages and other information will be key to completing the

statistics portion in a timely manner. This will also require some research into how to get all of

these statistics to show up with a graphical representation in the application, as that is something

that I have not done before in an app that would need to be constantly updated as things are

removed or added from a deck list. After all of these things are finished, the last things that will

need to be put together are just visual features and making sure the application looks ideal

enough to publish for other people to use. I will be having people test the application at each

phase of this process starting with the collection list, then to the deck list portion, then to the

statistics portion, and finally the exporting and copy portion, stopping part way in-between each

big milestone to ensure that everything works as intended. The people testing the application

along with myself have several years experience with playing Magic the Gathering and have

used applications in order to create collection lists and decklists before. They will be able to

provide feedback at all of the stages of creation of the app so that I can appropriately follow the

waterfall design model and continue onward once everything works as intended in each phase.
 West 12

Ethical Considerations

Currently, I don’t believe there will be any ethical concerns regarding MMCollector. The

project is generally just for use by hobbyists, and does not provide anything that would hinder

any underprivileged groups. My one concern for MMCollector is that the program will only be

available on Android devices, which leaves out a separate section of users that wish to use it for

iPhones. It could negatively impact iPhone users in a way that if this application were to be more

generally used by people who own Android devices, then iPhone users would not have access to

identical technology without the same application.

Legal Considerations

When creating MMCollector, a lot of legal considerations come into play since I am working

with a major company’s property and an API from a webpage that wasn’t created by myself.

With using Magic the Gathering properties, I first have to look at Wizards of the Coast policies

in order to ensure that there will be no issues with the creation of MMCollector.

According to Wizards of the Coast’s fan content policy page, there are seven important

steps that I must take in order to create the application in a fully legal manner (Wizards of the

Coast, 2017). Step one is to make sure that the application is entirely free (Wizards of the Coast,

2017). According to Wizards of the Coast, this includes the following:

You can’t require payments, surveys, downloads, subscriptions, or email registration to

access your Fan Content; You can’t sell or license your Fan Content to any third parties

for any type of compensation; and Your Fan Content must be free for others (including

Wizards) to view, access, share, and use without paying you anything, obtaining your

approval, or giving you credit (Wizards of the Coast, 2017).

 West 13

Step two of the fan content policy is that I must tell the community that it is unofficial and to

include a note stating that MMCollector is unofficial fan content that is not approved or endorsed

by Wizards (Wizards of the Coast, 2017). Step three and four is that I must respect other

people’s IP and Wizard’s IP, respectively (Wizards of the Coast, 2017). Step five ensures that I

do not use Wizard’s IP for “use (that) is inappropriate, offensive, damaging, or disparaging”

(Wizards of the Coast, 2017). Step six would be in the case of a sponsorship, to ensure that I do

not use sponsors harmful to Wizards as a company (Wizards of the Coast, 2017). Finally, step

seven would be to follow my own laws of my region or country in addition to following all

Terms of Use and Code of Conduct regulations put in place by Wizards of the Coast (Wizards of

the Coast, 2017).

With using Scryfall’s API, I must abide by the following guidelines for all use in terms of

data excluding card images:

You may not use Scryfall logos or use the Scryfall name in a way that implies Scryfall

has endorsed you, your work, or your product. You may not require anyone to make

payments, take surveys, agree to subscriptions, rate your content, or create accounts in

exchange for access to Scryfall data. You may not use Scryfall data to create new games,

or to imply the information and images are from any other game besides Magic: The

Gathering (​API Documentation​, n.d.).

For card images, there are distinct guidelines that I must follow according to the Scryfall

images API documentation page. I have to abide by the following guidelines when it comes to

using imagery from Scryfall:

 West 14

Do not cover, crop, or clip off the copyright or artist name on card images. Do not distort,

skew, or stretch card images. Do not blur, sharpen, desaturate, or color-shift card images.

Do not add your own watermarks, stamps, or logos to card images. Do not place card

images in a way that implies someone other than Wizards of the Coast created the card or

that is from another game besides Magic: The Gathering (​Card Imagery​, n.d.).

All of these legal policies and implementations will be important for me to take into

account as I create MMCollector and will be implemented for the final production of the app.

This will be especially important as I plan to push the application to the app store for free use

once the application is finished for full production in order to ensure there is no legal troubles

between myself and Wizards of the Coast or Scryfall.

Timeline/Budget

Original Timeline:

Part one of creating MMCollector was a significant success, and all of the ideas that were

planned out here were able to be finished. This first portion was mainly just set for starting up

everything and to build a base to go into the parts after it.

 West 15

Part two of creating MMCollector was also a success, with some exceptions. The creation

of search engine prediction had to get put aside and moved into a different part (Part 3). I was

able to get this working, but not to the point at which I believe it would be most efficient for the

user. Currently, the search engine prediction will show the words in a list underneath the search

bar, but there is no way for you to press the word for it to auto-fill the search bar, which was an

idea I really wanted to bring into the application.

Part three consisted entirely of the creation of the deck page. This ended up becoming its

own individual page from the collection page that was originally planned and was eventually

scrapped due to time constraints. Deck pages have a limit of 75 cards over-all with no separation

of the main deck list (60 cards) and the sideboard (15 cards). Coding in the 4 of each card

restriction had too many issues with certain cards that were exceptions to this rule, so I instead

implemented this page in a way that any card can have more than 4 copies.

Part four built off of part three by taking the deck list and building in statistics for the

deck when you have finished creating it. Statistics that were implemented successfully were type

counts, while casting cost averages and color averages were not able to be added again due to

time constraints.

Part five sadly was scrapped entirely due to time constraints. There was not enough time

for me to be able to sort out duplicating deck lists and being able to have more than one list at a

time, so the user currently can only use one deck list.

Part six was successfully implemented, though, with the “sharing” feature being the last

feature added to the application. Users are able to copy down the deck list file to their phone and

then paste it to any friends who would want to take a look at it.
 West 16

Usability Testing/Evaluation

The usability test plan consisted of approximately 6 stages, each coinciding with each of the

parts that are detailed in the Timeline/Budget section. Not all portions were able to be

implemented and some were moved around due to bugs that occurred during the creation of the

app.

Part 1’s original usability test plan is the following:

1. Test the Scryfall API with known card names. Try card names with unique characters

such as the character “Æ” and any odd names that could confuse the searches.

2. Test the usability of buttons and pop-up menus in order to add and delete a card from a

file, setting up the project to continue into part 2.

Part 1’s final test results were as follows:

1. Testing Scryfall’s API calls lead to a lot of new exceptions being found and changes

needing to be made to individual portions due to unique cards with special characters.

These were later implemented in part 2 and were able to be used extensively with only

one card type producing an error, which are known as “flip cards.”

2. Usability of buttons was moved from testing part 1 to part 4.

Part 2’s original usability test plan is the following:

1. Continue to test the usability of buttons and new menus in order to add and delete cards

from the saved file.

2. Test saving cards to a new page called the collection page. Once a card is saved, it should

show up in the collection page every time the application is loaded.

 West 17

3. Test for the search engine pulling predictions for card names that are close to the

currently entered text in the search box.

Part 2’s final test results were as follows:

1. This portion of testing was moved to part 4.

2. Testing saving cards to the new page which eventually was labeled the deck page was

successful during this stage.

3. Prediction testing for card names close to the card names were slightly successful. In

testing we learned that a lack of spaces between words, if a card has multiple words in it,

breaks the prediction. Once spaced out properly, getting as close as possible to the card

name usually (about 9/10 times in testing) would give you the correct card.

Part 3’s original usability test plan is the following:

1. Test saving cards from the collection page to a deck page. Once this is able to be done,

the user will test to make sure the card is not gone from the collection page but is added

to the deck page.

2. Users will test the deck page in order to ensure that card number restrictions are placed

properly for certain cards. For example, in a deck, most cards will have a maximum of 4

able to be put into a deck. The users will test to ensure you cannot go over the maximum

for these cards, and ensure the ones that are exceptions to this case are able to go over the

count of 4.

Part 3’s final test results were as follows:

1. This portion was scrapped due to time constraints.

 West 18

2. This portion was also scrapped due to time constraints and a significant amount of

exceptions that needed to be added with no indicators from Scryfall’s API of there being

no restriction on the cards. This lead to the deck page being able to add any number of a

unique cards to a deck list as long as the deck list did not go over 75 individual cards.

Part 4’s original usability test plan is the following:

1. Users will create a deck and attempt to obtain statistics from the deck they created. This

should give them miscellaneous statistics about their deck like the color count, average

cost count, and a few other statistics.

Part 4’s final test results were as follows:

1. Users created a deck and were able to create deck statistics with only the type counts in

the deck. Average color count and average cost count were scrapped due to time

constraints.

2. Buttons to increase and decrease the card counts in the deck list page were implemented

during this part. After extensive testing, we were eventually able to get the cards to be

removed and added.

Part 5’s original usability test plan is the following:

1. Users will use a button in the deck and collection page in order to duplicate their deck or

collection. They will also continue to test on the finalized version of the deck list page in

this part of testing.

Part 5’s final test results were as follows:

1. This portion was scrapped due to time constraints.

Part 6’s original usability test plan is the following:

 West 19

1. Users will use the sharing feature in order to copy the text from their files created, such as

a collection list or a deck list, and send them to their friends through a copy and paste

method.

Part 6’s final test results were as follows:

1. Users were able to use the copy and paste method to share deck lists with friends.

Final Implementation

Card.java:

Card.java is a Java file that implements all of the Scryfall API calls for cards specifically.

This pulls the name, oracle text, mana cost, type line, image uris, power, toughness, and loyalty

for a card. Some cards do not have power, toughness, and loyalty, which are taken into account

in the pages where cards are searched. See Appendix A 1 for an example of how Card.java finds

each individual card value and the functions used to call the values in the application.

CardDeleteDialog.java:

CardDeleteDialog.java is a Java file that is used to clear out the cards.txt and types.txt file

when needed. This dialog is able to be called in SavedCardsList.java by pressing the “Clear”

button. The code for deleting the cards and types list used in CardDeleteDialog.java can be found

in Appendix A 2.

CardPrediction.java:

CardPrediction.java is a Java file that pulls the data from a Scryfall API call for the

search engine prediction in MainActivity.java. This stores up to 20 predicted card names in a

string array as new characters are entered into the search bar. This is a relatively short file in
 West 20

comparison to the other files, but is implemented in a similar way to how Card.java is

implemented.

CardQuantityChange.java:

CardQuantityChange.java is a Java file that functions similarly to CardSearched, but has

some different implementations in it. With CardQuantityChange.java, you are able to pull up a

card and add or remove the card from your deck list while viewing all of the information about

the card. This file has a unique function called changeDeckQuantity, which can be seen in

Appendix A 3. This function takes a card name and a change in the quantity which allows for the

function to do both incrementing and decrementing. If the quantity change is a positive number,

then we simply append another card name to the cards.txt file with the cardName value and

increase the overallCardCount. If the change in quantity is a negative number, the function will

get a reader and look for the first place where the entered cardName appears in the file cards.txt

and replace it with a blank line. After doing so, it sets a boolean to skip over the while loop and

append the remaining lines to a StringBuilder, which is used to keep the remainder of the file the

same. At the end of the function, it calls another unique function to this file called fixBlanks,

which fixes the blank lines in the cards.txt or types.txt file as the cards are removed.

CardSearched.java:

CardSearched.java is a Java file that is used in order to search for a card that is entered in

MainActivity.java. This is also where you save a card to your deck list for the first time.

MainActivity.java:

MainActivity.java is a Java file that is used in order to traverse through the other pages of

the application. The user starts here and is able to navigate either by searching for a new card, or
 West 21

by clicking on the “Deck List” button which will take you to the deck list page.

MainActivity.java is primarily used for navigation, but also is the only place that CardPrediction

is used which is important for searching for individual cards.

SavedCardsList.java:

SavedCardsList.java is a Java file that holds all of the deck list for the user. This shows a

lot of information on one page, including the deck images, the deck list itself, the statistics for

the deck while also containing a button for clearing out the deck list and a button to copy your

deck list to your clipboard to share with friends.

ScryfallApi.java:

ScryfallApi.java is the file that holds onto all of the API calls. It queries a “fuzzy” card

search, which is what helps to find card names as they are entered into the search bar. The query

being “fuzzy” in comparison to an exact search is significant so that the user can enter a name

close to the card name and it will search for it, rather than the card name needing to be exact.

This file also queries up to 20 autocomplete cards based off of what the user has entered into the

search bar when they are searching for a card.

Discussion

When starting the creation of Mobile Magic Collector, I quickly realized the scope of

what the application would be as the weeks began. Problems started popping up very quickly.

Week 1 consisted of issues with the search function for specific cards that had unique values

when being called from the API that sometimes were not numbers but were rather characters.

Week 2 consisted primarily of trying to fix a drop down menu for the card prediction section in

the MainActivity.java file, but this eventually was scrapped due to time constraints. I was able to
 West 22

however get a prediction working, it just is not a clickable menu so the user still has to enter in

the card name entirely in order to search for the card. Week 3 was the discovery of the most

difficult error which lead to a lot of changes needing to be implemented to the application. I

figured out that there was a programmatic way to be able to add and remove images from the

deck list page, but it was outside of my scope of knowledge and was incredibly difficult to

implement. Due to time constraints, I decided that implementing a limit and simply hard-coding

the images into the respective XML files would be the easiest fix, which ended up taking a lot of

time to ensure everything was implemented in the proper way and was formatted properly as

well. Going into week 4, I discovered a bug with the images loading in a random order rather

than being sorted according to the deck list page. Loading images also were only triggerable by a

button, so a button labeled “IMG” was added to the SavedCardsList page. This is still an ongoing

error when loading the images too quickly - and there is no pattern to be found with it. The issue

might stem from the API calls being too quick, but after attempting to fix this with a significant

delay (over 5 seconds for each image), the images were still loading in a random order despite

being ordered in the deck list as they were entered. Week 5 and 6 were mainly spent revising

pages and didn’t run into many other errors besides the already known errors.

Rolling out the application for use by others was mainly what I’ve been doing in Week 7,

but was able to be done back during Week 5. I have had a link to the APK file (downloadable

application file) on my personal capstone web page since Week 5, and during the writing of this,

the application is currently undergoing approval onto the Google Play store.

Current screenshots of the program can be found in Appendix B 1. This shows the current

design of the application for all current pages of the application.

 West 23

Conclusion

Card collections and deck lists are commonspace for all Magic players to have, but

keeping track of these can be a big issue for players. Mobile Magic Collector looked to solve this

issue by creating an application that featured deck building with an interface that is primarily the

card images rather than just the name of a card with no other information coming from a list.

With the creation of MMCollector, the visual aspect has been achieved that was intended for the

application to stand apart from the other text-based deck builders and collection trackers that are

currently out in the Google Play Store. The design over-all became something that was clear and

concise, even for those who were not extremely familiar with the game Magic the Gathering in

an extensive way. In testing, this was the most important thing for me personally, that the users

were able to navigate through the application with next to no help or issues. Designing the app in

this way will make the application better for first time users so that if they have never used a

deck builder before on a phone, that this application will be very easy to pick up and edit

anything they might want to when they are building their deck.

Over-all, I learned a ton from taking this application on as an individual project. I went

into this application with mild knowledge of creating apps from previous courses I have taken

and wanted to take this as a big opportunity to learn as much as I possibly can. I learned a lot

about API calls in this application and how to implement them properly, which was a very good

experience for me personally. This branched into learning more about hashmaps and other parts

of programming I have rarely touched in my schooling so far. I also learned a significant amount

about adding and removing information locally onto a phone which was something I had never

worked with before, and now have plenty of knowledge about it which I feel I could easily use in
 West 24

the future for creating applications. My vision of the future of this application would be to go

back and visit the portions that I had to cut out due to time constraints. With more time, I feel as

though implementing several of the pieces that I missed out on would be very easily

implemented, but balancing out work, school, and other life activities during the time in this

course was difficult for me personally although I had an incredibly fun time getting this

application put together. Over-all, I am incredibly happy with the way it turned out as an

individual project and am looking forward to creating more for it in the future as I have extra

time to work on this project and improve it past the point at which it currently is in.
 West 25

References

Karsten, F. (2018, October 10). ​How Many Colored Mana Sources Do You Need to Consistently

​ etrieved from
Cast Your Spells? A Guilds of Ravnica Update. R

https://www.channelfireball.com/articles/how-many-colored-mana-sources-do-you-need-

to-consistently-cast-your-spells-a-guilds-of-ravnica-update/

Scryfall. (n.d.). ​API Documentation. ​Retrieved from ​https://scryfall.com/docs/api

Scryfall. (n.d.). ​Card Imagery. ​Retrieved from ​https://scryfall.com/docs/api/images

​ etrieved from
Wizards of the Coast. (2017, November 15). ​Fan Content Policy. R

https://company.wizards.com/fancontentpolicy
 West 26

Appendix

A. Code Snippets

1. Card.java example:

2. CardDeleteDialog.java example, deleteCards():

 West 27

3. CardQuantityChange, changeDeckQuantity():
 West 28

B. Screenshots

1. MainActivity, CardSearched, SavedCardsList, and CardQuantityChange

C. Team Member Roles and Responsibilities

Jacob West - Designer & Engineer

As the designer and engineer, I will be handling all of the creation of the application and

the full production of the application. My responsibilities for the creation of Mobile Magic

Collector will be:

● Setting up the Scryfall API and building the application’s search engine off of this API

● Creation of the deck files that will be made by the user when they create a new deck.

● Setting up saving the cards to a deck page. If necessary, the creation of a manual entry for

the deck page.

● Setting up the deck statistics page and functionality, ensuring that the math is correct and

accurate statistics are shown for the user.

● Setting up text-based sharing with friends

 West 29

● Putting the application onto the Google Play Store

● Conducting testing at all phases with a testing group.