Implement Previous and Next Track buttons on lock screen media player controls

[KeithBoynton]

I need access to the Previous and Next track commands from the lock screen (and via bluetooth connected devices) when media is playing via the MediaElement.

Previously I had this implemented on iOS using MPRemoteCommandCenter like this:

RemoteCommandCenter.NextTrackCommand.Enabled = true;
RemoteCommandCenter.PreviousTrackCommand.Enabled = true;

RemoteCommandCenter.NextTrackCommand.AddTarget(this, new Selector("nextTrackCommand:"));
RemoteCommandCenter.PreviousTrackCommand.AddTarget(this, new Selector("previousTrackCommand:"));

[Export("nextTrackCommand:")]
MPRemoteCommandHandlerStatus NextTrack(MPRemoteCommandEvent ev)
{
    ViewModel.Next();
    return MPRemoteCommandHandlerStatus.Success;
}

[Export("previousTrackCommand:")]
MPRemoteCommandHandlerStatus PreviousTrack(MPRemoteCommandEvent ev)
{
    ViewModel.Previous();
    return MPRemoteCommandHandlerStatus.Success;
}

[ne0rrmatrix]

We would want to create this for all devices. So Mac, iOS, windows and android. Are you interested in doing all of that? Or would you be more interested in doing the IOS part and have someone else do the other platforms?

[KeithBoynton]

No definitely all platforms, my app runs on all those platforms

[KeithBoynton]

So let me put a bit of context to what I need from it so we can discover the best way to implement.

My app has a couple of playlists, only 1 of which would play at any one time. It's lists of short previews of music tracks that users can listen to. They can either just let it play and it plays a bit of each tracks and automatically moves to the next track until it reaches the end of the list. So that would be the passive way of doing it.

Inside the app users can also just click next/previous and it does the obvious. When a user clicks next (or it gets to the end of the track) it marks that track as listened and moves on.

This is all implemented and working using custom buttons so the MediaElement itself is hidden (no video anyway).

The tracklists are implemented in two different CollectionViews and each of the tracks in the collections have a lot more info than just the artist, title, art and url that are not relevant to the media player. Users can manipulate those playlists quite substantially and often.

The reason I'm giving you this context is because I think you were suggesting to use a Playlist feature because that would mean a lot of the stuff is handled already which does make sense. With this I think you were talking about some built in Playlist that is associated with a media session or something like that.

When a user clicks the Next Track button on the lock screen controls the following would need to happen:

1. The cursor of the list would need to be updated
2. The track would need to be marked as listened

Also when the playlists in the app are changed (which they are often) that would need to be synched to the platform session playlist (if I understood you correctly).

Just as a bit of additional info, it's unlikely users would use the lock screen controls that much it's more the bluetooth control that comes with it that I've found users really use. So listening in the car for instance or using bluetooth headphones with next/previous buttons on them.

Hopefully that makes sense!?!

[ne0rrmatrix]

Yes that does make sense. But I believe we should leave implementing the playlist up to the developer and just wire up the ability to add items or remove items. The player has built in playlist support. Managing it should be a developer choice. We should let each dev implement it themselves.

[KeithBoynton]

Absolutely, but when you say wire up the ability to add/remove items, which playlist do you mean. For instance my app already has playlists and already has the ability to add/remove items. I imagined if we were to use the built in playlist support then it's got it's own playlist and we would need to keep app playlist and the built in playlist in sync or am I missing something?

[ne0rrmatrix]

Well if you add more than single item to the player in all of the devices it maintains an internal playlist that you can add/remove items. There is a bunch of stuff you can do with that. It is an internal playlist.

[KeithBoynton]

Yeah that's what I thought, maybe I wasn't explaining it very well.

So then we would need to bear this in mind with my particular requirements:

1. When a next/previous track is selected it would need to update the listened state of the last played track and the app cursor position of the current playing track
2. There are two playlists and users can/do switch between them often
3. A playlist can have up to 30,000 tracks on it (more realistically it would be about 3000)
4. When new tracks are added to a playlist it's usually a range and they are inserted in the current sort order so depending on the current sort order they could be added all over the place
5. When tracks are removed from a playlist again it could be a range spread across the collection

Number 1 is probably quite easily solved maybe using an event (eg. onNextTrackStarted) if the clicking and playing is all handled internally by the player.

The rest I think depends on what the performance would be like. This is why I was talking about the problem of keeping another (internal) playlist in sync with the app one.

For these requirements I wonder if it would not make more sense just to have delegates for the buttons like in the MPRemoteCommand example.

Thoughts?

[KeithBoynton]

Thinking about it a little more... maybe you wouldn't need to maintain the whole playlist in the internal one - just the previous track and the next one and as it progresses you just remove from the beginning and add to the end (and visa versa the other way)

[imadofficial]

While we're on the topic of MediaElement here, can someone make an event to invoke whenever the actual player gets paused? Since right now, whenever I pause the song through the lockscreen (iOS) it wouldn't update properly in-app.

[KeithBoynton]

That should already raise a PlayStateChanged event, with a state of "paused". I certainly see that