The CheckerBoard challenge proved to be more difficult than I expected when I began working on it. The main difficulty was placing the generated board onto the VBox and adding the change listener so the board would resize properly. Despite the difficulties, I believe I completed the challenge well. The board was able to successfully resize when the stage size changed, and the board would update when users selected a size or color. Many of the shortcomings in the project are in the logic of the code, with it being very redundant and verbose.
Going into the challenge, I felt that I did not understand the concepts of change listeners very well. Anytime I added a listener in previous programs, I modified code that was given as an example in class or online. Initially there was a bug in my program where the board would not resize to a smaller size because the listener was added to the wrong object. However, by the end of the project, I felt like I understood change listeners and event handlers a lot better.
For the most part, all of the requirements were met in the challenge. The checkerboard resized correctly when the stage size changes, and the board updated when the user changed the color or size of the grid. All requirements for the CheckerBoard class were met. The only issue was if a user selected the same grid size multiple times consecutively, the grid became slightly bigger after each selection and no longer fit on the stage.
The posted solution is quite different than my solution, mainly in that the code is less redundant and more concise. The CheckerBoard classes are similar. The main difference is the algorithm to build the board is more concise. The posted solution uses a stackpane in the view while I added and removed an anchorpane to the VBox in the controller. The stackpane seems to be easier to add and remove elements which was an issue I experienced with the VBox. I also think this contributed to the issue indicated earlier of the board getting slightly bigger when the same grid size is selected. The controller in the posted solution has fields for board parameters. This made the posted solution less verbose and redundant than mine. I constantly used the getters in the CheckerBoard class to set the parameters in the controller and had methods that performed similar tasks (like changing the size of the grid). The posted solution also got the id of a menu item and then used a switch statement when selecting for grid size or color. This eliminates redundancy in my code where I have a different method to handle the selection of each menu item. Finally, the posted solution adds its change listeners to the scene instead of the VBox. This does not seem to make that large of a different. The posted solution handles the changes more efficiently by only calling the renderBoard() method and getting the width and heigth inside of it, rather than getting all parameters, creating a new CheckerBoard object, and updating the view like I do in my solution.
By the end of the challenge, I had a much better understanding of change listeners, and I believe I understand the concepts in the challenge. To improve, I can think about the project more before I begin programming to ensure I understand the concepts. I can also spend more time refactoring to reduce the redundancy and complexity of my code.