Hi there!
I'm working on an Apple Music client and stuck on creating the now playing screen. I've set up all the buttons but struggling to observe the value of playbackTime to update the current playback time label and the progress bar accordingly.
Like you can observe the value of playbackRate and playbackState by making the player's state value as an @ObservedObject, how can I observe this value?
Thanks in advance!
Hello @snuff4,
Indeed, in iOS 15, playbackTime is not part of an object which conforms to ObservableObject, such as the player's state, and that is very much intentional.
As we were designing these new APIs, we were very concerned with having a property like playbackTime, which can change at a very high rate when the player is actually playing music, alongside other data such as the entries of the ApplicationMusicPlayer's queue, which people might want to observe to power complex UI, and which typically only changes every few minutes or so.
Our current recommendation is for you to setup a long running animation for the playback head based on the initial value of playbackTime, and the playbackRate; you should probably reset the animation whenever the playbackStatus changes (both playbackRate and playbackStatus are actually observable). Besides, it's likely that a long running animation will lead to smoother UI updates for the position of the playback head.
While I think developers can probably make do with this recommendation for the time being, I also think we should consider having an explicit supported mechanism for observing playbackTime; we have a few ideas on how it could be exposed. But I would encourage you to file a ticket on Feedback Assistant to explain why you would benefit from having such an API, so we can prioritize this task appropriately.
I hope this helps.
Best regards,
Hello @snuff4,
Indeed, in iOS 15, playbackTime is not part of an object which conforms to ObservableObject, such as the player's state, and that is very much intentional.
As we were designing these new APIs, we were very concerned with having a property like playbackTime, which can change at a very high rate when the player is actually playing music, alongside other data such as the entries of the ApplicationMusicPlayer's queue, which people might want to observe to power complex UI, and which typically only changes every few minutes or so.
Our current recommendation is for you to setup a long running animation for the playback head based on the initial value of playbackTime, and the playbackRate; you should probably reset the animation whenever the playbackStatus changes (both playbackRate and playbackStatus are actually observable). Besides, it's likely that a long running animation will lead to smoother UI updates for the position of the playback head.
While I think developers can probably make do with this recommendation for the time being, I also think we should consider having an explicit supported mechanism for observing playbackTime; we have a few ideas on how it could be exposed. But I would encourage you to file a ticket on Feedback Assistant to explain why you would benefit from having such an API, so we can prioritize this task appropriately.
I hope this helps.
Best regards,
Hi @JoeKun,
Thank you for your detailed answer! Much appreciated.
So, if I've to show the current duration in a label, I should probably have a timer running with the initial value of playbackTime? And then, whenever the playbackStatus changes, update the current duration value with the latest playbackTime and refresh the view?
I think I can do with this approach for the time being. But having playbackTime as an observable value will make it much much simpler. So, I'll file a ticket for this.
Thank you so much!
HI @snuff4,
Yes, exactly. As you said, for your use-case, you will also have to use a timer to update the label.
We just have to find a good way to expose the playbackTime as some kind of observable value that doesn't cause performance problems with other parts of the app that observe other properties which get updated much less frequently.
Thanks for taking the time to file a ticket for this!
Best regards,
