APP誕生全紀錄 - 容易忽略的必要功能2：APP跳轉
2022/09/09閱讀時間約 11 分鐘
一個APP在規劃的時候可能覺得主要功能就只有這一兩個，實作起來應該不難，卻忘了現代人的胃口已經越養越大，很多不在你預期內但對於使用者來說卻是很基本的功能；另一種是商店上架或是第三方要求的必要功能。
如果你還沒有閱讀過「APP誕生全紀錄」，建議可以先看一下，至少知道哪些可能是容易忽略的必要功能，前一篇我們提到了推播，今天我們來探討第二種必要功能：APP跳轉，透過一組文字連結能夠點選開啟APP並跳轉到正確功能頁面。使用者常常在APP大海中迷失找不到你的APP，或者想要有個良好的使用者體驗導引到下載安裝，但卻不知道如何提高使用者的轉換率嗎？APP跳轉就是答案。
可以看一下簡單的介紹影片
歷史發展
Mobile Deep Link
這是最原始型的APP跳轉，其原理是利用URI Scheme來指向APP。例如最常見的就是“http://www.xxx.com/”，使用者點擊後會打開瀏覽器跳到對應的網頁。這一段中http代表了網際網路的協定名，後面一串代表的是位置，如果是https我們知道是加密型網際網路的協定名，所以對於上面這兩個協定名，設備就會很自然的打開瀏覽器，如果是ftp://xxxx就會打開FTP協定相關的軟體。
所以我們就利用這個URI的架構來向使用者的設備註冊我們的軟體協定名，例如「聖經種子」就可以註冊bibleseed，那這樣只要把連結設定為bibleseed://xxxxxxxx，使用者點擊後自然就會如我們期望的導向到聖經種子的APP中啦！
那今天的文章就介紹到此......疑，不對呀？！如果Deep Link這麼完善了，為什麼還有其他的架構出來呢？但聰明的你一定在前面就已經發現原始協定其實有蠻多問題和陷阱在裡面。
- 如果都是註冊相同的協定，例如http，那設備怎麼知道要開啟Chrome或是Safari
- 承1，那如果有人搶先我註冊了一樣的名字，失去了唯一性，那該怎麼辦
- 如果使用者還沒安裝過我的APP，所以設備還沒註冊APP的協定，那點擊後會發生什麼事情
為了解決以上的問題，所以各大陣營就絞盡腦汁想出了各種解決方案，畢竟每個陣營都想當領頭羊，稱霸並主導這個協定，但以目前的態勢還是二分天下，尚未統一。Android陣營的提出了Web Link / App Link，而Apple陣營的則提出了 Universal Link。這些被提出的協定都有一個相同的方向，那就是都使用網際網路協定http來當作跳轉的平台。
Android Web Link
支援版本：Android 12 以前
Web Link只是Deep Link的延伸版本而已，指定http和https的協定名配上對應的host時會開啟一個選項視窗，可決定直接開啟APP或瀏覽器。
<data android:scheme="http" /><data android:host="bibleseed.nobodystudio.app" />
Android App Link
支援版本：Android 6.0 (API level 23) and higher
會驗證對應網域是否為此APP持有，需要比Web Link多一些驗證手段，在安裝後可直接開啟APP。
<intent-filter android:autoVerify="true"><data android:scheme="http" /><data android:scheme="https" /><data android:host="bibleseed.nobodystudio.app" /></intent-filter>
Apple Universal Link
支援版本：iOS 9或以上
一樣使用網際網路協定，可支援無APP時使用瀏覽器開啟網址並決定導向至App Store安裝，或是安裝完成後會直接開啟APP，無論哪種操作如果最終導向至APP後可以依照傳入的參數讓APP直接跳轉或導引至正確的內容頁面。
規則協定
我們先來看看為了達成使用者各種可能的情境所產生的這個可怕的思路流程圖。
其實要可以做到這些就是在自己的網域上帶入對應的驗證資料（粗體部分都是你需要填入的APP資訊），然後藉由URI帶入的data內容來決定走向和APP內的處理方法。
iOS驗證資料
http://你的網域/.well-known/apple-app-site-association
{"applinks":{"apps":[],"details":[{"appID":"NFTC7AK8F2.com.ebible.bibleseed","paths":["NOT /_/*","/ "]}]}}
Android驗證資料
http://你的網域/.well-known/assetlinks.json
[{"relation": ["delegate_permission/common.handle_all_urls"],"target": {"namespace": "android_app","package_name": "com.ebible.bibleseed","sha256_cert_fingerprints":["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]}}]
URI架構
https://bibleseed.nobodystudio.app/links/?link=https%3A%2F%2Fbibleseed.app%2F&?query&apn=com.ebible.bibleseed&ibi=com.ebible.bibleseed
一個基於Firebase Dynamic Link的範例如上，必要的參數有三個
- link：是deep link的主要內容，負責導向到哪裡和APP內抓取query的參數
- apn：Android的APP主要ID
- ibi：iOS的APP主要ID
- 其他參數：可參考連結
實作範例
我們來嘗試看看使用Flutter + FirebaseDynamicLink的開發環境實作一下吧！
參數環境設定
首先，要先把上一節說的驗證資料在你的網域中加入，再來如果是Android的環境也需要把第一節的相關設定寫入，接著我們就開始進入到flutter專案中。
安裝套件
#flutter pub add firebase_dynamic_links
接收/處理傳入資料
Future<void> main() async {WidgetsFlutterBinding.ensureInitialized();// 基本的Firebase系統initawait Firebase.initializeApp(options: DefaultFirebaseConfig.platformOptions);// Get any initial linksfinal PendingDynamicLinkData? initialLink = await FirebaseDynamicLinks.instance.getInitialLink();if (initialLink != null) {// 這裡拿到的deepLink就是前一節提到的link參數內容final Uri deepLink = initialLink.link;// Example of using the dynamic link to push the user to a different screenNavigator.pushNamed(context, deepLink.path);}runApp(MyApp(initialLink));}
額外說明
因為原本在實作時剛好Firebase Dynamic Link這個官方套件有問題，所以改用了其他接收initial link的套件來處理，其實拿到的系統傳入內容都是一樣的，只是要自己去切割處理一整串URI的內容，擷取出自己需要的部分。
另外iOS在測試時，是不能直接使用瀏覽器貼上Link測試的，必須在其他記事本或APP中點選開啟才能測試，這點需要注意。
加上短網址
APP跳轉的連結雖然很好用，但因為要挾帶的資訊量很大，所以難免會變成一串非常冗長的連結，這時候要怎麼辦呢？
如果一開始進入APP跳轉就直接接觸Dynamic Link的很容易被搞混在一起，建議分開理解
Firebase內附加了一個功能 - 縮短網址。在Firebase網頁中可以直接操作建立短網址，把這整串URI縮短避免讓人頭昏眼花；在SDK中也有API可以呼叫直接建立，名稱可以自定義也可以由系統隨機取。
https://bibleseed.nobodystudio.app/links/?link=https%3A%2F%2Fbibleseed.app%2F&?query&apn=com.ebible.bibleseed&ibi=com.ebible.bibleseed
https://bibleseed.nobodystudio.app/links/media
另外一種可以把一整串冗長的網址消除的方式就是轉化為QR Code，將上面連結轉化如左圖，是不是就變得很清爽呢！
總結
APP跳轉是相當常見且實用的一個功能，所以我列為第2種必要卻容易忽略的功能，不知道你的APP有沒有使用呢？或是你覺得有甚麼其他容易忽略的必要功能，也都可以留言一起討論囉！！
留言0
查看全部