Schottlw code review 1

[schottlw]

Analysis of the program

Overall, good start to an app!

• The code was readable and understandable for the most part (there were a couple things that were misspelled or could have been given a better name)
• The project does not utilize compose for UI currently, use XML layout instead
• Can see the start of some testing

Was the program available in UC Github on time?
Looked like work was being done in the repository up until the day of the due date, so I tried to wait until the final day before reviewing

Is the program documented/commented well enough for you to understand?
Overall, documented well: there are some comments throughout the project and the naming conventions made most files and variables self explanatory

Does the program compile?
Yes

Rationale behind my changes

• Restructured the dto to fit best practices and kotlin style guidelines
• Fixed a spelling error in a gradle dependency
• Added a testing dependency to gradle to get existing test to pass
• General code clean up of whitespaces to fit best practices and kotlin style guidelines
• Renamed testing file to better fit purpose, for better documentation

All of these changes aim to reduce technical debt of the in-progress project and allow it to be more readable as well as allow more functionalities to work

Three technical concepts I learned

• I was able to lean more about jetpack compose and how it works in android studio. My team's project started off as a blank compose project, so it already had jetpack compose integrated. Researching how to add compose to an existing project resulted in me combing through files I wouldn't typically work with and I was able to get a better understanding of what it takes to be able to create composable functions for a project's UI.
• I learned that, according to kotlin coding conventions (https://kotlinlang.org/docs/coding-conventions.html#class-headers), class constructors should be spaced out so that each primary constructor parameter is in a separate line, rather than declaring them all in one line. It makes it much more readable.
• I learned how to create UI with XML layouts. From this project, I found that android studio has a sort of drag and drop designer for layouts and you can create a screen right there. Then, you set it as the UI content in the MainActivity and that's what your app will look like when run.

Three of my commits

• healeyke/Cookit-@515bddf
• healeyke/Cookit-@51cbf2f
• healeyke/Cookit-@9b4116a

[schottlw]

Note about jetpack compose:
As apart of my review, I attempted to integrate jetpack compose and refactor the MainActivity class. Theoretically, you should be able add compose to an existing project, but I wasn't able to get it to fully working with the time I had. As to not increase technical debt, I did not include the work I did trying to add compose. If you guys decide to create UI elements with compose moving forward, Here's a helpful reference I found: https://stackoverflow.com/questions/61559352/add-jetpack-compose-to-existing-project I believe we may need to utilize compose as part of our final project requirements, so just something to think about.

[schottlw]

Added an additional test dependency so the test you guys had could run and pass

[schottlw]

Fixed spelling issue so dependency would register

[discospiff]

Good catch!

[schottlw]

Restructured the dto according to kotlin coding conventions: https://kotlinlang.org/docs/coding-conventions.html#class-headers

[schottlw]

Renamed 'ExampleUnitTest' to 'MovieIntegrationTest'. Currently, there isn't any unit testing going on and based on the example test you guys have, I assume integration tests will go here in the future, so I thought the name 'MovieIntegrationTest' fit better.

[discospiff]

Good idea... provided there are tests in here.

[discospiff]

Several good suggestions, worth considering merging this branch.