NFC场景下CreateNdefMessageCallback与CreateBeamUrisCallback有何区别？

核心区别梳理 #

1. 支持的数据类型不同 #

• CreateNdefMessageCallback：专注于生成NDEF格式消息，可以封装任意符合NDEF规范的数据——包括文本、URI、自定义MIME类型数据，甚至是多个NDEF记录组合的复杂结构，灵活性拉满，适合自定义或非标准化的数据传输场景。
• CreateBeamUrisCallback：仅用于发送URI列表，是系统专为URI传输设计的简化回调，只能处理Uri对象集合，适合直接分享网页链接、本地文件路径这类标准URI资源的场景。

2. 使用场景差异 #

• 用CreateNdefMessageCallback的情况：需要发送非URI的自定义数据（比如结构化文本、二进制数据），或者要精确控制NDEF消息的内部结构（比如多记录组合）。
• 用CreateBeamUrisCallback的情况：只需要快速分享一个或多个URI，系统会自动完成NDEF消息的封装，无需手动构建NDEF结构，代码更简洁。

3. 实现复杂度不同 #

• CreateNdefMessageCallback：需要手动构建NdefMessage对象，涉及创建NdefRecord、处理不同类型的记录封装，代码相对繁琐。示例：

@Override
public NdefMessage createNdefMessage(NfcEvent event) {
    String customText = "这是自定义文本数据";
    NdefRecord textRecord = NdefRecord.createTextRecord("zh", customText);
    return new NdefMessage(new NdefRecord[]{textRecord});
}

• CreateBeamUrisCallback：只需返回Uri列表，系统自动完成NDEF消息的生成，代码极简。示例：

@Override
public List<Uri> createBeamUris(NfcEvent event) {
    Uri targetUri = Uri.parse("https://example.com");
    return Arrays.asList(targetUri);
}

4. 接收端处理逻辑不同 #

• 用CreateBeamUrisCallback发送的URI，接收端系统会自动识别并触发对应应用打开（比如网页链接唤起浏览器，文件URI唤起文件管理器）；
• 用CreateNdefMessageCallback发送的自定义NDEF消息，需要接收方自行解析消息内容，处理逻辑更灵活但需要额外的自定义解析代码。

如果你之前只用过CreateNdefMessageCallback，在纯URI分享场景下切换到后者能大幅简化开发流程，无需手动处理NDEF记录的封装工作。

内容的提问来源于stack exchange，提问作者Fatimah