ios開發－－ URL Schemes 使用詳解

用原生 iOS 的人分兩種，懂 URL Schemes 的和不懂的。

前者是「魔法師」，後者是「麻瓜」。

URL Schemes 應用在 iOS 上已經很久了。對於使用者來說，在沙盒機制下的 iOS 中，如果想做到一定程度上的自動化就不可避免地要用到 URL Schemes。但因為 URL Schemes 的使用方式不像傳統 iOS 使用者接觸到的圖形介面那樣可以直觀地點來點去，造成了對它有興趣的人（尤其是對英文有恐懼的人）一定程度上理解的困難。

而且大多數目前正在使用 URL Schemes 的人並不具備自己編寫符合自己使用情境的 URL Schemes 的能力，於是他們更多的是跑到各種社交網站上去「求幫助」。所以當我們在搜尋 URL Schemes 相關詞條的時候，我們會看到那些社交網站上的人們分享出來的 URL Schemes 列表。新人們對此如獲至寶，彷彿列表以外再無 URL Schemes，在列表中急切地搜尋自己想要的應用，如果沒有就一臉失望，如果有了就愉悅地複製貼上。

實際上那些列表中的 URL Schemes 你都可以自己找到，那些你在用別人沒在用的應用的 URL Schemes 也同樣可以找到。更重要的是你要有能力通過 URL Schemes 為自己打造滿足自己需求的自動化操作。

我希望通過這篇對 URL Schemes 的使用方式詳細說明的文章，來解除想使用 URL Schemes 的朋友對它的疑惑，比如這些問題：

「什麼是 URL Schemes 啊？」
「URL Schemes 怎麼用啊？」
「從哪找我想用的應用的 URL Schemes 啊？」
「國內的 xx 軟體支援不支援 URL Schemes 啊？」

都能在文章中找到答案。

文章目錄（想看使用部分的可以直接跳轉到

基本 URL Schemes）：

注：文中會提到使用 Launch Center Pro、Drafts 等應用的例子，它們都是同類應用中的最好選擇，而支援 URL Schemes 是促成它們如此地位的不可忽視的原因。如果想深入瞭解 URL Schemes，這些應用恐怕是必不可少的。你可以在 AppShopper 這樣的網站參考其以往價格，以便在你覺得價格合適的時候入手這些應用。

簡介蘋果的沙盒機制

蘋果選擇沙盒來保障使用者的隱私和安全，但沙盒也阻礙了應用間合理的資訊共享，於是有了 URL Schemes 這個解決辦法。

一般來說，我們使用的智慧裝置上有許多我們的個人資訊。比如：聯絡方式、銀行卡/信用卡資訊、支付寶/Paypal/各大商城的賬戶密碼、照片甚至行程與位置資訊等。

如果說，你裝置上的每一個應用，不管是官方的還是你從任何商城安裝的應用都可以隨意地獲取這些資訊，那麼你輕則收到騷擾資訊和郵件、重則後果不堪設想。如何讓這些資訊不被其它應用隨意使用，或者說，如何讓這些資訊僅在裝置所有者本人知情並允許的情況下被使用，是所有智慧裝置與作業系統所要在乎的核心安全問題。

在 iOS 這個作業系統中，針對這個問題，蘋果使用了名為「沙盒」的機制：應用只能訪問它宣告可能訪問的資源。一切提交到 App Store 的應用都必須遵守這個機制。

在安全方面沙盒是個很好的解決辦法，但是有些矯枉過正。敏感的個人資訊我們不願意透露，卻不代表所有的資訊我們都不想與其它應用共享。

比如說我們要一次性地（沒錯，只按一次）把多個事件放到日曆中，這些事件包含日期時間以及持續時間等資訊，如果 App 之間資訊不能溝通，就無法做到這點。（在下文中的 x-callback-URL 的部分會詳述整個過程）

類似於一次性新增多個日曆事件這樣的，我們在使用智慧裝置的過程中會遇到很多不必要的重複的步驟。大多數人對這些重複的步驟是不自覺的，就像當自己電腦裡有一批檔案需要批量重新命名的時候，他們機械地重複著重新命名的過程。但是當我們掌握了這些裝置執行的模式，或者有了一些工具，我們就能將這些重複的步驟全部節省下來。在 iOS 上，我們可以利用的工具就是 URL Schemes。

URL Schemes 是什麼

通過對比網頁連結來理解 iOS 上的 URL Schemes，應該就容易多了。

URL Schemes 有兩個單詞：

URL，我們都很清楚，http://www.apple.com 就是個 URL，我們也叫它連結或網址；
Schemes，表示的是一個 URL 中的一個位置——最初始的位置，即 ://之前的那段字元。比如 http://www.apple.com 這個網址的 Schemes 是 http。

根據我們上面對 URL Schemes 的使用，我們可以很輕易地理解，在以本地應用為主的 iOS 上，我們可以像定位一個網頁一樣，用一種特殊的 URL 來定位一個應用甚至應用裡某個具體的功能。而定位這個應用的，就應該這個應用的 URL 的 Schemes 部分，也就是開頭兒那部分。比如簡訊，就是 sms:

你可以完全按照理解一個網頁的 URL ——也就是它的網址——的方式來理解一個 iOS 應用的 URL，拿蘋果的網站和 iOS 上的微信來做個簡單對比：

網頁（蘋果）	iOS 應用（微信）
網站首頁/開啟應用	http://www.apple.com	weixin://
子頁面/具體功能	http://www.apple.com/mac/（Mac頁面）	weixin://dl/moments（朋友圈）

在這裡，http://www.apple.com 和 weixin:// 都聲明瞭這是誰的地盤。然後在 http://www.apple.com 後面加上 /mac 就跳轉到從屬於 http://www.apple.com 的一個網頁（Mac 頁）上；同樣，在 weixin:// 後面加上 dl/moments 就進入了微信的一個具體的功能——朋友圈。

但是，兩者還有幾個重要的區別：

所有網頁都一定有網址，不管是首頁還是子頁。但未必所有的應用都有自己的 URL Schemes，更不是每個應用的每個功能都有相應的 URL Schemes。實際上，現狀是，大多數的應用只有用於開啟應用的 URL Schemes，而有一些應用甚至沒有用於開啟應用的 URL Schemes。幾乎沒有所有功能都有對應 URL 的應用。所以，不要說某某應用爛，不支援國內應用。一個 App 是否支援 URL Schemes 要看那個 App 的作者是否在自己的作品裡添加了 URL Schemes 相關的程式碼。
一個網址只對應一個網頁，但並非每個 URL Schemes 都只對應一款應用。這點是因為蘋果沒有對 URL Schemes 有不允許重複的硬性要求，所以曾經出現過有 App 使用支付寶的 URL Schemes 攔截支付帳號和密碼的事件。
一般網頁的 URL 比較好預測，而 iOS 上的 URL Schemes 因為沒有統一標準，所以非常難猜，通過猜來獲取 iOS 應用的 URL Schemes 是不現實的。

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 Schemes

基本 URL Schemes 的能力雖然簡單有限，但使用情境卻是最普遍的。

我所謂的基本 URL Schemes，是指一個 URL 的 Schemes 部分，比如上文提到的微信的 weixin:。這個部分的唯一功能，就是開啟相應應用，而不能夠跳轉到任何功能。

絕大多數所謂支援 URL Schemes 的應用，一般都是隻有這麼一個部分，它一般是這個應用的名稱，比如 OmniFocus 這款應用，它的基本 URL Schemes 就是 Omnifocus:。如果應用的主名稱是個中文名的話，它的 URL Schemes 也許會是應用名的拼音，比如墨客這款應用，它的基本 URL Schemes 是 moke:。

但，我前面提過了網頁 URL 和 iOS 應用的 URL 的三個重要區別，其中第三項，就是 iOS 上的 URL Schemes 並不規範，一個應用的 URL 可以是各種各樣的：

Coursera 的 URL 是：coursera-mobile:
Duet 這款遊戲的 URL 是：x-kumo-duet:
Monument 這款遊戲的 URL 是：fb690517270143345:
Feedly 的 URL 是：fb129765800430121:
扇貝新聞的 URL 是：wx95962d02b9c3e2f7:

它們目前並沒有統一的規則，所以猜測一個應用的意義並不太大，你可以試試，但不要過於指望這種方式。下文會提到如何查詢一個應用的基本 URL Schemes，只要那個應用支援 URL Schemes 就能找到。

基本 URL Schemes 的能力雖然簡單有限，但使用情境卻是最普遍的。作為一個使用 Launch Center Pro 代替 Home Screen 的人，這樣只能做到開啟應用的基本 URL Schemes 對我來說也是很重要的。

複雜 URL Schemes

掌握複雜 URL Schemes 你才算初步有了打造適應自己使用情境的自動化流程的能力。

iOS 應用的複雜 URL Schemes 就像網站的子頁面的連結一樣，在首頁網址的基礎上進行延伸。前面蘋果官網和微信對比的例子已經可以說明問題了，想不起來的可以再去回顧一下。

具體來看，複雜 URL Schemes 有兩種：一種是直接開啟某個應用的某個功能，另一種是開啟某個功能後直接填寫預設的字元。這同網頁網址的原理也是類似的：

比如 Google Image 搜尋的網址是：

https://image.google.com

這就是在它的主網址（Google.com）的基礎上做了修改的子網頁的網址。而如果我們搜尋一個詞條，網址實際上是：

http://images.google.com/images?q=關鍵字

iOS 上的 URL Schemes 同樣遵循這個規則，比如你要開啟 Fantastical 這個應用，這是一個基本 URL Schemes：

Fantastical:

然後你想使用 URL Schemes 開啟它的某個功能介面，比如直接開啟 Fantastical 新增新事件的介面，那就需要這個介面的 URL Schemes：

fantastical2://parse?sentence

如果你想事先填好事件是什麼，定在什麼時候進行，只要在原有的 URL 的基礎上再加上事件的描述：

fantastical2://parse?sentence=事件描述

就成為了一個更加實用的 URL Schemes，因為它不光直接讓你進入了某個你需要的功能介面，還直接幫你填好了你需要的內容，而跳轉到 Fantastical 以後，你需要的只是按一下完成。

有了這樣的 URL Schemes，應用之間才可以互相地協作。比如說，當我們在 Mr. Reader 上看到一篇文章裡面寫了一個不錯的軟體的時候，我們可以利用 OmniFocus 的 URL Schemes 將文章名儲存到任務名的部分，把連結儲存到備註的部分。在 iOS 8 的 Share Sheet 出現之前，這是唯一在 App 間傳輸資訊的方式。

複雜 URL Schemes 有一個特殊的用例是 Jumpback，字典類 App 用它的很多，比如歐路詞典。傳統的使用歐陸字典查詢單詞的 URL Schemes 是：

eudic://dict/想查的單詞

在這個基礎上，加上一句 Jumpback：

eudic://dict/想查的單詞?jumpback=指定URL

就能夠做到查完單詞以後，按左上角或左下角的返回按鈕，回到你想要回到的 App。我們用下面這個 URL Schemes 來詳細說明這個用例：

eudic://dict/[clipboard]?jumpback=launch:

這段 URL，做到的是：先複製你不會的單詞，然後開啟 Launch Center Pro 啟動這個動作，跳轉到歐陸詞典的該單詞的釋義頁面，當你確定了意思以後，按返回按鈕，回到 Launch Center Pro。

並不是每個應用都有它的複雜 URL Schemes，但一般來說，有系統規範的複雜 URL Schemes 的應用都是同類應用中的佼佼者。

基本 URL Schemes 我們猜不中，對複雜 URL Schemes 靠猜就更不靠譜了。支援複雜 URL Schemes 的應用，比如上面提到的 OmniFocus，還有 Due、Clear、Launch Center Pro 等等都會在自己的官網上有專門用來介紹自己的 URL Schemes 的網頁，有些還會提供具體的範例，來幫助使用者理解和使用自己應用的 URL Schemes。這方面的內容我們在後面的查詢部分再詳述。

變形 URL Schemes

在複雜 URL Schemes 的基礎上更上一層樓。

變形 URL Schemes 是指一些應用利用了 URL Schemes 的規則和 iOS 系統的一些內建功能，來拓充複雜 URL Schemes，並使其中需要輸入字元或引數的部分可以預設或輸入後再跳轉，進一步減少步驟。

單純使用 URL Schemes 是無法利用 iOS 內的一些基本功能的，比如說，輸入和剪下板，你用一下 iLauncher 這類的 App 你就知道，即便是複雜 URL Schemes，在跳轉具體功能介面以外也是乏力的，因為你就算知道規則，也沒辦法每次都靈活地輸入和呼叫剪下板，也就是無法應付任何變數，只能使用死的 URL。

所以有的應用就在 URL Schemes 的基礎上，使用了一些方法來呼叫剪下板或給你一個輸入框，做到先輸入內容，然後 URL 的相應部分。

我們這裡用 Launch Center Pro 來舉幾個簡單的例子：

比如用 OmniFocus 的新增任務的複雜 URL Schemes：

OmniFocus:///add?name=任務名&note=備註

你看這裡有兩個變數——任務名和備註。如果你不能自己每次都做到輸入這兩個變數，那這條 URL 實際上沒有意義，它只是會給你生成一個任務，任務名就叫做「任務名」這三個字，備註裡填的就是「備註」這兩個字。所以我們需要能夠輸入任務名和備註的內容，然後填寫到 URL 的相應位置。

在 Launch Center Pro 裡，輸入框表示為[prompt]，你只要在變數部分填入這個輸入框的表述方式，就會在執行動作時出現輸入框讓你輸入內容，所以我們可以把上面那個 URL 改為：

OmniFocus:///add?name=[prompt]&note=[prompt]

這樣在執行這個動作後，會先後出現兩個輸入框，第一個填進去的就是任務名，第二個填進去的就是備註。這樣這個 URL 才對於使用者有了實際使用上的意義。

在 Launch Center Pro 裡最後一條複製了的文字內容表示為[clipboard]，當你想用歐陸詞典直接搜尋你剛才複製好了的不知道意思的單詞的時候，就可以在 Launch Center Pro 裡新增一個這樣的動作：

eudic://dict/[clipboard]

這樣每次開啟這個動作就會直接跳轉到那個單詞的解釋頁面去。

Launch Center Pro 對複雜 URL 貢獻比較大的一個思路是使用 list（列表）。在 iOS 這樣只靠觸控屏互動的圖形介面上，「選擇」比「輸入」速度更快也更省事，尤其是對於那些你經常會輸入的內容來說，從一個列表裡選擇它們要比每次都輸入它們來得有效。比如說我們在使用 1Password 的時候，搜尋某一些服務（如郵箱、Evernote、Dropbox 等）的頻率要明顯地比另一些更高，這時候，把我們搜尋頻率較高的服務列一個列表就比每次都輸入它們更有效率，在 Launch Center Pro 中，在 1Password 裡建立一個列表的 URL 是這樣：

onepassword://search/[list|Google=Google|Dropbox=Dropbox|Weibo=Weibo|輸入=[prompt]]

在這裡簡單說明一下這個 URL 的 List 部分：

[list|Google=Google|Dropbox=Dropbox|微博=Weibo|輸入=[prompt]]

首先有一箇中括號[]，然後括號的最左邊是 list 和一個分隔符 |，這三樣元素聲明瞭這是一個列表。然後是 Google=Google、微博=Weibo 等常用服務，等號左邊，是顯示在列表上的名稱，而右邊是填入 URL 的字元。最後一個 輸入=[prompt]，左邊同樣是列表上的名稱，右邊是前面提到的輸入框。最後這一部分是列表中沒有你想要搜尋的專案的時候手動輸入用的。

Launch Center Pro 的用法還有很多，對變形 URL Schemes 也有其它的貢獻，包括文中提到的這些說明有些並不完整。除了 Launch Center Pro 以外，Drafts 等應用對變形 URL Schemes 也有自己的貢獻，比如把 Drafts 中的一篇筆記的某一行或幾行作為 URL 的元素安插在 URL 之中，也就是 [[line|n]] 這個 Tag 的用法等。但這篇文章的目的不是讓大家完全掌握 Launch Center Pro 和 Drafts，而是全面瞭解 URL Schemes 的各種用法，所以在這裡對這些效率應用的介紹都是點到為止。

x-callback-URL

第一次拓展 iOS 的自動化邊界的創舉，讓你可以跳出去再跳回來，真正的可以串聯多個步驟。

回到上一個操作的應用這件事對我們來說不新鮮，Windows 上同時按下 Alt + Tab 這個快捷鍵你大概不知道做了多少次了。iOS 9 也加入了這個功能：

從一個應用的介面跳轉到了另一個應用後，就會在左上角看到回到上一個應用的字樣，輕觸就能返回到上一個應用。這樣的事情我們在打造自己的自動化操作的時候毫無疑問也會想要做到，前面說過的 Jumpback 是一個選擇，除此之外還有更強力的代替者——x-callback-URL，它還有 iOS 9 上「返回上個應用」這一功能不能代替的地方。但是不可否認的是，x-callback-URL 的使用情境比較少，使用難度卻又比較高。

有了 x-callback-URL，我們就可以結合 Drafts 和 Fantastical 這樣的應用裡一次性新增多個事件；我們還可以結合 Due 跟墨客這樣的應用做到提醒我們發微博，並直接把微博內容儲存好，以便到時候可以一鍵發出去。

我們前面談到的 URL Schemes 都只有一個目的，不管結果是什麼，跳轉完成後就會停留在跳轉後的應用的介面。但在使用 URL Schemes 的時候，執行結果有時候可能成功（大多時候都成功啦，不然你做它幹嗎），有時候可能失敗（比如你用墨客的 URL 搜尋一個不存在的聯絡人），有時候我們也會手動將其取消（比如本來要添加個任務結果想想還是不添加了）。

如果我們還想讓應用根據不同的結果有對應的反應，就要用到 x-callback-URL。比如當上一個 URL Schemes 執行成功以後，我是要回到跳轉前的應用？還是要接另一個動作（接上另一段 URL Schemes，開啟另一個應用的某個功能）？無論是跳轉回上個應用還是開啟另一個動作，只要你在執行完一個 URL Schemes 後還想再利用一段新的 URL Schemes 做下一件事，就要靠 x-callback-URL，它的固定語法是：

在一個 URL Schemes 後面接&x-success，表示前一個 URL 成功以後下一步做什麼；
在一個 URL Schemes 後面接&x-error，表示前一個 URL 失敗以後下一步做什麼；
在一個 URL Schemes 後面接&x-cancel，表示取消前一個 URL 的操作結果後下一步做什麼；
還有一個 &x-source 我們遇到了再說。

現在來舉剛才提到的例子，x-callback-URL 的例子其實都非常複雜，做好心理準備：

用 Drafts 給 Fantastical 一次性新增多個事件

先回顧一下新增一個事件的複雜 URL Schemes：

Fantastical 支援自然語言識別，可以從一句話裡提取事件的名稱和時間，自動新增到預設日曆中，這非常適合使用 URL Schemes 來把任務傳送過去，因為你只要輸入一句「我什麼時候辦啥事兒」（事件日期要照顧下英文語法，事件名稱可以用中文），它就能幫你新增到預設的日曆裡：

fantastical2://parse?sentence=去銀座換 iPhone on this sunday at 15

你可以把上一個 URL 通過 Launch Center Pro 啟用，也可以把空格全都替換成%20以後直接填入 Safari 的位址列：

fantastical2://parse?sentence=去銀座換%20iPhone%20on%20this%20sunday%20at%2015

跳轉以後 Fantastical 裡就會生成一個任務——去銀座換 iPhone，時間是本週日下午三點：

目前為止，實際上用的實際上還都是複雜 URL，具體到 Fantastical 這裡，就是隻能新增一個事件。但我們有時候並不只是加一個事件。比如，大學生在考試的時候時間不統一，每節課每個老師都會在自己的課上來公佈自己這麼課的考試時間，那麼你可以把這些考試和時間先都記錄在 Drafts 裡，然後一併同時發到 Fantastical。

這個過程實際上是把多個傳送事件到 Fantastical 的 URL 綁在了一起，做到一個執行成功以後執行下一個，直到執行完，實現這樣的 URL 就只有 x-callback-URL 才可以，具體的 URL 可以說很複雜，是這樣的：

fantastical2://x-callback-url/parse?sentence=[[line|1]]&add=1&x-success={{drafts4://x-callback-url/runAction?text=[[line|2..]]&allowEmpty=NO&action=Events%20in%20Fantastical-Quick}}&x-cancel={{drafts4://}}

不要被嚇到，我們來逐條分析這段 URL 就能輕鬆讀懂它：

fantastical2://x-callback-url/parse?sentence= 這一句，你會發現比我們剛才用的 fantastical2://parse?sentence= 多了一截兒 x-callback-url/，原因是，當一個 App 的 URL 裡使用了多出來的這一段兒 x-callback-url/，就是在宣告，「各單位注意，我下面的 URL 要用到 x-callback-URL 了。」
緊接著是 [[line|1]]，這一段是 Drafts 的變形 URL，意味取文字中第一行的值。在這個動作中，我們看上面的截圖，第一行是微積分考試那一條，那麼就是把微積分這條先發到 Fantastical 裡。

接下來我們要做的事是，把剩下幾行也自動發到 Fantastical，並且在沒有東西的時候自動停止動作。

所以我們接著來看下一個小部分add=1，這是 Fantastical 的語法，再加一項任務。
下一句的 &x-success= 就是 x-callback-URL 的標準聲明瞭，即當上一步成功後，下一步做什麼。

然後你會看到雙層花括號


           
              
              
            
            相關推薦
			   
            
            
            
 

    

    
    ios開發之檢視控制器(UIViewController)-- 詳解
      
								
								            
						
                
由於本人也是初學ios開發，下面分享一下本人在自學中關於檢視控制器（UIViewController）的多種建立方法的總結（詳解）。

控制器的建立方式


注意： 以下程式碼都是在(Xcode 6. 

  
 

    

    
    iOS 開發實戰－鎖屏介面（手勢解鎖）
      
                
之前寫了一篇關於鎖屏的文章，是密碼鎖屏，可以參照:

關於如何在App後臺啟動等問題，該篇就不再贅述，之專注於介紹核心的實現部分。原始碼在Github上可以獲取。
實現思路
手勢鎖屏是一個3*3的9宮格介面，將每一個宮格用一個Button表示，然後給每一個button附上一 

  
 

    

    
    iOS 開發實戰－鎖屏介面（密碼解鎖）
      
                
改篇是介紹一個類似於支付寶返回Home重新開啟後手勢解鎖，不同的是改篇介紹的解鎖方法是輸入密碼，而不是手勢解鎖，下次有機會在單獨寫一篇手勢解鎖的實戰介紹。
涉及到的知識點
UIWindowAutoLayoutUIButton,UITextFieldAppDelegate開發 

  
 

    

    
    iOS開發筆記－xcode7編譯錯誤之缺少libc++.dylib
      
								
								            
						
                
升級了xcode後.dylib動態庫檔案的新增跟之前不一樣了，需要command+shitf＋g到/uer/lib後搜尋想要的.dylib檔案新增即可。
在與c＋＋混編的時候會因為缺少libc++.d 

  
 

    

    
    iOS URL scheme 詳解
      launch center pro支援的引數主要有兩個，[prompt]文字輸入框和[clipboard]剪貼簿
淘寶寶貝搜尋 taobao://http://s.taobao.com/?q=[prompt]
淘寶店鋪搜尋 taobao://http://shopsearch.taobao.com/brows 

  
 

    

    
    ArcGIS Runtime SDK for iOS開發之－顯示你的位置
      
                
       在地圖上顯示你的位置
       許多iOS裝置如iPod touch、iPad和iPhone提供了裝置的位置資訊。我們知道iOS包含了一個大家都很熟悉的CoreLocation框架，該框架為我們提供了位置獲取的功能，無論是通過Wi-Fi、蜂窩網路還是GPS 

  
 

    

    
    iOS開發筆記－Autolayout自動佈局與UIView動畫
      
								
								            
						
                
使用了Autolaout的檢視的動畫
方法一：簡單的說就是先找到想要變化的NSLayoutConstraint
然後改變constant值    NSLayoutConstraint * _botto 

  
 

    

    
    Android應用開發之所有動畫使用詳解
      factory   技術分享   resource   bsp   phi   顯示   程序   恢復   分享   題外話：有段時間沒有更新博客了，這篇文章也是之前寫了一半一直放在草稿箱，今天抽空把剩余的補上的。消失的這段時間真的好忙，節奏一下子有些適應不過來，早晨七點四十就得醒來，晚上九點四十才準備下班 

  
 

    

    
    B2C電商系統開發app平臺定制詳解
      amp   聯系   良性   幫助   產品   人工   定期   abc   不同   B2C電商系統開發從標品到非標品體現的是用戶從追求功能價值到追求情感價值的變遷。在電商1.0時代，為用戶習慣培養階段，圖書和3C等標品更利於降低用戶的信 任成本。B2C電商app開發，同時，用戶對標品的消費更多追求的 

  
 

    

    
    macOS開發之NSTableView的應用詳解 - 轉
      validate   creat   編寫   移除   分割線   gen   styles   如果   bool   傳送門：https://my.oschina.net/u/2340880/blog/886861
摘要: NSTableView是AppKit中的表視圖控件，是macOS開發中非常重要的 

  
 

    

    
    iOS自動布局框架-Masonry詳解
      asc   github上   區分   block   line   優先級   關鍵字   二次   con   目前iOS開發中大多數頁面都已經開始使用Interface Builder的方式進行UI開發了，但是在一些變化比較復雜的頁面，還是需要通過代碼來進行UI開發的。而且有很多比較老的項目，本身就還 

  
 

    

    
    微享商盟消費返利小程序系統開發（ 程序制作詳解）
      服務   系統   app   小程序   代碼   源碼   
	好用的同時總是少不了一些坑，或許我是才接觸沒多久的緣故吧！


	1.resttemplate fastjson替換jackson


	fastjson是國人的驕傲，符合國人的使用習慣。


	微享商盟消費返利小程序系統 

  
 

    

    
    微擎模塊開發manifest.xml文件詳解
      微擎微擎在安裝或卸載模塊時會根據manifest.xml生成（或刪除）數據庫中相應記錄，並執行manifest.xml裏指定的腳本。<application setting='true'>
	<name><![CDATA[壹應用]]></name> 

  
 

    

    
    2018-06-20-Python全棧開發day19-生成器函數詳解
      IE   示例   yield   概念   一個   print   容易   for循環   __next__   1.生成器函數
　　生成器函數，和普通函數的區別就是，
　　1.在生成器函數中使用yield代替return，而且yield可以被調用多次
　　2.當函數運行到yield時，會保留yield 

  
 

    

    
    3分鐘實現iOS語言本地化/國際化（圖文詳解）
      返回   sch   信息   con   ren   obj   end   xib   standard   
前言

語言本地化，又叫做語言國際化。
是指根據用戶操作系統的語言設置，自動將應用程序的語言設置為和用戶操作系統語言一致的語言。
往往一些應用程序需要提供給多個國家的人群使用，或者一個國家有多種 

  
 

    

    
    Windows 7/8/10 系統下Laravel框架的開發環境安裝及部署詳解（Vagrant + Homestead）
      所在   ntc   報錯   ould   intel   protoc   aliyun   manual   linux   註意！ laravel/homestead box項目地址已經不再是原來的

https://atlas.hashicorp.com/laravel/boxes/homestea 

  
 

    

    
    雙軌團隊獎級制度怎麽開發？直銷軟件詳解
      個人   下滑   獎勵   一個   公排系統   中心   排列   出現   鉆石   一.積分獎
　　A、普通卡;消費800元;每天獎勵5元，連續獎勵64天，共計320元，相當於6折享受產品。
　　B、金卡;消費4000元;每天獎勵24元，連續獎勵100天，共計2400元，相當於4 折享受產品。
　　 

  
 

    

    
    微信小程式開發筆記4—— IntersectionObserver 用法詳解
       
 
  
  
 看微信文件時看到這個很有趣的api，但是官方的文件和例子關於這個api的介紹都是很讓人失望的，所以花了點時間瞭解了以下這個方法，做個記錄，供參考。 
 簡介 
 首先，我的理解是，這是一個觀察器（廢話），它用來監測目標物件與某個參照物的相交情況。什麼是相交情況？通俗的說，就是兩個區域有重 

  
 

    

    
    nginx+lua openresty開發系列-（log日誌詳解）
       
 
  
  
 最近搭建流媒體伺服器，其中涉及到一些http服務api的操作， 之前一直使用的是python django框架來處理這些資訊， 這次編譯的是nginx添加了lua模組， 就想著使用lua來完成這些功能， 減少服務的搭建。好久沒有lua開發了，現在突然發現好多東西都記不住了， 所以就藉著這 

  
 

    

    
    Django 2.0 新款URL配置詳解
       
 
 Django2.0釋出後，很多人都擁抱變化，加入了2的行列。 但是和1.11相比，2.0在url的使用方面發生了很大的變化，下面介紹一下： 
 一、例項 
 先看一個例子： 
 from django.urls import path

from . import views

urlpattern