假设你要做一个本地文件处理工具。
文件解析、批量转换、结果导出，这些功能用 Java 写起来很顺手。但到了界面这一步，又有点犯难：表格怎么排、弹窗怎么做、深色模式怎么配，还得照顾不同屏幕尺寸。
这时候，把 Web 界面接进来，就是一个很自然的想法。
用 Shadcn UI 做页面，Java 继续处理业务，外面再配一个桌面窗口。既能保留已有的 Java 代码，也能按 Web 的方式做界面。
听起来挺合适。
不过，页面显示出来以后，真正的问题才开始：按钮怎么调用 Java？处理文件时会不会卡住？用户关掉窗口，任务怎么办？
咱们就拿这个文件处理工具，把这条路线聊清楚。
Shadcn UI 做界面，Java 处理业务
这里说的“用 Shadcn UI 写 Java 桌面应用”，可以理解为：用它构建 Web 界面，再把界面和 Java 业务逻辑连接起来。
如果按这个思路设计，分工可以很明确。
前端负责展示文件列表、收集操作参数、显示进度和处理结果。Java 负责读取文件、执行转换、保存数据，以及调用已有的业务代码。
两边之间，还需要一条通信通道。
用户点击按钮
↓
Web 界面提交任务
↓
通信接口
↓
Java 执行业务
↓
返回进度和结果
↓
界面更新
这条通道可以通过本地 HTTP，也可以通过桌面方案提供的桥接接口来实现。
至于是不是要把两边拆成独立进程，取决于具体方案，不必一开始就认定必须怎样。
但有件事需要提前定好：哪些能力可以交给页面调用，哪些必须留在 Java 这一侧控制。
比如，前端可以提交“转换用户选中的文件”，不代表它应该拥有随意读写整个磁盘的能力。页面需要什么，就提供什么，别为了省事，做出一个什么都能执行的万能接口。
一个“导入文件”按钮，能带出多少问题？
页面上放一个按钮，点击后调用 Java，这一步并不难理解。
但把场景补完整，就不只是一次调用了。
假设用户选择了一批文件，处理过程需要持续一段时间。这时候，界面至少应该告诉用户：任务有没有开始、正在处理什么、已经完成多少，以及出错后该怎么办。
不能点完按钮，只剩一个转圈动画。
更不能让用户猜：“这是还在处理，还是已经卡死了？”
我会把这类操作设计成任务：Java 接到请求后，先返回任务标识，再通过后续查询或事件通知更新进度。前端不用一直等着第一次调用返回最终结果。
接着还要考虑取消。
用户点了“取消”，不能只是把弹窗关掉，Java 那边却继续忙。
需要取消的究竟是哪一个任务？已经生成的文件要不要保留？正在写入的临时文件怎么清理？这些都要有明确处理。
还有重复点击。用户觉得没反应，连续点三次“开始”，后端准备执行一次，还是同时执行三次？
按钮可以先禁用，但后端也得有自己的重复提交处理。不能把所有希望都寄托在一个按钮状态上。
到这里就能看出来，组件能帮你把按钮做得漂亮，按钮按下去之后发生什么，还得自己设计。
通信调通了，不代表这部分做完了
最初写演示时，接口经常只有两种结果：成功，或者失败。
真给别人用，很快就会发现，“失败”两个字根本不够。
文件不存在、没有访问权限、格式不支持、目标目录写不进去，用户需要采取的操作完全不同。
所以，我会让 Java 返回明确的错误类型，再由界面给出对应提示。必要时保留任务编号，方便从日志里找到问题。
例如，与其弹出一句：
处理失败，请稍后重试。
不如说明白：
无法写入所选目录，请更换保存位置后重试。
对于权限不足的问题，让用户反复重试，只是在认真浪费他的时间。
启动顺序也一样。
如果采用独立 Java 进程，窗口打开时，后端可能还没准备好。此时应该显示初始化状态，或者等待就绪，而不是立即弹一个“连接失败”，让用户怀疑软件装坏了。
通信中断后，也不能默认任务已经失败，然后直接重新提交。最好能根据任务标识确认状态，避免同一批文件又被处理一遍。
另外，即使通信发生在本机，权限检查也别省。前端传来的路径和参数，Java 这一侧仍然要检查，不能因为“都是自己写的页面”就全部照单全收。
桌面体验，经常败在这些小地方
截图里，一张表格、几个按钮、一个弹窗，就能显得很完整。
可用户不会只看截图。
把显示缩放调大，文字会不会挤在一起？把窗口缩小，底部的确认按钮还能不能点到？用中文输入法搜索文件，输入过程是否正常？
鼠标能操作以后，还要试试键盘。
Tab 能不能顺着表单移动？弹窗打开后，焦点有没有落在里面？按 Esc 关闭弹窗，会不会连正在编辑的内容一起丢掉？
文件操作也值得多试几轮。路径里带中文和空格、一次选择多个文件、保存位置不可写，这些情况都应该放进测试。
还有一个看着很小、实际很容易扯出麻烦的问题：点击右上角关闭按钮，到底意味着什么？
对于前面的文件处理工具，可能有几种设计：直接退出并停止任务；提示用户确认；关闭窗口，但让任务继续在后台运行。
都可以讨论，但要选定一种，并让用户知道。
尤其是采用子进程的方案，别出现窗口已经消失，Java 进程却没有按预期退出的情况。下次重新打开软件，又启动一份任务，问题就更难排查了。
这些事情不会因为换了一套好看的组件而自动解决，却会直接影响用户愿不愿意继续用。
离开开发环境，再试一次
在自己的电脑上运行成功，和把安装包交给别人，是两个阶段。
开发时，前端服务已经开着，Java 环境也配好了，缺什么依赖自己都知道。但用户拿到的应该是一个可以正常安装、启动的软件，而不是一份环境搭建作业。
对于本地文件处理工具，我会安排一次这样的测试：
找一台没有开发工具的机器，安装后断网启动，选择文件、执行处理、导出结果，再退出并重新打开。
这个过程比单独检查页面更有用。
页面资源有没有被打进安装包？字体、图标是不是还依赖远程加载？配置保存到了哪里？重新打开以后，之前选择的目录还能不能找到？
运行时怎么提供，也要交代清楚。随应用分发，还是由使用环境预先提供，得在交付方案里确定，不能到了用户安装时再临时补说明。
至于安装包大小、启动等待和内存占用，我会直接拿打包后的程序测，不先给它贴“轻量”的标签。
用户不会因为内部架构设计得漂亮，就愿意多等一次白屏。
更新同样要把前后端放在一起考虑。前端加了一个新参数，Java 端却还是旧版本，这种不匹配应该在发布和启动检查时发现，而不是等用户点到某个按钮才暴露出来。
这条路线，什么情况下值得做？
如果项目已经有不少 Java 业务代码，团队也熟悉 Web 开发，同时界面里有大量表格、表单、筛选和配置操作，我会愿意拿一个完整功能试试。
已有逻辑不用全部重写，界面也能按熟悉的方式开发，这个理由已经很实在了。
但如果只是一个功能很少的小工具，我会先算一下：引入 Web 界面以后，多出来的资源打包、通信维护和运行时管理，值不值得？
不是看见一个漂亮页面，就一定要把整套方案搬过来。
开始验证时，也不用先把所有页面做完。就做一条完整流程：
选择文件、提交任务、显示进度、处理错误、取消操作，最后正常退出。
然后打成安装包，换一台机器跑。
这条流程走顺了，再继续加功能。否则，页面越做越多，底下那些没处理好的问题也只会跟着一起变多。
Shadcn UI 能让这个方案在界面上有一个不错的起点，但后面的工作省不掉。
好看的界面能让人愿意打开。点下去有回应，出错了看得懂，关掉后不留烂摊子，才会让人把它留下来。
发表于 10 小时前
|
查看: 6|
回复: 0
