口袋PC的MP3播放器项目开发详解

### 口袋 PC 的 MP3 播放器项目开发详解 #### 1. JavaCheck 分析 在开发应用程序时，我们可以在当前工作目录下执行命令来分析该目录中的所有类文件。这与图形版本的效果相同，但在应用程序开发过程中，如果需要定期运行，这种方式会更加便捷。以下是一个示例的最终总结输出： ```plaintext 5 classes were loaded. JavaCheck: 82 dependencies were analyzed, JavaCheck: 0 dependencies were Unsupported, JavaCheck: 5 dependencies were Optionally implemented, JavaCheck: 1 dependency was Modified, JavaCheck: 16 dependencies were Unresolved, JavaCheck: 60 dependencies were OK. 5 error(s), 17 warning(s) found. The class files DO NOT CONFORM to the specified platform. ``` 我们真正需要关注的是不支持（Unsupported）和未解析（Unresolved）的类。在这个例子中，没有不支持的类，所以如果要将应用程序移植到 pJava 平台，就需要查看未解析的类，即 Java Check 无法解析的类。 #### 2. 项目介绍 我们要开发的应用程序是一个 MP3 播放器的远程控制器（它也可以播放其他音频格式）。该远程控制应用程序将使用 pJava 配置文件为 CDC 设备（如 Pocket PC）编写。虽然这可能不是典型的商业应用程序，但它展示了在手持设备上工作所需的许多技术，并且其操作模式非常灵活，可轻松应用于许多其他应用程序。 应用程序本身非常简单，它使用了 Java 媒体框架（JMF），可以从 [Sun 的官网](http://www.javasoft.com/products/jmf) 下载，该网站还提供了安装说明。应用程序会获取一个目录，并列出该目录中的所有文件，假设这些文件都是音频文件，然后开始播放第一个文件，同时为用户提供一个基本的用户界面。远程控制器应能够向用户显示当前目录中的曲目列表，允许用户暂停和继续播放、跳转到下一首和上一首曲目，以及从列表中选择特定的曲目进行播放。 网络通信将通过 TCP/IP 进行，但应进行隔离，以便轻松转换到其他网络系统，如红外（IR）或蓝牙（Bluetooth）。所有网络通信都由客户端驱动，客户端向服务器发送请求。这对于功能有限的设备非常重要，因为如果设计一个服务器期望客户端始终可用的应用程序，虽然 CDC 设备能够进行多任务处理并运行后台任务，但给有限的设备增加额外的处理任务是不明智的。 #### 3. 工作原理 首先，我们需要定义用于通信的协议。虽然有许多标准协议可供选择，但我们将定义自己的协议。遵循标准通常很有用，但任何标准协议在灵活性上的提升都会被效率上的成本所抵消。根据应用程序的需求，你可能希望使用 HTTP 或类似协议以方便通过防火墙等，但这会显著增加网络处理负载，而我们希望将其保持在最低水平。 因此，我们将使用尽可能基本的协议，以最小化网络流量并降低客户端的处理需求。由于客户端将发起所有通信，服务器将监听一个套接字，等待客户端连接。我们需要选择一个合适的套接字，任何大于 1000 的数字都可以（小于 1000 的数字保留给标准定义的协议），这里我们选择 1710 作为一个合理的随机数。 客户端可以执行以下需要与服务器交互的任务： - 播放下一首曲目 - 播放上一首曲目 - 播放第一首曲目 - 播放最后一首曲目 - 获取曲目列表 - 播放第 n 首曲目（n 为列表中的曲目编号） - 暂停播放 - 继续播放 为了减少网络使用，我们可以将这些任务对应的消息简化为： - Next - Previous - First - Last - Track listing - Play n - Pause - Resume 虽然可以进一步将上述消息简化为单个字符以提高带宽使用效率，但这会增加创建和调试的复杂性。为了便于开发，最好将协议命令保持为人类可读的形式。 由于通信由客户端发起，当客户端连接到服务器时，服务器应发送第一条消息，以便客户端确定服务器已准备好接收命令。因此，我们决定服务器对初始连接的响应为 +OK。服务器响应通常以 + 或 - 开头，这样客户端可以通过检查第一个字符来判断通信是否成功，而无需查看整个消息。 当客户端发起连接，服务器响应 +OK 后，客户端发送上述命令之一，服务器会响应表示命令已执行。将响应与一些有用信息结合起来是有意义的，在这种情况下，以以下格式返回当前正在播放的曲目名称： ```plaintext +OK Playing Track track name ``` 除了暂停（pause）和曲目列表（track listing）命令外，所有命令的响应都遵循上述格式。暂停命令的响应为 +paused，曲目列表命令的响应为当前加载曲目的完整列表，格式如下： ```plaintext +Listing Follows track name 1 track name 2 track name 3 . ``` 注意，列表以单独一行的单个句号结尾，这是终止未知长度列表的标准方式。这个列表的长度与服务器加载的曲目数量相同。只有当有一首曲目名为 . 时才会出现问题，但这不仅不太可能，而且由于曲目名称基于文件名，在大多数个人计算机系统上实际上是不可能的。 我们还将添加一个状态（status）命令，该命令仅返回当前正在播放的曲目，以便客户端根据请求显示当前播放的曲目。 我们还需要确定命令和响应的大小写。这很重要，因为如果不明确指定，可能会在后续导致难以发现的问题。与许多现代协议一样，我们将协议定义为不区分大小写，即可以使用任意大小写字符的组合。这会增加一些处理开销，但可以避免后续问题。 定义好协议格式后，最好进行一次模拟运行，用笔和纸记录典型的客户端 - 服务器通信过程，以确保我们理解将要发生的事情，并为测试应用程序提供一些示例。以下是一个使用包含 MP3 文件的目录进行客户端和服务器通信的示例： | 客户端 | 服务器 | | --- | --- | | Open Connection | +OK | | Track Listing | +Listing Follows <br> EMF – You're Unbelievable <br> Babylon Zoo – Spaceman <br> Men Without Hats – Security <br> Men Without Hats – On Tuesday <br> Petula Clarck – Downtown <br> . | | Close Connection | | | Open Connection | +OK | | Status | +Playing Track EMF – You're Unbelievable | | Close Connection | | | Open Connection | +OK | | Next | +Playing Track Babylon Zoo – Spaceman | | Close Connection | | | Open Connection | +OK | | Previous | +Playing Track EMF – You're Unbelievable | | Close Connection | | | Open Connection | +OK | | Last | +Playing Track Petula Clark – Downtown | | Close Connection | | | Open Connection | +OK | | First | +Playing Track EMF – You're Unbelievable | | Close Connection | | | Open Connection | +OK | | Play 3 | +Playing Track Men Without Hats – Security | | Close Connection | | | Open Connection | +OK | | Pause | +Paused | | Close Connection | | | Open Connection | +OK | | Resume | +Playing Track Men Without Hats – Security | | Close Connection | | 这个表格展示了所有可能的命令和响应。我们可以进一步定义可能返回的各种错误消息以及如何处理它们，但最好先开始开发，看看会出现哪些问题。由于该系统允许客户端通过基于离散事务的通信（每个命令一个连接）来控制服务器，任何错误都将通过关闭网络连接并重新开始来处理。 服务器每个连接只接受一个命令，每个事务只能执行一个操作。我们需要考虑为什么做出这样的限制以及在什么情况下这种限制不合适。我们的应用程序旨在让客户端应用程序控制服务器上的功能，是一种严格的“控制”关系。将每个命令作为一个单独的连接会增加相当大的开销，但会使客户端和服务器更加简单，并且更容易进行错误恢复。因为每个事务都是独立的，所以任何单个事务失败都可以通过重复该事务来修复。 虽然这种操作模式并非适用于所有情况，但有些应用程序可能需要客户端和服务器之间进行连续通信，并通过保持连接打开来节省资源。在许多情况下，这种简单性和健壮性胜过资源成本。值得注意的是，HTTP 和所有基于 Web 的接口都采用了这种模式。 以下是服务器和客户端应用程序的流程图： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px; A([开始]):::startend --> B(监听端口 1710):::process B --> C{是否有客户端连接?}:::decision C -- 是 --> D(发送 +OK):::process D --> E(接收客户端命令):::process E --> F{命令是否有效?}:::decision F -- 是 --> G(执行命令):::process G --> H(发送响应):::process H --> I(关闭连接):::process I --> C F -- 否 --> J(发送错误响应):::pro ```