Why should Core#runCallbacks be run this often?

[Desoroxxx]

Currently I run Core#runCallbacks each 16ms like in the example of the java-impl branch, but why?
I get that some info can change, but I don't see any scenarios where having this much up to date info would be necessary or even useful.

Am I missing something?

Just to be clear I am not really concern about performance it most certainly doesn't matter, I am just weirded out by how often this would run for what it does

[JnCrMx]

Hi,

the library roughly follows the architecture of Discord's official library, which is designed as a callback based async library with some sort of event loop.

The RunCallbacks function is at the core of this architecture and basically receives new data from Discord and executes registered callbacks accordingly.
Discord has most likely chosen this architecture, because it works well with games. There are no blocking calls, and runCallbacks can simply be executed in the game's main loop and also does not block (as long as none of the registered callbacks block).

So for example, if you set a user activity (through the ActivityManager) the request gets sent to Discord over IPC. Discord then processes the request. However, while Discord is still processing, the updateActivity method completes already (due to its asynchronous design). Once the request has been processed, Discord replies via IPC. This reply gets read/received within the next runCallbacks call and the registered callback is executed accordingly.

In the Java implementation, each of the runCallbacks calls does the following:

• receive a message from the IPC socket (non-blocking; if there is no new message, the method simply returns)
• parse the message
• if the message is an event, execute the registered event handler
• if the message is a reply to a previously issued command (indicating failure or success), execute the registered callback

Therefore, it is required to regularly execute this method, so you won't miss any responses or events.
You can always run the runCallbacks function less frequently, however this will result in you receiving events later (or possibly missing events) and your callbacks getting executed a significant amount of time after the call has been completed.
Depending on your application (i.e. if you need to chain a lot of Game SDK function calls together) this might or might not be acceptable.

For other applications, this architecture might end up being a little cumbersome, especially if there is no existing event loop. The easiest way to deal with that, is just to spin up a new thread and simulate an event loop that way.

[Desoroxxx]

Thanks, I get it now.