Book Spy

Inspiration

During my first semester at college I observed multiple students that were not able to reach their academic potential because they did not have the means to buy expensive school textbooks. While listening to Mr. McEligot speak about striving to solve problems instead of make money, I realized that my software development skills can be used to help my low-income friends who either cannot afford textbooks or become financially burdened my them. The project also incorporated iOS design which I am interested in learning about.

What it does

Book Spy monitors online textbook prices for its users. This not only alleviates users of searching for affordable textbooks, but results in cheaper textbooks as Book Spy is capable of scouting deals constantly and independently. Book Spy also utilizes a range of productivity algorithms to make searching faster and more efficient. For example, Book Spy's data source is interchangeably derived from multiple free web APIs to offer a diversity of results and allow the app to be free. Additionally, Book Spy approaches categorizing profits in multiple ways. For example, the user is only emailed about a profitable opportunity if they have not been exposed to it on the app. Likewise, Book Spy determines the in-app profitability of a textbook based on long-term average prices and short-term ones. the majority of Book Spy's functionality is contained in the backend between the PHP and the MySQL. I did this so that I can easily add an Android app and website without re-designing its functionality.

How I built it

I first built as much of the front end (in Swift) as I could. This does not mean the visually appealing aspects, but the user inputs and the software's outputs. I found this method of programming to be beneficial because I was able to gain a thorough and concise understanding of the data structures and interactions necessary for the app to perform well, remain streamlined, and be completable in just 36 hours of work. It became apparent very quickly that one single API service would not be sufficient for Book Spy as it often submits multiple queries at a time between single user searches and the far more demanding and constantly running script to allocate and analyze data about the users' textbooks as quickly as possible without being IP throttled.

Challenges I ran into

Book Spy's frequency of API requests exceeded the limits of any API I could find. After a bit of thinking, I wrote a script that cycles API keys in coordination with API time limits. This allowed me to access all of the data that I needed without dividing the requests among a wide range of APIs which compromises the app's simplicity, security, and speed. Another challenge that I encountered was how to define a 'profitable' book. I realized that there is no one 'perfect' way to define a profitable textbook, therefore I needed multiple algorithms to determine profitability depending on the user's involvement and and age of the users' textbooks. Lastly, I ran into the problem of having to utilize with a database not only on another platform and responsive to a different programming language, but having to communicate with it entirely through character-restricting URLs. This forced me to tediously analyze every form of user input because not only was the URL sensitive to a range of characters, but it was a direct connection to my relatively unsecure database due to the hackathon's time constraints.

Accomplishments that I'm proud of

I am most proud of my database schema. It is very clean, relationally grouped, and easy to transition between. I am also very proud of the script I wrote that analyzes about 3 textbooks per second and collects about fifteen pieces of data each. I am also very proud of myself that I completed this project in only 34 hours. Although I feel like I will sleep for at least twenty hours when I get home.

What I learned

I learned how to intelligently approach complex projects involving lots of data. This was the first project I truly feel comfortable about that incorporates multiple scripts running simultaneously most of the time.

What's next for Book Spy

I will be submitting it to the iOS app store after a few revisions in a more relaxed environment. After that, I plan to make a website and Android app. I anticipate both to be relatively easy as the overwhelming majority of the algorithmic processes crucial to the service's functionality are complete, and easily accessible from a wide variety of platforms. I also plan to incorporate many more unique textbook APIs. I anticipate that this will yield more profitable results for the users and enable Book Spy to support a larger user-base while remaining free of charge.

Built With

• amazon-web-services
• api
• automation
• database
• email
• mysql
• php
• phpmyadmin
• swift
• users
• xampp
• xcode
• xml