Assignment 13
Due Date Thursday 11/01 at 9pm
Purpose To practice iterative refinement and list-processing, as well as learning about universe and distributed programming.
You should submit a single .rkt file containing your responses to all exercises via the Handin Server. We accept NO email submissions.
You are only allowed to use the language specified at the top of this page: failure to do so will result in a 0.
All steps of the design recipe are required except for data examples and templates. However, doing them would be helpful. :)
Project (Part 3)
Recall that in part 2 we asked you to design a music player that communicated with a server to play whatever songs it was sent. Unfortunately, this music player only displayed information about the next song coming up. Think about the music applications you use: iTunes, Pandora, Spotify, and so on. All of these applications show you some information, not just about the current song, but about the songs you have listened to in the past: your musical history.
For this part of the project we want you to add to your display so that you show a history of the songs you have listened to. Your program should keep track of how many times you have listened to each song in the history, so if you hear a song twice it should be ONE entry in your history. Since we can’t guarantee that two songs with the same name are the same, the server will now provide you with an ID so you can check whether you have played that song before.
Note that your history file, which exists to keep track of your play count, should keep track of the play count of each song across all runs of your client. Of course, if someone were to delete that file, the playcount would be lost, but designing a storage system for usage history that is more secure than just a text file is outside of the scope of this course.
; A ServerMsg is one of: ; - ErrorMsg ; - SongMsg ; A SongMsg is a (list "SONG" Nat Metadata String) ; - where the Nat is the song's unique ID# ; - the Metadata is information about the song ; - and the String is the actual byte-string of music
When the program ends, you should call write-file to write your history to a text file. Then, when the program starts up again, you should call read-csv-file to read that history so that you can display the same list of songs as before. Note that when a csv file has a trailing blank line at the end of the file, it is ignored.
Exercise 1 Edit your data definitions to keep track of any new information you will need.
Exercise 2 Edit your big-bang function so that when you exit the program it will write the song history to a text file. You may name this text file whatever (relevant and appropriate) name you like. When writing the data to the file, you should separate all the fields you write to the file with commas, and each entry on a new line (this will become useful in the next exercise). You may assume that none of the song names, artists, or albums will contain commas. Please do NOT write the byte-string to the file, as they are quite long and are not necessary for you to display the history. You may want to read the documentation for write-file.
Exercise 3 Edit your program so that the initial state of the world is built based on reading the history from your text file. You may want to read the documentation for read-csv-file. You should only call read-csv-file if you are sure that the file exists (the function file-exists? will come in handy for this).
Exercise 4 Change the way you draw the MusicPlayer so that it now displays a list of the songs you have heard along with how many times you have heard them. Each song you have listened to should only be displayed ONCE. If the history gets too long for your display, it is okay to cut it off at some point.