views:

395

answers:

2

When using in-app audio in the iPhone SDK, it is possible to allow users to select a list from their ipod library and create an in-app local playlist. If I want to persist this choice, it is easy to serialize the data and write to file, then recover.

Just vanilla like this, however, leads me to think there is going to be something wrong. For example, what if the user syncs and removes sounds? I can loop across them all and query the iPod DB at setup time, but with lists that could be 50,000 long, this could take some time.

How are other people doing this and what are some gotchas that I haven't though about?

+3  A: 

I would just do it lazily,

If a user wants to play a song, you could query the iPod DB, for that song in particular and maybe the whole song "Album" in case the user removed the Album. This would require two requests to the database before playing each song, but you could benchmark if it's fast enough, etc.

You could also put an option somewhere to "sync" the application with the iPod DB, but given as a choice for the user, giving the user a "warning" that it could take a while, maybe even giving him a time estimation for the size of his particular library.

I think that from a usability/battery saving point of view, this would be better than querying the whole database each time your application starts, or even in the background.

Mr.Gando
+2  A: 

I initially posted a response around saving the individual MPMediaItems. After some thought and a reread of the documentation for MPMediaPickerControllerDelegate, I think the approach to use is to save the representiveItem property of the MPMediaItemCollection and use that to construct an MPMediaQuery at runtime.

falconcreek