Examples of subscribing for callbacks?

[John Halloran]

Hi; I'm using the Hallon gem to work with collaborative playlists. In general, things are working well, but when the playlists are modified by other processes (i.e. add/delete tracks from the desktop client), my queries of the playlist return stale results. I'm sure that this has to do with the fact that I'm not subscribing to callbacks, but I cannot quite figure out how to do so from the existing documentation. 

Was wondering if anyone has examples that show an implementation including subscribing to callbacks?

[Kim Burgestrand]

On Thursday, February 14, 2013, John Halloran via Hallon wrote:

Hi; I'm using the Hallon gem to work with collaborative playlists. In general, things are working well, but when the playlists are modified by other processes (i.e. add/delete tracks from the desktop client), my queries of the playlist return stale results. I'm sure that this has to do with the fact that I'm not subscribing to callbacks, but I cannot quite figure out how to do so from the existing documentation. 

Was wondering if anyone has examples that show an implementation including subscribing to callbacks?

Most callbacks in libspotify do not fire on their own. Instead, they fire as a direct result of calling Session#process_events (so the call to process_events does not finish until all callbacks handlers have finished). One of the few aynchronous (i.e. happens in another thread) events is notify_main_thread. When it fires, the application should call Session#process_events from the main thread, because libspotify might need to do some internal work (such as downloading new data).

You can call Session#process_events whenever you want. Sometimes libspotify will have nothing to do when calling it, but there are no other downsides than a wasted call. Considering the notify_main_thread callback is not always called (or called fast enough), it's often better to just call process_events from time to time, when you have nothing else to do. This is what #load does on loadable objects, for example.

So, make sure to call #process_events from time to time, and you'll eventually receive updates from other clients.

As far as an example goes I can't write one at the moment (writing this from a mobile device), but I can link you the relevant documentation which contains some minimal examples: http://rdoc.info/github/Burgestrand/Hallon/Hallon/Observable/Playlist — for information on what callback is what, do look at the official libspotify documentation: https://developer.spotify.com/technologies/libspotify/docs/12.1.45/structsp__playlist__callbacks.html

--
Kim Burgestrand

[John Halloran]

Thanks, Kim. Calling 'process_events' does seem to get me back into sync with changes made to the the playlist.

Now my question is whether or not there is any way to determine how many times I should call 'process_events'.

It seems that multiple calls are required in order to get a playlist back into sync, but I'm not sure how to figure out how many calls are needed, or when the queue or events has been cleared.

The return value of 'process_events' seems a bit opaque as well, as it seems that it needs to be called repeatedly to clear a queue of events.... Any guidance here would be appreciated!

--
You received this message because you are subscribed to the Hallon ruby gem mailing list.

- To view this group online, visit https://groups.google.com/d/forum/ruby-hallon
- To post to this group, send email to ruby-...@googlegroups.com
- To unsubscribe from this group, send email to ruby-hallon...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "Hallon" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-hallon...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kim Burgestrand]

On Thursday, 14 February 2013 at 17:22, Hallon on behalf of John Halloran wrote:

Thanks, Kim. Calling 'process_events' does seem to get me back into sync with changes made to the the playlist.

Now my question is whether or not there is any way to determine how many times I should call 'process_events'.

Not as far as I know. In theory, there is no guarantee that the queue will ever be cleared, so process_events should

be called continuously throughout your application. The only reason for you to not call it is when you have something

else to do, such as your application logic!

 

It seems that multiple calls are required in order to get a playlist back into sync, but I'm not sure how to figure out how many calls are needed, or when the queue or events has been cleared.

I’d believe this would involve listening to a few callbacks (e.g. playlist_update_in_progress), but there’s also

a chance that nothing has happened to the playlist since last time you waited for changes, so simply waiting for the

callback forever is not a good solution either. libspotify is really written with you having a GUI in mind, that updates as

events are called from libspotify, where the time until a playlist loads or syncs does not matter.

 

The return value of 'process_events' seems a bit opaque as well, as it seems that it needs to be called repeatedly to clear a queue of events.... Any guidance here would be appreciated!

My best guess would be that the return value of process_events is simply a timer with exponential backoff. If process_events

end up doing nothing, the recommended time until the next call will increase, up until a maximum of one minute. Most likely

there is some arbitrary counter inside process_events that decides how many of the known events are allowed to be processed

before libspotify will allow you to do other work inbetween.

I’m sorry, but I don’t have a better answer for you other than speculations!

— Kim