Mazurojj code review 1.1

[JMaz-15]

Analysis of the program:
Because there was nothing composed in the Main Activity, this project was just a bunch of files with code and nothing you can see from a UI perspective. Based on the storyboards, I can see the vision of the project. It had a link to a JSON list of movies and had the services layers setup correctly.

Was the program available in UC Github on time?
Yes

Is the program documented/commented well enough for you to understand?
The project was not commented however through my knowledge of working through the individual assignment, listening in class and to the modules, and working on my own final project, I had a good understanding of what was going on in the project.

Does the program compile?
Yes, but there was no UI so there was nothing to see.

Rationale behind your changes.
Because this project had no UI, I created a simple homepage for them in accordance to their story boards. Basically I gave the two text fields, movie name and movie year, and a button that when it is clicked, the entry displays on the screen as they wanted per the storyboards.

Links to three specific commits that you made to your own group's GitHub repository before the end of sprint deadline.
https://github.com/JMaz-15/EasySurvey2/commits?author=JMaz-15

Above is the link to all my commits which were all February 23rd or prior.

three specific technical concepts that you learned from this code review
Doing this code review was basically a refresher of the individual assignment.

1. I was refreshed on the use of the BASE_URL in the RetrofitClientInstance object and the Get tag in the DAO. Basically these URLs combine to get the JSON list from the combined URL.
2. I was refreshed on the use of @SerializedName. Using this syntax allows the app to parse and read the JSON data by giving each value within the json data a name attribute which is what goes int he @SerialzedName declaration.
3. Creating the UI I was refreshed on just how to make a working UI that can read inputted data, and do something with that data. When the user clicks the button I created, the inputted user data will show using the toast in the button.

[discospiff]

The additions are likely needed for the project at some point, but are new, and sometimes incomplete, functionality. New functionality is better in a separate branch until fully developed, as features should not be merged to main/master until the meet the team's Definition of Done. Code review branches should minimize technical debt, and thus, be merge-able to master immediately. So, if the team desires these features, I'd keep the branch open, and iterate over the feature until it is complete.