您需要了解有關新 LIFF URL 的所有資訊

原文連結

對於 2020 年的 LINE 開發人員而言,我認為沒人知道LINE Front-end FrameworkLIFF,而 LIFF URL 是什麼樣的?

  • 最有可能回答 https://liff.line.me/xxx-xxx 也稱為通用連結
  • 接下來,可能是答 line://app/xxx-xxx 也稱為 LINE Scheme
  • 一些人可能會回答 https://line.me/R/app/xxx-xxx

但是,如果我進一步詢問,LIFF URL 如何工作?相信答案會多種多樣,尤其是在 6 月 29 日後,LINE 誕生了 LIFF SDK v2.3.0,該 LIFF SDK 的功能已大大改變。

但是,所有 LIFF 用戶仍然可以照常使用。即使開發人員已將 LIFF SDK 更新到最新版本,LINE 仍能很好地完成此作業。因為如果今天我們轉到開發人員控制台的 LIFF 頁面中,將會有一些其他設置:

此處添加的設定部分我們可以選擇 LIFF URL 以相同的方式工作(Replace)還是以新的方式(Concatenate)工作,這表明 LINE 已完成其工作,因為 LIFF 已全部構建。默認為 Replace,這就是為什麼不是每個人都知道更改的 LIFF URL 的行為的原因如果創建新的 LIFF 應用,則默認值為 Concatenate

本文將為您介紹有關 LIFF URL 的所有資訊,並說明以前您可能不知道的秘密。本文的主要內容包括:

  1. 如何啟動 LIFF URL 的方法。
  2. 測試未使用額外的 Path、query parameters 以及 URL fragments 的 LIFF URL。
  3. 測試帶有 Path、Query parameter 以及 URL fragment 的 LIFF URL。
  4. 將 Path、Query parameter 以及 URL fragment 加到 LINE Scheme 中。

1. 如何使用新的 LIFF URL 方法

使用新的 LIFF URL 功能必須包含 2 個因素,且缺一不可:

  1. 必須為 LIFF URL 選擇 Mode 作為 Concatenate。
  2. 使用 LIFF SDK v2.3.0更高版本

注意:請注意,上面的所有 3 種 LIFF SDK 都已經是 v2.3.0(儘管有些功能看起來不一樣)。

這樣使每個人都更容易理解 LIFF URL 工作模式(新的和傳統)的差異,並且你也可以嘗試看看。為此,我按下順序為範例創建了 2 個 LIFF 應用:


2. 試用所有不可自定義的 LIFF URL。

2.1 在 LINE app 中打開通用連結的 LIFF URL

在這種情況下,“Destination URL” 將是 “endpoint URL” 加上 “路徑” 和 “Query param” ,然後加上 LIFF 的 URL fragment 的形式顯示。

2.2 在外部瀏覽器中打開 LIFF URL

在這種情況下,“Destination URL” 將是 “endpoint URL” 加上 “路徑” 和 “Query param” ,但是新的 LIFF URL 和舊版本之間會有區別。

  • 新增:Target URL 將與 Endpoint URL 完全相同
  • 傳統模式:Target URL 會添加查詢參數 liff.state。

2.3 在 LINE 中打開 LIFF URL(如 LINE Scheme)

在這種情況下,機制與 2.1 完全相同。
註記:LIFF URL 的 LINE scheme 模式僅適用於 Android、iOS 和 iPad 上的 LINE app。


3. 使用帶有 Path、Query Parameter 和 URL fragment 的 LIFF URL 測試。

3.1 在 LINE app 中打開通用連結的 LIFF URL

如果在通用連結上附加了 Path、 Query Parameter 或 URL fragment,將有兩種重新導向的步驟:

  1. 首先先重新導向到到 Endpoint URL,接著通用連結後的 Path、Query Parameter 到 URL fragment 進行 URL 編碼,然後將編碼後的值設定在 liff.state 上,其形式包含原本 LIFF 的設定值。
  2. 將重新導向到 Destination URL,而 liff.state 的值將會解碼並將該值附加到Endpoint URL 上。

新舊 LIFF URL 的區別

  • 新模式:Destination URL 將獲得完整的 Endpoint URL 帶著 /liff1 並且包含 Path 和 Query parameter。
  • 傳統模式:Destination URL 會刪除 Endpoint URL 中的所有 path 和 Query parameter,因此在此範例中,若您想帶 /liff2,則必須將通用連結指定為 https://liff.line.me/1653575653-8WwXMavK/liff2/path?param= 9#hashtag

3.2 在外部瀏覽器中打開通用連結

該機制與 2.1 中的工作方式完全相同,不同之處在於在第一次導向時的結尾沒有附加 LIFF 原本 URL fragment 的值。

3.3 在 LINE 應用中打開 LINE Scheme

如果在 LINE Scheme LIFF URL 上加了 Path、Query parameter 或 URL fragment,在新舊模式中 Redirect 機制啟動將只有啟動一次。接下來的傳遞過程中會將 Path、URL fragment 移除,並只能傳遞 Query param 到 endpoint URL 上。


4. 將 Path、Query parameter 和 URL fragment 加到 LINE Scheme 的方法

從第 3 部分開始,我們知道帶有 LINE Scheme 的 LIFF URL 的功能是它只能傳遞Query parameter,而不會關注 Path 和 URL fragment。為了使其支持 Path 和 URL 片段,將有 2 種方式可使用:

4.1 處理附加到 Endpoint URL 的 Query param

這種方法將有點家。我們必須寫程式來檢查與匹配 query param 的案例以及我認為應該被重新導向到的位置上…… 但這部分太繁瑣。

4.2 liff.state 狀態

在使用了 3 部分的方法中,每當有 2 個重新導向的地方時,都會有一個名為 liff.state 的變數該變數是處理附加到 Endpoint URL 上的 Query param,其值是 encode 來自 URL path、Query parameter 以及 URL fragment,藉由這個方法可以將我們帶到 Destination URL,讓我們看一個範例:


Bonus

以下有 3 個是本文我沒有提到的主題。但是,將其收集作為禮物給在這裡閱讀的朋友 ^^

  1. 從現在開始,URL fragment 禁止指定 Endpoint URL。
  2. 在如下所示的 LIFF URL https://line.me/R/app/xxx-xxx 具有與 LINE Scheme line://app/xxx-xxx 有著相同的功能。
  3. 相信閱讀本文的人可能正在嘗試比較兩個版本間的差異,在這試用期間,通常會在程式碼中交替使用 LIFF ID,因此,如果突然在 LINE app 中打開 LIFF 並迫使我們登錄,猜測為 LIFF 通過網站上的連結調用我們的 ID 不匹配之類的… 這不太好處理 😂

結論

希望本文中的內容能幫助所有開發人員理解。並清楚地看到每種方法中的 LIFF URL 機制的區別,無論是傳統模式(Replace)還是新模式(Concatenate)。

最後,我想對正在開發 LIFF app 的大家說,新的 LIFF URL 遲早會取代原本的 URL。因此,建議儘早進行調整避免將來對您造成負擔…我們下次見。