Closed Katzen48 closed 4 years ago
Hi, thanks for your contribution. I have a few questions: How is the Observer pattern useful in this case? Not sure anyone will actually be needing that, as generally a server will only have one plugin/function acessing that API. Aswell, if we keep that (and the included overhead), please make sure the parent RichPresence object registers itself all the time for new Game/Party objects, not just when they have been null before, aswell as unregisters the old one.
Also, I have to ask you to stick to one code-style across the project please
What I wanted to achieve with the Observer pattern is, to automaticly send updates to the user, to update the Discord Rich Presence. This way, a developer would store all objects and update them, depending on the need.
I updated the code, to (hopefully) match the code style and attach the RichPresence object as an observer for the underlying Party and Game objects Additionally I added some code, to automaticly register an Observer for sending the updates to the player.
As this has been open for > 6 months, I assume there's no interest in merging this and close the pr.
Currently Discord Rich Presence support is only through sending a json object directly. This commit adds classes for Rich Presence, Game, Party and a method for sending in the bukkit and bungeecord implementation.
Every model extends the Observable pattern. You can attach Observers, which will get called, when a value changes.
Automatic updates are implemented not due to a missing general player object.