1. 真實世界的需求

如果是在Web世界中,要跨越好幾個的網站服務其實是很簡單的,一個href就搞定了。但對於手持裝置中的APP,其實是很困難的,例如您要從A應用服務呼叫B應用服務起來,甚至要達成Deep link,您就必須了解對方程式的呼叫方式,甚至連相關參數的呼叫方式都需要很清楚,但世界上有幾億個應用程式,我怎麼可能知道每一個應用服務的呼叫方式?而這就是APPLinks想達成的目的,讓用戶可以在各應用程式間相互呼叫,就如同網頁一樣好用,於是他們推出APPLinks

2. APPLinks 幾個重要觀念

(1) APPLinks是一個標準,這個標準說明了如何打開其他應用程式的方式,基本上您只要遵守這個標準,理論上所有應用程式都可以相互呼叫

(2) APPLinks的標準定義在網頁上,但這不代表您一定需要對映的網頁服務,您所需要的只是要有一個網頁去定義APPLinks所需要的標準內容即可,而非真的需要這個內容服務,因為目前Facebook有提供此服務,您可以省略網站設計的步驟

(3) APPLinks並沒有替代現有的 URL Scheme技術,他只是在URL Scheme這個技術之上,定義了互相呼叫的溝通標準

(4) APPLinks目前有一些Open Source SDK可以用,可以直接套用在APP中

3. APPLinks 的運作邏輯

(1) 在網頁或Facebook提供的網站服務上定義APPLinks所需要的Meta Data

(2) 在APP服務上加入APPLinks SDK

(3) 當用戶在某個已安裝的應用服務上點即某個APPLinks支援的連結,該APP會送出內容請求至(1)中的網頁(SDK有支援),這個請求稱為APPLinks In

(4) 若APPLinks In成功,將取回該網頁內容中的Meta Data,並進行解析(SDK有支援)

(5) 解析成功後,將解析出來的URL Scheme拼湊出來,並觸發URL Scheme(SDK有支援)

(6) 若此URL Scheme無誤,就可以順利將呼叫對方的APP起來,並完成必要的Deep link(Optional)

4. 個人想法
(1) 目前這只是Facebook一廂情願在推動的標準,就技術的角度來看,是可行的,因為他們根植於現有的URL Scheme技術之上,並沒有推翻過去的技術

(2) 除了配合Facebook之外,我仍懷疑這個技術是否會被普遍支援,主要原因是目前APP很難完全避免閃退,如果您想在多個APP內切換,個人認為閃退機率只會提高,這可能會嚴重影響使用者體驗

(3) 另外就是,在多個APP內跳躍,在使用者體驗上其實也是很奇怪的,網頁之所以可以,因為在操作上只是在多個頁籤間切換而已,但APP卻難以如此連續,再怎麼樣都會有跳離感,而造成操作上的不便

5. 結論
(1) 如果您的APP服務,高度依賴Facebook,由於Facebook目前有支援APPLinks,建議可以採用APPLinks + URL Scheme,應該會有幫助

(2) 但若您的目的不在於將Facebook APP的流量引入您的APP,甚至希望未來可以走向大同世界,各APP可以自由的相互串連,我建議您還是觀望為佳


另外一個很相近的技術是Google App Indexing,目前也在測試中,有空再跟各位分享

文章標籤
創作者介紹

Min's Web Life: 談網路產業研究與生活閒聊

miin1130 發表在 痞客邦 PIXNET 留言(1) 人氣()


留言列表 (1)

發表留言
  • 俴 誏 ? 闚
  • 隻下有一多發時後真見也和說公全在不小,當在中,她開得

    超◇可♀愛娃~娃臉學□生﹉妹♂真〇係♀有無可檔的□誘﹉惑〇~﹎給﹉你最貼心的呵﹋護〇保♂證﹉讓~您著迷!
    請♀複◇製♀下﹉列~網址﹌,﹂貼在瀏灠器☆上﹍前○往﹌
    dvd.okavok.com
    成﹂人§DVD
    超骨§感美☆
找更多相關文章與討論