專案演示

URL Scheme是什麼

　　由於蘋果的app都是在沙盒中，相互是不能訪問資料的。但是蘋果還是給出了一個可以在app之間跳轉的方法：URL Scheme。簡單的說，URL Scheme就是一個可以讓app相互之間可以跳轉的協議。每個app的URL Scheme都是不一樣的，如果存在一樣的URL Scheme，那麼系統就會響應先安裝那個app的URL Scheme，因為後安裝的app的URL Scheme被覆蓋掉了，是不能被呼叫的。
　　

URL Schemes 的發展

URL Schemes 的發展過程可以說就是 iOS 效率工具類 App 的發展過程。

起初的蘋果建立的 Apple URL Schemes 只是用於自用，裡面只有郵件、電話、iTunes 搜尋、Youtube 視訊等一些內建服務的 URL。

個人認為 URL Schemes 第一次大火是在 2011 年末（如有異議歡迎指正），那個時期也是越獄的鼎盛時期，那個時期越獄後大家都會裝的一個外掛是 SBSettings[1]。越獄的人都知道每當新系統釋出的時候，等待新系統的越獄釋出是最撩人的，而這段時期那些「不越獄就能做到某種越獄功能」的應用經常一時間風頭無兩。

2011年 iOS 5 釋出帶來了通知中心，沒過多久，出現了一大批使用 iOS 系統設定的 URL Schemes 的 App 神奇地完成了接近 SBSettings 的功能——它們可以讓我們從通知中心直接跳轉到某些 App 的特定介面，比如 Twitter 的發推介面。它們甚至還可以直接跳轉到系統設定裡的 Wi-Fi 選項。在這一批 App 中，就有如今效率軟體霸主之一 Launch Center Pro 的前身——Launch Center。

但很快，這一批 App 被蘋果火速下架，原因是「對通知中心的誤用」。模糊的解釋讓開發者們摸不到頭腦，這種不滿一直延續到 Launcher 在 iOS 8 之後的下架事件。

總之，在這一批 App 被下架之後，玩票的都離開了，只留下了一個 Launch Center。作者似乎覺得 URL Schemes 大有可為，所以在不觸碰紅線（當時的紅線是一不許動通知中心，二不許呼叫系統設定的介面）的基礎上繼續發力，在幾個月（2012年7月）之後推出了 Launch Center Pro v1.0。

另一個注意到 iOS 上的 URL Schemes 的作用的是 Drafts 的作者 Greg Pierce。不同於 Launch Center Pro，Greg Pierce 打造的是一個以輸入文字為主的效率應用，它以一個筆記本的面目示人，所以被媒體稱為「Launch Center for text」。

兩者大的區別在於先選動作還是先輸入。Launch Center Pro 的使用方法是：先開啟動作，如果需要輸入的話，你可以讓它跳出來一個輸入框，你來輸入，輸入完成後跳轉到相應應用。Drafts 則是先在筆記本里把東西輸入了，然後再選擇動作，跳轉到相應應用。

好像沒什麼大不了的嘛……嗎？這裡至少有兩個重要的區別：

Drafts 中輸入過的內容會儲存在筆記本中以留作備份，而 Launch Center Pro 裡的則是動作執行完了就沒了。
Drafts 中輸入過的內容可以通過 URL Schemes 進行多次使用或一次性發給多個應用或服務，而 Launch Center Pro 只能將輸入內容傳送到一個服務或應用。即除了剪下版外， Launch Center Pro 沒有其它變數的概念。
第三個區別不太重要：Launch Center Pro 裡的輸入框和 Drafts 的筆記本介面來比較很明顯不是一個好的寫作環境。
細節上的區別還有很多，兩者適用的範圍隨著各自的發展擴大，因此重合的那部分功能也愈發的不起眼。Launch Center Pro 和 Drafts 從那以後成為效率類應用中的雙雄，不斷提出更多更靈活使用 iOS 上 URL Schemes 的辦法。

比如 Launch Center Pro 提出了 List 的概念，將列表的想法融入到了 URL Schemes 中，列表的每一項可以是簡單的字元，又可以是一串新的複雜的 URL。使用列表可以讓我們每次的輸入變為更輕鬆的選擇，對於那些重複的任務更為高效。

而 Drafts 的作者直接不滿 URL Schemes 只能跳出不能跳回的問題，和 Marco Arment、Justin Williams 等人開發了 x-callback-URL 來做到跳出，並跳回這樣的動作。

可以說這兩款 App 對 URL Schemes 的推廣和使用構思上的貢獻是最突出的，現在 URL Schemes 越來越被 iOS 使用者和開發者所重視，在我眼裡，一款 App 是否完整系統地支援 URL Schemes 已經是判斷它是否優秀的標誌之一。

故事講到這裡，更重要的還是如何使用 URL Schemes。

故事裡沒有提到 Pythonista、Editorial 跟 Workflow，絕不是我認為這些 App 不夠腕兒，而是它們做的事情重點已經不在於 URL Schemes 了。
　　

URL Scheme有什麼作用

　　那麼MobLink網頁跳轉app指定介面什麼作用呢？我們所使用的每一個app就相當於一個功能，app的跳轉可以使得每個app就像一個功能元件一樣，幫助我們完成需要做的事情，比如三方支付，搜尋，導航，分享等等。

建立URL Scheme

1、首先在Info.plist中新增一行,選擇URL types，效果如下圖所示：

2、在展開的Item 0中填寫URL identifier,這個用來唯一標識使用者自定義的URL Scheme，推薦使用域名的反轉形式，如: shenzoom

3、在Item 0中新增新的一行，選擇URL Schemes

4、展開URL Schemes，在Item 0中輸入自定義的Scheme的名稱。在這裡只需要輸入自定義的Scheme的名稱即可，不需要加上://，例如這裡輸入的是fb149753595510548,那麼對應的自定義的URL就是fb149753595510548://，這裡可以輸入多個。
5、最後一個完整的示例效果圖：

使用URL Scheme

1、在Safari中使用
在Safari中直接在瀏覽器的位址列中輸入shenzoom://,即可啟動剛才的應用

2、在其他的應用程式中使用
在需要呼叫的地方使用下面的程式碼即可實現呼叫

NSString *customURL = @"shenzoom://";
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:customURL]];

3、引數的傳遞

NSString *customURL = @"shenzoom://?token=123abct&registered=1";
    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:customURL]];

在AppDelegate中可以實現下面的方法

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
        

上面的方法直接 返回YES 就可以

解析

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
{
    if ([sourceApplication isEqualToString:@"com.devzeng.demo.urlscheme"])
    {
        NSLog(@"呼叫的應用程式的Bundle ID是: %@", sourceApplication);
        NSLog(@"URL scheme:%@", [url scheme]);
        NSLog(@"URL query: %@", [url query]);
        return YES;
    }
    else
    {
        return NO;
    }
}

在你的動作執行完成了之後，有可能時需要返回到原有app的，這樣就需要你的app跳轉協議的url裡面應該能傳入呼叫者app的跳轉協議，這樣使用者跳轉到你的app完成動作後就能跳轉回去了
關於 iOS 中常見的白名單的說明可以參考：常見白名單設定

URL Schemes 的衰敗

蘋果的各項改進一點點蠶蝕了 URL Schemes 的領域，但目前宣告 URL Schemes 死刑還為時尚早。

6s 之後的裝置大概都會支援 3D Touch，它的特徵之一就是從 Homescreen 的 App 圖示上直接進入該 App 的具體某個功能了。這個功能也讓很多人興奮了一把，雖說會用 URL Schemes 的人早就做到類似的事了。不過，既然官方已經有了這樣的功能，為什麼還要用 URL Schemes？

同樣，在 iOS 9 中，我們還可以用 Siri 建立關於 App 的提醒事項，來做到以前只有用 Launch Center Pro 和 Due 這樣的 App 才能做到的定時開啟 App。而且 iPhone 6s 還可以做到不在充電狀態下使用 Hi, Siri 這樣我們要建立一個提醒事項或者鬧鈴也無比簡單，只要說一聲「Hi, Siri. 半小時以後叫我。」就能定一個計時器。在這種比較之下 Due 這樣的 App 的作用顯然是被大大地削弱了。除此之外還有通知中心部件，Sharesheet 的出現都在一定程度上代替了 URL Schemes 的作用，削弱了其價值。 但按照目前的狀態，充其量只能說 URL Schemes 在衰敗，還遠不能宣判其死刑。

3D Touch 和 URL Schemes 重複的地方只有一部分複雜 URL Schemes 的功能：一些複雜 URL Schemes 的功能 3D Touch 沒有涵蓋，反過來 3D Touch 也有一些可以做到的事通過複雜 URL Schemes 做不到。但在複雜 URL Schemes 之上的變形 URL Schemes 跟 x-callback-URL 都是 3D Touch 無法做到的。

Siri 確實非常好用，我每天都用它很多次。所以我知道，如果不戴耳機，它是通過揚聲器跟你交流的，這種時候它聽錯了你說錯了，都得來回矯情半天，周圍有人的話場面會變得很尷尬。所以很多場合，通過 Due 的 URL Schemes，直接從 Dock 中的 Launch Center Pro 裡找到一個 Timer 或新增一個提醒其實更舒服。

我承認 URL Schemes 如今已無往日輝煌，但它在 iOS 上的效率方面的作用能不能被完全替代，目前也未可知。