客户端-服务器架构：100% Android（Android 作为服务器）还是 Java EE+Android？
Client-Server architecture: 100% Android (Android as a server) or Java EE+Android?
上下文
我正在考虑采用 Java 的客户端-服务器架构。这个想法是几个 Android 平板电脑（假设大约 15 个）需要显示来自服务器的内容。内容可能会随时间变化（例如白天显示 v/s 夜间显示）。此外，平板电脑还会显示 Yes / No（或绿色/红色）按钮加上 free-text 评论字段。
每天收集评论并通过电子邮件发送报告。
于是就有了双向通信：
- 服务器发送到客户端的内容显示，内容可能会更新
- 客户端发送反馈给服务器 (
Yes / No + 自由文本 )
我试图寻找最佳实践，但我无法得到准确的答案，因为人们相当假设 server/client 架构会导致 J2EE-Android Java 编程。
这是我的问题：[哪种] 以下解决方案是最佳实践？
解决方案 1：100% Android。另一台平板电脑充当服务器，
集中显示内容并收集反馈。
这台平板电脑识别日期评论并通过邮件发送。
服务器只需要额外的一台平板电脑。没有真正的服务器编码。
解决方案 2：经典 Java EE/Android 架构。它需要一个额外的服务器单元（租用一个虚拟服务器或购买一个物理服务器）和额外的编程，但可以提供 JSP 个页面，以便 Web 应用程序显示评论。
专用服务器似乎更强大。然而，有越来越多的强大
现在平板电脑。
解决方案 3：非 Java EE（例如 C#，PHP) + Android架构。
我真的没有在这里看到任何 'Android' 特定的东西。我想你不应该束缚自己。
我认为您的第一个解决方案（将平板电脑用作服务器）不适合该任务。它不可扩展，甚至不够稳定。平板电脑不是真正的服务器。您将失去使用为服务器可用性、性能监控等发明的所有工具的可能性。
所以，当然，你应该在那里有一个单独的服务器。但它不一定是 J2EE。它可以是简单的 Netty 服务器一段时间。或者 ZeroMQ 一个。
在任何情况下，您都不应该将自己束缚在 'android' 上。与服务器的所有交换都应该使用通用和简单的格式来完成。以 JSON 为例。因此，如果您使用的格式支持布尔类型，无论您的客户理解什么，都不要将布尔字段作为 'Y'/'N' 值发送。为此使用布尔类型。
问：以下哪种解决方案 [1) 2) 3) ] 是最佳实践？
A: 价格方面/时间方面/性能方面 1) 但一旦从 1:15 答案摘要中移动，可扩展性方面可能会遇到问题一天到一些 1:1.000.000 或 1:10.000.000 范围。
ZeroMQ 将是我的首选。它拥有您身边所有最强大的部分{价格方面/时间方面/性能方面}以及可扩展性和性能以及快速原型制作方面。
话虽如此，您不会花费一个人*天的精力来构建任何东西，而是构建完成任务所需的功能。 ZeroMQ 在智能消息传递端完成剩下的工作。它创建（好吧，它已经创建了）一个框架（而不是一组低级元素）。
在此框架之上构建可让您专注于您的主要目标 - 服务（而不是支持元素的低级细节）。
因此你可以从性能扩展中抽象出来（ZeroMQ 允许你重新使用设计者的知识，他们已经购买了所有必要的东西，包括对故障恢复、自我修复和性能可扩展场景，无需重新设计您的顶级服务。
这绝对值得顶级 class 专家数百万*天的努力，您几乎没有预算和时间来（重新）花钱来接近您的目标在 ZeroMQ 框架中为您的项目中的高级任务做好准备。
如果您的规模经济适用于 15 台平板电脑（用户）Android UI（这意味着您必须掌握 Android 无论如何），去熟悉 ZeroMQ，因为重新使用它的绑定来匹配和去（许多绑定可用并且已经稳定多年用于许多（如果不是全部）其他生产级语言（Ada， C、C#、C++、Erlang、F#、FORTRAN、Go、java、LISP、Node.js、pascal、perl、PHP、Python、Objective-C Scala、Smalltalk ... 仅举几例）因此，您在该领域的智力投入 将在进一步的项目中得到回报 ，而不是在没有任何投资回报率的情况下获得赤裸裸的曝光在那 ).
下一个最佳步骤是什么？
我的建议是花时间阅读 Pieter HINTJENS 的书 "Code Connected, Volume 1"。 Pieter 是 ZeroMQ 框架的创始人之一，他分享了很多关于如何在分布式、容易出错的进程到进程消息传递环境中生存的见解。确实值得将时间花在他的伟大见解上。
诺塔贝内
问：您是否定义了您的最佳实践的指标？
答： 不。这可能（并且将）扭曲您可能期望收到的答案。
上下文
我正在考虑采用 Java 的客户端-服务器架构。这个想法是几个 Android 平板电脑（假设大约 15 个）需要显示来自服务器的内容。内容可能会随时间变化（例如白天显示 v/s 夜间显示）。此外，平板电脑还会显示 Yes / No（或绿色/红色）按钮加上 free-text 评论字段。
每天收集评论并通过电子邮件发送报告。
于是就有了双向通信：
- 服务器发送到客户端的内容显示，内容可能会更新
- 客户端发送反馈给服务器 (
Yes/No+ 自由文本 )
我试图寻找最佳实践，但我无法得到准确的答案，因为人们相当假设 server/client 架构会导致 J2EE-Android Java 编程。
这是我的问题：[哪种] 以下解决方案是最佳实践？
解决方案 1：100% Android。另一台平板电脑充当服务器，
集中显示内容并收集反馈。
这台平板电脑识别日期评论并通过邮件发送。
服务器只需要额外的一台平板电脑。没有真正的服务器编码。解决方案 2：经典 Java EE/Android 架构。它需要一个额外的服务器单元（租用一个虚拟服务器或购买一个物理服务器）和额外的编程，但可以提供 JSP 个页面，以便 Web 应用程序显示评论。
专用服务器似乎更强大。然而，有越来越多的强大 现在平板电脑。解决方案 3：非 Java EE（例如
C#，PHP) + Android架构。
我真的没有在这里看到任何 'Android' 特定的东西。我想你不应该束缚自己。
我认为您的第一个解决方案（将平板电脑用作服务器）不适合该任务。它不可扩展，甚至不够稳定。平板电脑不是真正的服务器。您将失去使用为服务器可用性、性能监控等发明的所有工具的可能性。
所以，当然，你应该在那里有一个单独的服务器。但它不一定是 J2EE。它可以是简单的 Netty 服务器一段时间。或者 ZeroMQ 一个。
在任何情况下，您都不应该将自己束缚在 'android' 上。与服务器的所有交换都应该使用通用和简单的格式来完成。以 JSON 为例。因此，如果您使用的格式支持布尔类型，无论您的客户理解什么，都不要将布尔字段作为 'Y'/'N' 值发送。为此使用布尔类型。
问：以下哪种解决方案 [1) 2) 3) ] 是最佳实践？
A: 价格方面/时间方面/性能方面 1) 但一旦从 1:15 答案摘要中移动，可扩展性方面可能会遇到问题一天到一些 1:1.000.000 或 1:10.000.000 范围。
ZeroMQ 将是我的首选。它拥有您身边所有最强大的部分{价格方面/时间方面/性能方面}以及可扩展性和性能以及快速原型制作方面。
话虽如此，您不会花费一个人*天的精力来构建任何东西，而是构建完成任务所需的功能。 ZeroMQ 在智能消息传递端完成剩下的工作。它创建（好吧，它已经创建了）一个框架（而不是一组低级元素）。
在此框架之上构建可让您专注于您的主要目标 - 服务（而不是支持元素的低级细节）。
因此你可以从性能扩展中抽象出来（ZeroMQ 允许你重新使用设计者的知识，他们已经购买了所有必要的东西，包括对故障恢复、自我修复和性能可扩展场景，无需重新设计您的顶级服务。
这绝对值得顶级 class 专家数百万*天的努力，您几乎没有预算和时间来（重新）花钱来接近您的目标在 ZeroMQ 框架中为您的项目中的高级任务做好准备。
如果您的规模经济适用于 15 台平板电脑（用户）Android UI（这意味着您必须掌握 Android 无论如何），去熟悉 ZeroMQ，因为重新使用它的绑定来匹配和去（许多绑定可用并且已经稳定多年用于许多（如果不是全部）其他生产级语言（Ada， C、C#、C++、Erlang、F#、FORTRAN、Go、java、LISP、Node.js、pascal、perl、PHP、Python、Objective-C Scala、Smalltalk ... 仅举几例）因此，您在该领域的智力投入 将在进一步的项目中得到回报 ，而不是在没有任何投资回报率的情况下获得赤裸裸的曝光在那 ).
下一个最佳步骤是什么？
我的建议是花时间阅读 Pieter HINTJENS 的书 "Code Connected, Volume 1"。 Pieter 是 ZeroMQ 框架的创始人之一，他分享了很多关于如何在分布式、容易出错的进程到进程消息传递环境中生存的见解。确实值得将时间花在他的伟大见解上。
诺塔贝内
问：您是否定义了您的最佳实践的指标？
答： 不。这可能（并且将）扭曲您可能期望收到的答案。