Hey! I’ve been meaning to write this article for a while now but was too busy with school and work. But now that I’m on break I have some extra time. This article discusses a project I created for a Software Engineering class called CoinTrack. For this project I was in a team with two other students, Hager and Parth, and we created this desktop application over the course of one semester. For the record, I recieved a 99 for my part in thie project. Unfortunately I don’t know where I lost the one point. The major points we were graded on included the following:
- The application follows MVC Architecture (Model View Controller)
- The application connects to an external API
- The application uses some sort of persistent data storage (text file or database)
- It must follow the Java Style Guide
That’s it. Not too bad. Before this project I had never created an MVC project, or connected to an API, or connected to a database, or even fully followed a Java style guide. I didn’t even know what MVC stood for. So I learned a ton of stuff from this course and it was one of, if not the, best class I have taken so far. If you are curious about the professor I had, his name is Ike Quigley. His personality and knowledge about the subject matter made this an incredibly interesting and fun class.
Ok, enough talking. I’m going to walk you through the development process of this project. If you want to take a look at the code check out the github repo.
- Introduction: Originally my team wanted to create some sort of messaging application, but when we were looking for an api to use for this we couldn’t find a free or cheap api to use. They all cost tens to hundreds of dollars a month. So we started looking for an api that would provide us interesting data that we could use to create things like graphs and tables. We ended up settling on an api called CoinRank which provides financial and historical data on the top 50 cryptocurrencies. This is a great api that has a free version where you get access to a few hundred thousand querys a month, which was more than enough for our needs. The critical features of this api are the ability to get detailed data about specific cryptocurrencies going back up to 5 years.
- Brain Storm: After picking out our api we had to sit down, or in this case join a discord call, and strategize about the actual structure of our project. We knew we wanted to have log-in, register, and forgot password stages. These portals will connect to a user table in an online database our program will connect to in order to validate logins. Once a user logs in they will be taken to a dashboard showing their saved coins. There will be two or three other tabs that will show data about all coins both in table form and in graph form.
- API: Ok, now that we had the basic structure formed it was time to prototype our api connections. This was totally new for me and I admit that I struggled for many nights trying to figure out how to “drill down” into a JSON response. But once I understood the different JSON structures it made so much more sense.
- The theory behind out api connection class was to create a single class that would actually make the connections and then have other classes that would pass various endpoints and keys to the connection class in order to parse different types of data. This method increases encapsulation and reusability.
- Database: For our database we decided to use a site called freemysqlhosting to setup an actual database online so everyone in out team could connect and have access to the same data. This website is nice because you get a free 30 day trial and can create up to 3 databases. After 30 days it will cost around $20 for a year of use.This was my first time successfully connecting a java project to a database. I actually ended up writing a blog post about it.
- If I was more familiar with integrating with a database I would have used some sort of SQL statement builder package to more easily access the database. But, since we didn’t go this route, our database connection file because huge since we needed a different method for every type of interaction with the db. If I could have gone back and re-worked the database class I would have, but the time crunch was real and we had to stick with what we already had.
- File Structure: The file structure of our project changed quite a bit throughout the semester. At first our files were quite unorganized but once we refactored the project to conform to MVC architecture it became much more readable.
- Interfaces: Something we put quite a bit of effort into was making sure we had interfaces for all classes. Interfaces are important for inforcing the use of methods for re-usable classes. They create a type of standard that future developers who may work on the project will see and understand that other parts of the project rely on this particular class being formatted in this way. That was a very convoluted sentence but basicallt it’s a preventative measure to help code maintainability.
- Controllers: Something I learned from this project is that it’s not always a good idea to have a single controller for the entire project. LOL. Ok, this might be obvious but at first it seemed like a good idea to keep everything on one controller. We soon found out that this was a very unmanagable way to organize stuff. The file literally exploded in size nearing 1000 lines long. This was when we decided to re-evaluate our life choices and switch to a multi-controller setup. Something I was worried about with this approach was code reuse. I didn’t want to have to implement a few of the same features on four different controllers. To mitigate this I made an “AssistantController” class that acted as an intermediary class where we had all the methods and action events used on more than one controller.
- Separation of Code: One of the many things my professor kept emphasizing throughout the semester was the separation or encapsulation of code. “Why is there SQL on your controller?!?!” he would ask a classmate. This was something I fell victim too myself. His point is totally valid though. In order to prevent your program from exploding in the future you need to keep your code separated. This means you keep all of your SQL code in the database connection class, and all of your api stuff in the api class. Then you make models that use that data or call on those classes, instead of just putting the code wherever is the most convenient at the time.
- Models: The real meat and potatoes of the program. Our project ended up having 19 different models and we easily could have added a few more. Something that seems pretty obvious but we didn’t implement until near the end of the semester was creating a User class. I’m not sure why we didn’t do this sooner because once we did we had a perfect, central place to access all of the data for a specific user. Models are, from the name, a huge part of the MODEL view controller (MVC) architecture. The majority of the time this is how the program works: The controllers manipulate the models, the models affect / update the view, the view sends input from the user to the controller, and sometimes the controller updates the view.
- Views: For our project we used Java FXML. I really like fxml and using scene builder to create GUI’s. It makes the design and implementation process much quicker than when working with plain JavaFX. Once we create an fxml view we generally don’t touch it too much afterwards. All of the logic happens in the models and the controllers move the data so for the most part the fxml files are a set it and forget it kind of view.
Thanks for reading, or skimming through this blog post. I want to mention my team mates I had on this project: Parth and Hager, both of who were a pleasure to work with.
