跨会话持久保存 iPod 播放列表 (MPMediaItemCollection) 的最佳实践答案

【问题标题】：Best Practices for persisting iPod Playlist (MPMediaItemCollection) across sessions跨会话持久保存 iPod 播放列表 (MPMediaItemCollection) 的最佳实践
【发布时间】：2010-04-21 05:33:00
【问题描述】：

在 iPhone SDK 中使用应用内音频时，可以允许用户从他们的 ipod 库中选择一个列表并创建一个应用内本地播放列表。如果我想坚持这个选择，很容易序列化数据并写入文件，然后恢复。

然而，像这样的香草让我认为会有什么问题。例如，如果用户同步和删除声音怎么办？我可以遍历它们并在设置时查询 iPod DB，但是对于可能有 50,000 长的列表，这可能需要一些时间。

其他人是如何做到这一点的，还有哪些我没有想到的问题？

【问题讨论】：

为什么会有人希望在应用程序中拥有如此庞大的播放列表？就个人而言（作为用户），我更喜欢 iPod 应用程序来管理我的播放列表，我唯一想要访问的是播放器控件和当前播放列表的可视化。如果我有一个播放列表，例如在我的 GPS 跟踪应用中，它可能会很短 (>100)。
MPMediaPickerController 返回一个集合。集合中的项目数可能是整个库。
我同意，它很可能很短。但我需要涵盖所有基础。如果允许用户从 ipod 应用程序中选择一个预设播放列表，它可能是“所有歌曲”播放列表。我需要涵盖这个潜在的选择。
正是我建议使用representativeItem 来构建查询的原因。 “理论上”如果选择“所有歌曲”播放列表，查询将返回“所有歌曲”。您只需要处理查询不返回任何内容的情况。

标签： iphone mpmediapickercontroller mpmediaitemcollection

【解决方案1】：

我会偷懒的，

如果用户想要播放一首歌曲，您可以查询 iPod DB，尤其是该歌曲，也可能是整首歌曲“专辑”，以防用户删除专辑。这将需要在播放每首歌曲之前向数据库发出两次请求，但您可以对它是否足够快等进行基准测试。

您还可以在某处使用iPod DB 将选项设置为“sync”应用程序，但作为用户选择，给用户一个“警告”，它可能需要一段时间，甚至可能给他对他的特定图书馆的大小进行了时间估计。

我认为从可用性/电池节省的角度来看，这比每次启动应用程序时查询整个数据库要好，甚至在后台查询。

【讨论】：

【解决方案2】：

我最初发布了关于保存单个 MPMediaItem 的回复。经过一番思考和重新阅读MPMediaPickerControllerDelegate 的文档后，我认为使用的方法是保存MPMediaItemCollection 的representiveItem 属性，并在运行时使用它来构造MPMediaQuery。

【讨论】：