功能與政策

大多數真實世界的應用程式都需要適應不同裝置和平台的功能與政策。本頁包含如何在您的程式碼中處理這些情況的建議。

考量不同裝置的獨特優勢與弱點。除了螢幕大小和輸入方式（例如觸控、滑鼠、鍵盤）之外，您還可以利用哪些獨特的功能？Flutter 能讓您的程式碼在不同的裝置上執行，但強大的設計不僅僅是執行程式碼。請思考每個平台最擅長的功能，並看看是否有可利用的獨特功能。

舉例來說：蘋果的 App Store 和 Google 的 Play 商店有不同的應用程式規範。不同的主機作業系統在時間推移以及彼此之間都有不同的功能。

另一個例子是利用網路極低的分享門檻。如果您要部署網頁應用程式，請決定要支援哪些深層連結，並在設計導覽路線時考慮這些連結。

Flutter 針對根據這些獨特功能處理不同行為的建議模式是為您的應用程式建立一組 Capability 和 Policy 類別。

能力 (capability) 定義程式碼或裝置可以做什麼。能力的範例包括：

• API 的存在與否
• 作業系統強制執行的限制
• 實體硬體需求（例如相機）

政策 (policy) 定義程式碼應該做什麼。

政策的範例包括：

• 應用程式商店指南
• 設計偏好
• 指向主機裝置的資源或文案
• 在伺服器端啟用的功能

最簡單的機械方式是使用 Platform.isAndroid、Platform.isIOS 和 kIsWeb。這些 API 在機械上讓您知道程式碼在哪裡執行，但隨著應用程式擴展其可執行範圍以及主機平台新增功能時，會有一些問題。

以下指南說明在開發應用程式的功能和政策時的最佳實務

避免使用 Platform.isAndroid 和類似的函數來做版面配置決策或假設裝置可以做什麼。

相反地，請在方法中描述您想要基於什麼進行分支。

範例：您的應用程式中有一個在網站上購買商品的連結，但您基於政策原因不想在 iOS 裝置上顯示該連結。

bool shouldAllowPurchaseClick() {
  // Banned by Apple App Store guidelines. 
  return !Platform.isIOS;
}

...
TextSpan(
  text: 'Buy in browser',
  style: new TextStyle(color: Colors.blue),
  recognizer: shouldAllowPurchaseClick ? TapGestureRecognizer()
    ..onTap = () { launch('<some url>') : null;
  } : null,

透過新增額外的間接層，您得到了什麼？程式碼更清楚地說明了分支路徑存在的原因。此方法可以直接存在於類別中，但程式碼的其他部分可能需要相同的檢查。如果是這樣，請將程式碼放在一個類別中。

class Policy {

  bool shouldAllowPurchaseClick() {
    // Banned by Apple App Store guidelines. 
    return !Platform.isIOS;
  }
}

將此程式碼放在類別中，任何小工具測試都可以模擬 Policy().shouldAllowPurchaseClick 並獨立於裝置的執行位置驗證其行為。這也表示，如果稍後您決定在網路上購買商品對於 Android 使用者來說不是正確的流程，您可以變更實作方式，而可點擊文字的測試則無需變更。

有時您希望您的程式碼執行某些操作，但 API 不存在，或者您可能依賴於尚未在您支援的所有平台上實作的插件功能。這是裝置可以做什麼的限制。

這些情況與上述描述的政策決策類似，但這些被稱為功能。為什麼要將政策類別與功能類別分開，當類別的結構相似時？Flutter 團隊在實際應用程式中發現，在程式碼編寫完成後，在應用程式可以做什麼和應該做什麼之間做出邏輯區分，有助於大型產品應對平台功能或要求的變更，以及您自己的偏好變更。

例如，考慮以下情況：一個平台新增了一個新的權限，要求使用者在您的程式碼呼叫敏感 API 之前與系統對話方塊互動。您的團隊完成了平台 1 的工作，並建立了一個名為 requirePermissionDialogFlow 的功能。然後，如果平台 2 針對新的 API 版本新增了類似的要求，則 requirePermissionDialogFlow 的實作現在可以檢查 API 層級，並針對平台 2 返回 true。您已經利用了您已經完成的工作。

我們建議您一開始就使用 Policy 類別，即使您覺得您不會做出太多基於政策的決策。隨著類別的複雜性增加或輸入數量增加，您可能會決定按功能或其他一些標準來分解政策類別。

對於政策實作，您可以使用編譯時、執行時或遠端程序呼叫 (RPC) 後端的實作方式。

編譯時政策檢查適用於偏好設定不太可能變更，且意外變更值可能會產生重大後果的平台。例如，如果一個平台要求您不得連結至 Play 商店，或要求您根據應用程式的內容使用特定的付款供應商。

執行時檢查適用於判斷使用者是否可以使用觸控螢幕。Android 有一個您可以檢查的功能，而您的網路實作可以檢查最大觸控點數。

RPC 後端的政策變更適用於增量功能推出或稍後可能變更的決策。

使用 Capability 類別來定義程式碼可以做什麼。您可以根據 API 的存在與否、作業系統強制執行的限制和實體硬體需求（例如相機）進行檢查。功能通常涉及編譯時或執行時檢查。

使用 Policy 類別（或取決於複雜性的多個類別）來定義程式碼應該做什麼，以符合應用程式商店指南、設計偏好和需要參考主機裝置的資產或文案。政策可以是編譯時、執行時或 RPC 檢查的混合體。

透過模擬功能和政策來測試分支程式碼，以便在功能或政策變更時，小工具測試不需要變更。

請根據功能和政策類別中要分支的內容來命名方法，而不是根據裝置類型命名。

除非另有說明，本網站上的文件反映 Flutter 的最新穩定版本。頁面最後更新於 2024-05-21。 檢視原始碼 或 回報問題。