Delete token reference(keyword)

.gitignore

@@ -3,7 +3,10 @@ out/
 !**/src/main/**/out/
 !**/src/test/**/out/
 .idea/easycode.ignore
+.idea/
+homework-5.iml
 
+src/keys
 target/
 
 ### Eclipse ###

README.md

@@ -1,181 +1,84 @@
-# Lab 5: Logout
-
-## Preamble
-
-In the current homework, you added code to the login use case to save the currently-logged-in
-user by saving the user in the Data Access Layer. You also added a unit test for this.
-
-In this lab, you will complete a logout use case as a team. You will also begin to discuss your project
-and the use cases that need to be implemented. 
-
-We have created all the Clean Architecture classes necessary for the logout use case.
-
-By Friday, your team will submit:
-- your completed lab code [for credit]
-- a draft of your project blueprint proposal. [required, but not for credit]
-
-# Phase 2 [for credit]
-_(recall, Phase 1 was your solo task of adding the storage of the currently-logged-in user)_
-
-## Task 0: Fork this repo on GitHub
-**To get started, one team member should fork this repo on GitHub and share it with the team. 
-All of you should then clone it.**
-
-* * *
-
-Suggested logistics: One of you should invite the others to collaborate on their fork of the
-original repo on GitHub. You can do this in your repo on GitHub under `Settings -> Collaborators`.
-This will allow you to push branches to a common repo and then use pull requests to contribute
-your code and review. To prevent others from pushing directly to the main branch,
-we recommend you set branch protection rules on GitHub. Below are how the settings might look if you
-add branch protection rules:
-
-![image of branch protection rules for main with the
-requirement of two approvers to merge in pull requests.
-](images/branch_protection_rules.png)
-
-* * *
-
-Open the project in IntelliJ and make sure you can successfully run `app/Main.java`.
-Note: you may need to set the Project SDK in the `Project Structure...` menu, and possibly
-also manually link the Maven project, as you did in Phase 1.
-
-## Task 1: Understanding the Program
-
-You may notice that we have refactored the CA engine code _slightly_ since Phase 1, but the
-way we build the engine is drastically different: we have switched from using Factories to
-using the Builder design pattern, which we'll be discussing in lecture soon. 
-
-Open up `app.Main` and read it as a team.
-- What are the Views and what are the current Use Cases?
-- Which Uses Cases are triggered from each View?
-- Which version of the DAO is `app.Main` using?
-
-The major change since Phase 1 is that we have added the `app.AppBuilder` class which makes
-it easier to understand how our CA engine is being constructed — it also makes `app.Main` nice and concise!
-- Why do all those `addX` methods end in `return this;`? 
-
-Run the program and make sure the signup and login Use Cases work.
-
-Currently, you'll notice that the "Log Out" button still doesn't actually log you out. It's time to fix
-that button, which is part of the `LoggedInView`.
-We have created all the classes for you, but some of the code is missing.
-As a team, your task is to fill in the missing code so that the Logout Use Case is implemented.
-**The next part of the readme describes how your team will do this.**
-
-* * *
-
-**Your team will know when you are done when:**
-
-- Clicking the "Log Out" button takes the user back to the Login View when you use the program.
-- The provided `LogoutInteractorTest` test passes.
-
-The "Log Out" button is an instance variable in class `LoggedInVew`. Go find it.
-Also look at the `interface_adapter.change_password.LoggedInViewModel`, which contains any
-data showing on the `LoggedInVew`.
-
-* * *
-
-## Task 2: Dividing up the work
-
-There are `TODO` comments left in the files
-Recall that you can use the TODO tool window to conveniently pull up a complete list.
-
-Once the TODOs are all complete, the "Log Out" button _should_ work!
-
-As a team, split up the TODOs (see below) between the members of your team.
-
-There are TODOs in seven of the files.
-Make sure each member has at least one TODO which they will be responsible for completing.
-If your team prefers to work in pairs, that is fine too. Your individual branches
-will not be graded for this — only the final, working version.
-
-The TODOs are summarized below (by file) to help your team decide how to split them up:
-
-* * *
-
-- `Main.java`
-
-  - [ ] TODO: add the Logout Use Case to the app using the appBuilder
-
-* * *
-
-- `LoggedInView.java` (tip: refer to the other views for similar code)
-
-  - [ ] TODO: save the logout controller in the instance variable.
-  - [ ] TODO: execute the logout use case through the Controller
-
-* * *
-
-- `LogoutController.java` (tip: refer to the other controllers for similar code)
-
-  - [ ] TODO: Save the interactor in the instance variable.
-  - [ ] TODO: run the use case interactor for the logout use case
-
-* * *
-
-- `LogoutInputData.java` (should be done with the LogoutInteractor TODOs below)
-
-  - [ ] TODO: save the current username in an instance variable and add a getter.
-
-- `LogoutInteractor.java` (tip: refer to `ChangePasswordInteractor.java` for similar code)
-
-  - [ ] TODO: save the DAO and Presenter in the instance variables.
-  - [ ] TODO: implement the logic of the Logout Use Case
-
-* * *
-
-- `LogoutOutputData.java`
-
-  - [ ] TODO: save the parameters in the instance variables.
-
-* * *
-
-- `LogoutPresenter.java` (tip: refer to `SignupPresenter.java` for similar code)
-
-  - [ ] TODO: assign to the three instance variables.
-  - [ ] TODO: have prepareSuccessView update the LoggedInState
-  - [ ] TODO: have prepareSuccessView update the LoginState
-
-* * *
-
-1. Make a branch named the first part of your UofT email address, everything before the `@`.
-For example, if your email address is `paul.gries@mail.utoronto.ca`, then the branch name would
-be `paul.gries`.
-
-Make sure you switch to the new branch.
-
-In the terminal, this would look like below, but replaced with your own information:
-```
-git branch paul.gries
-git switch paul.gries
-```
-
-2. Complete your assigned TODOs and make a pull request on GitHub. In your pull request,
-   briefly describe what your TODOs were and how you implemented them. If you aren't sure
-   about part of it, include this in your pull request so everyone knows what to look
-   for when reviewing — or you can of course discuss with your team before making your
-   pull request since you are physically working in the same space.
-   - **Important: don't push any changes to the `.idea` folder, as that
-     may cause issues for your other teammates, as some files contain
-     configurations specific to your individual IntelliJ projects.**
-
-3. Review each other's pull requests to ensure each TODO is correctly implemented and that
-   there are no Checkstyle issues in the files that were modified.
-
-4. Once all TODOs are completed, your team should debug as needed to ensure the
-   correctness of the code. Setting a breakpoint where the log-out use case
-   interactor starts its work will likely be a great place to start when debugging.
-
-And that's it; you now have a working Logout Use Case! Instructions for
-how to submit your work on MarkUs will be posted later.
-
-Your team should spend the rest of the lab working on your project blueprint.
-
-* * *
-
-# Project Blueprint
-
-See Quercus for details about the project blueprint! By the end of the week,
-the goal is for your team to have a fully drafted blueprint so that your team
-will be ready to get started on your project after Reading Week.
+# CSC 207 Project: Spotify Companion
+
+## Software Description
+The software is made through Java Swing and acts as an extension of a user’s Spotify account. 
+The program visualizes user listening patterns, 
+suggests new or related songs for their preferences, search songs by certain 
+lyrics and keywords that the user gives, and can find users with similar preferences. 
+It is going to be a general extension to the overall Spotify experience.
+<br />
+<br />
+The APIs we will use are Spotify (to access user data) and Azure OpenAI (to interpret data and recommend songs)
+
+## Authors
+Yanki Cer -> yankicer <br />
+Dimitrios Gkiokmema -> DimitriosGkiokmema <br />
+Quinn Reynolds -> Reyno256 <br />
+Ksenia Tkaczyk -> KseniaTk <br />
+Yicheng (Ethan) Wang -> eulogizee
+
+## Table of Contents
+1. [Features](#Features)
+2. [Installation Instructions](#Installation)
+3. [Usage](#Usage)
+4. [Feedback and Contributions](#Feedback)
+
+## Features
+There are six major features of the app; one for each of us to work on independently, and one to collaborate on as a team. Below is an image of the overall pages which a user can access. Below each feature is an image of the associated view in the software.![Project UI](images/CSC207%20Project%20Wireframe.png)
+### Login Screen <br />
+* Sign In/Out: The first is a user signing in and signing out(Team).
+
+![Login Screen](images/login_screen.png) <br />
+![Home Screen](images/home_screen.png) <br />
+
+* Recommendations: The app can also get song recommendations based on a user's music preferences using the for you button. (Dimitrios)
+![Recommendations Screen](images/csc207_progress1_dimitrios.png) <br />
+*   Search by Description: The user can enter the description of a song and have its title returned. (Quinn)
+
+![Description Search Screen](images/csc207_progress1_quinn.png) <br />
+
+* Search by Artist and Lyric: A user may want to see some songs based on a given keyword. They can enter the keyword into a search text box and get 
+suggestions. (Ethan)
+![Keyword Search Screen](images/csc207_progress1_ethan.png) <br />
+
+* Top Tracks: A user wants to see what their most listened to tracks are. (Yanki)
+![Analytics Screen](images/csc207_progress1_yanki.png) <br />
+
+* Similar Music: A user wants to find other individuals that have a similar music preference. (Ksenia)
+
+![Similar Listeners Screen](images/csc207_progress1_ksenia.jpg) <br />
+
+
+## Installation
+As this app is written entirely in Java it runs well on a variety of devices. 
+Currently, it has been tested on Windows 11, macOS 14 and Ubuntu 24, although likely
+many other operating systems would also work. 
+1. After installing the Java files the user must ensure all the Maven dependencies are properly installed. In IntelliJ IDEA this can be done by clicking on the m on the right side of the screen and clicking reload all maven projects incrementally as seen below.![Maven reload instructions.png](images/Maven%20reload%20instructions.png)
+2. The other packages which Maven will download are Okhttp(https://square.github.io/okhttp/) version 4.12.0, JFreeChart(https://www.jfree.org/jfreechart/) version 1.5.4 and Azure openAI(https://learn.microsoft.com/en-us/java/api/overview/azure/ai-openai-readme?view=azure-java-preview) beta version 12.
+3. To log in to the app you are required to have a spotify app access token. Getting this token is clearly explained in this link(https://developer.spotify.com/documentation/web-api/tutorials/getting-started), as well as below.
+   1. In the spotify app go to your Dashboard, click on the Create an app button and enter the following information: App Name: My App
+   App Description: This is my first Spotify app
+   Redirect URI: You won't need this parameter in this example, so let's use http://localhost:3000.
+   2. Check the Developer Terms of Service checkbox and tap on the Create button.
+   3. Click on the name of the app you have just created (My App)
+   4. Click on the Settings button
+   5. The Client ID can be found here, it is essential for the next part of the process so record it somewhere safe. The Client Secret can be found behind the View client secret link this is also required for the next step.
+   6. To request an access token navigate to https://hoppscotch.io/ and Send a POST request to the token endpoint URI.
+   7. Add the Content-Type header set to the application/x-www-form-urlencoded value.
+   8. Add an HTTP body containing the Client ID and Client Secret, along with the grant_type parameter set to client_credentials.
+   9. The response will be a spotify access token which is valid for 1 hour and can be used to log in to the app.
+4. In order to access the other API used in this project you must add a file called keys(with no file type extension) to the src directory of the project.
+5. Then you must paste in the Azure openAI api key used for the project, if you don't have this key, and you need access to it email quinn.reynolds@mail.utoronto.ca.
+6. After these steps the app should work for you, keep in mind you will need to regenerate a Spotify API key every hour. 
+
+
+## Usage
+
+## Feedback
+This code was written for CSC207 in the fall of 2024 and if you are reading 
+this document after that point then the code will no longer be maintained. 
+If you would like access to this repository please email dimitrios.gkiokmema@mail.utoronto.ca. As this is a public project please be civil and send all emails related to the project with the subject line "Spotify Companion <your GitHub username>". You can expect a response within 5 days in general.
+In terms of contribution, any pull requests which include changes to Interactor files must also 
+include updated tests for those files. It is expected that all code written for this project follow 
+the ACCEU framework for code documentation and commenting. Code reviews will be conducted by the 
+orignial authors of the repository based on adherence to the principles of Clean Architecture and SOLID principles of software design.

accessibility-report.md

@@ -0,0 +1,30 @@
+Principles of Universal Design
+	1.	Equitable Use:
+	•	Our program adheres to equitable use by offering features such as “search songs by description” and “search songs by keyword and artist,” which allow users with diverse music preferences to easily find songs regardless of specific knowledge about artists or genres.
+	•	Future enhancements could include adding a text-to-speech feature to ensure visually impaired users can interact with the program seamlessly.
+	2.	Flexibility in Use:
+	•	Features like “get song recommendations based on your music preferences” adapt to different user tastes and listening behaviors, offering personalized recommendations.
+	•	We could add language options in the future to accommodate non-English speakers, ensuring the interface is accessible to a broader audience.
+	3.	Simple and Intuitive Use:
+	•	The program’s interface for “search songs by keyword and artist” is designed to be straightforward, so even first-time users can understand and interact with it effectively.
+	•	Tooltips or brief explanations could be added to further improve intuitiveness, helping users unfamiliar with some features.
+	4.	Perceptible Information:
+	•	Users can clearly view and navigate their “top tracks” and “song recommendations” without requiring prior knowledge, thanks to a well-organized and readable display.
+	•	To improve accessibility, we could implement audio cues for visually impaired users.
+	5.	Tolerance for Error:
+	•	If users make typos while using the “search songs by keyword and artist” feature, the program could provide suggestions for corrections or display close matches.
+	•	Future updates could include an undo feature to revert accidental actions, such as removing a song from a playlist.
+	6.	Low Physical Effort:
+	•	The program minimizes physical effort by providing quick access to “top tracks” and “similar listeners” through single-click or tap actions.
+	•	Voice command integration could be a future addition, further reducing physical interaction requirements.
+	7.	Size and Space for Approach and Use:
+	•	The program’s interface is responsive and designed for both desktop and mobile platforms, ensuring that it remains functional and accessible regardless of the user’s device or screen size.
+	•	Future updates could optimize the app further for assistive devices, like screen readers or one-handed operation.
+
+Target Market
+
+If we were to market the program, our primary audience would include music enthusiasts and Spotify users who want to enhance their music discovery experience. This includes students seeking new music for studying or relaxation, casual listeners looking for recommendations, and advanced users who want insights like “similar listeners.” Additionally, our program could appeal to professionals in creative fields, like writers or designers, who use music to inspire their work. By focusing on personalization and intuitive search features, we aim to attract users who value ease of use and customization in their music experience.
+
+Demographic Considerations
+
+Our program is less likely to be used by people who do not use Spotify, as all features are designed around Spotify’s API and ecosystem. Additionally, some demographics may face barriers, such as those without internet access, non-English speakers, or users unfamiliar with digital music platforms. To mitigate this, we could add offline features or expand language support. Drawing from the ethics modules, we recognize the importance of accessibility for users with disabilities. As such, we plan to incorporate features like text-to-speech, voice commands, and screen reader compatibility to ensure that our program does not exclude these demographics. By addressing these considerations, we aim to create a more inclusive and universally appealing tool.