做劇本殺組隊(duì)App做到第4期終于到了寫表單這一步。前面的系列里我們已經(jīng)把Flutter for OpenHarmony的開發(fā)環(huán)境跑通、搭好了Tab框架、把列表頁和篩選邏輯做完了現(xiàn)在要處理的是整個(gè)組隊(duì)流程里最容易被草率對待、卻又最影響后續(xù)數(shù)據(jù)質(zhì)量的一環(huán)發(fā)起組隊(duì)表單頁。這篇實(shí)戰(zhàn)內(nèi)容解決的核心問題很直接如何把用戶隨手填寫的“組隊(duì)信息”變成一條結(jié)構(gòu)清晰、校驗(yàn)嚴(yán)謹(jǐn)、能夠直接入庫的組隊(duì)數(shù)據(jù)。適合的讀者是那些已經(jīng)能在OpenHarmony設(shè)備上跑起Flutter頁面、正準(zhǔn)備開始寫真實(shí)業(yè)務(wù)表單的人而不是還在糾結(jié)環(huán)境搭建的新手。如果你剛從Flutter標(biāo)準(zhǔn)版遷移過來這篇同樣有參考價(jià)值因?yàn)楸韱芜@塊在OpenHarmony適配層有不少細(xì)節(jié)值得單獨(dú)拿出來說。1. 發(fā)起組隊(duì)表單的整體設(shè)計(jì)與思路拆解1.1 做表單前先把要收集的“料”想明白我見過太多人寫表單上來就擺十幾個(gè)TextField想到什么加什么結(jié)果寫完之后發(fā)現(xiàn)存儲層字段對不上、列表頁篩選條件沒法用、編輯頁回顯邏輯稀爛。表單看起來是UI層的事但本質(zhì)上是數(shù)據(jù)建模的入口。發(fā)起組隊(duì)這個(gè)場景用戶到底要提供什么信息站在劇本殺店家和玩家兩端想一遍我會把字段分成以下幾組身份信息隊(duì)長昵稱、聯(lián)系方式這里我會建議只留昵稱聯(lián)系方式可以后期通過IM私聊避免隱私風(fēng)險(xiǎn)劇本信息劇本名稱、期望角色、人數(shù)上限時(shí)間信息開場時(shí)間、默認(rèn)時(shí)長地點(diǎn)信息門店選擇或自定義位置補(bǔ)充信息組隊(duì)描述、特殊需求每一組字段都會映射到后續(xù)列表篩選、詳情頁展示、消息通知推送。所以在設(shè)計(jì)表單時(shí)我建議先寫一份數(shù)據(jù)模型再反推表單字段而不是反過來被控件牽著走。這一點(diǎn)在后面寫模型代碼時(shí)會看得更清楚。1.2 從數(shù)據(jù)模型反推表單結(jié)構(gòu)拿我們這個(gè)劇本殺組隊(duì)App來說一條組隊(duì)記錄大概長這樣class TeamInfo { final String teamId; final String captainName; // 隊(duì)長昵稱 final String scriptName; // 劇本名稱 final String roleNeeds; // 期望角色比如“需要1個(gè)女玩家” final DateTime startTime; // 開場時(shí)間 final String location; // 地點(diǎn) final int maxMembers; // 人數(shù)上限 final String description; // 補(bǔ)充說明 final DateTime createdAt; // 創(chuàng)建時(shí)間 }這份模型確定之后表單的結(jié)構(gòu)也就鎖定了7個(gè)輸入項(xiàng)不多不少。有些字段可以合并展示比如“期望角色”和“補(bǔ)充說明”但存儲上必須分開因?yàn)榱斜眄摰暮Y選條件會用到角色這個(gè)維度。表單頁和模型的對應(yīng)關(guān)系我習(xí)慣畫成一張表作為開發(fā)前的對照清單表單字段數(shù)據(jù)模型字段類型交互控件校驗(yàn)規(guī)則隊(duì)長昵稱captainNameString文本輸入必填2~12個(gè)字符劇本名稱scriptNameString文本輸入必填至少2個(gè)字符期望角色roleNeedsString文本輸入選填最多30個(gè)字符開場時(shí)間startTimeDateTime日期時(shí)間選擇器必填不能早于當(dāng)前時(shí)間場地地點(diǎn)locationString文本輸入必填人數(shù)上限maxMembersint數(shù)字輸入必填2~12之間補(bǔ)充描述descriptionString多行文本選填最多200字這張表在動(dòng)手寫UI之前花10分鐘就能列完但它能幫你省掉后面至少一小時(shí)的返工時(shí)間。我之前在另一個(gè)項(xiàng)目里就是跳過這步直接寫控件結(jié)果模型字段被改了三次表單也推倒重來了三次。這次學(xué)乖了先模型后UI一次成型。2. 表單核心細(xì)節(jié)解析Form、TextFormField 與校驗(yàn)策略2.1 Form 與 TextFormField 的配合機(jī)制Flutter表單體系的核心是Form組件加上GlobalKeyFormState這套組合做的事情從開發(fā)者視角來看很簡單把一組輸入框的校驗(yàn)、保存、重置操作統(tǒng)一管理。關(guān)鍵點(diǎn)在于理解FormState的三個(gè)常用方法validate()遍歷所有已注冊的TextFormField逐個(gè)執(zhí)行各自的validator只要有任何一個(gè)校驗(yàn)失敗就返回false。save()觸發(fā)每個(gè)TextFormField的onSaved回調(diào)你在這里把輸入值寫回模型。reset()清空所有字段的錯(cuò)誤狀態(tài)。對應(yīng)到OpenHarmony版本的Flutter適配層這三個(gè)方法的語義和標(biāo)準(zhǔn)Flutter完全一致可以放心用。我習(xí)慣在initState里創(chuàng)建GlobalKey和TextEditingController在build方法里用Form包住ListView再在ListView里放各字段組件。結(jié)構(gòu)大致是class CreateTeamPage extends StatefulWidget { override StateCreateTeamPage createState() _CreateTeamPageState(); } class _CreateTeamPageState extends StateCreateTeamPage { final _formKey GlobalKeyFormState(); final _captainCtrl TextEditingController(); final _scriptCtrl TextEditingController(); final _roleCtrl TextEditingController(); final _descCtrl TextEditingController(); DateTime _startTime DateTime.now().add(const Duration(hours: 1)); String _location ; int _maxMembers 6; override void dispose() { _captainCtrl.dispose(); _scriptCtrl.dispose(); _roleCtrl.dispose(); _descCtrl.dispose(); super.dispose(); } // build方法省略后面單獨(dú)展開 }之所以每個(gè)controller都要在dispose里釋放是因?yàn)門extEditingController會持有輸入框的文本監(jiān)聽不及時(shí)釋放在OpenHarmony設(shè)備上如果反復(fù)進(jìn)出頁面容易出現(xiàn)內(nèi)存上漲后的卡頓現(xiàn)象。這個(gè)坑我在調(diào)試長列表時(shí)踩到過表單頁頻繁打開關(guān)閉同樣會遇到。2.2 校驗(yàn)邏輯不止是“不能為空”很多新手寫Validator只判斷空值但實(shí)際業(yè)務(wù)里的校驗(yàn)應(yīng)該更細(xì)致一些。以隊(duì)長昵稱為例_captainCtrl.text.trim().isEmpty ? 請?zhí)顚懩愕年欠Q : (_captainCtrl.text.trim().length 2 ? 昵稱至少2個(gè)字符 : null)這里做了兩個(gè)判斷第一層是必填第二層是最短長度。為什么不直接用TextFormField的maxLength屬性來代替因?yàn)閙axLength只是硬截?cái)嘤脩糨斎攵鴙alidator是在校驗(yàn)時(shí)給出提示兩者交互體驗(yàn)完全不同。硬截?cái)鄷層脩舾械健拔掖虻揭话氡磺辛恕倍ｒ?yàn)提示則給用戶解釋的機(jī)會。劇本名稱的校驗(yàn)類似但我會加一層單純?nèi)タ崭窈蟮拈L度判斷防止用戶只敲幾個(gè)空格就提交。人數(shù)上限字段的校驗(yàn)更有意思。如果用戶輸入0或者負(fù)數(shù)顯然不合理如果輸入500數(shù)據(jù)本身合法但對于組隊(duì)場景毫無意義。所以我把范圍限制在2到12之間并配合inputFormatters來限制輸入格式TextFormField( controller: _maxCtrl, keyboardType: TextInputType.number, inputFormatters: [FilteringTextInputFormatter.digitsOnly], validator: (value) { final num int.tryParse(value ?? ); if (num null || num 2 || num 12) { return 人數(shù)需在2~12之間; } return null; }, )digitsOnly這個(gè)formatter保證用戶只能輸入數(shù)字從源頭上攔截了字母和特殊字符。這一點(diǎn)在OpenHarmony的軟鍵盤上特別重要因?yàn)椴糠州斎敕ㄔ赥extInputType.number下仍然會切到中文輸入狀態(tài)用戶一鍵切拼音就能打出字母光靠鍵盤類型不夠必須用formatter兜底。2.3 實(shí)時(shí)校驗(yàn)、提交校驗(yàn)與交互節(jié)奏Form的校驗(yàn)時(shí)機(jī)有兩種做法一種是等用戶點(diǎn)擊提交按鈕時(shí)統(tǒng)一validate()另一種是配合AutovalidateMode讓輸入變化時(shí)立即校驗(yàn)。我的經(jīng)驗(yàn)是首次進(jìn)入頁面時(shí)用AutovalidateMode.disabled用戶點(diǎn)過一次提交按鈕后再切到AutovalidateMode.always。原因是第一次就讓用戶看到滿屏的紅字錯(cuò)誤體驗(yàn)非常壓迫。等用戶主動(dòng)提交過一次說明ta確實(shí)想完成這個(gè)操作這時(shí)候再實(shí)時(shí)標(biāo)紅反饋是正向的。這個(gè)交互節(jié)奏在Flutter里實(shí)現(xiàn)很簡單bool _autoValidate false; void _submit() { final valid _formKey.currentState!.validate(); if (!valid) { setState(() _autoValidate true); return; } // 剩余提交邏輯 }這段代碼里setState把_autoValidate置為true之后TextFormField的autovalidateMode判斷就從AutovalidateMode.disabled變成了AutovalidateMode.always。不用重建表單只需要讓build方法讀到新值。這個(gè)細(xì)節(jié)很多人容易跳過我特別拿出來說是因?yàn)樗谡鎸?shí)用戶測試?yán)锓答伈町惡苊黠@。組隊(duì)頁的使用者不是專業(yè)測試員看到錯(cuò)誤就以為是自己操作錯(cuò)不會意識到還有“提交按鈕觸發(fā)的第二次機(jī)會”。3. 實(shí)操從零搭一個(gè)發(fā)起組隊(duì)表單頁面3.1 頁面整體結(jié)構(gòu)與前置準(zhǔn)備在OpenHarmony項(xiàng)目里接入Flutter for OpenHarmony之后你的Flutter代碼完全可以作為一個(gè)獨(dú)立模塊存在。我這里默認(rèn)你已經(jīng)跑通了系列前面幾期的環(huán)境可以直接新建一個(gè)頁面文件create_team_page.dart并且已經(jīng)在路由配置表里注冊好了CreateTeamPage。頁面的整體結(jié)構(gòu)我會用Scaffold AppBar Form ListView。為什么不用Column直接堆字段因?yàn)楸韱雾撛谡鏅C(jī)上會有鍵盤彈起的情況ListView天然支持滾動(dòng)讓輸入框不被鍵盤完全擋住。而Column配合SingleChildScrollView也能實(shí)現(xiàn)但ListView對焦點(diǎn)滾動(dòng)到可視區(qū)的處理更自然。build方法的主干是這樣的override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text(發(fā)起組隊(duì))), body: SafeArea( child: Form( key: _formKey, autovalidateMode: _autoValidate ? AutovalidateMode.always : AutovalidateMode.disabled, child: ListView( padding: const EdgeInsets.all(16), children: [ _buildCaptainField(), _buildScriptField(), _buildRoleField(), _buildTimeField(), _buildLocationField(), _buildMaxMembersField(), _buildDescriptionField(), const SizedBox(height: 24), _buildSubmitButton(), ], ), ), ), ); }這里每一個(gè)_buildXxxField方法都返回一個(gè)widget拆分出來的好處是每個(gè)字段的構(gòu)建邏輯獨(dú)立改一個(gè)不會影響其他代碼review時(shí)也容易定位。3.2 日期與時(shí)間選擇的適配處理時(shí)間字段是組隊(duì)表單里最特殊的一個(gè)輸入項(xiàng)。用TextField讓用戶手動(dòng)輸入日期時(shí)間會帶來格式校驗(yàn)和時(shí)區(qū)解析一堆問題。標(biāo)準(zhǔn)Flutter的解法是用showDatePicker和showTimePicker在OpenHarmony的Flutter適配版里這兩個(gè)方法我在實(shí)踐里發(fā)現(xiàn)基本可用但需要注意兩個(gè)坑。第一個(gè)坑是showDatePicker的locale參數(shù)。如果不顯式傳入中文本地化配置OpenHarmony設(shè)備上彈出的日期選擇器可能是英文日歷的排版也可能對不上。處理方式是在MaterialApp里配置localizationsDelegates和supportedLocales這一點(diǎn)在標(biāo)準(zhǔn)Flutter工程里也需要做但很多遷移過來的項(xiàng)目會在這一步漏掉。第二個(gè)坑是時(shí)間選擇器的樣式適配。在OpenHarmony的原生控件風(fēng)格下Flutter的showTimePicker在部分設(shè)備上會出現(xiàn)彈層高度溢出。我后來改用了一種更穩(wěn)妥的做法自己寫一個(gè)底部彈出面板里面放兩個(gè)自定義的滾輪選擇器一個(gè)選小時(shí)一個(gè)選分鐘。這個(gè)方案完全繞開了showTimePicker的適配問題也保證了和App整體UI風(fēng)格一致。時(shí)間字段的展示我還是用了一個(gè)TextFormField但是把它設(shè)成只讀點(diǎn)擊時(shí)彈出選擇面板TextFormField( controller: _timeCtrl, readOnly: true, onTap: _openTimePicker, decoration: const InputDecoration( labelText: 開場時(shí)間, border: OutlineInputBorder(), ), validator: (value) value null || value.isEmpty ? 請選擇開場時(shí)間 : null, )用戶手勢流程是點(diǎn)擊輸入框 → 底部彈層出現(xiàn) → 選擇日期和時(shí)刻 → 點(diǎn)擊確定 → 輸入框回填格式化后的字符串。這樣既保證了格式統(tǒng)一也規(guī)避了手動(dòng)輸入的校驗(yàn)成本。3.3 提交處理校驗(yàn)、組裝與回寫狀態(tài)用戶填完所有字段點(diǎn)下“立即發(fā)布”按鈕這時(shí)表單頁才進(jìn)入真正的核心流程。這一步的邏輯要處理三件事校驗(yàn)所有字段、組裝TeamInfo模型、把新組隊(duì)數(shù)據(jù)回寫到列表狀態(tài)并返回上一頁。void _submit() { if (!_formKey.currentState!.validate()) { setState(() _autoValidate true); return; } final team TeamInfo( teamId: _generateId(), captainName: _captainCtrl.text.trim(), scriptName: _scriptCtrl.text.trim(), roleNeeds: _roleCtrl.text.trim(), startTime: _selectedTime, location: _locationCtrl.text.trim(), maxMembers: int.parse(_maxCtrl.text), description: _descCtrl.text.trim(), createdAt: DateTime.now(), ); Navigator.of(context).pop(team); }校驗(yàn)失敗后的邏輯前面已經(jīng)說過。校驗(yàn)通過后組裝模型時(shí)我的習(xí)慣是統(tǒng)一trim()把用戶無意敲進(jìn)去的首尾空格去掉避免存入數(shù)據(jù)庫后出現(xiàn)“張三 ”和“張三”兩條相似但不同的數(shù)據(jù)。這個(gè)細(xì)節(jié)在列表篩選時(shí)特別影響體驗(yàn)。組裝完成后頁面通過Navigator.pop(team)把數(shù)據(jù)帶回上一頁。上一頁可能是首頁也可能是隊(duì)伍列表頁它們只需要監(jiān)聽返回結(jié)果然后往列表頭部插入這條新數(shù)據(jù)并刷新UI即可。組件間的數(shù)據(jù)共享在這里不需要引入全套狀態(tài)管理框架用一個(gè)簡單的回傳就夠了。組裝模型時(shí)還有一個(gè)從模型設(shè)計(jì)階段就要確定的點(diǎn)teamId的生成方式。我這邊用的是時(shí)間戳加隨機(jī)數(shù)拼接String _generateId() { final timestamp DateTime.now().millisecondsSinceEpoch; final random Random().nextInt(9999).toString().padLeft(4, 0); return $timestamp$random; }這種方案在單機(jī)場景下夠用但如果你后面要接云端建議換成服務(wù)端生成的ID或者專門的唯一ID方案避免并發(fā)創(chuàng)建時(shí)撞ID。4. 常見問題與排查技巧實(shí)錄4.1 鍵盤遮擋與頁面自動(dòng)滾動(dòng)問題在OpenHarmony真機(jī)上調(diào)試表單頁時(shí)我遇到最多的問題就是點(diǎn)擊底部輸入框鍵盤彈起后輸入框被完全蓋住。雖然外部包了ListView但默認(rèn)情況下ListView不會自動(dòng)把焦點(diǎn)控件滾動(dòng)到可視區(qū)域。我用的處理方案是監(jiān)聽鍵盤高度做一次手動(dòng)滾動(dòng)。可以利用WidgetsBindingObserver監(jiān)聽didChangeMetrics獲取ViewInsets.bottom作為鍵盤高度再通過Scrollable.ensureVisible把當(dāng)前焦點(diǎn)控件滾出來。具體實(shí)現(xiàn)有點(diǎn)長但思路簡單獲取當(dāng)前焦點(diǎn)上下文交給ensureVisible處理。如果不想寫這么多輪子代碼還有一個(gè)更實(shí)際的降級方案把輸入框少的字段放上面多行文本和提交按鈕放中間這樣鍵盤彈起時(shí)把頁面整體抬起來最后一個(gè)輸入框也不會被完全遮住。實(shí)測下來在6寸左右的OpenHarmony設(shè)備上效果尚可但屏幕小的設(shè)備會顯得勉強(qiáng)。4.2 日期時(shí)間選擇器在OpenHarmony上的兼容打磨前面說過showDatePicker在OpenHarmony上能用但確實(shí)遇到過一些兼容性小問題比如彈窗位置偏移。排查下來發(fā)現(xiàn)是部分設(shè)備窗口顯示密度設(shè)置不同導(dǎo)致的。我的最終方案是自定義底部選擇面板用showModalBottomSheet包一個(gè)滾輪選擇器照片滾輪用CupertinoPicker這套組件在這個(gè)Flutter適配版里表現(xiàn)穩(wěn)定。下面是核心代碼片段Futurevoid _openTimePicker() async { final result await showModalBottomSheetDateTime( context: context, builder: (ctx) _TimePickerSheet( initialTime: _selectedTime, ), ); if (result ! null) { setState(() { _selectedTime result; _timeCtrl.text _formatTime(result); }); } }滾動(dòng)選擇器高度一般控制在220以內(nèi)底部留出安全區(qū)距離避免在帶手勢條的設(shè)備上被誤觸。這套方案在OpenHarmony和Android上表現(xiàn)一致代碼也不需要額外寫平臺判斷是我比較推薦的做法。4.3 校驗(yàn)不觸發(fā)與錯(cuò)誤狀態(tài)不清除的坑有朋友在社區(qū)反饋說明明字段是空的點(diǎn)擊提交卻沒有任何反應(yīng)。最常見的寫法錯(cuò)誤是把validator掛在了Container上而不是掛在TextFormField上。Form只能收集到TextFormField和FormField注冊的校驗(yàn)器放在普通組件里的校驗(yàn)邏輯不會生效。另一個(gè)更隱蔽的問題第一次校驗(yàn)失敗后錯(cuò)誤紅字一直顯示即使用戶已經(jīng)在改了錯(cuò)誤依然不消失。這是因?yàn)開autoValidate已經(jīng)是true但校驗(yàn)規(guī)則里的判定條件寫得不對。比如人數(shù)從0改成5如果表單里還是舊的非法值傳給validator紅字當(dāng)然不會消失。解決辦法是確保TextFormField的controller就是校驗(yàn)對象本身而不是一份拷貝這樣輸入變化才能立即反映到校驗(yàn)結(jié)果里。我建議遇到這種“紅字不消失”的情況先打印一遍實(shí)際拿到的valuedebugPrint(當(dāng)前輸入值: ${_maxCtrl.text});別小看這行日志很多奇怪的校驗(yàn)問題追到最后都是“我以為是X實(shí)際拿到的是Y”。4.4 頁面狀態(tài)保存離開再返回不丟數(shù)據(jù)表單寫了一半切到后臺再回來發(fā)現(xiàn)內(nèi)容全沒了。這個(gè)問題在OpenHarmony上出現(xiàn)的概率比標(biāo)準(zhǔn)Android上更高因?yàn)樵O(shè)備進(jìn)程被殺的情況更頻繁。常規(guī)思路是用PageStorageKey或者AutomaticKeepAliveClientMixin來保留狀態(tài)但表單頁這種需要主動(dòng)提交的頁面我更建議做得徹底一點(diǎn)在dispose前把表單內(nèi)容緩存到本地下次進(jìn)入時(shí)恢復(fù)。最簡單的方式是把表單數(shù)據(jù)序列化成JSON寫入SharedPreferencesoverride void dispose() { final data { captainName: _captainCtrl.text, scriptName: _scriptCtrl.text, // ... 其余字段 }; storage.setString(draft_team_info, jsonEncode(data)); super.dispose(); }恢復(fù)時(shí)在initState里讀出來填回各個(gè)controller。這個(gè)草稿箱機(jī)制看著不起眼但對于劇本殺組隊(duì)這種可能反復(fù)修改文案的場景用戶體驗(yàn)提升非常明顯。我另一個(gè)餐飲類App的反饋里用戶最感謝的功能之一就是這個(gè)草稿自動(dòng)保存。4.5 表單相關(guān)技術(shù)問題速查問題現(xiàn)象常見原因處理辦法點(diǎn)擊提交無反應(yīng)校驗(yàn)器掛錯(cuò)了組件確認(rèn)validator在TextFormField上數(shù)字輸入框能打字母鍵盤類型不是數(shù)字使用digitsOnly inputFormatter錯(cuò)誤提示不及時(shí)消失autovalidateMode未切換提交失敗后切到AutovalidateMode.always時(shí)間選擇彈窗位置錯(cuò)亂OpenHarmony窗口密度差異改用自定義底部彈層切后臺表單數(shù)據(jù)丟失進(jìn)程被回收草稿箱機(jī)制本地緩存鍵盤彈起后提交按鈕不可點(diǎn)滾動(dòng)區(qū)域沒有自適應(yīng)ListView ensureVisible 或調(diào)整布局5. 從表單頁看數(shù)據(jù)流組隊(duì)App的整體閉環(huán)5.1 發(fā)起組隊(duì)只是入口數(shù)據(jù)要能流轉(zhuǎn)起來很多人做表單頁把“點(diǎn)一下提交、數(shù)據(jù)打印在控制臺里”當(dāng)成結(jié)束。但真實(shí)的組隊(duì)App里這條數(shù)據(jù)接下來要經(jīng)歷好幾個(gè)環(huán)節(jié)寫入本地?cái)?shù)據(jù)庫或云端、列表頁插入一條新卡片、隊(duì)伍詳情頁讀取完整信息、其他玩家看到這條組隊(duì)后發(fā)起加入申請、隊(duì)長收到申請并處理。所以表單頁在架構(gòu)上要預(yù)留好“出口”。我在這套代碼里用的是一個(gè)TeamRepository類來封裝修數(shù)據(jù)的所有操作頁面只負(fù)責(zé)把表單喂給Repositoryclass TeamRepository { Futurebool createTeam(TeamInfo team) async { // 寫入本地或云端返回是否成功 } }這樣做的好處是表單頁根本不需要知道數(shù)據(jù)最終是存在SharedPreferences里、SQLite里還是遠(yuǎn)端數(shù)據(jù)庫里。以后把存儲方案從本地?fù)Q成云端只需要改Repository的實(shí)現(xiàn)表單頁一行代碼都不用動(dòng)。5.2 與列表頁、詳情頁的聯(lián)動(dòng)設(shè)計(jì)表單頁pop出去的TeamInfo在列表頁收到后插入列表頭部。這里有一個(gè)時(shí)序細(xì)節(jié)列表頁應(yīng)該在await返回結(jié)果后再做插入而不是在push之前就插入否則用戶取消了表單操作列表里卻多了一條臟數(shù)據(jù)。我的做法是Futurevoid _openCreatePage() async { final newTeam await Navigator.of(context).pushTeamInfo( MaterialPageRoute(builder: (_) const CreateTeamPage()), ); if (newTeam ! null) { setState(() _teamList.insert(0, newTeam)); } }只有返回結(jié)果非空時(shí)才刷新列表這個(gè)判斷能過濾掉用戶中途退出或返回鍵取消的情況。同樣的模式在詳情頁傳回隊(duì)長處理結(jié)果時(shí)也可以復(fù)用整個(gè)App的數(shù)據(jù)流會是列表頁 - 表單頁 - 列表頁 - 詳情頁 - 列表頁一條單向鏈路清晰也不容易出bug。5.3 表單字段的復(fù)用與擴(kuò)展空間組隊(duì)表單這套結(jié)構(gòu)在做完第一版后就會被復(fù)用到很多場景用戶個(gè)人資料編輯、劇本發(fā)布、房間信息修改。我的經(jīng)驗(yàn)是趁模塊化做在前面后期收益極大。我最常做的抽離是“表單字段配置化”。把每個(gè)字段的配置定義成一個(gè)對象class FieldConfig { final String label; final String hint; final TextInputType inputType; final String? Function(String?)? validator; final ListTextInputFormatter? formatters; }這幾個(gè)字段描述了一個(gè)輸入框絕大部分的UI和校驗(yàn)行為頁面構(gòu)建時(shí)循環(huán)遍歷配置列表動(dòng)態(tài)生成表單。新增一個(gè)字段時(shí)不需要再復(fù)制一整個(gè)TextFormField代碼塊而是往配置列表里加一個(gè)條目就行。這個(gè)模式唯一的缺點(diǎn)是寫起來比手搓字段稍繞但維護(hù)性上的收益遠(yuǎn)遠(yuǎn)超過前期多花的那點(diǎn)時(shí)間。我后來在兩個(gè)項(xiàng)目里復(fù)用了同一套配置化表單組件改起來都是幾分鐘的事。6. 繼續(xù)往前表單之后的那些真實(shí)問題表單完成之后你會發(fā)現(xiàn)真正的App邏輯才剛剛開始。最直接的挑戰(zhàn)是多人同時(shí)創(chuàng)建組隊(duì)時(shí)如何保證隊(duì)伍ID不沖突用戶提交的劇本名稱五花八門是否需要統(tǒng)一成預(yù)設(shè)列表時(shí)間到了卻沒約滿要不要自動(dòng)通知隊(duì)長修改組隊(duì)信息里包含的具體門店地址、價(jià)格信息要不要接入地圖能力。這些都是無底洞但從產(chǎn)品角度而言每一步都能提升玩家和店家的使用效率。我第一次寫這個(gè)表單頁的時(shí)候也想過把校驗(yàn)、存儲、通知全部塞進(jìn)同一個(gè)頁面的build方法里覺得這樣最快。后來代碼寫到第3天就撐不住了一個(gè)頁面兩千多行改一個(gè)按鈕的樣式都要小心會不會誤碰狀態(tài)邏輯。后來重構(gòu)把所有字段校驗(yàn)統(tǒng)一抽到獨(dú)立的校驗(yàn)函數(shù)里把存儲邏輯交給Repository把時(shí)間選擇器做成獨(dú)立組件頁面代碼砍到不到400行功能和之前完全一樣但維護(hù)起來輕松了一個(gè)量級。如果你正在做Flutter for OpenHarmony上的表單類需求我特別建議把這一篇里的設(shè)計(jì)順序走一遍先列字段再定模型再寫校驗(yàn)最后搭UI。這條路徑可能看起來比直接拖控件多花半小時(shí)但它在項(xiàng)目后期節(jié)省的時(shí)間遠(yuǎn)超你想象。至少我在這套組隊(duì)App項(xiàng)目里用同樣的方法順帶完成了編輯隊(duì)伍信息、個(gè)人資料設(shè)置兩個(gè)頁面全程沒有重建過任何表單組件只是換了字段配置和提交邏輯。好了這一期的表單實(shí)現(xiàn)就聊到這里。下一期我打算寫隊(duì)伍詳情頁的交互細(xì)節(jié)重點(diǎn)是OpenHarmony設(shè)備上列表滑動(dòng)加載與詳情頁轉(zhuǎn)場動(dòng)畫怎么取舍以及跨頁面狀態(tài)同步的幾種方案對比。到時(shí)候見。