Java !! Could someone help me with this? I have no ideas how to save and recall the game using serialization; this is new to me. Here is the code I've been doing so far Part III

Please download the code at: https://ufile.io/nov6e ( Click slow download free). I don't want to post directly on Chegg it takes up too much space.

Objectives

Serialization.

File I/O.

Configuration File.

[optional] javax.swing.JFileChooser.

[optional] multiple configuration files.

Instructions

In Parts I, II, and III, you created an implementation of the Game of Life. If you consider the pieces of the Game of Life within the context of the MVC model, clearly the core of the Game of Life is what you coded up in Part I. That part included all of the 'business rules', that is when birth, survival, overcrowding, and loneliness occur. One of the somewhat unsatisfying things about that initial implementation was the need to hard-code a starting point. Now, with Part III, it seems that the game is nearly complete. A starting point can be created relatively easily, albeit potentially a bit tedious (and error prone).

Save State

For this portion of the assignment, you will support saving and recalling the state of the Game of Life. Now, the state information is what's stored in the "two-dimensional" matrix you created in for Part I. (The quotes are there since technically Java does not support two-dimensional matrices, per se, but handles them as arrays of arrays.) What you need to do is serialize the data for storage into a file. You may find the notes (documentation) for java.io.Seralizable to be helpful.

Now, this serialized data (yes, it just means that it's been arranged into a single string of bytes) needs to be stored. Recall that java.io is structured around input and output streams. So, you will need to create an output stream (with an associated file open for writing) to save the state of the game. The serialized data can be stored using that output stream. Similarly, to restore the stored state of the game, you will need to create an input stream (with an associated file open for reading). Some research on your part will make this operation relatively trivial.

The question may arise about user interface for saving and restoring the state information. For example, you could have a textbox in your user interface, with Save and Restore buttons (or other similar captions). This is a minimal user interface, which is rather straight-forward to code. The issue becomes one of making sure that the user is providing reasonable file and folder information. To help the user give folder information, one could use javax.swing.JFileChooser. This class supports File Open and File Save As options. This circumvents a number of the potential problems with opening files for reading or writing, since the user will be 'guided' to give reasonable directory information. (There is an extra-credit option for filtering the files displayed by the File Open, and possibly amending the file name for File Save.)

Note: no matter how you support the user providing filename information, it is reasonable for the application to 'ask' before it overwrites a file. With this sort of game is not typical that a user will want to open a saved game, let it run for a while, then save the updated state (overwriting the formerly saved state). The initial state is of greater interest than the resultant state, since the resultant state is derivable in a mechanical way from the starting point. So, one of the requirements for full credit is to check for the existence of the output file and confirm overwrite before saving, even if it is the file that was read to give this starting state. (A simple confirm dialog box is supported by JOptionPane.)

Configuration

There are now some values which are customizable by the user, the most obvious is the number of generations per minute. Another is the file to load when the application starts up. These types are values are intrinsically different from the state data stored in the previous portion of this write-up. In general, these are values that should be loaded automatically when the application is opened.

As with saving state information, this data will need to be serialized. Rather than use some of the 'fancy' (operating system specific) mechanisms to store configuration information (like the registry in Windows), this information will be stored in a simple disk file. Select a filename and store the two pieces of information in the file. This is essentially hard-coded into the application (unless you do one of the extra-credit options). Note: the number of generations per minute should be an acceptable value, 1 - 250, inclusive. However, it should be reasonable to store a 'blank filename' in the configuration file.

There is a design issue here. Will the configuration file be written out every time the application shuts down? Alternately, will the be a part of the user interface, like a menu item, Save Configuration, perhaps on the File menu? Either option is fine. In your written report outline the choice you made and briefly explain the rationale behind this choice.