• Responsabili: Robert Grancsa, Tudorache Ioana-Alina , Alexandru Gheorghe
• Colaboratori: Sorina-Anamaria Buf, Ștefan Cocioran, Florian-Luis Micu
• Data publicarii: 18.12.2023, ora 13:30
• Deadline HARD: 14.01.2024 16.01.2024, ora 23:55
• Ultima modificare a enuntului:
  • 11.01.2024, ora 23:23 - added details for design patterns
  • 06.01.2024, ora 14:25 - details for updateRecommendations
• Ultima modificare a testelor: 29.12.2023, ora 14:54 - removed all songs from the library
• Schelet: GitHub
• History
  • 28.12.2023, ora 02:37 - simplified complex tests (6, 15, 16) and other fixes for date, recommandation and duplicate songs
  • 27.12.2023, ora 11:05 - fixed index for random song
  • 26.12.2023, ora 14:13 - replaced topPodcasts and recalculted mostProfitableSong
  • 24.12.2023, ora 13:25 - clarifications for wrapped
  • 24.12.2023, ora 13:25 - fixed createPlaylist in test 12
  • 24.12.2023, ora 13:25 - removed field from test 10 and fixed message for notifications
  • 23.12.2023, ora 14:10 - updated notifications info
  • 23.12.2023, ora 14:10 - updated notifications messages
  • 22.12.2023, ora 19:50 - updated search specifications
  • 22.12.2023, ora 22:33 - added hosts to input
  • 19.12.2023, ora 23:11 - removed bad field from refs

• Atenție! Pentru partea de citire / afișare nu este necesară folosirea adnotărilor din librăria Jackson. Puteți utiliza o metodă similară cu cea prezentată de noi în schelet, și anume să vă folosiți de clasa ObjectMapper. Nu există o metodă corectă sau greșită de a lucra cu input-ul / output-ul. Scopul nostru în cadrul acestui proiect nu este să vă testăm abilitatea de a lucra cu fișierele, ci să vă testăm atât înțelegerea cunoștințelor de bază dobândite în cadrul cursurilor și a laboratoarelor, cât și modul de gândire într-un limbaj de programare orientat obiect.
• Este obligatoriu să folosiți cel puțin 4 design pattern-uri. Trebuie sa precizati in README ce design pattern ati folosit, si motivatia & locatia unde a fost folosita
• Depunctari lipsa design pattern-uri: Pentru fiecare design pattern lipsa (din cele 4), veti avea o depunctare de -2.5p, astfel pentru:
  • 0 design pattern-uri - -10p
  • 1 design pattern-uri - -7.5p
  • 2 design pattern-uri - -5p
  • 3 design pattern-uri - -2.5p

• Implementarea a cel puțin 4 design pattern POO.
• Refactorizarea codului pentru a permite adăugarea funcționalităților noi.

Pentru acest proiect o să aveți de implementat o aplicație asemănătoare ca funcționalități cu Spotify, simulând diferite acțiuni făcute de utilizatori, acum cu feature-uri care ne adauga detalii despre monetizare si cat de mult foloseste un user platforma noastra. Pe langa asta, vom avea si modalitati de a adauga playlist-uri generate pe baza preferintelor userilor, sau a preferintelor fanilor de la un anumit artist. Iar pentru fiecare obiect adaugat nou pe platforma, utilizatorii vor primi notificari de la platforma cu noutatiile aparute.

În cadrul primelor etape, ați avut de implementat structura platformei noastre, care a constat în definirea entitatilor si obiectelor de mai jos.

GlobalWaves Wrapped este o statistica a platformei GlobalWaves care oferă utilizatorilor un rezumat personalizat al activității lor muzicale, inclusiv topul melodiilor ascultate, genuri preferate și alte statistici relevante, pe parcursul rularii programului.

Aceasta comanda poate fi apelată de pe orice pagină, si va afisa statistici de la timestamp 0 pana la timestamp-ul current. Se vor afisa o structura sub forma de ${nume}: ${count}, si vor fi sortate initial dupa count, iar in caz de egalitate dupa nume lexicografic.

La rularea comenzii de catre un user, o sa se afiseze urmatoarea configuratie:

• topArtists - artistii dupa numarul de listen-uri
• topGenres - genre-urile dupa numarul de listen-uri
• topSongs - melodiile dupa numarul de listen-uri
• topAlbums - albumele dupa numarul de listen-uri
• topEpisodes - episoadele de podcast dupa numarul de listen-uri

Mesaje posibile pentru aceasta comanda:

• "No data to show for user ${username}."

La rularea comenzii de catre un artist, o sa se afiseze urmatoarea configuratie:

• topAlbums - albumele dupa numarul de listen-uri
• topSongs - melodiile dupa numarul de listen-uri
• topFans - userii, dupa numarul de listen-uri pentru artistul curent
• listeners - numarul useri care au ascultat artistul curent

Mesaje posibile pentru aceasta comanda:

• "No data to show for user ${username}."

La rularea comenzii de catre un host, o sa se afiseze urmatoarea configuratie:

• topEpisodes - episoadele dupa numarul de listen-uri
• listeners - numarul useri care au ascultat artistul curent

Mesaje posibile pentru aceasta comanda:

• "No data to show for user ${username}."

Artisti de pe platforma au protestat pentru ca nu sunt platiti, asa ca introducem sectiunea de monetization. La fiecare play al melodiei, un user va plati catre artist o valoare calculata pe baza unor euristici. Pe langa asta, cumpararea de merch va transfera bani in contul artistului. La finalul fiecarea rulari se vor calcula si afisa banii pe care il primeste fiecare artist pe baza calculelor de mai jos.

Formatul afisarii va fi ${artist}: ${date}, unde datele vor avea urmatoarea forma:

• songRevenue - cati bani au scos de pe toate listen-urile de pe platforma
• merchRevenue - cati bani au scos de pe vanzarile de merch de pe platforma
• ranking - ranking-ul artistului de pe platforma dupa vanzari (indexate de la 1)
• mostProfitableSong - melodie pe care artistul a scos cei mai multi bani (bazat pe suma revenue-urilor)

Un utilizator poate sa cumpere merch al unui artist. Dupa cumpararea lui, artistul va primi pretul final al produsul in contul sau, care va fi adaugat in field-ul merchRevenue.

Userul nu are nici un wallet intern, asa ca fiecare buy va adauga revenue doar pentru artist, nu se va scadea nimic de la user.

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."
• "Cannot buy merch from this page."
• "The merch ${name} doesn't exist."
• "${username} has added new merch successfully."

Se vor afisa toate obiectele cumparate de catre user, in ordine cronologica dupa timpul cumparari lor.

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."
• "${username} is already a premium user."
• "${username} bought the subscription successfully."

{
    "command": "buyPremium",
    "username": "alice22",
    "timestamp": 10
}

{
    "command": "buyPremium",
    "username": "alice22",
    "timestamp": 10,
    "message": "alice22 bought the subscription successfully."
}

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."
• "${username} is not a premium user."
• "${username} cancelled the subscription successfully."

{
    "command": "cancelPremium",
    "username": "alice22",
    "timestamp": 15
}

{
    "command": "cancelPremium",
    "username": "alice22",
    "timestamp": 15,
    "message": "alice22 cancelled the subscription successfully."
}

Un utilizator poate cumpara subscriptie premium la pretul unic de 1.000.000, care va semnifica cat credit are pentru a plati artisti. La finalul fiecarei rularii, toti utilizatori care sunt premium vor adauga bani in contul artistilor de la care a ascultat. Formula pentru a afla cat primeste fiecare artist este urmatoarea:

unde:

• $val$ = valoarea de bani care se duce la artistul respectiv
• $song_{total}$ = numarul de cantece ascultate de catre userul premium
• $song_{artist}$ = numarul de cantece ascultate de la artistul

Exemplu: Un user premium care a ascultat 10 melodii:

• 3 de la Led Zeppelin
• 5 de la Eminem
• 2 de la Queen

O sa aiba distributia urmatoare a baniilor:

• $ 10^6/10 * 3 $ pentru Led Zeppelin
• $ 10^6/10 * 5 $ pentru Eminem
• $ 10^6/10 * 2 $ pentru Queen

Pentru ca un utilizator free nu plateste deloc ca sa foloseasca aplicatia, va primi la momente predefinite ad-uri. Acestea vor fi adaugate in coada userului atunci cand va aparea comanda “adBreak” de la input. In acest caz, dupa terminarea melodiei curente, utilizatorul va avea de ascultat obligatoriu un ad care este unskippable.

Ad-ul este un cantec definite in library, si ar trebui sa functioneaze la fel ca un cantec normal doar ca nu se poate da skip la el. Totusi, un load il va suprascrie mereu.

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."
• "${username} is not playing any music."
• "Ad inserted successfully."

{
  "command": "adBreak",
  "username": "alice22",
  "timestamp": 15,
  "price": 100
}

{
  "command": "adBreak",
  "username": "alice22",
  "timestamp": 15,
  "message": "Ad inserted successfully."
}

Atunci cand ad-ul intra in player, se vor calcula ultimele melodii ascultate intre ad-ul curent, si ultimul ad primit (sau inceputul istoricului), si artistii ai caror melodii a ascultat acel user vor primii valoarea urmatoare:

unde:

• $val$ = valoarea de bani care se duce la artistul respectiv
• $price_{ad}$ = cat valoareaza ad-ul respectiv
• $song_{last}$ = numarul de cantece ascultate de catre user de la ultimul adBreak pana la adBreak-ul curent
• $song_{artist}$ = numarul de cantece ascultate de la artist

Exemplu: Un user non-premium care a ascultat 5 melodii urmate de un ad, urmate de inca 2:

• 2 de la Led Zeppelin
• 3 de la Eminem
• Ad (cost 500)
• 2 de la Queen

O sa aiba distributia urmatoare a baniilor:

• $ 500/5 * 2 $ pentru Led Zeppelin
• $ 500/5 * 3 $ pentru Eminem
• $ 0 $ pentru Queen, deoarece inca nu a primit un ad care sa plateasca acele piese

Veti avea de implementat un sistem de notificari pentru urmatoarele categorii:

• Playlist:
  • Owner-ul playlist-ului va primi notificare cand cineva se aboneaza la playlist-ul lui
• Creator de continut (Userul primeste notificare pentru orice operatie de mai jos daca este abonat la un Artist/Host):
  • Cand este adaugat un concert (actiune valida doar pentru Artist)
  • Cand este adaugat un album nou / podcast
  • Cand este adaugat merch
  • Cand este adaugat un announcement

Userul se va putea abona la oricare creator de continut, si incepand de la momentul acela el va primii notificari pentru oricare din actiunile enumerate mai sus. Notificarea pentru playlist-uri va fi activata pentru fiecare playlist public by default.

Pentru a se abona la un artist/host, utilizatorul trebuie sa se afle pe pagina artistului/host-ului. Daca utilizatorul va da de 2 ori la rand comanda subscribe pentru un artist/host, el se va dezabona de la acel user.

Mesaje posibile pentru aceasta comanda:

• "The username ${username} doesn't exist."
• "To subscribe you need to be on the page of an artist or host."
• "${username} (subscribed/unsubscribed) (to/from) ${artist/host} successfully."

Fiecare notificare va fi declansata de unul dintre evenimentele descrise mai sus. La adaugarea unui album nou, fiecare utilizator abonat la artistul respectiv va trebui notificat cu un mesaj de forma "New Album: New Album from ${artist}." .

Un utilizator poate sa-si acceseze singur notificarile. O accesare afiseaza toate notificarile, si le sterge, astfel incat la urmatoarea accesare a notificarilor cele deja accesate sa nu mai existe.

Fiecare utilizator normal va primii recomandari pentru melodii si playlist-uri, care vor fi afisate pe HomePage-ul acestuia. Pentru a le reda, utilizatorul trebuie sa primeasca comanda de loadRecommendations.

Output-ul pentru printarea HomePage-ului utilizatorului va avea urmatorul format:

"Liked songs:\n\t[songname1, songname2, …]\n\nFollowed playlists:\n\t[playlistname1, playlistname2, …]\n\nSong recommendations:\n\t[songname1, songname2, …]\n\nPlaylists recommendations:\n\t[playlistname1, playlistname2, …]"

Exemplu :

{
  "user" : "melodicmind42",
  "command" : "printCurrentPage",
  "timestamp" : 150,
  "message" : "Liked songs:\n\t[Rhythmic Revolution]\n\nFollowed playlists:\n\t[]\n\nSong recommendations:\n\t[Rhythm Rise]\n\nPlaylists recommendations:\n\t[]"
}

Recomandarile sunt de 3 tipuri:

• se ia melodia curenta pe care utilizatorul o asculta
• daca utilizatorul a ascultat 30s sau mai mult din melodie, atunci se va cauta o melodie random din acelasi genre
• alegerea random se va baza pe un seed reprezentat de cat a ascultat utilizatorul din melodia curenta

• se va crea un playlist random din melodiile pentru top 3 genre
• top 3 genre se vor determina in functie de cate melodii are utilizatorul din acel gen in
  • melodiile la care utilizatorul a dat like
  • playlist-urile create de utilizator
  • playlist-urile la care utilizatorul a dat follow

• melodiile gasite pentru top 3 genre vor fi DISTINCTE si se vor sorta in functie de numarul de likes al melodiei
• pentru fiecare dintre cele 3 genre-uri se vor selecta:
  • top 5 melodii din primul gen
  • top 3 melodii din al 2-lea gen
  • top 2 melodii din ultimul gen
• numele playlistului va fi de forma
  "${username}'s recommendations"

{
    "command": "updateRecommendations",
    "username": "alice22",
    "timestamp": 165,
    "recommendationType": "random_playlist"
 }

{
  "command" : "updateRecommendations",
  "user" : "alice22",
  "timestamp" : 135,
  "message" : "The recommendations for user alice22 have been updated successfully."
}

• se va crea un playlist pe baza recomandarilor celor top 5 fans
• pentru artistul melodiei curente, se iau top 5 fans
• pentru fiecare fan gasit, se vor lua top 5 melodii din lista de melodii la care utilizatorul a dat like
• melodiile sunt sortate in functie de numarul de likes
• cele top 5 melodii pentru fiecare fan vor fi adaugate la playlist
• numele playlistului va fi de forma
  "${artistName} Fan Club recommendations"

{
    "command": "updateRecommendations",
    "username": "alice22",
    "timestamp": 15,
    "recommendationType": "fans_playlist"
}

{
  "command" : "updateRecommendations",
  "user" : "alice22",
  "timestamp" : 15,
  "message" : "The recommendations for user alice22 have been updated successfully."
}

Mesaje posibile pentru aceasta comanda:

• "No new recommendations were found"
• "The username ${username} doesn't exist."
• "${username} is not a normal user."
• "The recommendations for user ${username} have been updated successfully."

Consideram user-ul alice22 care asculta melodia “Amsterdam” din genre-ul “alternative rock”. Deja au trecut 30s de cand a dat play la melodie. Se primeste comanda de updateRecommendations de tipul random song. Se verifica ca alice22 a ascultat mai mult de 30s din melodie. Se cauta melodiile din genre-ul “alternative rock”. Se alege random una dintre melodiile gasite, unde seed = passedTime din melodia curenta. Aceasta va fi adaugata in recomandarile de melodii ale lui alice22, ce vor fi vizibile si in HomePage-ul acesteia.

{
  "command": "status",
  "username": "alice22",
  "timestamp": 90
},
{
  "command": "like",
  "username": "alice22",
  "timestamp": 130
},
{
  "command": "updateRecommendations",
  "username": "alice22",
  "timestamp": 135,
  "recommendationType": "random_song"
},
{
  "command": "printCurrentPage",
  "username": "alice22",
  "timestamp": 150
}

{
  "command" : "status",
  "user" : "alice22",
  "timestamp" : 90,
  "stats" : {
    "name" : "Amsterdam",
    "remainedTime" : 257,
    "repeat" : "No Repeat",
    "shuffle" : false,
    "paused" : false
  }
}, {
  "command" : "like",
  "user" : "alice22",
  "timestamp" : 130,
  "message" : "Like registered successfully."
}, {
  "command" : "updateRecommendations",
  "user" : "alice22",
  "timestamp" : 135,
  "message" : "The recommendations for user alice22 have been updated successfully."
}, {
  "user" : "alice22",
  "command" : "printCurrentPage",
  "timestamp" : 150,
  "message" : "Liked songs:\n\t[Amsterdam]\n\nFollowed playlists:\n\t[]\n\nSong recommendations:\n\t[Reset Me]\n\nPlaylists recommendations:\n\t[]"
}

Utilizatorul normal va putea asculta ultima recomandare primita prin comanda de loadRecommendations, ce este identica cu cea de load clasic, doar ca in loc de a lua ultima cautare, se va lua ultima recomandare.

Mesaje posibile pentru aceasta comanda:

• "No recommendations available."
• "Playback loaded successfully."
• "${username} is offline."

Un utilizator normal va putea da back/foward la pagini. De fiecare data cand utilizatorul primeste comanda de ChangePage, pagina respectiva va fi adaugata la istoricul de navigare al utlizatorului. Paginile prin care utilizatorul poate naviga sunt cele definite in cadrul etapei II - HomePage, LikedContentPage, ArtistPage si HostPage.

Cand se primeste comanda de

• nextPage - utilizatorul va naviga la urmatoarea pagina din istoric, daca exista
• previousPage - utilizatorul va naviga la pagina anterioara din istoric, daca exista

Mesaje posibile pentru aceasta comanda:

• "There are no pages left to go forward."
• "There are no pages left to go back."
• "The user ${username} has navigated successfully to the next page."
• "The user ${username} has navigated successfully to the previous page."

În rezolvarea etapei 3 veți putea folosi ca punct de pornire soluția oficială a etapei 2, dar vă sfătuim să lucrați pe codul scris de voi pentru a putea înțelege mai repede cum să implementați noile funcționalități fără nevoia de a înțelege principiile și interacțiunile din soluția oficială.

Pentru a întelege mai bine cum funcționează citirea/scrie în fișierele JSON vă recomandăm să citiți Json & Jackson.

În cadrul soluției oficiale este folosit Lombok, un tool care simplifică codul prin eliminarea anumitor segmente explicite, cum ar fi getteri și setteri. Puteți folosi și voi aceste adnotări.

1. Se citesc listele cu useri, melodii si podcast-uri, in format JSON - e facuta deja citirea in schelet.
2. Se citesc comenzile si sunt puse in obiecte.
3. Se primesc secvențial comenzi și se execută pe măsură ce sunt primite.
4. După executarea unei comenzi, se afișează rezultatul ei în fișierul JSON de ieșire.
5. La terminarea tuturor comenzilor se termină și execuția programului.

• Pentru depanarea diferențelor dintre output-ul vostru si fișierele ref, vă recomandăm acest site.
• Verificați periodic această pagină, deoarece scheletul/cerința pot suferi modificări în urma unor erori din partea noastră.

Punctajul constă din:

• 80p implementare - trecerea testelor
• 10p coding style (vezi checkstyle)
• 5p README clar, concis, explicații axate pe design (flow, interacțiuni)
• 5p folosire git pentru versionarea temei

Depunctările pentru designul și organizarea codului se vor scădea din punctajul testelor. Dacă vor apărea depunctări specifice temei în momentul evaluării, nemenționate pe pagina cu depunctări generale, ele se vor încadra în limitele de maxim 15 pentru design, 5p pentru readme. Dacă tema nu respecta cerințele, sau are zero design OOP atunci se pot face depunctari suplimentare.

Folosirea git pentru versionare va fi verificata din folderul .git pe care trebuie să îl includeți în arhiva temei. Punctajul se va acorda dacă ați făcut minim 3 commit-uri relevante și cu mesaj sugestiv. NU este permis să aveți repository-urile de git publice până la deadline-ul hard.

Bonusuri: La evaluare, putem oferi bonusuri pentru design foarte bun, cod bine documentat, dar și pentru diverse elemente suplimentare alese de voi.

Unul din obiectivele temei este învățarea respectării code-style-ului limbajului pe care îl folosiți. Aceste convenții (de exemplu cum numiți fișierele, clasele, variabilele, cum indentați) sunt verificate pentru temă de către tool-ul checkstyle.

Pe pagina de Recomandări cod găsiți câteva exemple de coding style.

Dacă numărul de erori depistate de checkstyle depășește 30, atunci punctele pentru coding-style nu vor fi acordate. Dacă punctajul este negativ, acesta se trunchiază la 0.

Exemple:

• punctaj_total = 100 și nr_erori = 200 ⇒ nota_finala = 90
• punctaj_total = 100 și nr_erori = 29 ⇒ nota_finala = 100
• punctaj_total = 80 și nr_erori = 30 ⇒ nota_finala = 80
• punctaj_total = 80 și nr_erori = 31 ⇒ nota_finala = 70

Arhiva pe care o veţi urca pe VMChecker va trebui să conţină în directorul rădăcină:

• fișierul README.md
• folder-ul src cu pachetele și cu fișierele .java
• folderul .git

• Schelet de cod
• Indicații pentru teme
• Recomandări coding style & javadoc