3

i read the msdn overview on Background audio and took a look at the example app but I'm a little bit confused about messages and the data that could be exchanged through them. 

ValueSet messageDictionary = new ValueSet();
messageDictionary.Add("key", "value");
BackgroundMediaPlayer.SendMessageToBackground(messageDictionary);

The new introduced object ValueSet with KeyValuePairs(string, object) has to be used for communication between foreground and background task.
I would like to send instances of custom classes (let's say Audiofiles containing Artist, Album, Filepath, etc. of an medialibrary) to the background task. Unfortunately that is not possible (=>Exception, type not supported) - it seems that only primitive values are allowed.

Of course, a possibility would be to serialize the data. Does anyone know an easier way, or Microsoft's recommended way?

====================================
UPDATE:
Only possible way seems to
(i) serialize the data and send it via the messages
(ii) store the data in a file and communicate the background task to process them

nevertheless, I would be grateful for any recommendations to this topic :-)

formatC
  • 83
  • 6

2 Answers2

1

You can send all data in string format and switch keys in MessageReceivedFromForeground handler in background task. Very simple and usefull example is found here: http://mark.mymonster.nl/2014/05/02/windows-phone-81ndashbackground-audio-in-windows-phone-store-apps

alixey
  • 11
  • 1
0

[Oops 1 year later...]

The architecture I use is a combination of the two methods you mentioned and a third one, I use:

  • 1 serialized communication class object
  • 1 database file
  • Few settings (current track, to be able to resume it in case of suspended app)

My fore-back messages always have the same structure:

  • a key that is always the same; and
  • a value that is a serialization of a communication object

This communication object includes an Action Enum value (that is why there is no need for different keys, it is easier to handle that way), and all the basic information required is contained within the communication object It works quite well, as long as you don't have much information to exchange between back and foreground, serialization performance shouldn't be a problem. It could probably be optimized however I am not sure it worth it.

The second part of the communication is a file that works like a database for the playlist, and is only written from the foreground. That allows to simplify the data sent, without concurrent writing issues. In your case this file would contain a serialized xml of the next songs to play, with all relevant information, and the message would only contains an id of this song to find it in the list.

Jean
  • 4,911
  • 3
  • 29
  • 50